Category: Restoration

Posted on by — Leave a comment

CPS1 – Street Fighter II Repair – Part 1

About 1 year ago, I was gifted a couple of arcade boards and an arcade control panel by a friend of mine. Sadly, this friend has recently passed away, so I have now promoted a couple of projects involving these parts to the top of my priority list.

I started by connecting up the two arcade boards (Street Fighter II and Caveman Ninja) to see what we get out of them. The Caveman Ninja board had no output at all, but the Streetfighter II board actually had output to the screen, so I decided to start with this board as I figured it would be the easier repair (Yeah, right!).

Upon powering up the board, the game ran through the RAM tests, which all passed. But then it just hung on that screen.

I figured I’d start off with giving the board a good clean up, removing all of the socketed chips, sanding down the pins and giving them all a dose of de-oxit.

The only change in behavior was that the board no longer worked. At this point, I realised my rookie mistake where I had put one of the PAL chips the wrong way around. The writing printed on the chip was upsidedown compared to the others, and I just didn’t check the notch. Very disappointing, but luckily not unrecoverable.

The code for all of the PALs has been reverse-engineered for this board (https://wiki.pldarchive.co.uk/index.php?title=Street_Fighter_2_Champion_Edition), so after I had ordered some GAL16V8s, I programmed one of them with the code and was finally back to square one.

So where do we go from here? Ideally, I need to know what the board is actually trying to do at the point it is crashing. It was at this point that I had an idea. Everybody has surely heard of MAME (Multi Arcade Machine Emulator), which allows you to run Arcade ROMs on many different platforms. However, it also has some advanced features that most people would not have used before, one of which is an internal debugger, which allows you to disassemble the ROM code and also step through the code one instruction at a time, whilst also setting breakpoints and monitoring for specific conditions.

Running the ROM file in MAME, I could see that after the RAM tests, the screen goes blank and then changes the text to Street Fighter II. My board doesn’t get this far, so I needed to concentrate on the code that runs after the last RAM check, but before the screen blanks.

After a bit of playing around, I found a nice breakpoint to set at address 754. This is a loop in the code that prints a character to the screen. So with a breakpoint set here, every time I start the emulator running, it will print one more character to the screen and then pause. This will allow me to step through until the last OK message is written to the screen and then see what happens next.

I could see that during the RAM tests, all it was doing was writing a character into RAM and then reading it back and comparing it. I don’t think this is the most conclusive RAM test, but I guess it’s good enough to find basic RAM issues. I did do a quick check here and manually modified the area of memory so the compare would fail. It responded by marking that RAM test as “NG” (Not Good), and then froze the game. I didn’t need to do this bit as all the tests were passing, but I thought it was interesting.

The next thing I wanted to do was to try to find out where my board was stopping. I had a thought that if I could insert a reboot command into the actual ROM code at various points, I could then burn this to an EPROM and stick it in my board. If my board went into a reboot loop, then I would know that it was getting as far as executing that command.

68000 Assembly is not a speciality of mine, so I used AI to help here (sometimes it does actually have some uses!). My first attempts used a jump instruction to jump to address 0 and reset the board, but this had one small issue in that the opcode was 3 words long (6 bytes). The issue with this is that I could only insert it where another 6-byte opcode existed; otherwise, I would be overwriting other code. Asking AI for another way of rebooting the board, it suggested the opcode “ILLEGAL” which has a hex code of 4AFC. With this being 1 word long, I could insert it anywhere in the ROM without breaking anything.

I gave it a quick test and confirmed that my board did indeed reboot when it hit this command. I continued going through the code in chunks and added my reboot at various points to see how far my code was executing.

I eventually homed in on the exact part of the code where the board was stopping.

The culprit was an opcode stored at the address 1A0:

MOVE $2000, SR

Giving AI another chance to show its uses. I asked what this command did. It turns out this command essentially changes the Status Registers on the CPU. With the value of $2000, it would achieve the following:

  • Set the CPU to Supervisor mode
  • Enables interrupts
  • Clears all condition flags
  • Disabled Trace mode.

Out of those options, I already had a hunch of which one to concentrate on. Going back to the MAME debugger, after the command at 1A0, the next instruction executed was at address 5C6. But there was no jump instruction, so why did it suddenly jump to that address? One logical answer is that an interrupt was triggered.

A bit more research showed that on the 68K CPU, when an interrupt is triggered, it will jump to the address held in the interrupt vector relating to that interrupt. These values are located in the address range 60 to $7C, and looking at that area in the ROM file, I could see 05C6 listed, which confirmed to me that an interrupt was indeed being triggered that was causing the code to jump to address 5C6. The problem now is that my board never triggers that interrupt.

The 68k CPU has 3 interrupt pins, which are inputs. Each one of these can either be high or low, giving us 3 binary bits, and a total of 8 possible combinations.

According to the schematics for the CPS1 board, one of these interrupts is tied to 5V, which I confirmed with my scope. That left two other interrupt pins. I monitored both of these on my scope, and both of them remained permanently high.

The interrupt signal is an active low signal, so with all these staying high, no interrupt would ever be triggered, and my board would just sit there waiting for this signal. I traced the Interrupt pins on my board back to a 74LS74, which is a dual positive-edge-triggered flip-flop. I took a look at the datasheet for this IC and probed the input pins. One of the pins had a regular pulse to it, and looking at the schematics, this signal was the vertical blank signal.

With this input being triggered, the output pin going to the CPU should also be triggered. So it looks like the first issue to be identified is actually a faulty 74LS chip.

One last thing I could try before wrapping up this part of the repair was to replicate the interrupt being triggered. I could do this by simply shorting this signal to ground. Since the vertical blank signal was a continuous pulse. I replicated this by just tapping a ground wire onto the interrupt pin. With this, I was able to “run” the game frame by frame.

There is another issue in that the background graphics are corrupted. But that will be a problem for another day, after I have got the board at least running the code.

Stay tuned for part 2 once the new 74LS74 chips have arrived

Posted on by — Leave a comment

Impromptu Toastrack Repair

Every now and again I like to have a move around in my retro room and possibly swap out some systems. Well I decided that to represent the Spectrum, I would get one of my 128K Spectrums connected up. I grabbed one off the shelf and plugged it all in ready to sit down and have a play. Only to find out, this one had become faulty!

When turning it on using the RGB scart cable, the picture was pretty much black. But this wasn’t a dead Spectrum, as if you looked closely you could see that the computer itself was running fine.

It’s not very clear in the picture but in the center of the screen you can just make out the 128k menu.

This then was more of an issue with the video signal, specifically the blanking signal on the scart cable. Just to rule out a bad cable I tested my other toastrack and that displayed fine.

There is sometimes an issue with Spectrums and certain TVs when using the RGB scart cable, and there is a quick mod you can do to increase the blanking voltage which helps in this situation. But I didn’t think that was what was going on here, and I was pretty sure I had already done that mod on this system at some point.

I opened it up and checked the blanking voltage which was at 1.45v. Yeah, there is something not happy here. Another common fault with these machines which would match the issue I was seeing, is the two transistors, TR4 and TR5.

Taking TR4 off the board and giving it a test, confirmed my suspicions.

That doesn’t look much like a transistor to me! So, a quick trip to eBay and a few days waiting for some replacements to arrive.

I did test TR5, and it actually tested OK. But I replaced it anyway to be safe. Sometimes, if you only replace TR4, TR5 can end up damaging the new replacement.

Anyway, we are now back to having a decent voltage on the blanking circuit, and yes, I had already done the blanking mod on this one.

Time to put it back together and give it a test!

All working 😀

Unfortunately, that used up my spare time this evening, so i don’t actually get to sit down and play a game. Slightly, will have to put his adventure on hold until next time.

Posted on by — 1 Comment

Spectrum 48K Repair

Today I had a bit of spare time, so decided to take a look at a Spectrum 48K for one of my work colleagues. It had unfortunately been plugged in using an Acorn Electron PSU as he mixed up the power supplies.

The Acorn Electron uses a 19v ac power supply, where as the Spectrum uses a 9V DC supply. As you can imagine, the poor Speccy did not appreciate this very much.

First job was to check the voltage regulator. As expected, this was dead, so I swapped this out with a new 7805 regulator. Now we were getting a stable 5v output from the regulator.

Next step was to dig out the thermal camera and see what the system looked like powered up, I didn’t hook it up to a TV yet as I was pretty confident there were more issues I would need to solve first.

I forgot to take a photo the frist time around, so the photo above is after I had already replaced the far left RAM chip which was also getting very hot.

There were 5 chips in total that were getting pretty toasty. I socketed all of these and tested the removed chips, all of which tested faulty.

With the new RAM in place, I figured it was time to test the machine out. Even though no chips were getting hot now, some more of the RAM could have still been faulty.

Luckily, In this case, that was not the case and the Speccy booted up, seemingly with no issues. I wrote a little BASIC program just to make sure it was executing code.

So far so good, but I wanted to test some games out. At this point I grabbed my DivMMC device and hooked it up. But here we ran into another issue. The DivMMC was not showing any life when connected to this computer. From previous experience I knew that the M1 line on the CPU can stop the DivMMC from working if it doesn’t function properly. And sure enough, I probed pin 27 on the Z80 and it was just sat there at around 2V, not doing anything.

Fortunately, I had some spare Z80s in stock, so i removed the Z80, and fitted a socket along with the replacement Z80.

Finally we have a fully functional Spectrum again 😀

Posted on by — 2 Comments

The DX7 is fixed :)

