I have finally cleared the decks enough to get back to a brain-dead LC II that came my way.
It has never booted. Back when, I did some quick poking around, saw some signs of capacitor death, then recapped the PSU and the logic board and cleaned it up. Still: after power on, all voltages are good, but no chime, no disk accesses, no video.
(I checked the speaker connection, and it was OK. I haven't checked the modem port, but I presume it's cold; see below.)
There was an empty socket for the FPU and on the backside, it looked as if something sharp had been at work: some of the pads had gouges and solderballs filling their depressions. Possible layer-to-layer opens or shorts? Solder bridges on the top side under the socket? I removed the socket and the excess solder, then spent a dull afternoon continuity/short testing address and data lines from the CPU to ROM, CPU to RAM, CPU to GLU. Nothing found - but it was tedious, error-prone work and should be repeated, for confidence.
I shelved it until today. I studied up on the schematic and scoped the address lines to the ROMs. A2-A8 all go high together briefly after power-up and then.. go low. Forever. Unless I am mistaken, the CPU is not accessing ROM.
I instrumented the Apple-customized 34064 and the Egret, betting that something was holding the system in reset. I had already checked the 68030 /RESET line but, when lacking a theory, one must double-check. At power-on, the PSU 5V supply rises steadily. When it passes 1.1V or so, the 34064 raises VREF to 1.2V and keeps it there. When the PSU 5V gets to about 3.4V (the VBAT is 3.67V), the VRTC outputs begins to rise from VBAT to track the PSU. When the PSU 5V gets to about 4.4V, the 34064 asserts 5VDETECT to the Egret. Egret raises nFAST_RESET and then raises nRESET.
In short, the 34064 and EGRET all seem to be playing fair.
My plan now is to read the `030 User Manual further and hope that additional ideas come to light.I seek fresh ideas on why the CPU might not be proceeding with instruction fetch. I have not scoped any of the bus control lines (DSACK etc) and so it's a little early to be asking, but if anyone sees a pattern here ..
It has never booted. Back when, I did some quick poking around, saw some signs of capacitor death, then recapped the PSU and the logic board and cleaned it up. Still: after power on, all voltages are good, but no chime, no disk accesses, no video.
(I checked the speaker connection, and it was OK. I haven't checked the modem port, but I presume it's cold; see below.)
There was an empty socket for the FPU and on the backside, it looked as if something sharp had been at work: some of the pads had gouges and solderballs filling their depressions. Possible layer-to-layer opens or shorts? Solder bridges on the top side under the socket? I removed the socket and the excess solder, then spent a dull afternoon continuity/short testing address and data lines from the CPU to ROM, CPU to RAM, CPU to GLU. Nothing found - but it was tedious, error-prone work and should be repeated, for confidence.
I shelved it until today. I studied up on the schematic and scoped the address lines to the ROMs. A2-A8 all go high together briefly after power-up and then.. go low. Forever. Unless I am mistaken, the CPU is not accessing ROM.
I instrumented the Apple-customized 34064 and the Egret, betting that something was holding the system in reset. I had already checked the 68030 /RESET line but, when lacking a theory, one must double-check. At power-on, the PSU 5V supply rises steadily. When it passes 1.1V or so, the 34064 raises VREF to 1.2V and keeps it there. When the PSU 5V gets to about 3.4V (the VBAT is 3.67V), the VRTC outputs begins to rise from VBAT to track the PSU. When the PSU 5V gets to about 4.4V, the 34064 asserts 5VDETECT to the Egret. Egret raises nFAST_RESET and then raises nRESET.
In short, the 34064 and EGRET all seem to be playing fair.
My plan now is to read the `030 User Manual further and hope that additional ideas come to light.I seek fresh ideas on why the CPU might not be proceeding with instruction fetch. I have not scoped any of the bus control lines (DSACK etc) and so it's a little early to be asking, but if anyone sees a pattern here ..
)
