Hints on repairing arcade boards

A little disclaimer: for a few years I've been repairing arcade boards, with varying degrees of success. This guide was written in the hope that the few nuggets of knowledge I've picked up along the way might be useful to other people trying to repair their own faulty games. But please be aware that I'm not a professional repair engineer so the advice given below may well differ from the wise teachings of the cognoscenti. And most importantly of all, I will not accept any share of responsibility for any damage or injury that results from following the advice below.

That said, I hope you find this guide useful when nursing any faulty games you might have back to health. Good luck!

Contents

Scope
First Steps
Tools
The Video Probe
Pinpointing Faulty Components
Game is running but inputs are faulty
Game is running but has graphic problems
Game is running but has sound problems
Game is not running

Scope

This is not a comprehensive guide to repairing arcade boards. It's a write-up of the experience I've picked up while repairing the sort of games I collect, namely raster games from 1979 to early 90's. (I collect more recent games too but generally don't even attempt to diagnose and repair them).

First steps

You have a game board. It's not fully working. For now, we don't care quite how; the salient point is that there is some fault and you've already ascertained that it's not due to the monitor, controls, speakers, etc, probably by testing the setup with a known-good board.

The four usual suspects below are some of the most common causes of arcade board faults, yet are the easiest to diagnose and fix. Furthermore, when examining more tricky repairs we need to be sure that the possible causes below can be discounted:

1) Test that the power supply voltages are good

In general, games have the following power connections:

5 Volts - this is the most critical power input to the board, feeding all the logic chips. Though some games are more fussy than others, this input must usually lie within 0.25V either side of +5V. Virtually all boards have a voltage regulator IC to give better tolerance to inaccurate input voltage, but there are exceptions among quite old boards, for whom even a small voltage discrepancy can cause a wide variety of different symptoms.
     A poor +5V input is a likely suspect if the board is suffering from multiple, unrelated problems. For example, startup tests may fail, but citing a different ROM/RAM each time; at the same time the video sync may be erratic, incorrect sounds may be played, controls act on their own or fail altogether, and the behaviour of the game program generally is a little mad. As a general rule of thumb when repairing boards, assume that the most simple possible explanation for the symptoms is the most likely. Should you encounter a game exhibiting many of the problems just described, the power supply should be considered the most likely culprit as the chances of components going faulty in all the separate systems affected is highly unlikely.
     It's best not to measure the 5V line near the harness or power supply as the voltage will be less by the time it actually reaches the components. Instead choose an arbitrary logic chip and apply a voltmeter across its power pins (the 'bottom left' and 'top right' pins, if the chip's notch is considered 'top').

12 Volts - usually the 12V line is only used to power the sound amplifier. Some boards I've seen use it to also drive the video output signals.

-5 Volts - this input is often not used. However some old RAM chips require a -5V input and will eventually be damaged if this power line is not received.

2) Test for touching bent pins on underside

When boards have been pressing against each other in storage the pins on the 'solder side' can bend and touch each other, causing all manner of malfunctions.

(I've noticed that Capcom CPS1 boards (Street Fighter II, Final Fight etc) are particularly prone to this happening as they frequently have long component legs and no mounting feet).

Boards which have been scraping against each other due to bad storage conditions may suffer from PCB tracks being cut. A careful visual inspection is required to identify such occurrences, which usually only affect the boards' solder sides.

This problem occurs very frequently and the physical damage can sometimes be extremely subtle.

4) Test that socketed components are inserted correctly

Inter-board connectors and socketed ICs which are not inserted correctly can cause a very wide range of problems. Test that all such components of your board are making good contact.

Occasionally (though quite seldom in my experience), accumulated grime on the legs of socketed components will result in a poor connection being made. For these occasions a small pencil eraser is regarded as a good tool for cleaning the legs.

Tools

Depending on how involved your board repair job may be, the following tools may all be necessary at some point.