Today was the day that the new 74LS374 arrived in the post. My first quick test was to put the new chip into my chip tester, and it confirmed the chip was ok whulst thebold one still reported faulty, so it looks like the chip tester might actually be trustworthy. I’ll be doing some more testing with this in the future as it could be a very handy tool.

Next step, was to get the new IC fitted and see if the issue was resolved. After powering it on i checked all the address lines and everything looked perfect! The welcome message showed up with no corruption and the DX7 was fully functional again 😀

The only thing left to do was test it out with a talented musician at the keys. Unfortunately I couldn’t find one, so you’ll have to put up with this!

Musical talents aside. I’m pretty happy with this repair, the DX7 is a great piece of music history, and it’s really nice to see it fully functional again.

I can add vintage synthesiser repair to my resume now 🫠

Unfortunately the DX7 has now got to go back to its owner, maybe I need to set up another watch list on eBay 🤔

Posted on by — Leave a comment

Yamaha DX-7 Repair

Recently, a colleague at work contacted me and asked if I wanted some old computer stuff, including a 19″ CRT monitor and a colour Dot Matrix printer. This donation was gladly accepted, and whilst collecting my new toys, we found ourselves discussing various retro tech.

During this conversation, he mentioned that he had a Yamaha DX7 synthesiser that he had purchased, but it had a fault. It is very common for the batteries to die on these, which then leads to corrupted content in the RAM. In this case, though, the battery had already been replaced, but it didn’t fix the issue.

