Category: Restoration

The Atari 8 bit computers have always been a bit of a mystery to me. I never owned one myself when i was younger, and only ever got to play on an Atari XEGS a couple of times at a friends house. I have a few different ones now but I didnt have an Atari 400. So when one popped up for sale at a good price, and with my new favourite words, faulty – spares or repairs, I jumped at the chance.

True to the description, when I powered on the unit, all I got was a red screen. I started with all the normal checks, were the power levels correct? Was the reset circuit working? Do I have a clock signal, and do the data bus and address bus lines look ok?

All of these checks appeared to be fine, so that always makes the repair slightly more difficult. Since I have a few other Atari’s I decided just to try swapping over the CPU and Pokey chips as they can fail. Both checked out fine so I marked them with a nice little tick just to remind myself in case I ever started second guessing the fault.

Now seemed like a good time to bust out my thermal camera, annoyingly I forgot to take a photo of this, but I noticed that one of the ROM chips was getting a lot hotter than the other two. I did a bit of reading up and found the Atari 400 has 3 ROM chips, The first 2 contain the OS ROM which are 4k each, then the 3rd contain an FPP (Floating Point Package) ROM which is 2K. This was the chip that was getting pretty toasty.

Concentrating on this chip now, I started looking on the oscilloscope and noticed that although in my first test the data bus and address bus looked fine, what I was now seeing was when the computer is first turned on, the data bus was held high across all pins for a few seconds and then faded down to normal activity. Something very strange going on!

To see if the FPP chip was causing this weird behaviour, I pulled it out and turned on the computer once more and was pretty shocked to see the following screen.

So it was alive! But how? Since I still had the ROM chip in my hand. Well, it turns out the Atari 400 will actually run fine with the FPP ROM removed, right until it needs to do something with the maths stored in this ROM.

So this was good news. The computer itself appears fine and I just have a faulty ROM chip. The issue now is the Atari uses customised 2316 style ROM chips which are hard to get these days. So I turned my attention to one of the 23xx EPROM adapters which allow you to use an M27C64 in place of the 2316 chip.

I ordered one of these from eBay as I didn’t have any in my parts bin.

Whilst waiting for that to turn up I decided to keep on troubleshooting just in case the ROM chip turned out not to be the issue, but instead maybe the chip select circuit wasn’t working. I actually went down a bit of a rabbit hole on this one, since there were 3 ROM chips, I really wanted to understand how the correct chip got chosen. So I found a copy of the memory map for the Atari. Looked at the memory locations for the OS ROM and the FPP ROM, translated these addresses into binary, and then from that worked out that address line 11 through to 15 were what was being decoded into the chip select lines via a 74LS42, 4 Line BCD to 10 Line Decimal Decoder.

As an example, if the last 5 bits on the address bus were 11011, This would set pin 18 on the FPP ROM chip (One of it’s 3 chip select lines) to high, then pin 21 on the FPP ROM chip to high, then the last 3 bits 011 would go to inputs ABC on the 74LS42, which would cause it to set the final chip select line on the FPP ROM to low. This combination of High High Low is the correct combination to select this specific chip.

I used the same logic above to work out how the Lower and Upper OS ROM chips were selected. This is where I hit a bit of an issue. The schematics I was looking at, combined with the decoding above didn’t add up. There was no way the computer could select the Lower ROM or the Upper ROM by themselves, it would always select both ROM chips.

I was fairly sure my workings out were correct, so I went in search of different schematics for the Atari 400. When I found some, even though they were low quality, I was pleasently suprised to see that the first schematics I was looking at were indeed wrong. For some reason I was pretty happy about this, it meant that I understood how the system worked well enough that I could actually disagree with the schematics that were right in front of me.

Notice on the left picture above that ROM 103 and 104 both have the same Chip Select combination, where as on the slightly blurry image, Pin 21 is Active High on one and Active Low on the other. If you are wondering about the 3rd chip select line, it is actually A11 (I would have to work it out, but I think it is used as a chip select on the FPP ROM but may actually be used as an address line on the OS ROM, something to ponder another day).

After all of that I decided the chip select logic all looked to be fine, and my issue was still likely to be the ROM chip itself.

After a couple of days the 23xx adapter arrived and I spent a long time trying to configure it correctly to emulate the FPP ROM. It took me a lot longer than I care to imagine to realise that the pins on the back, of which you need to bridge two of them, were actually in the order 321 rather than 123 (Why!!!!!), once I had worked that out, I set up the adapter by bridging pins 2-3 on 18,20 and 21. Then bridging 5 as the output pin. I wrote the FPP ROM code to my AT28C64 EEPROM chip, and since this was a 64kbit chip instead of a 16, I repeated the ROM code 4 times to fill the chip (I did try it just at address 0000 but that didn’t work, so remember to do this step).

