So, before I started working on this game again, I took a new photo of the graphics PCB so I don’t have to show the old dirty one every time.

So, remember that in Part 1 of this repair log, I replaced a 74LS163 Binary Counter that was broken. Well, I figured that if that one is broken, there is a possibility that there are some other broken ones too. I inspected the PCB and I found another 4 74LS163′s in the top right corner at locations A17, A18, B17 and B18 (next to the 2 rams). Their functionality however appeared to be different from the one I previously replaced. Since their inputs are connected and their outputs go straight to the rams next to them, I think their functionality is to cycle through the rams starting from a given address that can be supplied by another component.

When I tested these four components, I found out that the one on location A17 was faulty. This one drives the four most significant bits of the address lines of the ram at A19.

I replaced it, put in a new one from my stock and plugged the PCB into my arcade cabinet again. And this was the result:

Well, I can hear you think: “That’s not much better. That actually looks worse!”

Actually, that isn’t true. This arcade game (like many others) probably works by rendering odd and even frames in separate portions of the hardware. These frames are then alternated quickly. That’s probably why you can see that one frame is actually quite good, while the other is positioned wrong.

If you keep that in mind and compare the new situation (on the right) with the state it was after the last repair (on the left):

Then you can clearly see that the image has now shifted a bit more to the correct side (to the right).

So this made me realize that there still might be a problem left in that circuit on the top right corner of the board (containing the four counters and two RAMs). I checked those components, I double checked them and I triple checked them. I backtracked the signals until I reached the connector of the PCB. I forward tracked them until I started running in circles. I couldn’t find any other error.

I had checked all other RAMs before and I could remember that there was one on the board that was acting a bit strange, but I left that problem to be solved later. Now it was the time to get back to that.

On the graphics PCB, there is a section of four 2114 RAMs in the lower center of the board in positions H8, H9, J8 and J9. When I checked these, all address lines seemed to fine. However, when I checked the I/O lines, the RAM in position J9 was acting quite weird.

This was an I/O line of one of the other RAMs (they all looked similar):

This was an I/O line of the RAM in position J9:

You can see there’s some traffic, but it’s really faint. And the clear line that is “stable” around 1.5V is not a good sign either…

The problem with RAMs however is that they can be quite hard to debug since the I/O pins are (hence the name) used for inputting and outputting data. This means that if the RAM is faulty and not outputting anything, there will still be traffic on the I/O pins. So this weird measurements could sure mean that the RAM is broken, but it could also mean that a component that provides input to this RAM is doing some weird stuff.

When I traced the I/O pins backwards, I easily reached a 74LS245 (Octal 3-STATE Bus Transceiver) next to it.

This component can be used to isolate two busses (one on the A-pins and one on the B-pins). (If you don’t know what a bus is, you can read more about it here)

The I/O pins of the RAM were connected to 5A, 6A, 7A and 8A. The pins B1 through B8 were connected directly to the data bus of the system.

Since pins 1A through 4A were connected to another RAM and they were working perfectly and a second 74LS245 (also directly connected to the data bus) was working perfectly, it would be very strange if only the lower half of this component had stopped working.

So I concluded the RAM was indeed fried. I replaced the broken 2114 with a 2148 I still had laying around. I know it’s a bit overkill (2148′s are compatible with 2114′s but they are much faster and thus more expensive), but it would be actually more costly for me to order some 2114′s than to use an 2148 I still have. If I ever do order 2114′s I’ll replace the 2148 again, since I socket all chips I replace.

When I put the game back in my arcade cabinet, this was the result:

As you can see, the result is astonishing! The game looks almost perfect. There are only some problems left with the sprites showing up pink. I’ll try to fix that next. Stay tuned for what hopefully should be the last part of this repair log!

Today, I attempted a repair on my Konami Hyper Olympics ’84 PCB that was in my mind already for a long time. It’s easy and short to document this repair, but it really took a long time to do the repair itself!

As a reference, here is a picture of the (lower) graphics PCB again on which I was working in the original condition (in which I bought it):

