Re: Help me restore my //c to working order!

[dempson@actrix.gen.nz (David Empson)]

Andrew <abc4e@mtmail.mtsu.edu> wrote:

> On Tue, 10 May 2011 13:37:34 -0700, Osgeld wrote:
> 
> > On May 10, 9:27 am, "Bill Garber" <willy4...@comcast.net> wrote:
> >> I'd say that if you are getting a different RAM error each time that
> >> it's not a DRAM itself, but possibly a loose connection on the MMU,
> >> Memory Management Unit, or even the CPU. If these are socketed, you
> >> might try lifting them slightly and pressing them back down to score
> >> the pins so that they make better contact. This is one of the pitfalls
> >> of socketed ICs after they sit around for a time. Let us know how you
> >> make out.  :)
> > 
> > I agree remove and re-seat any socketed chips, though there is only a
> > few in a //c
> 
> Thanks guys, I reseated the CPU, MMU, and, um, whatever the one to the
> left of the MMU is. No dice unfortunately. :( On the bright side, I 
> didn't break it any further as far as I can tell. I guess maybe the MMU
> itself is actually bad?

Could also be a dry joint on one of the sockets (or soldered chips), or
a broken or shorted track on the motherboard.

Given that the self-test is running OK, the MMU must be working well
enough to decode the ROM addresses. The RAM is also partly working,
because the self-test is able to display the error message.

The //c has two banks of eight 64K x 1 RAM chips. One bank implements
main memory and the other bank implements auxiliary memory.

The error implies that random data is being read back from all eight RAM
chips, but probably only in a limited range of addresses, since the text
buffer (in main memory) is OK (at least for writing). I expect zero page
and stack in main memory are reading and writing OK, otherwise the self
test might not have been able to get far enough to display that message.

The RAM uses a multiplexed address with row and column strobes. I expect
it will have 8-bit row and column address, and that means the address
going to main RAM must be mostly OK, because a fault on a high order
address pin would have caused errors within each page of memory, which
would affect the appearance of the text screen and the error message.

Therefore the most likely scenarios are (in order):

- A faulty buffer chip (or its control signals) which sits between
auxiliary RAM and the data bus. (I haven't confirmed whether there is
such a chip - no circuit diagrams handy at present.)

- A fault with the chip select or read/write control signals getting to
auxiliary RAM chips but not the main RAM chips.

- A fault with the address signals getting to auxiliary RAM chips but
not the main RAM chips.

- A fault affecting reading from main memory but not writing to it.

- An internal MMU fault (localised to accessing one portion of the RAM).

Does anyone happen to know if the //c self test displays different error
messages for main and auxiliary RAM faults? That would help to narrow
down the problem.

-- 
David Empson
dempson@actrix.gen.nz