A1200 post electrolyte damage: Alice overheating?

[screwtop]

Hi team,

I have an A1200 (PAL, rev 1D.4) that's giving me trouble. I bought it used about ten years ago, and it clearly had an issue with leaking capacitors by the time I bought it. There was missing audio (one channel, IIRC), and evidence of leaked electrolyte around the 22 uF and 47 uF SMD caps. I removed those, washed the board thoroughly several times (including a couple of dishwasher cycles), and replaced them. I also identified and repaired a couple of PCB tracks and a via that had dissolved away under the right audio coupling cap (I desoldered the keyboard connector to check under there too). The system would then run, but only for about a minute before going haywire, with junk (corrupted repeating patterns) being displayed on the screen and eventually a reset loop. Noting that the Alice chip gets rather hot, I suspected thermal issues. I found that keeping Alice cold with freeze spray would allow the machine to keep running (for at least ten minutes). I reflowed the solder around all the Alice pins, but that didn't help. A small VGA heat sink on Alice was also not enough to keep things working. I put the board away.

I got the machine out again recently to troubleshoot again. I recapped it again (replacing all electrolytics this time, both SMD and through-hole) and checked the earlier repair I'd done. It doesn't look too bad, and no further damage seems to have occurred due to the 100 uF or 10 uF caps. I now also have a thermal camera and a set of DiagROM chips. At some point I'd also removed E123C (7 MHz) and E125C (7 MHz quadrature); E121C and E122C (CPUCLK/CPUCLK_A) were not populated from the factory.

The symptoms now are the same as before: it boots and runs OK for about a minute, then video and audio go crazy, and resetting just gets stuck in a reset loop.

I noticed that the PLA/GAL chip XU9 next to Alice also gets rather hot (much hotter than my other A1200), but I gather these may run at very different temperatures depending on the technology used. I put a small heatsink (for a stepper motor driver chip) on XU9 but that alone didn't seem to help.

With a chunky aluminium heat sink (but no fan) on the Alice chip, the machine can run long enough for DiagROM to perform some useful tests. Memory checks out fine: no errors after several passes. Interrupts and CIA tests OK. But some of the video tests don't run (not sure if that's an issue with my DiagROM).

I've read other reports of Alice running hot and causing instability. I wondered if the conductive slurry of electrolyte and copper could have allowed +/-12 V to leak where it shouldn't, causing some permanent damage. I've read other reports of certain DRAM lines going low-impedance and drawing too much current, or capacitors going losing their resistance when warmed up. I also wonder if there could be broken PCB tracks where I can't see them, maybe underneath Alice or XU9.

I'm open to suggestions at this point. I have a 50 MHz oscilloscope, so can potentially investigate clock and data signals. I wondered if removing or replacing DRAM chips might be worth trying, or simply replacing Alice and/or XU9, if I can source them. I don't have a hot air rework station, but can borrow one.

Thanks for reading.

[F0LLETT]

Have you checked E127R?

Some boards have an issue, that causes this type of issue. If its a ferrite bead or resistor, remove it and short it out.

[screwtop]

Ha, I'd just been reading about E127R! It appears to be a small ferrite on this board, but I've bridged it and the machine still goes nuts after about a minute with no heat sink on Alice. Might the quadrature versions of that clock (and the *_A copies?) need similar treatment?

When looking closely at the board, I thought I saw signs of cracked/dry solder joints on a couple of the 0-ohm resistors to the right of Alice (plausible given the thermal cycling in the area). I'd already got my hopes up, but after reflowing these (and a few others nearby), no improvement.

Just for reference, both Alice and UX9 run at about 35 K above ambient, so about 55°C (131°F) at room temperature (I was testing in a very cold garage!). I should also have mentioned that I'm doing all of this with no expansion cards, FDD, or IDE storage.

After reading some posts on linuxjedi.co.uk, I wonder if a PiStorm32 could be worth getting (for the diagnostic potential alone)...

[screwtop]

Also meant to mention: DiagROM starts writing random binary garbage to the serial port when the glitch happens. Things seem to go haywire when Alice's case temperature reaches 40-45°C (104-113°F).

[screwtop]

I've done some further investigation and at the instant the glitching starts, the CCKQ clock signal goes bad. This signal is generated by Alice, which is reinforcing my idea that some kind of damage to Alice's internals could be the root cause. The CCKQ signal still has the correct shape and frequency, but the level drops to about 2 Vp-p. I'll want to rule out bad passives on the signal - I could try removing E128C and E129C, and perhaps even the resistors if necessary to isolate things.

[screwtop]

Also, actively cooling Alice once the glitching has started doesn't restore the CCKQ clock signal to normal. Once it goes bad, it apparently stays bad, and you have to power off the machine for a while before it will restart usefully.

[screwtop]

A further update:

Isolating Alice's CCKQ output by removing E128R and E129R does not improve the quality of the CCKQ signal at the output pin, which starts out OK at cold boot, but drops suddenly to about 2 Vp-p after about a minute (sometimes less, sometimes more). Therefore, it doesn't seem to be a problem with anything else attached to the CCKQ line such as EMI filter capacitors or other chips in the chipset.

