Arcade Hardware — A Survey, Not a Catalog

Companion docs: psx-recomp.md, ps2-recomp.md, ps3-recomp.md, ps4-recomp.md, amiga-recomp.md, megadrive-recomp.md, snes-recomp.md, saturn-recomp.md, engine-based-porting.md.

“Arcade hardware” isn’t one platform — it’s roughly five decades of custom boards from dozens of manufacturers, far more heterogeneous than any single console generation covered so far. A board-by-board catalog would be enormous and mostly redundant. The useful organizing fact, confirmed below rather than assumed, is that a large share of that history isn’t a distinct engineering problem at all — it’s literally the same silicon as a home console already (or soon-to-be) surveyed here, running under a JAMMA harness instead of a TV cable. What’s genuinely arcade-specific concentrates in two places instead: hardware-level anti-piracy that home consoles of the same eras mostly didn’t need, and a distinct hardware-reimplementation technique — FPGA cores — that has quietly become one of arcade preservation’s biggest success stories.

Same silicon, different box: boards that inherit from a console doc

Sony ZN-1 / ZN-2 (Capcom, Taito’s licensed “FX-1/FX-1A/FX-1B,” and Namco System 11/12, the last “developed jointly by Namco and Sony… based on a prototype of the PlayStation”) are PS1 hardware — same MIPS R3000A-derived CPU family, same GTE lineage — swapped from CD-ROM to ROM/RAM game boards with a manufacturer-specific BIOS and security ASIC gating the daughterboard. MAME’s own driver layout confirms the lineage at the code level: zn.cpp sits in MAME’s sony/ directory next to psx.cpp and reuses the PSX CPU/GPU core rather than reimplementing it (zn.cpp, Namco System 11 and System 12 — Wikipedia). Whatever’s true about PS1 recompilation prospects in psx-recomp.md — mature source decompilation for named titles, early-but-moving general recompilers — applies directly to Ridge Racer, Tekken, and Taito’s ZN-era catalog; there’s no separate “arcade CPU problem” here.

Namco System 246 / System 256 (2000+, debut title Bloody Roar 3) are PS2 boards outright: the same R5900 “Emotion Engine” and Graphics Synthesizer as retail PS2, System 256 overclocking the EE and doubling RAM. Both were licensed beyond Namco (Capcom’s Capcom Fighting Evolution, Taito’s Battle Gear 3), running Tekken 4/5, Soul Calibur II/III, and Time Crisis (Wikipedia, Arcade Otaku Wiki). Everything ps2-recomp.md says about the Emotion Engine/VU1 problem, and PS2Recomp’s early VU1-incomplete state, is the applicable state of the art here too.

Namco System 357 (2007, flagship title Tekken 6) is confirmed genuine PS3 silicon: a 3.2GHz Cell BE (PPE + six SPEs) and RSX-derived graphics with GDDR3, matching retail PS3, with a successor (System 369, Tekken Tag Tournament 2) explicitly matching PS3 Slim (Wikipedia, PS3 Developer Wiki). ps3-recomp.md’s assessment — ps3recomp’s early-but-real SPU/PPU lifting, RPCS3 as reference — is directly relevant, not a new problem class.

Sega NAOMI / NAOMI 2 (1998+) is Dreamcast’s architecture scaled up: the same Hitachi SH-4 CPU and PowerVR2 GPU family as retail Dreamcast, with more RAM, faster VRAM, and a swappable ROM/GD-ROM DIMM board read into RAM at boot; NAOMI 2 adds a second PowerVR CLX2 plus a “PowerVR Elan” geometry chip. Crazy Taxi, Virtua Fighter 3tb, and Marvel vs. Capcom 2 all ran on it (Sega Retro, Emulation General Wiki). This series hasn’t written a dedicated Dreamcast doc yet — flagged here as a gap, since NAOMI’s recompilation prospects would inherit almost entirely from whatever that doc eventually concludes about SH-4/PowerVR2.

Same silicon, different problem entirely: Taito Type X

Taito Type X (2004) through Type X4 (2016), plus Type X Zero and the NESiCAxLive digital-distribution variant, are commodity x86 PC hardware — Celeron/Pentium 4 through Core i5/i7, AGP-then-PCIe ATI/Nvidia GPUs, running Windows XP Embedded — not custom arcade silicon at all (Wikipedia). That changes the framing completely, in exactly the direction ps4-recomp.md already argues for x86-64 consoles: there is no CPU-lifting problem, because the code is already native to the host architecture. What stands in the way is DRM — physical-era boards used USB/parallel dongles and encrypted HDD containers, while later NESiCAxLive titles authenticate against Taito’s own NESYS network license server rather than any local security chip (Wikipedia). The community’s answer looks nothing like a recompiler or even a traditional emulator: TeknoParrot is a loader/compatibility shim that runs the original PC binaries directly on ordinary Windows, patching out dongle/hardware-ID checks (400+ titles across Type X, Sega Lindbergh/RingEdge, Namco’s PC boards) — and separately, the community has stood up a fake NESiCAxLive server so cabinets authenticate against it instead of Taito’s own (Arcade-Projects). MAME does not emulate Type X at all. Type X preservation is a dongle/license-server defeat problem dressed as an arcade board, not an architecture problem.

