Dead A3000D - not even the LEDs are turning on!

[JoeMuc2006]

Hi folks,

currently I have a friend's beautiful A3000D here for repair - actually for the second time. Back in 2018, I removed the battery and respective damage which didn't appear too bad. The electrolyte spread out to U480 and U477. I desoldered both and found a damaged trace that was restored with a bodge wire on the bottom side of the board. Didn't change the chips though as they looked good enough after a cleanup.
We made a deal that we would switch it on together to celebrate the moment. It took almost seven years to get to that point, and when we switched it on eventually, well, not much to celebrate: the PSU fan roared as usual but nothing else happened. No video, no floppy clicking, not even any of the LEDs turns on which must be due to an issue very early in the chain of steps the Amiga goes through at power-up.
The place we were at that time is an arcade / pinball museum so there was a specialist around for oldschool electronics who advised to replace the Denise socket, and even did that as he had the better-suited equipment. However, we were in bad luck as this didn't change anything.
So the 3000 is back on my bench again and I'm now trying to find out whatever it is.
I re-checked the board for remaining corrosion that I might have overlooked in 2018, and found some through-hole vias that looked rotten so I patched them with wires soldered to the traces on both sides to bypass the through-hole connection. By continuity measurements, this looks okay. Didn't help though.

This is what I can tell about the behavior:

• board is REV9/03
• both LEDs (POWER and SCSI) stay completely off. I have never seen this before. POWER should be dim at least but there is absolutely nothing to see
• keyboard CAPS LOCK LED: sometimes stays on constantly from the moment the unit is switched on and can't be toggled. In other events, it would go off after a second on power-up like usual, and then could be toggled five times until it froze (CIA not processing keybord input and buffer is running full, I guess)
• CPU has 25MHz on pin 6. Not a beautiful square wave though, it's between square and sine wave actually but a 25MHz 5V peak-to-peak signal still with no fluctuations
• power supply outputs all voltages including VID and TICK in an acceptable range even under load
• I know from my own A3000D (that I regrettably sold years ago) that the board won't be happy without the daughter board so it is plugged in during tests of course
• 1MB of FAST RAM is populated in the DIP sockets, using the optional 2nd MB of CHIP RAM. So for CHIP RAM, only the soldered ones are present, making 1MB CHIP plus 1MB FAST. If anything about this were wrong, I would expect at least some color on the screen indicating missing ram, and missing RAM should not cause the LEDs to stay off
• Kickstart ROMs are v40.68, the classic EPROMS with the glass window and sticker across. I have tried my DiagROMs instead but nothing changed
• checked some random electrolytics for their ESR and at least the ones I checked have close to zero Ohms, pretty good for their age
• jumpers are in factory default settings, as far as I can tell
• during tests, nothing but PSU, keyboard, and a monitor are connected

Unfortunately there is no Amiga PCB Explorer available for the 3000D board. The best I could find is https://github.com/iansbremner/ReAmiga-3000---KiCAD.git which is close to the original design at least in the region of interest - I still think all of this is a consequence of the battery leakage so that is where I would put my focus. It is of course possible that there is another additional problem but we know the 3000 worked when it was last used (2002 probably, lol). It was since stored an a good environment but this shelf time gave the battery around 16 years of doing its thing. Again, my assumption is that it could have been much worse but still it's bad enough for a lot of headache and guessing.
Is there any place where I can find a systematic approach to troubleshooting A3000 power-up behavior? Or a list of points where specific voltages or signals must be measurable? I would be very grateful for any advice. If there is anything you want to know, I'll happily contribute accordingly.
Thanks a ton!

Cheers,
Joe

[JoeMuc2006]

Whoa, that was spot-on. Actually all of the POWER LED solder points and traces were breaky. Fixed that so we can now move on. The LED now turns on but stays dim. There's still no video and nothing else.
Unfortunately, I have no monitor to watch the analog 15kHz output. Maybe it does render colors which don't make it through Amber to the VGA port. Well, I'll look more deeply into it.
Thank you for the hint, @mechy! Also for the link, will check it out.