I did a quick Google search for the schematics, and essentially what I saw were the schematics of an 8-bit microcomputer. I said I’d take it back with me and take a look to see what was going wrong. Occasionally, the keyboard would appear to boot up, but would then hang, other times, the display would be garbled and completely unresponsive.

I knew the CPU was trying to run code because the display was occasionally showing correct text. Just to rule out a ROM chip issue, I downloaded the ROM file from the internet and compared it with the ROM stored on this chip. All looked ok, but I wrote the ROM to a new chip anyway and tested with the same result.

I then grabbed my scope and started probing the pins on the ROM chip to see what the address bus and data buses looked like. It was with the scope that I saw the issue, or at least the first issue. The data bus pins were all looking good with nice strong 5V peak-to-peak signals. But the first 8 address bus pins (0 to 7) were all a lot lower. Address bus pins 8-15 were all working as expected.

I dragged out the schematics and did a quick glance around for something that was only connected to the first 8 address bus pins. There was one very obvious candidate, a 74LS374 transparent latch IC that sat between the address bus and the ROM chip. Looking at the inputs of this IC showed they were nice and strong with no issues, but all the outputs were low, as shown in the picture above.

I suspected that this chip was faulty, but it could still be another IC on the board pulling the outputs low. So to test for that, I snipped one of the output pins so it was floating, then measured again. Exactly the same issue. At this point, I then removed the IC from the board, ready for the replacement chip to arrive.

Now off the board, I tested the chip in my chip tester just out of curiosity. It did indeed state that the device was faulty. I will be testing the new ones when they arrive, as I’ve not used this chip tester before, so not sure how much trust to put into it yet.

All I need to do now is await the delivery of the new IC and hopefully, this classic synth will be back up and running again. I will of course update everyone with the result, and hopefully this is the only fault 🙂