Same CPU family, mature community: Neo Geo MVS

SNK’s Neo Geo MVS pairs a 68000 main CPU with a Z80 sound co-processor — plain scalar CISC, no vector/DSP coprocessor, the same “easy CPU tier” this series established for m68k in amiga-recomp.md and megadrive-recomp.md (also 68000+Z80). MVS (arcade) and AES (home) run identical hardware — cartridges are interchangeable — so there’s no real arcade/console split to draw here (Copetti’s Neo Geo writeup). What’s arcade-specific is SNK’s late-era anti-bootleg silicon: the NEO-SMA chip (introduced with King of Fighters 2000) holds part of the program ROM internally and decrypts the rest via on-chip bit-swapping, while KOF2003 used a different scramble/XOR scheme (neogeodev.org). MAME’s neogeo.cpp driver carries dedicated per-generation decrypt routines, the product of a two-decade-plus reverse-engineering effort aided by the platform’s unusually long ~1990–2004 commercial run. No static recompilation project targeting Neo Geo ROMs turned up in searching.

The genuinely arcade-specific problem: encryption coprocessors

This is the one category with essentially no analog elsewhere in this doc series. Arcade boards were an extraordinarily lucrative bootlegging target — a single PCB could be cloned and resold thousands of times — so manufacturers invested in hardware anti-piracy that PS1/PS2/PS3/Amiga mostly never needed at the CPU-instruction level.

Capcom CPS2 (1993) is the canonical case. Program decryption keys lived in battery-backed volatile RAM on the board’s B-side; once the battery dropped below roughly 2V, the keys vanished and the board could no longer execute any code — the “suicide battery,” a real and permanent failure mode that drove much of the preservation urgency (Hackaday: Desuiciding Capcom Arcade Boards). The scheme was a pair of four-round Feistel ciphers under a 64-bit key, encrypting opcode fetches specifically, decrypted on the fly by a custom ASIC as the 68000 fetched instructions. The break took over half a decade: a 2001 “CPS-2 Shock” hardware extraction yielded partial XOR data, and full cryptanalysis — by Andreas Naive and Nicola Salmoria — wasn’t folded into MAME until January 2007 (CP System II — Wikipedia); a 2016 follow-up technique (“de-suiciding”/“phoenixing,” Cruz/Urbina/Court) can revive already-dead boards via Capcom’s own factory programming port. (CPS1 shipped with essentially no ROM encryption on its main 68000 code — CPS2’s suicide-battery scheme was a deliberate, considerable step up.)

Sega’s FD1094 / FD1089 are arguably more radical, used across System 16/18/24/X boards: 68000 CPU modules that decrypt their own instruction stream internally, per physical chip, using a key held in on-die battery-backed SRAM. Interrupt-vector and normal opcodes are decrypted differently, and — critically — only fetched instructions are decrypted, not general data reads, so a raw ROM dump alone tells you almost nothing: there’s no way to read the “real” program without extracting the key from that exact chip, and a dead on-die battery could make a cartridge’s code permanently unrecoverable. Reverse-engineering credit generally goes to Charles MacDonald and Nicola Salmoria; current documentation (arcadehacker’s Security Programming Guide) describes it as “several years of work by a small group of arcade enthusiasts,” with dedicated key-extraction programmers now able to pull working keys from surviving chips. Nothing in PS1/PS2/PS3/PS4/Amiga territory resembles a CPU package that refuses to reveal its own opcodes without per-unit physical key extraction — arcade’s own problem class.

Konami adds a smaller, better-documented example: chips like the 053260 sound ASIC and 054986A hybrid sound module have been reverse-engineered from decapped die photos and traced schematics by the furrtek/SiliconRE project, with community reproductions documented on Arcade-Projects — narrower than CPS2 or FD1094/1089, but the same pattern: custom ASICs guarding logic a home console of the same era didn’t bother protecting.

MAME: reference implementation, and (mostly) not a recompiler

MAME (Nicola Salmoria, 1997; merged with the MESS home-computer project in 2015) is the dominant open reference implementation across nearly all of this — thousands of drivers, more board coverage than any single-platform emulator this series has looked at. Its philosophy leans toward low-level emulation (accurate per-chip behavioral modeling) over high-level approximation wherever documentation supports it, and for the oldest, simplest boards it goes further than CPU-core LLE: its netlist device and companion discrete-sound project numerically solve the actual analog/TTL circuits on early discrete-logic sound boards (Pong-era hardware) — genuine gate/component-level simulation, not software approximation.