[JoeMuc2006]

you could use a A520 modulator on the 23pin port to get composite out and maybe run that to a tv or capture card? if u had one with a rca composite jack.  prob not a option either i guess?.
Seen alot of cracked led boards like that.

Yip, that's exactly what I was planning. Unfortunately, we are in the process of moving, and the A520 was one of the first things that already moved to the new location, along with the DiagROMs, so I'll have to get that box back. It's Murphy all over.

[JoeMuc2006]

@Castellen: great, thank you so much for all these advice. Will go through them one by one, however, a 15kHz monitor no longer exists, and all the hardware that might be of use now is somewhere else (A520, external flicker fixer, DiagROM) so I'll have to get them before I can continue.
What remains safe to say is that the unit is not booting. There is no floppy activity, and SCSI does not do anything either. Keyboard still behaves as described (buffer running full, input not being processed)
Will keep you up to date!

[JoeMuc2006]

@Castellen Okay, next issue appears to be the (near) absence of _KBRST so apparently you are spot-on another time. So GARY is the master regarding the very early startup, right?
Measuring _KBRST (in a through-hole at the south edge's left side of the DMAC, or U714 pin 1 alternatively) with a scope, I can see that it goes from low to only 226mV, which is definitely in the low realm, when I switch on the power supply. Subsequently, the derived signals stay low, too:

• _CPURST: 86mV measured on a through-hole via south of the CPU
• _RESET (74mV at U714 pin 4)
• _FPURST (93mV at U714 pin 9)

The scope does not show any changes in these voltages once they are established, no ripple or anything. I think if there is no _KBRST, the passives in the circuitry determine the respective baseline voltages but I might be completely off track here.
I think it's no use to check the subsequent steps until this is sorted out because it totally explains why the system is not coming up at all.
Now the question is, how safely is FAT GARY to blame? The replacement would cost around 100 EUR and I want to be sure that replacing it will actually help. No idea how to test the chip on its own though...
Is it viable to set _KBRST, _CPURST, _RESET, and _FPURST to +5V forcefully with a switch after powering up the system to get the chips to go out of their reset state? Just to rule out that it's anything else than FAT GARY? Or would exactly this do any damage to GARY? Is there any prerequisite GARY needs to set _KBRST high which might not be fulfilled?

Additionally, I had a closer look at the voltages the PSU delivers under load:

• +12V rail has 11.7V
• -12V rail has -12.4V
• +5V rail has 4.66V which is a little low. But is that already too low to cause all this trouble?

Other things checked / done:

• PAULA socket renewed (this was done in the arcade shop already)
• re-checked all the soldering we did for missing joints, shorts, open traces
• checked all the jumpers available on the board, and they match the hardware guide presets

By the way, eventually I found this: https://archive.org/details/amiga-hardware-reference-manual-3rd-edition/page/3/mode/1up?view=theater
Going to consult the reference manual to save you all the trouble of guiding me. I promise to report any breakthrough.

Cheers, and thank you again!

[JoeMuc2006]

Meh, that hardware reference manual is not covering the A3000 so not too helpful. Now looking for reasons GARY might inhibit to leave the reset state....
Discovered  a signal _FAIL going towards GARY's pin 56 (POWERUP) in the schematics. I can see in the scope that this is slowly (within almost exactly 1 second) rising to high level, so we can rule that out. Rise time is thanks to the electrolytic capacitor next to it, I think.
Found _BERR to go high immediately.
Measured GARY's CLK90 and the 68030 CLK30, screenshots are attached. Both are sine waves, probably normal but I have no idea and nothing to compare to.

[JoeMuc2006]

Here's the _KBRST waveform from GARY pin 36. It's going from zero to around 270mV only and does not change after that. There is some peak though (hence the >3.46V Pk-Pk measurement), maybe it's going near high very briefly and is then pulled back down...

[JoeMuc2006]

closeup of that _KBRST peak

[JoeMuc2006]

Okay, I took the risk and added a switch across pins 1 and 14 of U713 (sorry I called it U714 before, my bad)
When I power up now and then throw the switch, the system actually comes up! Even the 31kHz Amber output works!
So it seems that GARY is in trouble, not generating _KBRST. I don't know for sure but it seems to be time to replace it.

[JoeMuc2006]

Finally got my DiagROMs back, and the results are surprising. It seems that only little is at fault. The unit boots up on Kickstart 3.1 properly though, and reads disks, so besides DiagROM I can now also use AmigaTestKit. Still need that RESET hack of course, and the keyboard is totally erratic. It won't pick up any key properly, and delay inputs for seconds. Looks mostly random to me. The screenshot attached is from AmigaTestKit and shows what happens after I pressed Q and W subsequently. The result has nothing to do with either key.
I checked with a different keyboard and it stays like that. Using AmigaTestKit in WinUAE, and pushing Q and W individually, one after another, results in $10 $90 $11 $91, which appears expectable, with 10 and 11 being the Q and W keycodes (on pushing down), and $80 added to their values is the "release" code. So something is badly at fault about the keyboard and I need to look into this next.
A FAT GARY was ordered and despite the doubts I'm hoping that it resolves some of the issues.
We tried to insert a load of Toshiba TC514100AZ-60 ZIP-RAMs, only to find out they are most likely incompatible 
Oh, and a lot of DiagROM and ATK tests succeed, for instance, the CIA and timing tests.
I'll keep you up to date.

[JoeMuc2006]

Checked _KBCLK (green) and _KBDAT (yellow) with the scope, and compared to an A2000 it looks like _KBCLK is being pulled down by something in the faulty A3000. The keyboard event is in both cases "Q down" so keycode $10.
Sorry, the timebase is not the same in both screenshots but what is clearly visible is that both signals start high and return to high in the A2000. The A3000's _KBDAT is similar but the same does not apply to _KBCLK which idles at around 1V instead of 5V even outside of keyboard events (probably that's too little to count as high). It reaches the low state properly though.
The connection between the DIN terminal's _KBCLK and FAT GARY pin 44 is fine, measures less than 1 Ohm.
I measured the resistance to ground from _KBCLK without power on, and found that it's ~1.5kOhms when FAT GARY is home, and open line when it was pulled. Curious. Might be another thing pointing towards GARY being the culprit? However, 1.5kOhms is a little too big to pull the signal down that much, right?

