IBM Memory sidecar debugging

Hardware questions and modifications

IBM Memory sidecar debugging

Postby Brutman » Thu Feb 18, 2016 10:01 pm

(Paging Alan)

I'm trying to recover some of my lost brain cells. I figured debugging a memory sidecar should be easy ...

This is a 128K IBM sidecar with 16 64Kx1 chips and a DRAM controller for refresh. The machine does not recognize the sidecar because the sidecar is corrupting data. Here is the pattern I have found so far:

Write all 0x00: All is good.
Write all 0xFF: All is good.
Write all 0x55: Readback shows 0x51. Bit 2 (the third bit from LSB) has been dropped. Great - stuck bit!
Write all 0xAA: Readback shows 0xAE. Bit 2 (the third bit from LSB) is on when it should be off - uh oh, not stuck?

Interesting. It's not a bit stuck on or stuck off. So now I start looking at what the neighboring bits are doing and I try some more combinations:

Write all 0xF8: Readback 0xFC. Bit 3 gets toggled on again, so it seems to follow bit 4.
Write all 0xF3: Readback 0xF7. Bit 3 gets toggled on again, but bit 4 was zero. It followed bit 2?

(Many more patterns tested ...)

To make a long story short, the problem is always bit 3. But I can't nail down the pattern of corruption - it's not a nice stuck on or stuck off. It seems to be sensitive to other bits being on. I've been writing 256 bytes at a time. If I read back the same pattern the affected bytes will change slightly, but it's always bit 3.

So what's failing here? Is the individual DRAM chip that holds the contents of bit 3 bad? I can't tell from this. Given that the nature of the problem changes with the bit pattern I have to suspect the DRAM controller. My understanding of DRAM controllers is that besides doing the refreshing for the chips, they are also what the CPU sees on the bus. ie: the chips are hidden behind the controller because the CPU can't have direct access due to the DRAM refresh cycle.

The DRAM controller is a DP8409AN. There is other logic on the board but it looks to be mostly glue logic for interfacing to the system bus and address decoding logic.

Any thoughts on where to look next? I've posted a hi-res image of the board here in case there are other suspect components I should be looking at: http://www.brutman.com/pics/IBM_memory_sidecar.jpg



Mike
Brutman
Site Admin
 
Posts: 952
Joined: Sat Jun 21, 2008 5:03 pm

Re: IBM Memory sidecar debugging

Postby alanh » Thu Feb 18, 2016 11:13 pm

I'm feeling deja-vu. Have you talked about this before?

If you write a pattern and read it back multiple times, is the read back always consistent? If so, it points to a problem during the write cycle. If not, it points to a problem on the read.

Are there any addresses where it reads back correctly? Since the memory is organized as 16 chips x 1 bit, so there are 8 pairs of chips that are ganged to the same 8 bits. So if all addresses have the same problem, it's likely in the common data path and not any one chip.

The data path isn't buffered through the controller. I simply creates the multiplexed row/col address bus and corresponding strobes.

Finally, it might not be the data bits at all. I would try writing a deterministic pattern to all addresses - like the 16-bit offset of each word to each word. Then when you read it back, you might find an incorrect address aliased to an address to which is doesn't belong.
alanh
 
Posts: 258
Joined: Tue May 10, 2011 6:52 pm
Location: Atlanta, GA

Re: IBM Memory sidecar debugging

Postby Brutman » Thu Feb 18, 2016 11:22 pm

No, this is new for me. I want to learn to start fixing this stuff.

The reads are not consistent; back to back reads can vary.

The machine does work with a different sidecar so hopefully it is a data path problem on the card. I wish I had schematics but it's simple enough to work through it. What exactly is the data path if the controller is not on the path? Just latches or glue logic to attach the card to the bus?
Brutman
Site Admin
 
Posts: 952
Joined: Sat Jun 21, 2008 5:03 pm

Re: IBM Memory sidecar debugging

Postby Brutman » Fri Feb 19, 2016 10:46 pm

So I read up on DRAM controllers and DRAMs and then started tracing the circuit. After about an hour I noticed that the sidecar connector was missing the copper in the socket were pin B2 would go. And of course, wouldn't you know it, that corresponds to Data2, the screwed up bit.

The corruption was the damn thing is just floating!

Time to get some sidecar connectors.
Brutman
Site Admin
 
Posts: 952
Joined: Sat Jun 21, 2008 5:03 pm

Re: IBM Memory sidecar debugging

Postby alanh » Fri Feb 19, 2016 11:03 pm

If someone can nail down a supply, I'm ok buying a hundred or more to make sure we have a supply.
alanh
 
Posts: 258
Joined: Tue May 10, 2011 6:52 pm
Location: Atlanta, GA


Return to PCjr Hardware

Who is online

Users browsing this forum: No registered users and 1 guest