[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Self-test error codes

BLuRry wrote:

I have a //e enhanced, with a very damaged 8mhz zip chip processor.  I
plan to replace the zip chip with an unmodified 65C02 processor.
Before I do, I wanted to make sure the self-test code wasn't revealing
something else as a problem as well.

After running the self test, I see the following on the screen:

RAM: 0 0 0 0 0 0 0 1

Would this indicate the last ram chip is damaged, or that the processor
is just having trouble reading from that memory line due to a damaged
pin?


I would suspect the RAM, since the processor has to fetch code
using that pin, too, and is apparently is working.


Should I be too nervous about putting in a 65C02 processor that's
faster than 1mhz?  (or is that kept in check by the on-board osc?)


You will have to use at least a 2MHz processor to meet the timing
requirments of the //e.  Anything faster than that will work, but,
of course, won't run any faster than the standard 1MHz.


A side topic of lesser importance: Would it be possible to gut the
parts of the zip chip and make a daughter-card (to plug in to the 6502
socket) housing all the parts of the zip chip?  Does anyone have a
schematic for such a thing, but some random chance?  :-)


Yes, in principle--but I think you'll find that a multi-chip
module is not an easy rework job!

I assume your problems are weak/broken pins.  Using advanced
techniques to gain access to the pin "stubs" and re-attach
them to a machined-pin socket is probably your best bet.

I know there's a physical clearance issue, but it would have
been best if all Zip Chips had shipped in a machined-pin socket,
and even better if, while in that socket, it cleared peripheral
cards...

-michael

Music synthesis for 8-bit Apple II's!
Home page:  http://members.aol.com/MJMahon/

"The wastebasket is our most important design
tool--and it is seriously underused."