MAME’s “DRC” (Dynamic Recompiler) does compile some CPU cores — MIPS3, PowerPC, SH-2/SH-4, ARM64 backends as of recent releases — to an internal “UML” IR at runtime for speed (Dynamic Recompiler Author’s Guide), but that’s a JIT, the same category as RPCS3’s or PCSX2’s recompilers surveyed elsewhere in this series, not ahead-of-time static translation. No MAME-adjacent static/AOT recompilation project, for any board or era, turned up searching.

FPGA reimplementation: a genuine peer technique, not a footnote

The one place arcade preservation has produced something arguably more radical than software recompilation is the MiSTer FPGA scene. JOTEGO (Jose Tejada), via jotego/jtcores, maintains open Verilog cores claiming 1,050+ supported titles as of early 2025, covering CPS1/CPS1.5/CPS2 and a broad swath of Konami and Toaplan boards — built from genuine hardware reverse engineering (the project maintains its own KiCAD schematics as primary research artifacts), not ported MAME driver source. Neo Geo’s MiSTer core is a separate effort, MiSTer-devel/NeoGeo_MiSTer by Furrtek, reportedly built after physically decapping the board’s custom chips (GamesRadar).

This deserves treatment as a peer technique, not a curiosity: FPGA cores synthesize reconfigurable hardware logic that behaves like the original silicon cycle-for-cycle — a different kind of thing from both software emulation (interpreting or JIT-ing on a host CPU) and static recompilation (translating instructions ahead of time into new native host code). It’s hardware reconstruction, running at the gate level with no software layer at all. For boards with hardware-locked encryption like CPS2 and FD1094/1089, a core that faithfully reimplements the decryption ASIC sidesteps the cryptanalysis problem entirely by just being the chip again — arguably why this scene has succeeded where general-purpose recompilers haven’t attempted these boards at all.

Golden-age boards: trivially easy silicon, almost no recompilation interest

Pac-Man, Galaga, Donkey Kong-era boards (roughly 1978–1983) run plain Z80 or 6502 CPUs — no coprocessors, no MMU, simpler than even PS1’s R3000A, the easiest CPU tier discussed anywhere in this series. Despite that, static recompilation targeting this era specifically is thin. The clearest example is Norbert Kehrer’s static binary translation of Atari’s Asteroids (1979) to JavaScript — a genuine automated 6502→JavaScript translator with optimization passes, explicitly self-described as static binary recompilation (project page, live demo) — but it’s a solo, single-game project, and nothing comparable exists for Pac-Man, Galaga, or Donkey Kong; those instead have ordinary interpreted emulators (e.g. galagino for microcontrollers). No dedicated “Z80-to-C” or “6502-to-C” static recompiler comparable to the NES 6502-recompilation scene surfaced for arcade boards. The likely reason: MAME’s interpreted/LLE emulation is already essentially perfect and runs these boards at a tiny fraction of any modern CPU’s budget, so the performance motive driving recompilation elsewhere (N64, PS1) simply doesn’t exist here.

Honest synthesis: arcade isn’t one answer, it’s a map

“Is arcade recompilation solved” has no single honest answer, because arcade isn’t a platform — it’s a map from era/board-family to whichever already-established technique applies:

• ZN-1/ZN-2, System 246/256, System 357 — not a distinct problem; inherit directly from psx-recomp.md, ps2-recomp.md, and ps3-recomp.md at whatever maturity those docs describe.
• NAOMI/NAOMI 2 — inherits from Dreamcast (SH-4/PowerVR2), a doc this series hasn’t written yet; a placeholder dependency.
• Taito Type X — not a CPU problem, per ps4-recomp.md’s x86-native framing; solved today by DRM/license-shim tooling (TeknoParrot), not emulation or recompilation.
• Neo Geo MVS — easy CPU tier (m68k, per amiga-recomp.md and megadrive-recomp.md), mature decryption community, zero static recompilation activity found.
• CPS1/CPS2, FD1094/FD1089, Konami’s protection ASICs — the one genuinely arcade-native hard problem here: silicon-level anti-piracy with no analog in any console this series has covered, solved historically through cryptanalysis and (for some chips) physical decapping, not any CPU-translation technique.
• Golden-age Z80/6502 boards — the easiest silicon surveyed, and correspondingly the least recompilation activity, since interpreted emulation already solved the performance problem decades ago.

Two things make arcade genuinely distinct rather than just “consoles, but in a cabinet”: the hardware-encryption coprocessors, which forced a reverse-engineering discipline home-console preservation rarely needed, and the FPGA reimplementation scene, arguably the most successful “run it natively, no software layer” arcade preservation technique that exists — a genuine peer to static recompilation, not a footnote to it.