As you can see on the picture, the four lower roms have had a hard time. You can even see that some pins are green or brown from oxidation.

Well, I did clean the board a lot, but it’s really hard to clean the pins inside the sockets very well. So my plan was to replace the sockets of those four roms. The only thing I needed was a confirmation that this could actually give some benefit, so I fired up my oscilloscope again.

After checking a couple of pins on those roms, I got my confirmation. This is an address line as it’s arriving in good condition on one of the pins on the socket:

And this is what actually arrives on the rom:

It’s easy to understand that a rom can’t do anything with a signal that is this heavily distorted. So I took out the roms of their sockets and I started to remove the first socket.

This was easier said than done. The problem was that the sockets were so close to the PCB that it’s almost impossible to cut under them without damaging any traces on the PCB. I found this out the hard way: I damaged a trace and had to repair it with a wire on the back side of the PCB.

So I switched techniques. I started to destroy all plastic of the socket first by attacking it with sharp pliers (for electronics). When only the metal pins were left, I sucked up as much as solder from the back side of the PCB with a desoldering pump. Then I carefully removed every pin (without pulling it!) while applying heat of my soldering iron to the pin as close to the PCB as possible. Lastly I cleaned all the holes again with my soldering iron and desoldering pump. Soldering on the new sockets went quick and easy.

I have to warn you: when using this technique be very careful while cutting the socket. Only cut when you’re sure that you wont hit the PCB. Don’t put your pliers or any other tool between the socket and the PCB. And never try to pull any pins out of their holes. They should easily fall or it should be easy to take take them out (while applying heat).

The first socket removed. As you can see, the result is quite good. I did first try to cut it from the right side (which you can clearly see in the picture), but that was a bad idea.

This is what was left of the first socket I removed:

Destroying the second socket:

The second socket removed. The result is really good!

Destroying the last socket. The other three new sockets are already in place.

And then I put the PCB back in my arcade cabinet. I expected to see some improvement, but not that much. When I turned on my cabinet, I was completely amazed.

Yes, the screen is still scrambled, but this is a huge improvement since the last time! You can actually see the game now. And I already have a couple of things in my mind I will check during the next fix.

This repair is definitely going the right way. Stay tuned for the next part!

Some time ago I bought a couple of non-working arcade PCB’s pretty cheap. One of them was Hyper Olympic ’84, the Japanese version of Hyper Sports, which is the successor of the insanely popular Track & Field.

When I bought the board, it was almost completely dead. As you can see in this picture, someone probably spilled something over it (my guess would be soda).

These boards were marked GX330 by Konami. My guess would be that the upper board handles the main program and the audio while the second board handles graphics.

When I tried to boot this board I got a still image showing only some characters and a lot of distortion in the image.

Since it was so dirty, it would be almost impossible if the socketed chips would still make good contact. So I removed all of them from their sockets and cleaned them thoroughly. Some of them had so badly corroded pins that they almost immediately broke off when I removed them from their sockets.

After testing the board this time, I still got nothing more than the still image, but at least the distortion went away. I was already making progress.

I realized that I couldn’t continue repairing this board if I didn’t thoroughly cleaned it. So I removed all socketed chips and the ribbon connectors from both boards and cleaned them with water and soap in the sink.

As you can see, both boards were shining as never before!

I let them dry for a couple of days (probably more than long enough, but I wanted to be sure) and when I tested them again, the game actually booted! The game was running and sound was working too, but the graphics were really scrambled.

Yes the graphics are scrambled, yes the colors are weird, yes the orange bar at the left is strange, but this was a huge step! Now it was possible for me to start debugging a working game.

So, after this step, months passed. I actually wrote a thesis, graduated, found a job and made 3 foreign trips before continuing on board.

Today I started debugging. Since, according to me, the lower PCB handles graphical stuff and the 4 (ee)proms in the lower right corner were heavily damaged, I headed straight for those. When I fired up my oscilloscope and checked them, I noticed they weren’t doing anything. There was just no activity at all arriving at their address lines. That means that some other component is faulty so the game can’t even attempt to access the roms.