Multimeter - must be able to read voltages to at least one decimal place for power supply checking, and have a continuity test bleeper for tracing and testing PCB tracks. Any extra features aren't particularly necessary.

Soldering iron - for circuit board repair work, the smaller and lighter the better. Your iron really shouldn't need to be particularly high powered. For touching up soldering on surface-mount chips you'll really appreciate having something small and light with a sharp pointy tip (and also a scalpel and magnifying glass). I use a 12W Antex iron from Maplin, which turns out to be one of the cheapest available. I'd also usually recommend using as thin a solder as you can get. For desoldering and making harnesses I use thicker solder and a more powerful iron with a larger tip.

Solder sucker - (a spring-powered syringe for sucking up excess solder). Inexpensive and absolutely invaluable. Desoldering braid (fine braided copper wire for mopping up mess) is also useful for delicate work, but buy the sucker first.

Other small hand tools - small pliers, snips and small screwdrivers are pretty essential.

Aerosols - contact cleaner and Fluxclene can often come in handy. Fluxclene is a strong solvent used for removing the flux in solder which over time can rot, damaging the PCB. It's also invaluable for removing marker pen and residues of sticky labels. Occasionally it can be too strong for certain boards and can itself attack the solder mask (PCB coating, usually green) so use carefully.

Wire-wrapping wire- wire for patching tracks on boards or re-routing signals should ideally be very thin, solid-core insulated wire. 'Wire-wrapping wire' (not to be confused with Maplin's wire-wrapping pen system which is too fine to be practical) is ideal for these applications.

Video probe - read on...

If you want to delve deeper it'll usually mean spending a little more cash. However, the following tools are really worthwhile:

EPROM programmer- old EPROMs can be prone to failure. A programmer isn't cheap but is pretty essential.

Oscilloscope- although a video probe is often the only visualisation tool you'll need, there are some occasions (such as probing the sound and video sync systems) where an oscilloscope may be necessary. Appropriate old, second-hand scopes can be picked up reasonably inexpensively.

The source code to MAME- The MAME source code gives a fantastic insight into how the various systems that compose a game board work together. Although MAME is more focussed on appearing correct to the player than accurately representing the behind-the-scenes game workings, its source code can give a lot of information that just wouldn't be available elsewhere. Furthermore by playing about with the code you can attempt to recreate by simulation the hardware problems your game is facing. And best of all it's free!

If you've got all these, you should be kitted-up pretty well for finding most commonly-occurring board problems. But not all. It can be extremely difficult identifying malfunctioning devices which output on common signal lines (eg. CPU busses) in a non-destructive manner. Sadly, lots of components fall into this category. The final tool in the chest would be a logic analyser and/or CPU emulator, which sadly would probably set you back a small fortune and yet still wouldn't be a silver bullet for tracking down faults.

The video probe

Detach the red, green or blue video output from your JAMMA harness and source the newly-orphaned monitor input from a loose wire via a protection resistor (I once heard 470 ohms recommended). What you'll just have made is known as a video probe, one of the most useful tools for diagnosing board faults.

Holding the loose wire(s) against component legs allows signals from the board to be visualised. The effective 5 MHz sample resolution, huge 16 ms capture window and three channel display provided by the existing game monitor gives far more powerful visualisation abilities than those of most oscilloscopes. The format of the signal representation is also (usually) more convenient, especially as it enables signal values to be correlated with positions of the raster display.

A video probe relies on a good sync signal being output from the game. Some monitors (and especially TVs) cut off the display if the sync signal is missing or bad, rendering the tool useless. In these situations you'll need to use a logic probe, or better still an oscilloscope, to identify the cause of the broken sync.

One last point to make - the tool will draw a tiny amount of current from the line it's touching. This isn't usually an issue, but if you touch one of the pins of the crystal from which the sync signal is derived its timing will be affected and your monitor will make a horrible noise trying to adjust. This probably isn't very healthy for your monitor (I disclaim all responsibility) and should be avoided!

Pinpointing faulty components

Having eliminated the usual suspects as the cause of the board's problem, we conclude that the fault is caused by a broken component and will attempt to pinpoint the culprit by considering the symptoms. Needless to say, hunting for a faulty component is a much easier task if you happen to have a known good copy of the game with which you can swap component boards and socketed chips or observe the correct behaviour of certain relevant signals.

Most arcade boards comprise three systems: CPU, graphics and sound. Since the latter two are entirely controlled by the CPU, we need to be sure that the CPU system is fully working before trying to solve problems which impact on the graphics or sound. The question of whether the game is indeed 'running' is usually easily answered - many faults manifest themselves as video or audio glitchiness, where the game can clearly be seen playing. For severe graphic problems (either no display or a completely meaningless one), we may need to coin the game up to hear if the sounds indicate that behind-the-scenes it's actually playing OK. And if we suspect a multiple fault in which both video and audio systems are severely affected, the question of whether the game is running may only be answered by holding a video probe to a CPU bus line and judging if the signal looks typical of a running game. But such cases are very rare.

A game which appears to run fine but locks up or resets occasionally, or a game which fails a self-diagnostic test of the CPU system (through RAM/ROM checks) should be considered 'not running'.

Game is running but inputs are faulty

Input systems are not typically very complicated. For most games which use only buttons and joysticks, a buffer/bus driver chip is used to connect inputs (up to eight at a time per chip) directly to the CPU. If this chip is blown a number of inputs will die. Simple.

There's a very good reason why this interfacing chip is vulnerable: as well as serving joystick and button inputs, the chip also interfaces the coin input. If a coin counter is to be connected to this input it must be through a diode; without it the surge of back EMF caused by de-energising the coils in the counter can zap the input chip. Some arcade proprietors are either not aware of this danger or don't consider the protection to be worth the effort.

Repairing a board which has suffered this fault is a straightforward task. Trace the PCB track of an affected input from the edge connector and replace the first chip you come to (not mistaking it for the filters and pull-up resistor arrays that the signal passes through first, which can sometimes be in a similar but distinctively different DIL package).

Games which use more sophisticated controls can rely on the same principle, but with a level of indirection to decode the input before passing it to the buffer chip, such as analog-to-digital conversion for games using analog joysticks, steering wheels connected to potentiometers, etc. Games which use spinners, trackballs etc. must feature circuitry to count the number of pulses received by the sensors as this is likely to be greater than the once-per-video-frame polling rate which is convenient for the game software.

While the simple bus-driver solution is adequate for a large number of games, some choose instead to use a custom I/O chip for interfacing. (Checking the source code for MAME can indicate when this is the case - look for comments indicating that the memory-mapped I/O is fake).

Game is running but has graphic problems

Floating inputs

Unconnected inputs to graphic-related chips (usually caused by broken tracks on the PCB) can cause graphical elements to exhibit a characteristic 'static' effect. To locate the 'floating' input, gently run your fingers/hands over the legs of all the components on the underside of the board/s. This can require great patience and a little care to not cause undue lacerations. When the floating input is touched, the stray EMF generated by your body will drive the input and a noticeable change to the pattern of the static should be seen on-screen.

When the individual pin has been identified (which can require quite a bit of dexterity), trace its PCB track back to the input component. Verify the continuity of the track using a continuity checker (note: not all broken tracks are visibly damaged). If the continuity is broken, install a patch wire. Otherwise it looks like the output driver from the input chip has died - use a video probe to find out.

Thermal failures

Graphical glitches which occur when the game has been left on for a while may be caused by a component whose failure is influenced by heat. Applying aerosol-coolant to different regions of the board should enable the affected part to be identified.

Bad ROMs

A bad graphics ROM should cause a well-defined subset of graphical elements to be disturbed. The easiest way to identify the problem chip is by running the game on MAME with a good set of ROMs and systematically ruin each graphic ROM image in turn (renaming some other random file is easiest) until the same subset of graphical elements is affected as your faulty board. The MAME source code will tell you which of the image files are related to graphics elements and will usually further help by suggesting whether they're characters, tiles or sprites.

Once the target chip has been identified try reseating it in its socket. If this doesn't work, try cleaning its legs with a pencil eraser and reseating. If this still doesn't work chances are you'll have to burn the known-good image onto a fresh EPROM. And if that doesn't work, check the integrity of the ROM sockets and the PCB tracks leading to it.

Bad RAMs

The telltale sign of a ROM being bad is that detail within a character, sprite or tile is incorrect. The telltale sign of a RAM being bad is that the character is correctly drawn, but in a place where it shouldn't be. Or lots of places it shouldn't be. Or it's missing altogether, as are all the other characters. Or sprites. Or tiles. Etc.

Most games use a double-buffering technique to ensure smooth animation, under which display RAMs are divided into two banks. As one set is being written to by the CPU to 'draw' the next frame, the other is being read by the video hardware to 'display' the current frame. A failure of a RAM chip in one of these banks can lead to a very characteristic rapid flickering (30 Hz) of some display elements.

Identifying which of a number of display RAM chips on a board is faulty is not an easy task. A useful technique that can sometimes help is 'piggybacking' a known good chip on top of a candidate suspect one. If a good RAM is held on top of a faulty one, the outputs should fight each other and some change to the fault pattern should be visible on-screen. It's probably worth mentioning that having the good chip's outputs fight those of the faulty one isn't going to do the good chip any good.

The problem with ROMs and RAMs

...and bus-contributing devices in general is that they can develop a fault which causes them to output at the wrong time. When a shared signal is being permanently pulled down by one device it can be impossible to identify the culprit without pulling devices out of the circuit. This is fine if the chips are socketed and an absolute pain if they're not.

Game is running but has sound problems

Dead amplifier

Failure of the sound amplifier is a common fault, probably related to the fact that these things can get extremely hot when the board is on. To test the amplifier, turn the volume control all the way up. If you can hear a background humming/buzzing then the amplifier's fine. Otherwise it's probably blown, though other causes could include a broken volume control or a bad +12V power line.

Some sounds are missing

A large number of games feature more than one sound-generator IC (PSG). If a subset of sounds is missing, the chances are one of these PSGs has died. Common chip numbers for sound generators include AY-3-891x, and YMxxxx (plus dozens of others - see sndintrf.h of the MAME sources).

Amplifier is OK but there are no sounds

Assuming your board has more than one sound generator IC, the complete absence of sounds implies that the circuitry that drives the PSGs has gone. For the vast majority of boards, these generators are driven by a separate CPU (very often a Z80). Assuming this is the case, use a video probe and proceed to examine the sub-CPU system as you would the main CPU system (see 'Game is not running').

The wrong sounds are being played

Most likely an address bus line to a samples ROM is being lost somewhere, possibly inside the ROM itself. Verify the sound ROMs with an EPROM burner and ROMIDENT, or swap them for ones from a known good board.

Sounds are all present but there's some background noise

In my experience this is usually caused by physical damage to an analog component such as a capacitor having an amputated leg. Poor grounding or power supply noise could also be a factor, but analog electronics ain't my thing. Sorry!

Game is not running

The same common causes of failure for video systems (bad ROM, bad RAM, broken tracks, thermal failure, etc.) can equally apply to the CPU system, but since code execution is an all-or-nothing affair, identifying the faulty component is a much more difficult task.

Bad CPU control signals

A number of elementary support signals must be provided to a CPU before it can execute code, notably clock, interrupt and reset lines. If a video probe shows no activity taking place on the CPU's data or address busses you should first suspect these support signals. If the support signals check out OK but the bus signals are static, the CPU itself is likely to have died.

Verifying that the interrupt lines (names such as INT, IRQ, NMI) are not held down is an easy task. The reset line is more difficult since it should be pulsed once very briefly when the game is first powered up. Verifying that it's not being held down is easy*, but testing whether it was pulsed in the first place isn't. Use a patch wire to ground it yourself momentarily, and see if that brings the game up. If it does, try to figure out the logic that's supposed to drive the signal and look for faulty components along the way. If it doesn't the signal's not the problem so probably isn't suspect.

Clock signals meanwhile are in the order of several MHz, so video probes and cheap oscilloscopes often can't display a sufficiently high bandwidth to adequately visualise them. However, a mid-brightness pattern on a video probe indicates that the clock is probably OK, especially if a vague moire pattern can be seen. If a valid clock signal cannot be seen as input to the CPU, trace the signal back through the components that generate it until you hit a device whose output does not correspond to its input.

* Before completely leaving the subject of the reset line, it's worth mentioning watchdog timers. There are countdown circuits which pulse the reset line after a fixed unit of time. If the game code is executing OK, a signal is regularly sent to the watchdog timer to reset the countdown and stave off the reset. Watchdog counters serve both to boot-up the game on power-up, and to reset it if it crashes due to a bug in the program code. If you see that the reset line has a regular pulse, it's just the watchdog timer doing its job; the failure of the CPU to read valid code is the likely cause, not the reset line logic.

Code ROM failure

Most boards perform a self-diagnostic test on bootup in which the integrity of the code ROMs is verified. Others (and often bootlegs) don't. And a self-check of code ROMs is only going to work if the ROM which contains the code for the tests is not faulty itself.

Having established that the CPU's bus signals look as if it is at least trying to execute code, you should conduct a thorough test of the code ROMs (use an EPROM burner and ROMIDENT or swap with ROMs from a known good board). Symptoms of a faulty code ROM include a completely meaningless (usually frozen) display on startup, or consistent crashes at the same point during gameplay. Or if you're lucky, a message on bootup which reads something like 'BAD ROM 3' :)

