Image Map Image Map
Page 1 of 4 1234 LastLast
Results 1 to 10 of 34

Thread: Memory test error with Toshiba T1100

  1. #1

    Default Memory test error with Toshiba T1100

    My trusty Toshiba T1100 is showing it's age.
    I only fire up this machine every few months but just the other day it did the following:
    Upon booting (with a DOS 3.3 disk in A: drive) - the T1100 starts it's memory test. At 448K it gives 1 long beep and shows ERROR 700D6:0A and sits there. I then press RETURN and it gives 1 short beep and then boots fine from A: drive.

    I think I have a RAM problem.
    I opened the case (incidentally it's clean as a whistle inside.) I look around inside for some chips to reseat but most every chip is soldered down. I reseat what I can and buttoned it back up.



    I get the same boot ERROR every time now. It used to finish nicely at 640K and boot DOS.

    So, - I took the T1100 apart again. I pushed and prodded things and nothing helps. I believe when I make the effort to fix this thing, then it should cooperate, but it won't.

    Any suggestions, my fellow vintagians?
    _________________________________________________
    Real programmers don't document.
    If it was hard to write, it should be hard to understand.

  2. #2
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    29,609
    Blog Entries
    20

    Default

    Sounds like a DRAM failure. You can see by examining and playing with the locations around 700D:6 using DEBUG.

    Try the following DEBUG commands:

    F700D:0L10 FF
    D700D:0L10

    (you should see nothing but FF)
    F700D:0L10 00
    D700:0L10

    (you should see nothing but 00)

    If you get anything else, you've got a bad chip (or two). You can rework the board, but it's not something for a first-timer.

  3. #3

    Default

    Thanks Chuck(G)

    I ran DEBUG with the locations you gave me and they produce the word Error in every instance.Then I was digging around and found the original floppy disks and ran the Diagnostics on those.It says I have 448 K.It seems odd that 192 K got 'knocked' out but that's what happened. It's over my head here, but 192 seems an odd number. Why not 128 or something like that? I don't know how the DRAM chips divide up, but 192 K seems odd to me. (But I'm lost here anyway.) Don't guess I'll be correcting this problem, so I'll have to muddle along with 448 K as long as that holds up.

    Darn, and the thing is only about 25 years old! Can't they make computers to last anymore?
    Last edited by Vint; February 3rd, 2010 at 09:02 PM.
    _________________________________________________
    Real programmers don't document.
    If it was hard to write, it should be hard to understand.

  4. #4
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    29,609
    Blog Entries
    20

    Default

    Here's a DEBUG transcript of me doing exactly what I said above. Note that DEBUG produces a "-" prompt. Spaces do matter.
    Code:
    D:\>debug
    -F700D:0L10 FF
    -D700D:0L10
    700D:0000  FF FF FF FF FF FF FF FF-FF FF FF FF FF FF FF FF   ................
    -F700D:0L10 00
    -D700D:0L10
    700D:0000  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00   ................
    -Q
    
    D:\>

  5. #5
    Join Date
    Dec 2005
    Location
    Toronto ON Canada
    Posts
    7,044

    Default

    Quote Originally Posted by Vint View Post
    Thanks Chuck(G)

    ...It seems odd that 192 K got 'knocked' out but that's what happened. It's over my head here, but 192 seems an odd number. Why not 128 or something like that? I don't know how the DRAM chips divide up, but 192 K seems odd to me. ...
    192=128+64, so yeah it is 128 x 1 1/2

  6. #6

    Default I'm catching on now

    Thanks again for walking me thru this Chuck(G)

    As you can tell I'm not a Debug whiz. Now that I've keyed in correctly per your example I have the following -



    So, if that works correctly, I wonder what's producing this error?




    Also, by MikeS tally - I now see where the 192 comes from - Thanks
    _________________________________________________
    Real programmers don't document.
    If it was hard to write, it should be hard to understand.

  7. #7

    Default

    Quote Originally Posted by Vint View Post
    Thanks again for walking me thru this Chuck(G)

    As you can tell I'm not a Debug whiz. Now that I've keyed in correctly per your example I have the following -

    If you look carefully, the "FF FF FF..." row about halfway through starts displaying "F0 F0 F0...". That looks like to me where the memory is bad. If I'm not mistaken (please correct me if I'm wrong), the debug test is writing all 1s to all of the addresses in the RAM and reading them back, then writing all 0s and reading them back. So it looks to me as though you only have about 3/4ths of your RAM operational.

    Kyle

  8. #8
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    29,609
    Blog Entries
    20

    Default

    Yup, the "F0" tells all. Most likely, you've got a failed DRAM chip. Since I don't know what kind of DRAM your system uses, it's hard to figure which DRAM chip it might be. But you wrote 1's in the lower 4 bits of each byte and more than half of them came back 0's.

    And the error starts at--are you ready for this?--physical address 700D6.

    There you go...

  9. #9

    Default

    Quote Originally Posted by Chuck(G) View Post
    Yup, the "F0" tells all. Most likely, you've got a failed DRAM chip. Since I don't know what kind of DRAM your system uses, it's hard to figure which DRAM chip it might be. But you wrote 1's in the lower 4 bits of each byte and more than half of them came back 0's.

    And the error starts at--are you ready for this?--physical address 700D6.

    There you go...
    Why doesn't it use the other hex characters to show exactly which bits aren't being displayed? You say that if more than half of them come back as 0s, it shows a 0.

    I guess I'm just used to the memory debugger my SWTPC uses!

    Kyle

  10. #10
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    29,609
    Blog Entries
    20

    Default

    Quote Originally Posted by antiquekid3 View Post
    Why doesn't it use the other hex characters to show exactly which bits aren't being displayed? You say that if more than half of them come back as 0s, it shows a 0.

    I guess I'm just used to the memory debugger my SWTPC uses!
    No, I didn't say that. I said: "But you wrote 1's in the lower 4 bits of each byte and more than half of them came back 0's."

    In other words, you wrote 16 bytes with all bits set to "1". Over half of those 16 bytes (10 to be exact) did not show values with the lower 4 bits set to "1".

    Merely stating the obvious...

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •