Sega Space Harrier arcade pcb repair

A classic game, and a massive pcb set – CPU board, video board, ROM board and audio board.  The game can be bench tested with just a +5V supply (no need for +12 or -5) but power has to be run separately to each board.  (Forgetting to power the ROM board will give bad or missing sprites!).

This board played fine except only put video out in the blue channel.  A couple of resistors had been clipped out near the video connector but this seemed to be a previous attempt to debug the problem rather than the cause of it.  The real problem was nearby though, the HC273 @ IC111 had failed with all the outputs stuck low.  IC111 handles green & red channels, IC104 handles blue.

Next problem was lack of sound samples – speech & drums.  Synth music worked fine which pretty much guaranteed the sound CPU and program was running properly.  Samples are played by a DAC chip on the audio board, and the samples ultimately come from the ROM chips.  You can think of this process in two halves – the part of the process that sets up the address lines for the ROMs, and the part of the circuit that uses the data that comes out of the ROMs and feeds it to the DAC.  A logic probe showed all the address inputs pulsing as expected, as well as the data output at the ROMs.  The DAC inputs were mostly low, except for some random bursts of static now and again, which at least proved the amplifier was working.  I have to admit I don’t really understand what the circuit involving the DAC data does – there are a bunch of sequential adders and the top bit of the highest adder is what clocks the DAC.  It seems the adders were working but couldn’t ‘count high enough’.  Eventually I found a single dead pin, which was a corroded trace underneath one of the IC’s – what a crazy fault.  With that patched, sound was perfect.

Finally inputs were tested, and the analog joystick inputs didn’t seem to function (each axis can be tested with a 5K pot).  On this board the CD4051 chip at IC125, which is used in converting the analog inputs to digital, was simply missing.  It was cleanly removed so a previous owner must have scavenged it to fix something else.  This part is easily available and a new replacement was ordered, and the game worked perfectly.

Pinout info from http://www.higenekodo.jp/untiku/pinout/harrier_h.htm

Capcom Ghosts and Goblins arcade pcb repair #2

The game played but background tiles were clearly wrong in places as were some of the sprites.  As the game has relatively few tiles I looked in the MAME tilemap viewer first of all – the background mountains started around location 0xf0 in the viewer.  It appeared the tiles from location 0xe0 and up were being drawn instead, so I wondered if bit 4 was stuck somewhere (bit 4 being 0×10 in hex which is the difference between 0xf0 and 0xe0).

Probing around the tilemap part of the schematics I found the A4 output line on the LS273 at 5A was indeed stuck low even while the input was pulsing.  In fact a multi-meter showed the line was physically tied to ground rather than just logically low, so some kind of internal short.  The LS273 was replaced and backgrounds were correct again.

As most of the sprites were correct I suspected the eproms – there are 3 pairs and a failure of any pair would affect some sprites but not others.  Eprom 16 was indeed bad, and sprites were fixed when I burned a replacement.  Underneath the sticker the reason for the failure was obvious – some kind of physical impact had smashed the die.

Namco Galaga 88 arcade pcb repair

Game booted to distorted text.  Although it wasn’t readable I suspected the error related to the custom key chip, a security chip used in these boards.  Swapping the keycus with a known working one enabled the game to boot, confirming the failure.  Luckily the program ROMs can be patched to ignore the keycus completely.

The distorted look applied to all tilemap graphics in the game as well as the text.  A logic probe on the graphics ROMs showed one of the address lines was stuck – that was the reason for the blockiness – repeated pixels because certain addresses could not be accessed.  The tilemap and text is driven by the 123 custom and all signs pointed to that being the cause of the stuck address line.  I swapped it with one taken from a Final Lap board and… no change.  That sucks.  It seems I didn’t check the inputs well enough to that custom as there was a dead input – which in turn caused the stuck output.  Although this custom generates most of the address lines for the tiles LN0, LN1, LN2 come from the CPU board.  This was a physical fault – the pin for LN2 was snapped off inside the connector.  With that patched everything was fine for the main tiles.  The text layer had a little extra fault which was corrosion under the ROM socket.  One of the data lines sometimes did not make good contact between the text ROM at U8 and the 123 custom.

Sega Outrun arcade pcb repair

Game was stuck in a reset loop with only colored lines on screen. Logic probe confirmed the main CPU was continually resetting. I initially suspected the RAM as the TMM2063 chips used on this board can often be unreliable. I piggybacked known good RAM over each chip one at a time and although the game still didn’t work, the colored line behavior changed with the RAM at IC130 and IC115 piggybacked. A change was enough to convince me to desolder this RAM and fit sockets and new RAM. Game worked again!

With the board out of the cabinet this was also a good time to fit the ‘enhanced’ ROM set – http://www.finck.net/outrun/index.html

Some notes on bench-testing Outrun

Outrun is not a JAMMA game of course, so the minimum to bench test is connect +5V and GND to both boards, as well as monitor GND, sync and RGB. Hooking up 12V, -5V or any inputs or sound is not required to get the game to boot.

Konami Aliens arcade pcb repair #2

Game had bad graphics on the intro and missing title screen.  Mask ROM test indicated rom J13 was bad – and it was.  A 27c400 eprom was used as a replacement (if I remember right that’s actually twice as big as is needed, but I didn’t have any others spare.  Instead I used the trick of writing the same data to upper and lower halves of the ROM so it was correct regardless of the state of the top address line).