Saturday, 31 August 2013

Acorn Archimedes A3000 Repair

A recent video by Dave Jones on his EEVBlog showed a tear down of an Acorn A3000 (I think they had officially dropped the Archimedes name at this point, but it is still sometimes referred to as an Archimedes 3000 or Archimedes A3000). The one Dave had suffered from what is sadly a common fault on this range of machines (and things like the Commodore Amiga A501), that of battery leaking and damaging the boards. Knowing this often wrote off the boards, I had been looking for a cheap A3000 that looked good externally, but where the main board was shot. My plan was to 'upgrade' the ARM2 processor to the ARM11 of a Raspberry Pi. I was going to convert the keyboard (like my other Vintage USB keyboards) and run RISC OS on it, so externally, it would look like an A3000, just inside would be the pi rather than the A3000.
Looks ok, doesn't it? Many of these had school names etched into the top of them. This is also the A3000 which is the last model to have BBC style red function keys. The later A3010 and A3020 had green function keys and no reference to the BBC heritage.
Again, the inside loosk OK. The expansion cover is missing, there is no econet module or serial upgrade. There is however a 3MB upgrade (taking the memory to 4MB in total). The horrors lurk under the keyboard - those of a nervous disposition look away now...
Over the 20-25 years since these machines were manufactured, the batteries have leaked an alkali solution over the area of the board around them. In the case of the A3000, that is the RTC / CMOS RAM and the 4 ROM chips (RISO OS runs from RAM, so no need for an OS disk like the Amiga).
The alkali can eat away at the copper, and indeed both the legs of the 32.768KHz crystal had gone, as had one leg of a capacitor. The tracks all seemed intact, bar one connection from the RTC chip to the crystal which I patched up.
As horrid as it looks, a wash in a vinegar solution and a clean with IPA seems to have brought it up nicely. Originally, the battery was a 1.2V rechargeable, and the user guide recommended having the machine switched on at least 1 hour a week to keep it topped up. I didn't fancy that, so I went for a standard CR2032 3V battery, as used on almost all PC motherboards these days. The PCF8583P RTC chip claims to work from 1.0 to 6.0V, so 3V should do nicely. I added a diode in series to stop it trying to change the battery and powered it on.
I didn't get any photos of the screen at this point, but it wasn't a great start, the settings were wrong (it defaults to all the ROMs being virtually 'unplugged', like the BBC Master), so was just showing 'Supervisor'. However, I couldn't get a stable picture. I didn't want to reset the config until I could see what was going on. The LCD TV wouldn't lock on to the sync, so I tried the composite video on a Commodore 1901 monitor. Same thing. The 1901 has an RGB input, so I made up a lead for that and tried. Same again.Testing it with the scope showed the sync was around 31Khz, not the 15.4KHz I'd expect - it seems the machine was in high res mode. So I went for the factory reset (hold down delete whilst powering it up). I got the screen with a red border which synced up fine, and then up came the loading screen.
It looks to have been upgraded to RISC OS 3.11, which is the last version supported on this hardware. And there we have the RISC desktop.
There is still the issue of a mouse. I didn't get one with this machine, and they are tricky to find (round 9 pin connector, discrete wired buttons and quadrature outputs).
For the moment, pressing F12 allows you to type. All the keys and the floppy disk seem to work fine. Acorn always seem to be on the ball when it comes to thinking about expansion, and I found places on the board where sockets could be fitted for alternate mouse and keyboard connections. They are both controlled by an 8051 based microcontroller which converts key presses and mouse moves to serial data, presumably using the same protocol as the controller in the external keyboards on the earlier A400 series machines. There is even a jumper to interrupt that serial data and inject new traffic. So in theory, if I can work out the protocol, I could add a microcontroller with a mouse and convert it's output to serial and inject it into the system as if it had come form the 8051.
Having fixed it, that put paid to my plan to install the Raspberry Pi, I think I need to look for one a bit more broken - or try less hard to fix the next one.