How the game is protected

The commercial problem

A 1985 arcade board is a box of standard parts. Anyone with an EPROM programmer can read the ROMs, copy them, and build the same machine from a catalogue. Capcom's entire investment in writing the game is protected by nothing at all - unless the ROMs are useless on their own.

So the program is stored scrambled, and one part on the board knows how to unscramble it. Copy the ROMs without that part and you have a box that does nothing.

Only during instruction fetches

The custom chip sits in the data path between the program ROMs and the Z80, drawn on its own supplementary sheet. The CPU-side data bus goes to one set of its pins, the memory-side bus to another, and the full address bus passes through as well.

The crucial detail is when it acts. It is gated by /M1, the Z80's own signal meaning "I am fetching an instruction", combined with a real memory cycle - $MREQ AND /RFSH, assembled by 6N and the Schmitt inverters at 11J.

So the same byte behaves differently depending on why it is being read. Fetched as an instruction, it is descrambled. Read as data - a lookup table, a text string, a graphic - it comes through untouched.

This is what makes the scheme actually work commercially, and it is worth being clear about why. If everything were scrambled, you could simply unscramble the whole ROM once and burn a clean copy. Because only opcodes are transformed, an offline fix would need to know which bytes the program will ever execute as opposed to read - which means solving the halting problem for the game, or running it and watching. MAME reflects this exactly: it gives the machine a separate opcode address space and decrypts into that, leaving the normal data view of the same ROMs alone.

The chip sits in the data path between the program ROMs and the CPU, and it only acts when the Z80 signals an opcode fetch with /M1. Tables, text and graphics read from the same ROMs pass through unchanged, so the scrambling cannot be undone offline without knowing which bytes the program will ever execute.

What the scrambling actually is

Now the anticlimax, and it is a pleasing one. The transformation is a fixed rearrangement of eight wires.

Bits 0 and 4 pass straight through. The other six rotate across the nibble boundary: bits 1 to 3 move up four places, bits 5 to 7 move down four. MAME expresses it as one line: dst = (src & 0x11) | ((src & 0xE0) >> 4) | ((src & 0x0E) << 4).

No key, no state, no arithmetic, nothing that varies with the address. In principle a handful of wires crossed over would do it - the reason it takes a 48-pin package is not the swap itself but the gating, and mostly the sheer number of pins needed to pass a full address bus and two data buses through one part.

Which raises the obvious question: why bother, if it is that simple? Because it does not have to be strong, only inconvenient. A rival needs to work out the mapping, notice it only applies to opcodes, and then manufacture a part that does it. That is weeks of work and a custom component for a product with a commercial life measured in months.

The entire protection scheme, drawn out. It is a fixed rearrangement of eight wires with no key, no state and no arithmetic - which is exactly why it was replaceable by a bootlegger with one PAL, and exactly why it still worked commercially: the swap only happens during instruction fetches.

How it was beaten, twice

It was beaten, of course, and both boards in this project are proof. Guru's hardware notes put it plainly: on bootlegs the custom chip is replaced by a PAL, a 74LS245 and a 74LS08 on a plug-in sub-board.

That is the entire counterfeit. A programmable logic device to perform the bit swap, a bus transceiver to drive the data, one gate to combine /M1 with the memory cycle. Three standard parts on a riser, replacing a chip nobody outside Capcom could buy.

The two boards here took different routes. The dirtier board carries exactly that: a PAL16L8 riser plugged into the custom socket at 10M. The cleaner board solves it in software instead, with the descrambled code stored directly in the ROMs. The two are distinguishable by a single byte - the very first opcode the CPU ever fetches - and MAME encodes that difference as two separate decrypt routines, one commented "the first opcode is not encrypted" and the other "the first opcode is encrypted".

There is a whole page on each of those boards: the PAL riser and the on-board PAL.

A note on what the socket at 10M means

If you are ever looking at one of these boards, the socket at 10M tells you most of what you need to know. An original Capcom machine has a 48-pin custom chip in it. Anything else - a riser, a daughterboard, an empty socket with the code stored plain - means you are holding a copy.

It is also, appropriately enough, the single most likely thing to be wrong on a board that powers up and does nothing at all. If the opcodes arriving at the CPU are wrong, the very first instruction is already nonsense, and the machine never gets far enough to show you a symptom.

The drawings behind this story

Each one opens the interactive schematic, where every chip and every net on the sheet can be traced pin by pin.

Every chip in this story

3 chips across 1 sheet. Click any of them to open the schematic with that chip selected. A few appear on more than one drawing, because Capcom split some packages across sheets.

← back to the dashboard