Back from the Grave: Acorn A3000 (Battery leak)

In 1983, Acorn - already well known for the existing BBC Micro - set about attempting to compete with IBM in the business domain.  After determining that all the existing options were unsuitable they would settle on designing their own processor, unknowingly becoming one of the grandfathers of modern computing. Following successful simulations run in BASIC on a BBC Micro, in 1985 they would produce the first prototype Acorn RISC Machine processors, better known today as ARM processors.

It would be a further 2 years before these processors would see a commercial release, however, as the ARMv2 powering the brand new BBC Archimedes. A dozen or so models were released in all over the next 5 years eventually producing the ARMv3 and perhaps the first ever example of an SoC in a commercial product with the ARM250 variant of the ARMv2.

While their obvious performance advantage over the existing competition, especially in 32-bit scenarios, went largely unnoticed (and largely unused in 2D games), it's fair to say their legacy has well and truly outlived all but x86 when it comes to modern computers.

 

This particular A3000 (only the BBC-branded systems ever used the name "Archimedes") was sourced second hand from eBay by my brother in known not-working condition. As is typical it was physically processed and cleaned before addressing the elephant in the room: just about every single Archimedes ever produced, BBC or Acorn branded, has had the persistent memory battery leak, and this one was no exception.

The damage in this case was isolated to the front left corner of the mainboard. This area contains not only the battery but the CMOS RAM (which uses the battery), mouse connectors, keyboard connectors, ROMs, and much of their supporting circuitry. Initial inspections revealed two missing components (a surface mount resistor and the middle of a zero-ohm link), several corroded legs, some legs with green fuzz, and a couple of questionable electrical connections.

Attempting to boot the system in this state was unsuccessful. The screen would sync to a signal for several seconds before blanking out, providing little if any usable feedback.

As a first step, the critical components were addressed. This meant cleaning the legs on the ROMs, CMOS RAM, and keyboard multiplexer chips, which were subsequently socketed. While this did improve the electrical situation, the system behaved the same. Another issue was clearly still present.

Due to its proximity to the "Blast Zone" and hopefully non-critical nature, we attempted to boot the machine with the CMOS chip removed in case it was feeding back poor data resulting in a non-standard boot. With the chip removed and holding down Delete to perform a CMOS wipe on startup, this time there was a change - the floppy drive lights slowly blinked out a 32-bit diagnostic code indicating a CMOS failure, and the system booted into a supervisor prompt. If nothing else, this meant enough worked to start doing further diagnostics.

By a stroke of luck, it turns out that the CMOS chip itself was not faulty. Rather, two nearby capacitors with badly acid-damaged legs were responsible for the issue. These were easily replaced as a matter of course (all capacitors, both near the battery and otherwise, will eventually be replaced due to the vintage of the machine) but were prioritised due to their location. With the CMOS chip back in and now receiving correct power, the machine would now boot to its GUI instead of a prompt.

Of course, a GUI is not much use if it cannot be navigated due to the lack of a mouse, and the prompt is of limited use if the keyboard is not working correctly. The connectors for both were unfortunately damaged by the battery. In addition, all of the damaged zero-ohm links are in the mouse signal path, so even if the connector was good it would not have worked.

Repairing the mouse interface is arguably the easier affair, so that's where we started. The zero-ohm links were replaced with normal patch wires (even the original service manual had mentioned that 22SWG wire was a suitable alternative part) which made restoring the signal path easy. However the connector is an uncommon, though not proprietary, 9-pin Mini-DIN. Since we weren't planning to use an original mouse anyway, this will instead be replaced by a more familiar 9-pin D-Sub, wired up identically to an Amiga joystick/mouse port (though with one extra button) to make it possible to use the same Smallymouse adaptor on multiple systems.

The keyboard, on the other hand, represented a more difficult problem. While the keyboard itself appeared to be completely functional, the damaged connector had damaged the ribbon cables during their removal (necessary to properly work on the system). While the ribbons could have their tips re-done using carbon glue, this would need to be re-done every time it was removed again. As such it was necessary to either replace or repair the keyboard connectors.

Individual testing of keys indicated that, rather fortunately, only one of the two connectors (the lower one, closest to the battery) really needed any attention. The solution was a rather simple one: remove each pin, one by one, and clean them off thoroughly. Of course, simple doesn't always mean easy, and removing the pins required carefully bending the mounting pin straight so it could be removed from the top, before careful decontamination - all while trying not to drop the tiny thing. Installation is obviously the reverse, making sure to be mindful that none of the contacts were broken or incorrectly bent in the process.

The last step is to replace the battery and its associated circuitry (basically two SMD resistors). Since it was a battery which caused the initial problem we've opted not to install another one, rather using a 5.5v supercapacitor in a button-cell format which was basically designed for this purpose. This retains the recharging facilities while ensuring no future acid-related damage should the system go unused for an extended period. Plus it should hold its charge better than the old NiCad-based cell.

Another BftG down. As usual I'm unsure when the next will come, but we do have a candidate already lined up: an Acorn A4000 with similar damage acquired at the same time. Due to the changed placement of the battery it is possible it will be an easier fix, however there are a number of small traces and components nearby related to the floppy drive, and fewer discrete (thus replaceable) chips, so actually getting it usable could be more interesting.

*UPDATE*

As it happens, the system wasn't quite at 100% after all of this. It turns out that the system clock was faulty - hours could not be set (though they could be counted), and the time it kept was not accurate. Since we had initially assumed the CMOS chip had failed a replacement was already sourced, and upon its arrival it was installed. Remarkably this fixed both issues.

What makes this particularly interesting is that the CMOS chip has a serial interface. As a result the faulty clock functionality must be handled by the same input and output pins as the rest of the working facilities. Which means the chip itself was internally damaged somehow (possibly by the acid, possibly by time) and it needed to be replaced anyway.

 
Remember that electricity can be dangerous to both property and life.  If you don't respect it you can wind up seriously hurting or even killing yourself or others, and chances are it's going to be painful while it's happening.  Unless you're sure of what you're doing, avoid tampering with any electrical circuit - especially when it's live or mains powered - and always ensure you have a nearby assistant who can contact emergency services.