Skip to content

Arcade PCB fault-finding

How to troubleshoot a dead or faulty game board. Goal: locate the culprit without shotgun-swapping parts. For JAMMA/JVS context see JAMMA wiring.

Before you open it: the environment

  1. Power: +5 V must be set at the board edge under load (harness drop). Too low → crashes/corrupt graphics that get mistaken for a board fault. Check +12 V and −5 V. See power.
  2. Common ground PSU/board/panel, clean JAMMA contacts (eraser, IPA).
  3. Compatible sync/monitor (15 kHz vs 31 kHz).

Procedure (dead board / no-boot)

  1. Visual inspection: corrosion (battery, caps), cut traces, oxidised EPROM legs, leaking SMD caps, burnt parts, dubious prior repairs.
  2. Power at the point of use: measure +5 V on the board; look for a short (raise current-limited, find the hotspot).
  3. Clocks: on the scope, check the oscillator (Xtal) and the CPU clock — no clock, no life.
  4. Reset: the /RESET line must release after power-up (staying low = stuck CPU). Check the reset circuit (often an RC + custom).
  5. Watchdog: many arcade boards have a watchdog that resets if the CPU stops "kicking" it → a 1-2 Hz reset loop on /RESET betrays a CPU that crashes at boot.
  6. Bus: activity on the address/data bus (scope/analyzer) → is the CPU "running" or frozen?

Signal tracing & substitution

  • Good/bad comparison: the most powerful method. With a known-good reference board, compare point by point (clocks, resets, custom outputs) on the scope.
  • Multimeter diode mode: measure the clamp diodes inside logic ICs — a pin that reads different from identical neighbours betrays a dead pin (stuck high/low).
  • Substitution: on sockets, test by swapping (RAM, 74xx logic, GAL, sometimes EPROM). Many faults are work/video RAM or bus buffers.
  • Dedicated tester (Fluke 9010A + POD): inject/read the bus, test RAM/ROM, follow the CPU.

On what conditions a troubleshooting procedure holds ✅

The first chapter of Midway's 1976 test manual is not a procedure: it is a list of assumptions

The Standardized Test Procedure for Midway's Processor Boards (Midway Mfg. Co., ref. MM 1700-1, Franklin Park, Illinois, 55 pp.) is one of the oldest board-troubleshooting documents this wiki holds. ⓘ It covers the 8080 boards of Gunfight and Sea Wolf (1975-76) — a platform this wiki covers on no page. What follows is kept for the method, not for the designators.

⚠️ Before any measurement it states its assumptions — and that is what procedures most often leave out:

  1. ⚠️ "It is assumed that the Mother Board was working once and has gone bad during use, that is, there are no shorts on the board." ⓘ The whole procedure presupposes a board that worked and then failed. A board that never worked — bad repair, wrong part, original short — is not covered. That is the distinction people skip, and it changes everything.
  2. ⚠️ "It is assumed that (a) the Power Supply, (b) the Game Board, and (c) the Tester are all in good working condition. Also the Monitor is synchronized." ⓘ A "bad board" verdict is therefore only valid once those four have been cleared first.
  3. And the tools required: a 50 MHz oscilloscope, a RAM test board with a good test PROM, and a set of good ROMs or PROMs.

✅ The document is equally frank about what it is not: "It does not in any way try to explain how the board works. Throughout the book the major emphasis has been on "How to Fix the Board" and no attempt has been made to describe "How it Works"." ⓘ A repair manual is not an architecture manual — and conflating the two sends you looking in the wrong place.

Its structure by \"case\" — a transposable model

ⓘ Diagnosis there is not a symptom list but a four-branch tree, decided by what you see on screen:

Case What you observe What it points at
A good picture, bad program the program, not the board
B1 bad picture, good vertical lines, no RAM test PROM, decoding (IC 7442), 74174 latches
B2 bad picture, bad vertical lines RAM, bidirectional bus (IC 8216), 74153 multiplexer
B3 bad picture, no vertical lines clock — 3245 driver, 74LS74 flip-flop, IC 9322
C no picture, dead board —
D good picture but corrupted sprite 74166 shift register