Posted on by — Leave a comment

3DFX Repair – Diamond Monster 3D VooDoo 1

I already have a few retro PCs in my collection, but I was missing one specific era, and that was the era when the 3dfx VooDoo cards hit the shelves. A friend of mine got one for his pc, and it was a complete game-changer back then. Everything went from blocky-looking textures to gorgeous, smoothed polygons.

The price of VooDoo cards is now quite high, costing around £120 for a working one. But where is the fun in buying a working one when you can buy spares and repairs for a 3rd of the price 🙂

So for 39.99 inc postage, I picked up a Diamond Monster 3D VooDoo card. I had a small concern that the previous owner had admitted to fixing a couple of traces, which meant he had at least attempted to repair this card and had not succeeded. So could I do any better?

I gave the card a quick clean and inspected the traces that he had already repaired. I guess this card was chucked in a box at some point and had gotten scratched. They looked fine, but I re-did them just in case. I also noticed a couple of missing capacitors. There were only decoupling caps, but I replaced those anyway.

The next step was to test it out and see what state it was in. And things were not looking good. I ran the 3DFX diagnostic utility mojo.exe from DOS, and it just hung the system straight after DOS4GW.exe was loaded.

So I then tried booting into Windows 98. Amazingly, it did actually detect the card and installed the driver, but once installed, I got a yellow exclamation mark saying there was a resource conflict. Hmmm, that’s a bit odd. Just as a test, I went into the card settings and changed the memory address to a different one that wasn’t conflicting. I then launched the command prompt from Windows and tried mojo.exe again. This time, I got a different result.

Some noteworthy things here are that it was at least detecting the card now, but no memory on the card and the error code 0xdead didn’t fill me with confidence. The Bogus number of TMUs 57005 error is also hexadecimal for the word DEAD.

The above test gave me some clues, and I started to wonder exactly how a memory space gets assigned to a card when a PC turns on. Without changing the address in Windows, I was still just getting a complete hang in DOS, so it seemed this initial process wasn’t working properly.

I read a whole bunch of docs and figured out that when a PC turns on, the motherboard will probe the IDSEL pins on each PCI slot and communicate with the device on each slot to get the vendor ID and hardware ID. This part must be working, as Windows detected the device.

The next step involved BAR registers (Base Address Registers). This sounded promising. Essentially, each PCI device can have up to 6 BARs. When the card is initialised, these BARs will be queried, and the result of these queries will tell the PC how many chunks of memory space or I/O space the card needs to function. This part of the process is reliant on the PC talking to the card over the PCI address bus. If this process failed, then the card could report that it needs either an incorrect amount of memory or all of it!

At this point, I had already reflowed all the pins on the FBI chip and TMU, as I knew this was a common failure on these cards. But the problem remained, so I needed to check all the address lines. I tried to find a nice picture of the PCI slot pinouts, but since the card doesn’t have all the pins present, it was difficult to work out the pin numbers, so I went with a different approach. Every pin on the 3D X card should in theory, be connected to the FBI chip. So I put my meter on continuity, put one lead on the first PCI card pin and then ran the second along all pins of the FBI chip. As long as I got at least one beep somewhere, I assumed the pin was connected fine.

I eventually came across one pin that didn’t seem to be connected to any pin on the FBI chip. So I followed the trace from that pin and found a smoking gun!

Checking continuity between the PCI pin and the via after the break confirmed that there was no continuity. So I carefully scraped away at some of the solder resist and placed a bodge wire across the gap. After confirming connectivity, it was time to do another test.

Result!!! After booting directly into DOS and running mojo.exe again, no hanging and everything looked good to go.

So once again, I booted into Windows, this time with no device conflicts. I ran one of the 3DFX demos, and it launched fine, but with one small issue. I could see a pattern of dots on some of the textures.

This was a different fault now, so it was time to move my attention to the TMU chip instead. After carefully inspecting my re-flow work, I noticed the slightest solder bridge between two pins relating to the address bus between the TMU and the memory chips. After clearing this final issue, everything is now working perfectly and I am in possession of a fully working £39.99 VooDoo card.

Posted on by — Leave a comment

Sony Trinitron KV-28FX68U Repair