Following some tips from Jens that I'd read on the icomp.de forums, I was also interested in the condition of Alice's Vbb pin 55, which is stabilised externally by C2X. Jens advocates adding a further 10 uF in parallel with C2X to bolster the bypassing. I believe Vbb is normally supposed to be about -3 V, but on my problem 1200 it's only -1.1 V at cold boot, and what's really interesting is that Vbb drops to -0.1 V at the same time as CCKQ goes bad and the glitching starts. (DiagROM continues to run OK via serial port, however.)

Next step will be to remove C2X and test it, and fit a larger value MLCC cap if I can find one.

I'll also want to compare the Vbb readings against my working A1200. There isn't much information online about the Vbb pin, and it was apparently a later addition in the history of the Agnus family.

[screwtop]

On my good A1200 (a PAL rev 1D.1), Alice's Vbb pin reads -3 V, which I've read is the expected value. The -1 V collapsing to -0.1 V on the bad board certainly looks unhealthy.

I've not been able to mess with C2X yet, but some thermal imaging revealed that on the misbehaving board, Alice and XU9 (the GAL next door) run respectively about 10 K and 15 K hotter than their counterparts on the good board. (That's under the same conditions and running from the same PSU, and with a small heat sink on XU9 on the bad board).

[screwtop]

Today's experiment: supplying Alice's Vbb from an external source. I wanted to test the behaviour of this 1200 without the +/-12 V supplies (only +5 V), so I wired up a connector and hooked it to my bench power supply. Since I have a second output on this supply, I set it for 3 V below the ground for the 5 V supply, and connected it to the Vbb end of C2X (which I'd also replaced with a 10 uF electrolytic cap with a 100 nF ceramic in parallel).

Results: Running without +/-12 V makes no difference to the glitch, the health of Vbb or the CCKQ clock signals. Running with the extra capacitance also did not help noticeably. But supplying a negative voltage to Vbb seems to keep the CCKQ signal good and allows the system to keep running! If Vbb rises above about -0.8 V the CCKQ signal goes bad, but if Vbb is lowered again below -1.5 V, it comes right again. Alice doesn't draw any appreciable current on Vbb.

Overall power consumption was about 1.57 A @ 5 V (7.85 W), and interestingly, improving the Vbb strength (lowering the voltage from -1 V to -3 V) makes Alice run cooler and with lower current draw from the 5 V supply.

I'll need to test a bit more and figure out how to make this a permanent fix, but it's looking hopeful that I now have a(nother) working 1200! I've tested it today with internal and external floppy drives, a mouse, but no keyboard, and so far no demos or games I've tried have shown any unexpected issues.

[Boing-ball]

Today's experiment: supplying Alice's Vbb from an external source. I wanted to test the behaviour of this 1200 without the +/-12 V supplies (only +5 V), so I wired up a connector and hooked it to my bench power supply. Since I have a second output on this supply, I set it for 3 V below the ground for the 5 V supply, and connected it to one end of C2X (which I'd also replaced with a 10 uF electrolytic cap with a 100 nF ceramic in parallel).

Results:Running without +/-12 V makes no difference to the glitch, the health of Vbb or the CCKQ clock signals. Running with the extra capacitance also did not help noticeably. But supplying a negative voltage to Vbb seems to keep the CCKQ signal good and allows the system to keep running! If Vbb rises above about -0.8 V the CCKQ signal goes bad, but if Vbb is lowered again below -1.5 V, it comes right again. Alice doesn't draw any appreciable current on Vbb.

Overall power consumption was about 1.57 A @ 5 V (7.85 W), and interestingly, improving the Vbb strength (lowering the voltage from -1 V to -3 V) makes Alice run cooler and with lower current draw from the 5 V supply.

I'll need to test a bit more and figure out how to make this a permanent fix, but it's looking hopeful that I now have a working 1200. I've tested it today with internal and external floppy drives, a mouse, but no keyboard, and so far no demos or games I've tried have shown any unexpected issues.

Some great problem solving there. Keep us updated…

[screwtop]

I had a chance today to do some work on this A1200 and thought I should post an update here. I posted a question on Stack Exchange asking for possible ways to provide the -3 V "crutch" for Alice's Vbb. Today I built the second circuit described there by Simon Fitch, which uses a zener diode to create a simple voltage regulator powered from the -12 V supply - first on breadboard, then (having verified that it works!) soldered up on stripboard.

Interestingly, a commenter on Stack Exchange having the same problem linked to this forum, where a solution (provided by Jens of Individual Computers fame!) using a negative voltage regulator is described. So, it seems this Vbb failure of Alice's is not completely unique to me - maybe something to watch out for...

I've been spurred on this evening to solder in the audio coupling caps, audio connectors, keyboard connector, and a couple of other components I'd removed when assessing the damage to the motherboard due to leaking capacitors. It's great to have the machine working after all this time!