• Please review our updated Terms and Rules here

IBM PC XT 5160 RAM Errors on Bank 0 - It's not RAM?

booboo

Experienced Member
Joined
Sep 13, 2009
Messages
172
Location
Dallas, Texas, USA
I'm diagnosing this XT 5160 (64KB-256KB systemboard) that won't post. After replacing the IBM BIOS with Rudd's diag ROM I get a screen and it proceeds to test. It's failing in Bank 0 (2KB) with all chips except Parity shown bad bits. See screen... I've replaced with known good RAM and still have same issue. What potential problems could be causing this? I have a known good power supply and CGA card powering this motherboard.

20231111_190723982_iOS (Small).jpg
 
It's failing in Bank 0 (2KB) ...
Address wise, the screenshot informs us that
- STEP 1: Address 00000 tested good.
- STEP 2: Address 00001 tested bad. (At which point, testing stopped.)

... with all chips except Parity shown bad bits.
In regard to the parity bit, the user documentation includes, "If there is a faulty RAM chip for parity, it will not be shown until all faulty RAM chip/s for data (in the same bank) have been rectified."
That is because it is not possible to test the parity bit when data bits are bad.
So ignore the indication that the parity bit is good.

( Given that it is misleading, I think I might modify the diagnostic not to show the parity bit if there are any bad data bits. )

I've replaced with known good RAM and still have same issue. What potential problems could be causing this? I have a known good power supply and CGA card powering this motherboard.
Had the failure shown as 'all bits at address 00000', then I would have said that there were quite a few possibilities, but it is quite odd (pun unintended) that address 00000 passes and address 00001 fails on all bits.

Is that always the case when you run the diagnostic, or does the address change sometimes ?

Do you have a logic probe ?
Do you have a logic analyser ?
Do you have the ability to create a U18 ROM if I pass you custom code to go into it ?
 
Thanks @modem7 for the quick review. It's always the same address, regardless of attempts or changing RAM. I've removed all RAM from banks 1, 2, and 3, only leaving bank 0. I do have the ability to burn a U18 ROM (I just burned the Rudd's code to run these diags), so love to get some code to as you suggested.

No logic tools, really. I did meter out all A0-A7 lines across all Bank 0 chips and they are all connected. Same with Vcc, RAS, CAS, Write. DIN and DOUT is not connected across the bank.
 
1. Is this a motherboard that was working for you, then failed, or is this a motherboard that you acquired in a faulty state ?

2. If you remove one of the RAM chips in bank 0, does the failing address change to 00000 with the removed chip shown like at [here] ?

3. Do you have one of the devices shown at [here] ?
 
  1. The board came as-is to me, without history. So don't know how long it hasn't worked correctly
  2. I've actually been looking at the various options of the mem test:
    1. I removed all RAM and the error was same as the initial picture, *EXCEPT* that the error was on 0000:0000
    2. I removed a single chip and then the error was like the picture you reference, see below. The error is on 0000:0000 instead of 0000:0001.
    3. The rest accurate documents the missing chip. I can remove / move the missing chip and the error follows the location.
  3. I'll see if can borrow such a device locally, but I don't.
1chip.jpg
 
Hello,

I used @modem7's excellent site to diagnose the faulty RAM on my Model 5160. Depending on the diagnostic ROM you are using, I found it convenient to use my phone to record video of the RAM checks running so I could keep track of all the errors.

I have some videos here of the troubleshooting if you're interested - lots of detail in the "video description" as well:



I've now upgraded the 256KB board to be a 640KB board (thanks again to @modem7) ... and was working fine but now it refuses to see the keyboard ... it's on the list for me to look into ... I'm not hijacking your thread ;)

Brett.
 
The board came as-is to me, without history. So don't know how long it hasn't worked correctly
And we don't know if someone attempted a repair, and 'broke' things in the process.

As an example, someone came on these forums with a faulty 5150/5160 motherboard, and it turned out that someone had fitted the wrong type of RAM chip in one of the sockets. We can rule that out in your case because you "removed all RAM from banks 1, 2, and 3, only leaving bank 0" and "replaced with known good RAM and still have same issue."

Presumably, those known-good chips are 4164 class, being that you have a '64 - 256KB' motherboard.

I've actually been looking at the various options of the mem test:
  1. I removed all RAM and the error was same as the initial picture, *EXCEPT* that the error was on 0000:0000
  2. I removed a single chip and then the error was like the picture you reference, see below. The error is on 0000:0000 instead of 0000:0001.
  3. The rest accurate documents the missing chip. I can remove / move the missing chip and the error follows the location.
That informs me that when Ruud's Diagnostic ROM (RDR) tests motherboard address 00000, that an address somewhere in RAM bank 0 is being successfully tested.

When RDR goes to test motherboard address 00001, something is very wrong. For example, maybe (repeat: maybe) a ROM address or an 'empty' address is somehow being hit.

3. Do you have one of the devices shown at [here] ?
I'll see if can borrow such a device locally, but I don't.
You should look to acquire one anyway. They are cheap, and used as the output device for some of the test code for U18 at [here]. When I write custom test code for U18, the device is my preferred output device, but alternately, I can send beep patterns to the speaker, assuming that the associated circuitry is working. Do you hear the short-long-short beep sequence from the speaker when RDR starts ?

I can also output to a serial terminal (or terminal program) via a serial port at 3F8h (the standard I/O address for the first serial port). I will be, very shorty, releasing a new version of RDR that does that.

And a logic probe is something else you should get. Based on the information that I have presently, a logic probe will probably be required down the track, i.e. I send custom ROM code to you (via DM) and get you to report what the probe shows on certain IC pins.
 
Hello,

I used @modem7's excellent site to diagnose the faulty RAM on my Model 5160. Depending on the diagnostic ROM you are using, I found it convenient to use my phone to record video of the RAM checks running so I could keep track of all the errors.

I have some videos here of the troubleshooting if you're interested - lots of detail in the "video description" as well:

I've now upgraded the 256KB board to be a 640KB board (thanks again to @modem7) ... and was working fine but now it refuses to see the keyboard ... it's on the list for me to look into ... I'm not hijacking your thread ;)

Brett.
Thanks, appreciate the video! Yeah, the issue here is that it's not a single (or even multiple) RAM chip failure. The entire bank 0 keeps failing in the testing, even replacing the entire bank 0 with known good chips. I need to perform the tests above from Modem7 but I suspect there's something else amiss with this motherboard.
 
Presumably, those known-good chips are 4164 class, being that you have a '64 - 256KB' motherboard.

When RDR goes to test motherboard address 00001, something is very wrong. For example, maybe (repeat: maybe) a ROM address or an 'empty' address is somehow being hit.

Do you hear the short-long-short beep sequence from the speaker when RDR starts ?

Thank you. To your points: (1) Yes they are known good NEC 4164 -120 chips. Stolen from a six-pack board from a 5150 :). (2) Yes, I get the short-long-short beeps from RDR program.
 
