Owner of a broken Arch.

So my purchases from AliExpress finally started trickling in, and, with some sockets from Jaycar I was ready to move forward with trying to fix the Archimedes.

This was very heavily assisted by the always excellent team over on StarDot.

Step 1: Burn off a set of Diagnostics ROMs to allow me to see where the RAM was failing. Everything else would rely on that first step. I downloaded the ROM images and fired up my trusty TL866II+ and burned the ROMs out. One ROM failed, but that was why I purchased them in bulk. They were cheap so no love lost there.

Step 2: Insert the ROMs in the Archimedes. My Archie had an ALA32 ROM expansion board so I very carefully removed it and inserted the ROMs in place. I had to change some jumpers on the motherboard, but it wasn’t too hard to find which ones. (Page 77). With that change in place and the new ROMs in the correct position (With the ROMs to the front of the board with the spare pins towards the back of the board) I was ready to fire it up.

Step 3: Boot up the Archimedes. It actually booted up, which was excellent, and displayed a ROM Diagnostics screen albeit with some corruption.

At this point it was late and I went to bed.

The next day I plugged in my keyboard adapter and fired up the diagnostics again. I pressed ‘2’ on the keyboard and let it run. (I had tried option 1 but I don’t think it liked not having a printer)

So reading that across I could see some bad chips. It took me a little while and some additional help from the team over on StarDot to translate this.

So first up &55555555 is Hexadecimal so we need to convert it to Binary, which is, unimaginatively a pattern of 01010101010101010101010101010101
We can see that the output we are getting doesn’t match that. We’re getting 010101010101000101010101000101?? (where the last two bits are flipping randomly)
This Archie is laid out using 32 pieces of 1 bit wide 1 Mbit RAM chips, laid out in a 1 to 1 fashion with the 32 bit data lines.
Further to this, the StarDot support team pointed out that on this diagnostic, the least significant bit is to the right.
(Keeping up? Good!)
Now, referring to the motherboard schematics, I was able to construct a chart with the bit pattern at the top (as it was coming out of the system), with the bit being tested underneath, followed by the actual chip number below that

0101010101010B01010101010B0101BB <- Output from Diag
33222222222211111111110000000000 <- Bit number (read down)
10987654321098765432109876543210
86868686868676767575757575757565 <- Chip number (read down)
57463524130291806857463524130291

So, reading down the columns, we see that Bit 0 (Chip IC51) is dead, as is Bit 1 (Chip IC69), followed by Bit 6 (Chip IC54) and Bit 18 (Chip IC61)

I then checked connectivity for every trace to the nearby resistor (All fine), the value of the resistor (All fine at 68Ω) and then from there to the inside of the CPU socket. (All fine).

It was also at this point I was advised that, despite all appearances, the carrier board was, indeed, socketed, so I didn’t need to remove it. Back in it goes. (Seriously! The “socket” I literally mistook for lightly soldered through hole plating. It’s amazing. I don’t want to think how much it must have cost)

Time to break out the desoldering gun. Chip IC61 and IC54 both came out without too much difficulty, but the other two were heavily corroded and needed desoldering and resoldering with loads of flux. Once they were out, the top pads were so heavily tarnished I honestly thought I’d killed the through hole plating! Thankfully a quick cleanup with a fiberglass pen revealed the underlying copper. I plated them with a bit of solder and dropped sockets in all 4 spots.

Initially I refitted the original RAM to confirm the faults stayed and weren’t related to, say, a damaged trace. After that, I replaced the “bad” RAM chips, one by one, and one by one the RAM issues went away. Also, the screen got less glitchy each time!

I will admit to a silly mistake at this point. I wasn’t paying attention, and thought one of the RAM chips hadn’t worked after replacement, until I looked closer and realised the “bad” bit had moved! It had passed the first part of the test and found a fifth potential bad memory location.

Back to my cheat sheet and this time the bit pattern has reversed, suggesting this chip is held low.

1010101010101010101010101010B010 <- Output from Diag
33222222222211111111110000000000 <- Bit number (read down)
10987654321098765432109876543210
86868686868676767575757575757565 <- Chip number (read down)
57463524130291806857463524130291

Out comes Bit 3 (Chip IC70) and in goes a socket and a replacement RAM chip. At this point it actually passed all the tests, albeit with still having graphical glitches.

I tried the original ROMs back inside and it still only booted to a red screen.

Of course, the StarDot team came to the rescue again, by pointing out that I’d only tested the first 1MB. I needed to press “M” twice to expand the memory footprint to cover the full 4MB. So off we go again! Look! More bad RAM!

Now it’s late at night, and rather than risk burning myself, I go to bed, fresh and ready for another attempt the next day. Out with the chip decoder…

10101010101010101010101010B01010 <- Output from Diag
33222222222211111111110000000000 <- Bit number (read down)
10987654321098765432109876543210
86868686868676767575757575757565 <- Chip number (read down)
57463524130291806857463524130291

So Bit 5 (Chip IC71)needs to come out. This one put up a real fight. I had to desolder, resolder and then desolder again each side at least twice, but I got there in the end. In goes the socket. In goes the RAM. I hope this is it. I’m down to my last 2 sockets and my last 4 RAM chips.

Fire it up and immediately it’s obvious something has changed. There’s no graphics glitches. It’s all clean. More importantly after about 30 minutes, it seems to have finished checking without any errors!

OK. Out comes the test ROMs. In go the original ROMs. Change the jumpers. Turn it on and… I get a blue screen? What does that mean?

Then I remember you need to reset the CMOS on the Archimedes by holding down the DEL key on the keyboard. I do that and…

It works! It actually works! After all this effort by both myself and the team at StarDot, we got it working! I’ve played with the mouse and opened some of the built in apps and it seems to be working absolutely fine. I’m ecstatic!

I still need to replace a dead capacitor on the mainboard, but after that, it’ll be time to put it back in the case, connect up the HDD and see if it’ll do anything else. Hee!