For decades, video game collectors treated arcade printed circuit boards as industrial artifacts engineered for eternity. Heavy fiberglass FR4 substrates, rugged edge connectors, and military-grade solder masks created an impression of permanent durability. That physical solidity masked an intentional architectural vulnerability. During the late 1980s and throughout the 1990s, major Japanese arcade manufacturers introduced hardware-level copy protection schemes designed to self-destruct. Driven by aggressive competition against bootleggers in East Asia, companies like Sega and Capcom embedded cryptographic keys into volatile Static RAM chips kept alive by soldered lithium batteries.
When that battery drops below two volts, the encryption keys evaporate permanently. The central processor suddenly receives scrambled ciphertext, encounters illegal instruction traps, and halts execution forever. Across the community, this planned obsolescence mechanism earned a grim technical label: the suicide battery.
What began as an aggressive commercial copyright defense degenerated into an archival nightmare. Thousands of rare arcade titles—from Alien Syndrome and Shinobi to Super Street Fighter II Turbo and Dungeons & Dragons: Shadow over Mystara—became digital corpses while sitting untouched in climate-controlled collections. Only years of relentless open-source hardware reverse engineering rescued this legacy from corporate neglect.
+-------------------------------------------------------------------------+
| Capcom CPS-2 B-Board Security Architecture |
| |
| +-------------------------------------------------------------------+ |
| | Encrypted Program ROMs | |
| | * Mask ROMs / 27C160 EPROMs holding ciphertext 68000 opcodes | |
| +-------------------------------------------------------------------+ |
| | |
| v (Encrypted 16-bit Opcode Data Bus) |
| +-------------------------------------------------------------------+ |
| | Capcom DL-1520 Custom Security ASIC | |
| | | |
| | +-------------------------------------------------------------+ | |
| | | Volatile Key Storage (Internal SRAM) | | |
| | | * Two 4-round Feistel Ciphers | | |
| | | * Dynamic 64-bit Encryption Keys | | |
| | +-------------------------------------------------------------+ | |
| | ^ ^ | |
| | | | | |
| | | Power Rail | Programming| |
| | +-------------------+ +-------------------+ | |
| | | 3.6V 1/2AA Battery| | CN9 Test Header | | |
| | | (Tadiran Lithium) | | (Factory Key Port)| | |
| | +-------------------+ +-------------------+ | |
| | | |
| | * Real-Time On-the-Fly Opcode Decryption Engine | |
| +-------------------------------------------------------------------+ |
| | |
| v (Decrypted Plaintext 68000 Instructions) |
| +-------------------------------------------------------------------+ |
| | Motorola 68EC000 Microprocessor @ 16 MHz | |
| | * Fetches clean opcodes -> Normal execution | |
| | * Dead battery -> Corrupt opcodes -> Illegal instruction trap | |
| | * System halts -> Solid green / cyan / blank screen of death | |
| +-------------------------------------------------------------------+ |
+-------------------------------------------------------------------------+
The Rise of Hardware DRM in Coin-Op Silicon
To understand why arcade manufacturers engineered self-bricking hardware, one must look at the cutthroat economics of late-twentieth-century arcade distribution. In the 1980s, coin-operated video games represented the bleeding edge of interactive computing. Developing landmark titles required massive capital expenditures for custom graphics synthesizers, tile engines, and sound DSPs.
Yet coin-op hardware faced immediate exploitation. As soon as a hit title arrived in operator locations, unauthorized workshops in Taiwan, South Korea, and Hong Kong desoldered the standard EPROMs, duplicated the binary images, cloned the motherboard logic onto cheap multi-layer boards, and sold counterfeit PCBs at a third of the manufacturer list price. Standard software copy protection was useless; bootleggers simply disassembled the machine code, bypassed branch conditions with NOP instructions, and burnt modified binaries into blank chips.
Manufacturers responded by shifting protection into silicon. Sega pioneered this strategy in 1986 with its Pre-System 16 and System 16B hardware platforms, deploying custom security microprocessors designated FD1089 and FD1094. As documented in technical references on the FD1094 and FD1089 Suicide Battery Architecture, Sega encased a standard Hitachi or Motorola 68000 core inside an opaque epoxy module alongside a lithium coin cell and an 8-kilobyte battery-backed SRAM table.
+-------------------------------------------------------------------------+
| Sega FD1094 Potted Cryptographic CPU |
| |
| +-------------------------------------------------------------------+ |
| | Opaque Plastic Epoxy Housing | |
| | | |
| | +-----------------------+ +-----------------------+ | |
| | | Standard 68000 Core | | 3V Lithium Coin Cell | | |
| | | (16/32-bit CISC CPU) | | (Permanent Welded) | | |
| | +-----------------------+ +-----------------------+ | |
| | ^ | | |
| | | Internal Bus v Standby Bias | |
| | +-------------------------------------------------------------+ | |
| | | Volatile Decryption RAM (8 KB Decryption Tables) | | |
| | | * Opcodes decrypted inside the chip casing before execution| | |
| | +-------------------------------------------------------------+ | |
| +-------------------------------------------------------------------+ |
| | |
| v 64-Pin DIP Footprint |
| ===================================================================== |
| Sega System 16/18/24 Motherboard |
+-------------------------------------------------------------------------+
As detailed across technical teardowns on Decryption and Removal of Suicide Batteries in Sega Boardsets, the FD1094 intercepted program memory addresses and decrypted opcodes internally before feeding them into the CPU arithmetic logic unit. External address and data buses carried purely encrypted signals. If anyone attempted to pry open the epoxy casing or if the welded battery expired, power to the internal SRAM vanished. The decryption table was wiped in milliseconds, leaving behind a completely unresponsive, inert plastic block.
Capcom took this concept further. On the Capcom Play System 1 (CPS-1), Capcom initially customized its CPS-B graphics ASIC for individual games. However, fabrication costs mounted with every release. As historical analyses on Capcom CPS1 Hardware Architecture demonstrate, Capcom solved this production bottleneck with the CPS-B-21 revision. They integrated battery-backed configuration registers directly into the ASIC, allowing factory line workers to program game-specific register mappings into volatile memory without cutting new silicon masks.
When Capcom launched the CP System II (CPS-2) in 1993, they perfected this defensive weapon. As documented in the comprehensive CP System II Technical History, the platform separated games into two interlocking plastic shells: the "A" board containing the power regulation, JAMMA edge, and video DACs, and the "B" board housing the game ROMs and custom ASICs. To run Super Street Fighter II, Darkstalkers, or Alien vs. Predator, the host system required continuous mathematical handshake validations performed by custom silicon.
+-------------------------------------------------------------------------+
| The Voltage Decay and Suicide Timeline |
| |
| Battery Voltage: |
| 3.6V |==========================================\ |
| | \ <- Critical Knee |
| 3.0V | \ |
| | \ |
| 2.0V | - - - - - - - - - - - - - - - - - - - - - - -\ - Low Voltage Trap|
| | \ |
| 1.0V | \ |
| | \ |
| 0.0V +--------------------------------------------------\------------> |
| Year 1 Year 5 Year 10 Year 15 Year 20 Year 25 |
| |
| [ Operational Phase ] [ Chemical Breakdown & Erasure ] |
| * Standby current ~1-2 µA * Passivation layer collapses |
| * Volatile SRAM stable * Voltage plummets in weeks |
| * Opcode decryption verified * SRAM zeroed; board suicided |
+-------------------------------------------------------------------------+
The Cryptographic Anatomy of Capcom's DL-1520
The security heart of the CPS-2 B-board is a custom ASIC labeled DL-1520. For decades, the retro engineering community debated how this chip operated. Many assumed it was merely an address scrambler. The truth proved far more advanced.
Independent reverse-engineering work covered by Hackaday's Teardown of Capcom Custom Silicon Security revealed that the DL-1520 implements two four-round Feistel ciphers driven by a 64-bit cryptographic key. When the Motorola 68EC000 requests an instruction from the program ROMs, the DL-1520 intercepts the 16-bit ciphertext word on the fly. Within a single bus clock cycle, the chip routes the encrypted word through its Feistel substitution-permutation network, reverses the encryption using the active key stored in battery-backed SRAM, and outputs plaintext opcodes onto the CPU internal bus.
+-------------------------------------------------------------------------+
| Feistel Opcode Decryption Cycle in DL-1520 |
| |
| Encrypted 16-bit Opcode from ROM |
| | |
| v |
| [ Split Word ] ----> Left Half (L0) & Right Half (R0) |
| | | |
| v v |
| Round 1: L1 = R0 R1 = L0 ^ F(R0, Subkey_1) |
| | | |
| v v |
| Round 2: L2 = R1 R2 = L1 ^ F(R1, Subkey_2) |
| | | |
| v v |
| Round 3: L3 = R2 R3 = L2 ^ F(R2, Subkey_3) |
| | | |
| v v |
| Round 4: L4 = R3 R4 = L3 ^ F(R3, Subkey_4) |
| | | |
| +--------+----------+ |
| | |
| v |
| [ Combined 16-bit Plaintext ] |
| | |
| v |
| Dispatched to 68000 Execution Core |
+-------------------------------------------------------------------------+
This cycle-accurate decryption engine functions seamlessly as long as the 3.6V Tadiran lithium thionyl chloride battery maintains sufficient voltage across the ASIC standby pin. Under normal conditions, the SRAM logic consumes a minuscule quiescent current of roughly 1 to 2 microamps. At this draw, a 1/2AA cell theoretically holds enough capacity to survive a decade.
Once that cell reaches its chemical exhaustion curve, the voltage curve drops off a cliff. When VCC falls below approximately 2.0 volts, the flip-flops inside the internal SRAM lose their bi-stable state. Bits flip randomly, and the 64-bit key collapses into indeterminate zeroes and ones.
The moment an operator or collector applies mains power to a board in this state, disaster strikes. The 68000 attempts to read the initial stack pointer and reset vector from addresses $000000 through $000007. Because the DL-1520 applies corrupted key mathematics to the encrypted boot ROM, the CPU receives garbage instructions instead of valid program entry routines. Within a few clock cycles, the processor triggers a software trap—typically an illegal opcode exception, address error, or bus error.
The system hardware hangs. The video pipeline cannot initialize tile registers or palette tables, outputting a uniform, single-color framebuffer. In the arcade restoration scene, this symptom is unmistakable: * A solid yellow screen indicates an early CPU initialization failure. * A solid green screen indicates the program ROMs were read, but the decrypted execution thread crashed before graphics hardware handshakes occurred. * A solid white or cyan screen signals a total memory parity collapse.
The hardware is physically intact. The custom silicon is undamaged. Yet the game is dead.
The Preservation Crisis and Collector Fetishism
During the active lifespan of the CPS-2, Capcom maintained an official service protocol. Arcade operators with dead boards could ship the cartridge back to Capcom, pay a servicing fee, and factory technicians would connect proprietary equipment to reload the cryptographic key and solder a fresh battery. By the early 2000s, Capcom discontinued maintenance operations for legacy platforms. The official revival pipeline closed permanently.
What followed was a dark era for physical arcade preservation. Collectors without technical engineering training discovered that their favorite boards were dying en masse in storage. In response, early romhackers and arcade enthusiasts sought destructive workarounds.
As documented in the Arcade Otaku CPS2 Maintenance Guide, the first widespread revival solution emerged in 2001 via the CPS-2 Shock group and hacker Razoola. Known as "Phoenix Edition" code, this technique bypassed the security ASIC entirely. Razoola analyzed decrypted memory dumps obtained through hardware probes, extracted the plaintext code, and produced modified ROM images.
+-------------------------------------------------------------------------+
| Destructive "Phoenixing" vs Clean Preservation |
| |
| [ Original Dead CPS-2 Board ] |
| | |
| +------------------------------------+ |
| | | |
| v v |
| [ The 2001 "Phoenix" Hack ] [ 2016 Open Desuicider ] |
| * Cut the battery off * Connect Arduino to CN9 / CN2 |
| * Discharge capacitor to erase ASIC * Pulse original 64-bit keys |
| * Desolder original factory mask ROMs * DL-1520 SRAM restored |
| * Burn modified, hacked EPROMs * Keep 100% factory mask ROMs |
| * Solder jump wires to PCB pads * Zero PCB traces modified |
| | | |
| v v |
| Permanently Altered Hardware Factory-Authentic Operation |
| (Destroys Museum/Collector Value) (Flawless Historical Integrity) |
+-------------------------------------------------------------------------+
Reviving a board with Phoenix ROMs demanded severe, permanent alterations: 1. Collectors clipped and discarded the battery. 2. They intentionally shorted the capacitor pins beside the DL-1520 to completely clear any residual charges in the ASIC logic. 3. They desoldered original, factory-branded mask ROMs from the PCB. 4. They burnt decrypted, patched code into modern UV EPROMs and soldered them into the board. 5. In several revisions, technicians had to solder jumper wires across motherboard traces to force specific memory bank selections.
Phoenixing rescued games from total oblivion, but it was archival butchery. It permanently altered historic circuit boards, replaced irreplaceable factory mask ROMs with cheap burned chips, and introduced timing anomalies into game software. Thousands of original arcade boards were mutilated in this manner across two decades.
Simultaneously, a bizarre pathology took root within the collector marketplace. As the prices of vintage arcade PCBs escalated on Yahoo Auctions Japan and eBay, collectors began pricing games based on "unmolested" originality. Listings proudly advertised: "100% original, factory-soldered battery intact!"
This valuation model is dangerous technical ignorance. A thirty-year-old lithium thionyl chloride battery is a chemical hazard. As these cylindrical cells age, their inner seals degrade. Electrolyte containing thionyl chloride and lithium tetrachloroaluminate leaks onto the multi-layer FR4 fiberglass substrate. The chemical reaction forms hydrochloric acid upon contact with moisture in the air.
This corrosive liquid eats copper traces, dissolves surface-mount resistor arrays, and seeps beneath the QFP pins of custom graphics ASICs. Leaving an original 1994 battery attached to a CPS-2 board guarantees the passive destruction of historic silicon.
Reverse Engineering the Cryptographic Black Box
The breakthrough that liberated arcade hardware from this dilemma began with software preservationists. To emulate systems like the CPS-2 accurately without relying on bootleg patched ROMs, developers in the MAME project needed to replicate the exact cryptographic transformations of the DL-1520.
As detailed in the public driver source code of the MAME Capcom CPS-2 Implementation, engineers like Nicola Salmoria and Andreas Naive performed exhaustive mathematical cryptanalysis on ciphertext-plaintext pairs. By comparing raw ROM data with memory captures from running arcade cabinets, they cracked the mathematical structure of the Feistel network, determining the exact key tables for every commercial release.
However, knowing the mathematical key did not immediately solve the physical hardware crisis. If your real Vampire Savior board died on your shelf, running MAME on a PC offered no comfort; your real hardware remained bricked.
The turning point occurred in April 2016. Engineers Eduardo Cruz, Artemio Urbina, and Ian Court achieved what was long deemed impossible: full hardware restoration of original CPS-2 boards without replacing ROMs or cutting a single circuit trace.
As announced in the historic dispatch Important Capcom CPS2 Announcement on Arcade Hacker, the team successfully reverse-engineered the programming protocol Capcom used on its factory assembly lines.
+-------------------------------------------------------------------------+
| The ArcadeHacker Injection Protocol (CN9) |
| |
| +------------------------+ +--------------------------+ |
| | Arduino Uno / Mega | | CPS-2 Top "B" Board | |
| | Open Hardware Tool | | | |
| | | | [ CN9 Factory Header ] | |
| | Digital Pin 2 (DATA) | ------------> | Pin 2 (Serial Data) | |
| | Digital Pin 3 (STP1) | ------------> | Pin 3 (Setup Line 1) | |
| | Digital Pin 11 (CLK) | ------------> | Pin 4 (Clock In) | |
| | Digital Pin 12 (STP2)| ------------> | Pin 5 (Setup Line 2) | |
| | GND | ------------> | Pin 1 (System Ground) | |
| +------------------------+ +--------------------------+ |
| | |
| v |
| +--------------------------+ |
| | DL-1520 Security ASIC | |
| | * Latches Serial Stream | |
| | * Populates 64-bit Keys | |
| | * Restores Decryption | |
| +--------------------------+ |
+-------------------------------------------------------------------------+
For years, hardware hackers had eyed a small, unpopulated 6-pin connector on CPS-2 boards designated CN9 (or specific test points on earlier revision 4 and 5 boards labeled CN2). Anyone who probed CN9 while the board was running risked immediately wiping the keys and killing the game.
Eduardo Cruz cracked the secret of this port. In his technical investigation A Journey Into Capcom CPS2 Silicon, Cruz explained that CN9 was an asynchronous serial programming bus. During manufacturing, Capcom did not program the DL-1520 before soldering. Instead, fully assembled cartridges were placed on an automated programming bed, and a factory jig injected the specific game key directly through CN9 into the ASIC internal SRAM in milliseconds.
The engineering team turned this discovery into an accessible, open-source preservation utility: the ArcadeHacker CPS2 Desuicider GitHub Repository.
Using a standard $5 Arduino Uno, an LCD keypad shield, and five jumper wires, any collector can connect to the CN9 header or CN2 solder pads. The script contains the verified key tables for every single CPS-2 game. By selecting the game title from a scrolling menu, the Arduino clocks the appropriate 64-bit key stream directly into the DL-1520 SRAM registers.
Within four seconds, a board that had been bricked for twenty years boots cleanly with its original factory mask ROMs.
The Physical Media Mandate: Maintenance Over Fetishism
The triumph of the open-source arcade desuicider dismantled two decades of predatory aftermarket pricing and harmful collector myths. It established clear rules for the physical preservation of complex 1990s coin-op hardware.
First, static museum storage without active maintenance is a fantasy. Solid-state hardware does not preserve itself when locked inside display cases. Leaving factory lithium batteries on Sega System 16 or Capcom CPS-2 boards guarantees chemical leakage, trace corrosion, and silicon suicide. True conservation demands proactive intervention: * Solder out original, dying batteries immediately. * Install high-quality CR2032 or 1/2AA battery sockets equipped with low-forward-voltage Schottky diodes, allowing regular battery swaps without power interruptions. * For long-term archival storage, embrace battery-less operation. With open-source key injectors readily available, a CPS-2 board can safely rest without any battery installed. When a curator or collector wishes to operate the machine, they can inject the key in five seconds via the test header, restoring factory operation without subjecting the PCB to chemical hazards.
+-------------------------------------------------------------------------+
| Modern Arcade Board Preservation Matrix |
| |
| Strategy Physical Impact Failure Risk Archival Value |
| --------------------------------------------------------------------- |
| Factory Battery Zero modifications 100% (Leak & Zero (Guarantees|
| (Left untouched) (Original solder) destructive PCB destruction|
| suicide) via acid rot) |
| |
| Phoenix Modding High (Cuts traces, Low Low (Destroys |
| (2000s bootleg) desolders ROMs) (Permanent) original ROMs |
| & authentic bus|
| |
| Desuicider + Minimal (Clean Near zero Maximum |
| Socketed Battery removable mod) (Preventable (Original logic|
| maintenance) & zero damage) |
| |
| Battery-Free + Zero permanent mod Absolute zero Pristine |
| On-Demand Injection (Keys pulsed when (Zero chemical (Infinite shelf|
| needed for play) components) preservation) |
+-------------------------------------------------------------------------+
Second, the suicide battery crisis exposes the inherent danger of hardware-level digital rights management. In their zeal to extinguish bootleggers, Capcom and Sega built programmed extinction into their own historical catalog. Had independent reverse engineers, cryptanalysts, and open-source hardware developers not dedicated thousands of uncompensated hours to decapping chips and probing test buses, vast swaths of coin-op history would have been erased.
Preserving physical interactive media requires more than preserving plastic and fiberglass. It demands the uncompromised mastery of the logic gates, clock cycles, and encryption keys that animate that silicon. The resurrection of dead arcade hardware is proof that when proprietary copy protection wars end, the open-source community remains the only authentic custodian of gaming history.
No comments yet. Be the first to start the discussion!