Finally I was ready to plug in the new ROM chip and when I powered on the computer I was greated with Memo Pad. Now the issue here is Memo Pad actually worked without the FPP ROM installed so I wasn’t really testing anything yet, apart from it wasn’t giving me a red screen.

I happened to have an ATARI SALT Diagnostics cartridge kicking around (Yes I did try this at the start of my repair, but it wouldn’t run with the computer in the state it was in). The good thing about this cartridge is you can just burn an EEPROM and stick it in this cartridge to test ROM files. So I download an Atari BASIC ROM as I had read that this needs the FPP ROM to fucntion.

First test was to pull out my new ROM replacement and try Atari BASIC. It loaded and I got the ready prompt, but then a load of garbage appaeared on the screen and it crashed.

Next I placed my FPP ROM back in the socket, repeated the test and this time I had a fully functioning Atari 400.

All that was left was to re-assemble to computer and feel happy that I’d saved yet another computer and gained a lot more knowledge of the Atari 400 along the journey.

And here it is, The Atari 400!

My latest eBay purchase was a Sinclair QL fully boxed with manual, power supply and a bunch of microdrive cartridges. This was again listed as not working so was expecting to do another repair.

When it arrived my first test was to check the voltages coming from the power supply. Nothing seemed to be being output so this was definately one of the issues I needed to sort. I didn’t want to make a start repairing this one yet as I am still working on the MSX2. But I thought I’d just open up the power supply and check for any obvious issues.

It all looked clean inside the PSU, so I plugged it back in to check some of the voltage lines only to find they now all looked fine. I checked the voltages at the connector end again and once again everything looked good.

I can only assume a loose connection at this point so I put it all back together for now. I then plugged the QL in to find it all seemed to be working perfectly. I tested both microdrives and they worked fine also.

The only issue I discovered was the keyboard membrane had a break in one of the tracks. This is a common fault with these old membrane based keyboards and luckily brand new ones are still available so I have ordered one and just need to wait a few days for that to arrive.

So, I think I got another pretty good deal with this one. Bit of a shame that it wasn’t much of a repair as I really enjoy getting stuck into that (The MSX2 repair has been great fun in that respect so will post an update about that shortly).

Anyway, here it is. The Sinclair QL

I recently purchased a cheap Atari 800XL which was listed as not working. I’ve been trying to find some broken computers as fixing them up and learning about how they work has started to become a big part of this hobby for me.

So when I plugged in the computer and it sprang into life, I was pretty dissapointed. At this time it seemed like the only fault was a loose connection on the power LED.

However, the 800XL has a built in system test mode, and when I ran this it looked a bit odd. All the memory passed the memory test, but there wasn’t enough of it showing. This issue was confirmed when I tried to run a game on the system and it just crashed.

I looked at the system using my thermal camera and couldn’t see any obvious faults with the memory.

I had some spare RAM chips, so decided the next course of action would be to fit some sockets and start swapping the RAM chips around. I decided to fit the sockets one chip at a time and then test swapping the RAM as I go.

As luck would have it, after swapping the first chip, things started to look correct on the system test, and games now loaded without issue.

So, as repairs go, this was a pretty easy one and not the most exciting I have dealt with. But is was nice to pick up a bargain computer and return back to its working state.

My next task will be to give it a bit of a clean up and see what this system has to offer. I have a couple of other 8bit Atari’s but it isn’t really a platform I have spent too much time playing with yet. This is something I need to change.

Recently a BBC Master was listed on one of the Facebook Groups I am on. It was listed as not working for £75 so I decided to grab it and try and revive it.

My assumption was that the issue was going to be the Rifa caps in the power supply.

So after waiting for Royal Mail to take a week to deliver a 24hr parcel, it finally arrived.

First of all I opened it up to see what we were dealing with. I was not surprised at all to discover the Rifa capacitors had indeed let go.

Luckily I had already ordered some replacements so a few minutes later, I had the old ones out of the board.

All of the other capacitors in the PSU looked fine so for now at least, I have only replaced the main culprits.

Upon putting everything back together, the BBC got powered back up and it sprang into life. Since the CMOS battery was also dead, I had to reset the settings and replace the batteries.

I really want to set this up somewhere where I can use it easily. So I think I’m going to look into getting an additional desk for my retro room. Hopefully I can setup some Acorn and Amstrad computers as I don’t have any out currently.

After a trip down to the South West Amiga Group’s latest meet on Saturday, I strangely enough ended up returning home with an Acorn Archimedes A3010. The computer was labelled as non-working and I paid the sum of £50 for the privilege of bringing it home with me.

These computers are notorious for being destroyed by their onboard batteries. Thankfully the previous owner had already cut the battery out and cleaned the board, but then didn’t get any further with the repair.

