On Mon, 23 Mar 2020, Brent Hilpert via cctalk wrote:
> I have 4000/90 which behaves funny. It only
starts, after switching on
> twice. The first time, all LEDs stay on, flipping the switch off/on, it
> boots happily.
[...]
I've experienced behaviour like this in an
Apple-something.
It related to a dead RTC/boot-ROM battery. I figured it out (years ago)
but now forget the exact mechanistics, but it was along the lines of the
first power-on leaves enough charge in a capacitor for the subsequent
power-on to see the RTC/ROM as at least 'valid', albeit not 'correct',
if you get my drift.
That's just a suggestion/possibility - I'm not acquainted with the
4000/90 specifically.
A correlation with an expired DS1287A chip seems plausible, though not
fully verified.
I have a 4000/90 that seemed dead having been stored alive and left
unused for a prolonged period. The symptom were all LEDs steady lit after
power-up, as if the CPU has failed to execute any instructions after
coming out of reset. Multiple consecutive power-ups didn't help.
The 4000/90 has a couple of potential reasons as to why its CPU would not
start executing:
- a broken CPU (obviously) or chipset,
- flash ROM corruption (with no write-protection provided regrettably all
too easy to happen),
- bitfile ROM corruption (used with the CEAC and SQWF FPGAs in the /90
only; replaced with ASICs and the ROM removed in the /90A and the /96),
- power-good signal not asserted by the PSU.
NB the LED latches sit on EDAL (as does the DS1287A), so if the CEAC FPGA
does not come up they won't budge even if the CPU executes from main flash
ROM.
If I were to believe documentation, I'd expect the very first couple of
instructions executed from the reset vector to poke at the LEDs rather
than the DS1287A to indicate execution has started, but I haven't actually
looked at the code there (I should have!). I didn't therefore consider
the DS1287A, especially as it was already dead in that machine before it
was left to sit.
It appears to make a difference however whether the DS1287A has been only
discharged enough not to keep the contents across a power down or whether
it has been indeed deeply discharged (the chip obviously continues to suck
power from its lithium cell even past the point it cannot hold contents
from anymore). I experimented with replacing the chip
with a couple of
spares, but it didn't help. Frustrated I put the machine
aside and left
it untouched for a couple of months.
I came back to it once again, disassembled, reassembled, disassembled
again and verified the tantalum capacitors in-circuit (all measured fine)
replaced the PSU, replaced the DS1287A a couple of times again, and then
suddenly with one of the replacement DS1287A chips it started to work.
I tried the chips that didn't again and oddly the machine continued to
work, and kept working on many occasions for a couple of years more until
I last checked it sometime last year. Hopefully it still does (and I plan
to replace the DS1287A once expired with one of my reworked chips as shown
here: <ftp://ftp.linux-mips.org/pub/linux/mips/people/macro/ds1287/>; so
far I only did the replacement with a couple of DECstation 5000 systems),
however I cannot verify that now due to the current chaos in Europe making
travel impossible and keeping me away.
I need to warn you too that the H7819 PSU the 4000/90 uses also suffers
from the quaternary ammonium salt system issue with
some capacitors used,
so it's at risk of developing catastrophic leaks (I
don't remember offhand
if the capacitors are safely upside down as in the H7821, and I can't
easily check right now; I highly suspect it is the case though, so try
keeping the machine in the right position while in storage). Furthermore
much of the contents of this PSU has been treated with hot melt, making
any diagnosis or repair a real pain. I would recommend examining the PSU
just in case anyway. It might be on the verge of giving the power-good
signal.
I realise I may have added confusion rather than helped, but at least
there may be hints as to the causes for odd behaviour and a hope for full
recovery.
Maciej