Image Map Image Map
Page 2 of 2 FirstFirst 12
Results 11 to 14 of 14

Thread: IBM 5150 Parity Error

  1. #11

    Default

    Quote Originally Posted by shirsch View Post
    Materials science has improved quite a bit since 1981.
    That depends upon what materials you're talking about. The raw PWB's themselves are far more junky now, and many types of discrete semiconductors are much less durable.

  2. #12

    Default

    Quote Originally Posted by shirsch View Post
    I was unable to find a diagnostic ROM for 5150. The only ones I saw were for XT (5160).
    Iím pretty sure they are both the same image for the landmark supersoft roms for 5150 or 5160.

  3. #13
    Join Date
    May 2006
    Location
    Melbourne, Australia
    Posts
    7,072

    Default

    Quote Originally Posted by shirsch View Post
    Nailed it. When all else has been ruled out whatever is left, however unlikely, must be the culprit. Even though the error code indicated a problem with bank 1, I took a chance and removed bank 0, replacing it with sockets. Plugged in 9 new chips and the phantom parity error on bank 1 is no longer showing up. I can only surmise that the POST test logic was being thrown off by a bit error in the first 16k bank. HTH someone else down the line.
    Good work.

    Looking at the circuit diagram and POST source code, I suspect that the failure mode of the bank-0 bit-0 chip was: the RAM chip was always outputting its data (i.e. including times when it is not meant to be). So perhaps the error sequence in the POST was:

    Step 1: POST does check of bank 0. That tests good. (Info: The last test pattern used was 00 hex.)

    BAD: At this point, the 'always outputs data' bit-0 chip in bank 0 is still outputting its data onto the memory data bus, and because the final test pattern used was 00, the chip is outputting a LOW.

    Step 2: POST checks bank 1 (16K) using the first (of four) test pattern, which is AA (10101010). That passes (because bit-0 in the test pattern is LOW).

    Step 3: POST checks bank 1 (16K) using the second (of four) test pattern, which is 55 (01010101). That fails on bit 0 because a HIGH/LOW conflict occurs with: bank-0 bit-0 chip outputting a LOW, and attempted write of a HIGH to the bit-0 chip of bank 1. I.e. On your motherboard, the LOW is 'winning out' on the bit-0 line of the memory data bus. The POST reads back a LOW on bit-0, and so POST reports XOR of [write = 55(01010101)] and [read = 54 (01010100)], which is 01 (00000001).



    BTW: When you earlier experimented by "pulled bit 7 from row 1" (bank 1), you saw '0480' (bank-1 bit-7), not '0481' (bank-1, bit-7 and bit-0). The reason may be that then, the POST only got as far as step 2: POST reported XOR of [write = AA (10101010)] and [read = 2A (00101010)], which is 80 (10000000).

  4. #14
    Join Date
    Aug 2008
    Location
    Burlington, VT
    Posts
    302

    Default

    Wow - thanks for that detailed breakdown! Sounds perfectly reasonable to me.

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
  •