I don’t class myself as an Acorn expert by any means, but I have done a lot of reading up on the Acorn machines in the past from when I repaired my RISC PC. From my previous repair, I also have an Acorn “POST Box” which is a little USB board that connects to the diagnostic port on 32bit Acorns and gets some extra diagnostic details from the machine.

Upon connecting up the board, I could see a RAM error message with the code 0000FFFF. These error messages are actually in Hexadecimal and therefore translated as 00000000000000001111111111111111 in binary. Indicating that the highest 16 bits of RAM were fine, but the lowest 16 bits were not working. The A3010 has two RAM chips on board and the one furthest to the right is responsible for the low bits.

After grabbing my multimeter and the schematics for the board, I probed all the pins and found the RAS line was not connected (RAS and CAS are used for selecting the Row and Column of memory to be read) and neither were 6 other pins. So my first repair was re-linking these traces. Some I just soldered on top of the board and some I used fine wire from the memory chip to the vias on the bottom of the board.

After this, I had a booting computer but quickly noticed the mouse wasn’t working. Using my oscilloscope I probed the LS241 buffer chip on the board that deals with the mouse signals. All signals looked fine going into the input pins on the chip apart from one bad trace, but there were no output signals at all. Luckily I have a spare donor board for the RISC PC which uses the same chip, so a quick transplant and another wire repair got the mouse back up and running.

Almost there, but one last problem was that the floppy disk drive not working correctly, it would initialise but then return an error saying “Drive Empty”. After doing a bit more research I found that the A3010 used pin 34 on the floppy to determine if there is a disk in the drive. I probed all of the pins and they all had connectivity to the controller chip. But most of the floppy control pins are pulled high to 5v via a resistor. I checked pin 34 and the signal was permanently low.

Further inspection revealed that the trace going to the pull-up resistor was broken. The same issue was affecting the index pin also (Pin 8). With both of these now repaired, the floppy drive came to life and I now have a fully working Archimedes.

Gotta say I’m pretty happy with how that repair went. And what better way to celebrate, than a quick game of Lemmings!

I’ve been fairly busy recently and even though I’ve still been doing a lot of stuff with retro hardware, I’ve not found time to update this site. So I need to catch up, starting with this one which I have actually had for over a year but I knew it wasn’t working so has been sat in my pile of things to fix.

This is the Acorn Risc PC600. As with nearly all of these units, it came into my hands with battery damage. The leak was pretty bad, so the first step was to cut the battery off and clean it all up.

I then purchased an Acorn POST box interface which would allow me to easily read the power on self-test error messages on startup. Upon powering it on it showed that the CMOS was unreadable and it had sirq and virq errors (Sound and Video). Reading up on these it is usually caused by the buffer chip and the resistor network chip next to the battery, no longer being connected to the vidc chip. Using a multimeter I jotted down all the broken traces and re-joined them all.

Powering it back on whilst holding delete to reset the CMOS settings, the POST still gave a virq error and I was about to turn it off when it booted into RISC OS. At this moment in time I was pretty happy. There was still an issue but I had a functioning machine. I was able to test the HDD and the floppy both of which worked. It was then time to go back to my day job for a while, so left it there ready for me to come back later.

After work that day I went back into my workshop and the first thing I wanted to do was format a floppy disk. So I grabbed the mouse, clicked on the floppy drive and the screen went black. Powering it off and back on gave me nothing, and even POST wasn’t working now. After a few choice words were spoken, I started looking around and checking signals with the multimeter. It looked like the PC was being held in reset. These RISC PCs do something a bit unique when they are in reset where they do a count sequence on the address bus, therefore on a multimeter you see it where A0 will have a square wave at a certain frequency, then A1 will be half that frequency, A2, half again and so on. But I checked the reset signal and it looked like every other reset signal I had seen on 8-bit machines, goes high, then after around half a second, goes low.

Some head scratching followed, I expect some more swear words, then I read an Acorn technical manual that gave me the answer. The reset pin on these machines is actually active low! So the circuit was functioning, but the final output was the inverse of what it should have been. Checking the circuit diagram there was a not gate IC on the reset circuit that dealt with inverting the reset signal for the CPU. I ordered a new one and replaced it with the hope I would be back up and running again.

Well, this hope was soon dashed when I powered it back on. The system would POST now, so I had fixed that issue, but I still got the vidq error, followed by a red screen, and then at that point I lost all video output. So something was still wrong.

I spent quite some time going over every signal I could think of and they all looked ok, but by ok, I mean that the signals were there and doing something. What I didn’t know is if the signals were doing what they were meant to be doing. At this point, I decided to look at some other ways of getting this machine back running again.