Whilst sat browsing Facebook one day, I saw a post from someone local asking if anyone had a CRT for sale as theirs had broken, and they included a photo of their lovely 28-inch Sony Trinitron TV. I messaged him and asked what the fault was, and apparently the picture went off and was now just blinking the power LED with 2 blinks, which according to the service manual translates as Over Current Protection (OCP) triggered.

I said that if he was going to bin it, then I would like to pick it up and attempt to repair it. After all, you can’t really learn to repair stuff without having some broken ones to fix.

A couple of weeks later, he messaged me to say if I wanted to pick it up, then I could have it. So I got in the car and went and collected it. With some help from the Mrs, we got it home and down into my workshop, where I could then start my testing.

The first thing I needed was lots of information about CRT TVs and exactly how they work. And for this, I highly recommend watching videos by Randy Fromm on YouTube (Start with this one) After watching those, I had a very good understanding of what I was looking for. Even so, this Trinitron turned out to be quite a puzzle.

The first thing I did was test the TV to see what happened when I powered it on. And just as the guy had said, upon powering on, all I got was a blinking power LED flashing twice, then pausing and repeating. The issue with this error code is that it isn’t really very descriptive. Basically something, somewhere in the TV was apparently pulling too much current.

The other thing I noticed was that I wasn’t hearing any high voltage at all. Normally, when you power on a CRT, you will hear a crackling sound from the high-voltage circuit. So I downloaded the service manual for the set and started to look at all of the voltages to start with. This wasn’t that easy, because as soon as the TV detected the overcurrent, it shut down the power supply! Luckily, I have an oscilloscope, and this meant I could visualise the voltage for the very brief moment it was there.

From what I could see, the main voltages were present, specifically the 135V B+ voltage, which would go on to generate the high voltage via the flyback transformer. Another common fault on CRTs is the Horizontal Output Transistor; without this part working, you won’t get any image on the screen, and that part could easily pull too much current if it were to be faulty. But after testing it, it looked fine to me, and on my scope, I could see the required 135V pulses being sent to the flyback. So I really expected to hear some high-voltage crackling when the set powered on.

After looking around, I found that two fusible resistors had blown, which were right next to the flyback. I was hoping that they may have been the cause of the issue. But I wasn’t going to be that lucky, and after replacing the resistors, there was still no life in the set.

At this point, I decided I needed to test or replace the flyback. Unfortunately, I didn’t have any way of testing it at the time. So I looked around and luckily I found a replacement flyback on eBay from Malaysia. The part was new old stock, so I snapped it up and waited for it to arrive.

Fast forward to delivery day, and I swapped the flyback over, held my breath and hit the power button. For a split second, I heard a nice static crackle from the CRT, and then it shut down and sat blinking its LED at me. At least this proved that the flyback was indeed faulty.

The next few weeks were slow and painful. My bedtime reading was the schematics for all the various boards inside the TV. Every now and again, I would have an idea of something to test, so I’d run down, test it and come back to bed depressed that it still wasn’t working.

I went through all of the test points on the CRT and compared the waveforms to what was in the service manual and I just couldn’t find anything wrong.

I then had an idea, a potentially dangerous idea which I don’t think I would recommend to anyone! But I had basically run out of things to try.

The way the Over Current Protection circuit worked, is that it measures the voltage drop across a resistor and if that voltage drop was too high (two much current) it would trigger an OCP line that originates from the power supply board and gets sent to the microprocessor board which would then shut down the TV.

So what if I simply disconnected the OCP wire between the power supply and the processor? It wouldn’t get the OCP signal and would keep the TV running. Maybe then, whatever part was causing the issue would very quickly get hot, and using my thermal camera, I could see where the issue was.

Either that, or it would burst into flames and I wouldn’t need to worry about repairing it anymore 🙂

So, I pulled the OCP wire out of the connector block, pointed my thermal camera at the back of the TV and nervously hit the power button.

And……..

It came on and just worked. I carried on looking around with my camera, but nothing looked wrong. So I left it running for a while and carried on monitoring the situation. After about 20 minutes, everything was still fine, so I powered it off, reconnected the OCP wire and was straight back to a blinking light again.

After scratching my head until I had no hair left, my conclusion was that there wasn’t an overcurrent issue, but actually an issue with the overcurrent protection circuit itself.