ⓘ The name of case D shows how concrete this document is: it is called "Bad Cowboy" — the Gunfight character. And the manual gives the transposition key: "The Mother Boards used in both the games Gunfight and Sea Wolf are identical except for the Program part. […] Substituting "Ship" for "Cowboy" in this book should enable fixing the Sea Wolf games as well."

ⓘ A production figure, in passing: the manual notes in a footnote that the yield of these boards at Midway "is of the order of 99.7 %", the small fall-out being attributed to manufacturing defects.

Signature analysis — the method Atari kept out of its manuals ✅

Some Atari schematics carry four-digit numbers that are neither a part reference nor a component value. They are signatures, and reading them takes a specific instrument.

The principle: a CRC, but in hardware

ⓘ A signature is a cyclic redundancy check (CRC) computed by hardware. A known data stream is pushed through the board, it ripples through the circuits in a repeatable pattern, and what you read at a given point is compared with the value the manufacturer published for that point. ⓘ A mismatch names the faulty stage — and, step by step, the package.

⚠️ The instrument is the CAT Box — Computer Assisted Troubleshooter — sold by Atari from 1981. You remove the game board's processor and plug the CAT Box in its place: through a 50-way fine-pitch edge connector on early boards (Missile Command, Centipede), through a "Pod" adapter in the processor socket on later Z80 boards (Dig Dug).

✅ Four probes, and this is where the method lives:

Probe Where it goes
Start and Stop on the chip enable line of the package under test
Clock on the clock that clocks data through that package
Data on ONE of the data lines

⚠️ One data line at a time. ⓘ An eight-bit ROM therefore takes eight passes and eight signatures — eight values to compare, not one.

Why a hardwired counter rather than the CAT Box's processor

The CAT Box has its own 6502, able to address the whole board. It is not used to sweep the address space: a discrete 16-bit counter does it — four 4-bit counters on two 74LS393, buffered by 74LS244 — cycling $0000 to $FFFF continuously.

⚠️ The reason is not thrift, it is logic. Letting the processor address would mean instruction fetch and execute cycles, which also use the address and data buses — and would reset the Start/Stop stage every time. ⓘ The signature would be scrambled by the very instrument measuring it.

ⓘ The calculation itself: a 74LS193 counter clocks each bit picked up by the Data probe into cascaded 74LS164 shift registers; the output is fed back through exclusive-OR gates to form the next value. ⓘ Sixteen bits out — hence the four hex digits. The Data probe doubles as a logic probe, through LM339 comparators and two LEDs, 0 and 1.

ⓘ And the method is not only for faults: eight four-digit signatures are enough to check a ROM image's integrity.

✅ The document exists, and this wiki now holds it

ⓘ Written earlier on 12 September: "none of the Atari archives this wiki holds is field-service literature". ⚠️ That was true of what it held then. The document arrived the same day:

Tempest™ Troubleshooting Guide, TM-195, 1st and 2nd printing, © 1981 Atari, Inc. — subtitled ⓘ "Complete with Signatures and Memory Map". → Atari vector games

✅ And it bears out the conclusion, while sharpening it: the signatures are neither in the game's technical manual nor on the schematics — they are in a separate troubleshooting guide. ⓘ Atari itself names the four parts of a complete documentation set, in its own copyright notice:

"this troubleshooting guide, the technical manual, its accompanying schematic diagrams, and the monitor manual"

⚠️ The "operator / technician" split was therefore too coarse: there are four tiers, and the troubleshooting guide is the one that did not ship with the cabinet.

⚠️ And the signatures are NOT hexadecimal

The third-party document this started from speaks of "4-hexdigit signatures". ⚠️ That is wrong, and TM-195 shows it.

ⓘ Measured across TM-195's 27 signature table rows: the alphabet used is exactly 0 1 2 3 4 5 6 7 8 9 A C F H P U — the sixteen symbols of Hewlett-Packard signature analysis. ⚠️ No character outside it, and 18 of the 27 values cannot be written in hexadecimal at all: 0PC5, 270P, HPP0, HAP7, 755P, 2A8P, C4U4, H1U9…

ⓘ This is not a notation quibble: anyone expecting hex will read 0PC5 as an instrument fault. ⓘ The CAT Box shows its signatures on seven-segment displays.