Possible problem with A1 decoding? Unfortunately, the test stops and we don't know if the problem would persist with addresses 00003, 00005...etc.
 
Possible problem with A1 decoding? Unfortunately, the test stops and we don't know if the problem would persist with addresses 00003, 00005...etc.
Reference diagram at [here].

Ruud's Diagnostic ROM is executing okay, and so we know that A1 is functioning from the CPU through to the external data bus.

If we hypothesise that something is wrong with A1 in the row/column multiplexer for the motherboard RAM banks, it just means that different-to-intended RAM addresses in the bank 0 chips will sometimes be read/written.
In that case, it would be the 'Testing RAM - Address' test that is expected fail.

( Bank 0 is still the target because A1 does not go to the RAM bank select logic. )

Nonetheless, sometime today, I will DM to the OP some test code that checks for the first, say, 10 addresses.
 
Another hypothesis I see is:
- When motherboard address 00001 is being addressed, something else besides the RAM subsystem is putting data onto the data bus.
- The RAM subsystem is losing the 'tug-of-war' in that bus contention.
- If the U18 ROM is within scope of the problem, it is wining the 'tug-of-war' in that bus contention. (Ruud's Diagnostic ROM is executing okay.)

Some possible causes:
- Faulty ISA card.
- One of the address decode circuits on the motherboard has gone faulty in a particular way.
- Faulty chip on the motherboard, driving the data bus when it shouldn't be.

Is the video card the only card that you have plugged in ?

Perhaps we are getting ahead of ourselves. I will later DM to you some test code to establish whether or not the symptom is odd/even related.

Irrespective of the result, I anticipate asking you to later run other test code that reads motherboard address 00001 in a loop, and getting you to look at certain IC pins using a logic probe.
 
Thank you for all the attention! No other ISA cards are on the system, I tried also a 16-bit VGA (that supports 8 bit systems) and wouldn't POST; and because RDR doesn't support VGA then I took it out.

I'm heading out of town for work for a week, then thanksgiving is upon us. So don't rush with the test code (and I'm going to be only monitoring w/o access to the system for 2 weeks). :(
 
Back
Top