I took a look at the schematics for this section of the board, didn’t understand how on earth it was supposed to work, so I went and watched some videos about over-protection circuits. The main thing seemed to be that for the OCP to trigger, there would need to be a large voltage drop across the current sensing resistor, but I was getting a 0.13V drop, which seemed perfectly fine to me. So the next step in the circuit was two transistors, which would monitor that voltage and turn on when overcurrent was detected. It looked like one of the transistors was outputting the OCP signal from its emitter, but with the voltage being in spec, there was no reason why it should. So, just for completeness, I swapped out both of these transistors as there wasn’t much else left that it could be.

After replacing these parts, I finally had a fully working CRT again and was able to reconnect the OCP wire.

So the moral of the story, although these newer CRT sets have the luxury of running their own diagnostics. Don’t just blindly trust what they are saying, and don’t rule out the fact that the diagnostic circuit itself could be the fault!

I would also like to point out that although this story seems quite short, these events were spread out over 6 weeks! But I do feel I have learnt a hell of a lot about CRTs on the journey so for that I am quite happy with myself.

Nothing left to do now but kick back and play a bit of Jumping Flash on the PlayStation to celebrate my victory 🙂

Posted on by — Leave a comment

Microvitec Cub 1441 monitor repair

Back during my early school days, some of the classrooms had BBC Micros in them along with a beige metal CRT monitor with Cub written on it. These displays were nicely matched to the BBC and were very common at the time.

I happened to log into Facebook at a perfect time last week when a guy I know (Zeb) posted on the Acorn group that he had a Cub monitor free for collection for whomever claimed it first. He doesn’t live that far away from me so I jumped at the offer.

Zeb then messaged me to say, he forgot to mention that it was broken and did I still want it. To most people this would have put them off, but for me it made the offer even better! Now I had a reason to learn more about CRT repair!

I went and collected the monitor and brought it back home and after an initial inspection I plugged it in to see what happened. The monitor fired up, I could hear the high voltage working and then a single horizontal line appeared across the center of the screen so I turned it off before any damage was done to the phosphor.

The schematics for these monitors are available to download so I grabbed them and started to look at the vertical deflection part of the circuit. This seemed to get it’s power from a section of the circuit that contained a nice big capacitor that was connected to ground. This looked like a perfect candidate for the fault so I removed the capacitor and tested it with my ESR meter and sure enough it was shorted. I didn’t have a replacement so I ordered one and decided to do some more research while I waited for it to arrive.

I soon discovered that this fault was actually a fairly common issue with these displays and it often kills one of the fusible resistors at the same time. So I tested this and sure enough that resistor was also dead so I ordered some replacements.

Once those parts arrived I fitted them and turned of the monitor and was greated with full vertical deflection.

I was pretty happy at this stage but that was short lived.

I connected up the BBC and powered the monitor back on. Instead of a nice picture, I got a weird squiggly pattern and then magic smoke started to come from the monitor so I quickly powered it off again. The smoke had come from the resistor I had replaced. So it looked like there was a bigger issue that had possibly caused the capacitor and resistor to die in the first place.

I then spent a couple of hours looking at the schematics and testing capacitors and resistors in the vertical deflection section and everything i looked at tested fine.

The service manual had several images of test points and what the waveforms should look like. So I grabbed my scope and started looking at these signals. Most of them were fine but I had no field output signal. I was pretty convinced now that the TDA1170 IC was internally shorted and was causing a high current draw which killed the resistor.

So, I went back on eBay and found out that these ICs were still available. A couple of days later it arrived and as soon as I finished my day job and went down to my workshop and fitted the new part. Whilst holding my breath, I powered the monitor back on and everything seemed to be fine, full vertical deflection and no smoke.

It was now time to connect the BBC back up and see what happened. This time I got a nice clear image and still no smoke!

This was a pretty satisfying repair and during this I have been watching a bunch of videos about CRT theory and repair. The best ones I have found so far are the CRT workshop videos by “Randy Fromm” on YouTube. I would highly recommend watching these as they contain a wealth of information and real world experience within them.

I also have another CRT here now which I am trying to repair, which is a 28inch Sony Trinitorn that has an over current protection fault. That was is going to be a bit harder to troubleshoot but my understanding of how these CRTs work is much greater now so I am confident that one day I will get it fixed.

Posted on by — Leave a comment

Atari 400 repair

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!

Posted on by — 1 Comment

A Quantum Leap! The Sinclair QL

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