So I just took a random address line of a rom and traced it back. This brought me to a component 74LS273 (Octal D-type Flip-Flip with clear) in location G13.

As you can see in the picture, this thingy contains 8 D-Flip-Flops (if you don’t know what a flip-flop is, then you can read something about it here). Essentially these things are just memory units which hold the address data before they go to the roms. When I inspected this chip, I found out it wasn’t doing anything. The reason for this was simple to find out: the clock signal that is supposed to drive this chip (flip the flip-flops) at pin 11 was stuck high. So my next move was to trace back where the clock signal was coming from.

I traced it back to the pin 6 of the 74LS32 (Quad 2-Input OR Gates) chip in position F12.

As you can see, this is a very simple chip and pin 6 (2Y) is just the output of an OR-gate with 2A and 2B as its input. And since pin 4 (2A) was tied low to ground, this OR-gate wasn’t performing any logical function. So my guess is that it was just used here as a buffer to amplify the signal or to delay the signal with the duration of one logic gate. Anyway, I had to trace back the input on pin 5 (2B), which was also stuck high.

This led me to a chip in position F18 from which all readings were faded away. On some (horribly scanned and almost unreadable) schematics I found on the internet, I managed to figure out that this was a 74LS139.

The signal I was tracing was an output on pin 5 (1Y1). I checked both corresponding inputs (1A and 1B) and they were both dead, so this wasn’t the culprit either. Both inputs on 1A and 1B brought me to a 74LS86 (Quad 2-Input Exclusive-OR Gate) in position F16. They arrived at pins 11 and 8 respectively.

So actually they were both the output of a XOR-gate. (3Y and 4Y) Since also here both 3B and 4B were tied low to ground, I only had to check 3A and 4A. Both those inputs were also dead. Well, “dead”… The weird part was that they were fixed at about 1.4V, which is not low and not high. It’s something in between. This might be an indication that there’s definitely something wrong. They led me to the chip next to it, a 74LS163 (Synchronous 4-Bit Binary Counters).

Well, this chip is pretty interesting, since it’s a counter. It basically works like this (simplified): you can store a 4-bit binary number into the chip via the inputs A, B, C and D (with A being the least significant bit) and then every time a rising pulse occurs on CLK, the chip will increment the number it has in its memory and output that on the pins Qa, Qb, Qc and Qd. It’s also important to know that the chip will overflow (and thus can keep counting). This is visualized in the following diagram (click for full view):

On my board, the traces I was following connected to Qc and Qd. All inputs (A,B,C and D) and outputs (Qa, Qb, Qc and Qd) were stuck on an unholy voltage of 1.4V. Weird.

I found out that the inputs A,B,C and D were not connected to anything at all and there was a pretty fast clock signal present on CLK. This means this chip is not used for counting, but for lowering the frequency of a clock pulse.

Since a continuous clock signal is present on CLK, this chip is continuously counting in an endless loop. This means that on Qa, the output will switch from high to low and vice versa every time a rise is detected on CLK (because Qa represents the least significant bit of the output). As a result you should get a clock signal on Qa with half the frequency of the one supplied on CLK. This can actually also be seen in the diagram I posted above.

In the same manner a signal with frequency 1/4th of the original must be present on Qb, one with frequency 1/8th on Qc and one with frequency 1/16th on Qd.

Since on this chip on my board all requirements were met for it to produce those signals and Qa, Qb, Qc and Qd were all dead, I concluded that this chip was the culprit.

I unsoldered it, soldered in a socket and replaced it with a 74LS163 (which I still had a couple laying around of), et voilà. The 74LS163 started counting happily and I measured busy activity on the address lines of the roms I started on.

When I plugged the board in my arcade cabinet, the screen was still scrambled (which I expected), but I could already notice some differences. Colors were good, the orange bar on the left had disappeared and I started to notice more textures. So we’re on the right track!

I hope that I can solve this problem entirely and I will post the next fix here too.