I was fairly happy with the fact that all other components were working and there was just a board fault somewhere. So I managed to grab another Spares or Repairs board off eBay. This one looked in much better condition than mine so I was hopeful it would be an easier fix. When I got the new board I was again greeted with virq errors and also a DRAM error. I started going through each of the data bus pins to check that there were signals going to the vidc chip. I then noticed that two of the data bus signals seemed to be competing with each other and looked messed up. Confirmation of this issue was discovered when the helpful people over on the stardot forum explained that the DRAM error was actually a hex number and by translating that into binary it showed an issue with data lines 25 and 26.

Using a multimeter, I then discovered that D25 and D26 actually showed continuity between the two pins. The problem here is the data bus goes all over the motherboard so where was the short? I started easy and removed the ROM chips and the CPU, same issue. I then removed the buffer chips as these can go faulty, still the same issue. With only a couple of options left, one being the IOMD chip which was going to be practically impossible to replace, I removed the last easy component, one of the resistor network chips, at this point the short vanished! So I soldered everything else back in place, transplanted this IC from my other board, and finally a working RISC PC 600!

I am fairly happy with my repair as I do now have a functioning PC. But I think I am still going to have to go back and visit my other board. Now I have a functioning device I can see exactly what good signals should look like and can hopefully pinpoint the issue. I am fairly sure it’s going to be the data bus connection to the vidc chip, but the signals were all present, so now I need to look for ones that even though they are present, just don’t look like they are supposed to. I will post an update if I ever get to the bottom of the issue.

My next step is to start discovering what these machines are capable of. I have already swapped the drive out with am IDE to SD adapter and I think I would like to experiment with sticking a second processor in the unit. There is a board that allows a 486 processor to be inserted as a second CPU and then run DOS programs within a window in RISC OS, This sounds pretty neat and I do have a spare Blue Lightning 486 DX2-66 processor sat here wanting to be used.

Thanks go to Ian on the stardot forums for providing help through this repair and also building the Acorm POST box which proved very helpful.

The Dragon 32 was an 8-bit computer based around the Motorola MC6809E CPU which meant it was very similar to the Tandy TRS80 CoCo range of computers.

This particular example came to my collection as a nonworking example. When powered on the screen just showed a load of garbage. After dealing with a couple of other computers with this chip layout, I knew that the video chip works independently of the CPU, so the fact it was displaying garbage on the screen, likely meant that the CPU was not running the correct code.

A first check over with an oscilloscope showed that all the data and address bus lines seemed to be active, indicating that the CPU was at least attempting to run something. When a Dragon is first turned on it will perform a CPU reset and then start executing the ROM code from address $8000. I checked the reset line on the CPU which was functioning as expected (Low then High).

Maybe the ROM was faulty? This Dragon has two ROM chips, one lower and one upper, each 8k in size. The lower ROM chip contains the code to clear the screen, so if that chip wasn’t working then we would see the garbled screen. But also the upper ROM chip contains the reset vector for the CPU (It is this that specifies where to start running the ROM code from). So if either of these chips were dead, we would have an issue.

The ROM chips in this machine are 2364 EPROMS. Unfortunately, these can’t be read by the TL866 programmer I have, so I had to build an adapter to make it read as an M27C128 chip. But once I had done that, I verified the contents of the two ROM chips and they both came back fine, so not our issue here.

Computers that use the MC6809 CPU also tend to use another chip named the SAM chip. This chip does the address logic. So if this chip was bad, then when the CPU tried to read the ROMs, it might not actually be succeeding. I went over the pins on the chip and couldn’t see any obvious fault here either. Luckily my TRS80 CoCo2 computer uses the same SAM chip and it was socketed, so just to rule this one out I swapped them over and confirmed that this chip was fine.

If the RAM is faulty, then any instructions that the CPU stores data in memory won’t work. So once again this could cause the computer not to start up. But I checked all the CAS and RAS signals, along with the address pins and the data in and out pins, and I couldn’t see any obvious issues.

I decided then to dig out the datasheet for the CPU and started going over each pin to see if they looked like they were performing their duty. It was at this stage that I noticed the Read/Write pin on the CPU was stuck high and was never changing its value. Without this pin changing, the CPU will always be reading from the data bus but never writing to it. There is no way it can initialise the video chip without writing to the data bus. Unfortunately, the CPU in my TRS80 CoCo2 was soldered into place and I didn’t fancy removing that so I had to wait for a new CPU to arrive off eBay.

Once the new CPU arrived I swapped it out and powered up the Dragon, this time to be treated with the Microsoft Basic boot screen! A fully working Dragon 32 is now in my collection.

I have also discovered that my CoCoSDC adapter also works with this machine so I have an easy way of loading up some Dragon games from SD Card.