What TM-195 gives, and what no explanation replaces ✅

What the guide supplies Example, as printed
Where the three probes go, test by test Start and Stop on A6-3, Clock on C2-39 (Ø2)
Expected signature, pin by pin J5-10 WDCLR → 0PC5 · J5-11 VGGO → 270P
⚠️ Two sanity checks on the set-up probe on ground → 0000 · probe on +5 V → 0001
⚠️ And +5 V does not always give 0001 in the ROM test set-up, +5 V must give 7A70
Hardware precautions "install a 270 pF capacitor between IC B3, Pin 2 and ground" · "To obtain signatures from IC J5, ground R/W testpoint"
CAT Box settings DBUS SOURCE, BYTES (1 / 256 / 1024), R/W MODE (OFF / STATIC / PULSE)

⚠️ The +5 V check is the part people skip and must not: the same probe on the same point returns 0001 or 7A70 depending on the set-up. ⓘ A signature means nothing outside its set-up — which is why the guide restates the settings before every table.

⚠️ What remains true, and what changed

✅ Still true, and verified: across the 11 Battlezone schematic sheets, Cyberball's 19, and the 64 pages of the Battlezone Cabaret TM-166, no signature. ⓘ TM-166 stops at "Printed-Circuit Board Replacement": whoever owns the manuals shipped with the cabinet will not find them in there.

⚠️ What changed: this wiki now holds the document that carries them, and no longer needs a third party to describe the method.

Typical fault patterns (arcade)

Symptom Common leads
Black screen, no image power, stuck reset, clock, watchdog looping, program ROM, sync
Reset loop (~1 Hz) CPU crash at boot → work RAM, ROM, CPU custom, bus
Stable checkerboard / garbage video RAM, character generator, misread graphics ROM
Missing/shifted tiles/sprites graphics ROM (dead bit), tile/sprite RAM, video custom
Frozen colour columns/rows colour/palette RAM, RAMDAC, custom
No sound / hum amp, sound CPU (Z80), YM/OKI, sound ROM, DAC; audio ground
One channel / voice dead sound chip (YM2151/2610…), ADPCM ROM (OKIM6295)
Random crashes low +5 V, marginal RAM, cracked joints, caps
Dead controls input buffers (LS245/244), JAMMA traces, I/O custom

Customs (the hard part of arcade)

  • Many systems rely on ASIC/customs (Sega 315-xxxx, Namco C-chips, Capcom, Konami…) unobtainable new. A custom fault = donor (another dead board), reprofessional rework (reflow/reball) or an FPGA replacement where one exists.
  • Reflow/reball of a QFP/BGA custom: a last resort on cracked joints — see traces & vias / reflow.

Protections & batteries

  • FD1094/FD1089, CPS-2, C-Chip, MCU: a "dead" board may be a flat-battery protection (suicide), not a hardware fault. Check before desoldering → see the relevant system/PCB page and backup batteries.

See also

Sources & attribution

  • Synthesis of established arcade troubleshooting methods (signal tracing, substitution, watchdog); specific values/pinouts = system schematic/manual, not invented.
  • Signature analysis & the CAT Box — How Atari Signature Analysis Works, written by Phillip Eaton, revision 1.1 of 20 September 2001 (first release: 26 December 1999). ⚠️ This is not an Atari document: it is a third party's analysis, reconstructing how the CAT Box works from its schematic. ⓘ This wiki takes the method and the component references from it, with attribution, and does not host the document — it carries its author's personal contact details. ⓘ The author also flags what he believes to be an error in Atari's own diagram (a counter in package B5 apparently cascading into itself); ⚠️ this wiki does not hold the CAT Box schematic and can neither confirm nor deny it.

Review & corrections

How this space is used

Spotted a wrong value, an outdated procedure, a chip reference that does not match your board? Say so here, with what you observed (model, board revision, serial number, measurement). Every report is cross-checked against a source before anything changes — an unverifiable correction is published as “reported by …, not cross-checked” rather than silently applied.

Reading is open to everyone; posting requires signing in with Discord. Reports from the wiki's declared reviewers are handled first; anyone else's are read too, but go through a human before anything is changed.