Be aware that the results of self-diagnostic tests can often be incorrect. That it identifies a problem with a particular chip means either that the chip itself is faulty, or that the internal data pathway to the chip is bad. As an example, the sound ROMs/RAMs are often included in the tests and might not be directly accessible by the CPU bus. Verifying these chips entails passing a request to the sound hardware to self-verify and reporting the results. If the path to the sound hardware is damaged, or the ROM on the sound hardware which performs the test is faulty, the display can report that *all* the sound ROMs and RAMs are bad. (Konami boards seem to frequently suffer from this). As said before, multiple failures are relatively rare. If a diagnosis reports numerous problems, suspect a deeper cause.

Suicide batteries

As an anti-piracy measure, some manufacturers encrypt certain game ROMs and use a key held in battery-backed RAM to perform decryption. Once the battery runs out of juice the contents of the RAM are lost and the game stops working. For some affected boards a set of decrypted ROM images have been obtained which together with some minor board modifications can bring the game back to life.

Affected boards include most Gaelco games, late Capcom pre-CPS1 games (Pang etc.), late CPS1 games (Cadillacs & Dinosaurs, Punisher, etc.), all CPS2 games, many Sega games from System 16 onwards, and a small number of assorted others.

For an excellent guide to reincarnating dead-battery games, see the Dead Battery Society.

Other possible causes

Repairing non-running games is a painful task as any of a large number of possible devices may have broken. Consider the case of the dead bus driver which had been zapped by a coin counter, mentioned in 'Game is running but inputs are faulty'; if the chip had died in such a way that it held one of the output lines low, the entire game would be brought to a halt. Identifying which of the numerous bus devices was ruining the common signal would mean butchering the board, replacing each candidate chip with a known good one until the faulty chip was eventually found.

Still not working?

Oh well, never mind. You win some, you lose some.

Mike Dean, October 2001

My email address is mike@mailnet.co.uk but I'll be out of the country until December and will have limited net access during this time.