[JoeMuc2006]

All right, one step further.
The ODD CIA (U350) is at fault as it seems. Removing the decoupling capacitor for KBCLK didn't do anything but after I swapped U350 and U300, the reset logic works as it should. So if the ODD CIA is actually broken, it might now affect the parallel port but as that port isn't going to be used anyway, I think we can live with that. The keyboard was behaving as it should at first but now it's only briefly blinking caps lock about every two seconds, and not reacting to anything. I'll have to check the signal levels again.
The next issue now is that the board won't boot when a SCSI disk is connected to the internal SCSI bus and no FAST RAM is present (but 2MB CHIP). It's giving me a guru-style red error display with code 87010001 which points towards dos.library not having sufficient memory. I don't remember this for sure but it might be totally normal that using SCSI devices requires at least 1MB of FAST RAM installed. It looks a lot better after I moved the optional second MB of CHIP RAM (DRAM DIP chips) to the appropriate FAST RAM sockets and configured FAST to be 256Kx4. There's no more error now and the HDD can be seen in the boot menu. (not bootable though because it contains only data)
Overall, it doesn't look too bad now. Thank you @Castellen for all your advice, it was really helpful!
I will give another update shortly once anything new has come up. We are planning to build some ZIP2SIMM adapters to use the more convenient SIMM modules. PCB order was placed and module slots are at least available. These adapters have become really rare lately. I'll give a shout if we have any excess units to sell eventually.