Emulation and Preservation

An emulator is software that pretends to be another computer. It reads the same program bytes the original console ran, decodes them the way that console's CPU did, and produces the same results: the same pixels, the same sound, the same behavior. The hard part is that a game console is not just a CPU. It is a CPU plus a graphics chip, a sound chip, controllers, timers, and the wiring between them, all running at once and all watching each other's clocks. A faithful emulator has to model every part and keep them in step. The simplest approach is interpretation: fetch one emulated instruction, figure out what it means, do it, repeat. That is straightforward and easy to get right, but slow, because the host spends many native instructions on each emulated one. Most of the history of emulation is a negotiation between that simplicity and the speed real games demand.

When a console's CPU is fast, plain interpretation cannot keep up, so emulators reach for dynamic recompilation, also called a JIT (just-in-time) recompiler. Instead of interpreting each instruction every time, the emulator translates a whole block of the guest's machine code into the host CPU's native machine code, then runs that translated block directly and caches it for reuse. A loop that runs a million times gets translated once. Dolphin, which emulates the GameCube's PowerPC "Gekko" and the Wii's "Broadway," leans on a JIT for exactly this reason; pure interpretation of those chips on a desktop would crawl. The cost is complexity and a subtler relationship with accuracy: the recompiler must reproduce not just the result of each instruction but its side effects and timing closely enough that games behave. Low-end CPUs like the Game Boy's are slow enough that an interpreter suffices, which is part of why handheld emulation reached high accuracy earlier than console emulation.

For years "it boots and looks right" was the bar. Then a quieter argument took hold: looking right is not the same as being right. Near (formerly byuu) started bsnes on October 14, 2004, after hitting Super Famicom bugs that only appeared on real hardware, and built it around low-level, cycle-accurate emulation; the project was renamed higan in 2012 as it grew to cover more systems. Cycle accuracy means stepping every chip in time the way the silicon did, so a game relying on the exact moment a scanline is drawn, or on a race between two chips, behaves identically. The trade is brutal: cycle-accurate cores can need an order of magnitude more host power than a "good enough" emulator. Critics call that wasteful; defenders answer that preservation has no second chance, and that the obscure timing bug nobody hits today is exactly what an archive exists to keep. Near died in 2021, and the work continued as a collaborative project.

There is a different route that sidesteps the speed-versus-accuracy fight. Instead of running the old hardware's behavior as software on a general CPU, an FPGA is reconfigured into the old hardware's actual digital logic. An FPGA is a chip whose gates can be rewired after manufacture, so a "core" describes the original console's circuits and the FPGA becomes that circuitry, running in parallel the way the real chips did. The MiSTer project, started by Alexey "Sorgelig" Melnikov in June 2017 as a successor to the earlier MIST, does this on Terasic's DE10-Nano board, built around an Intel Cyclone V FPGA paired with a dual-core ARM that handles loading and menus. Commercial hardware such as Analogue's consoles takes the same FPGA approach in a polished product. The appeal is low input lag and behavior that comes from logic rather than approximation; the limits are that each system must be painstakingly described in hardware terms, and large FPGAs are expensive, so the most demanding consoles lag behind.

Before anything can be emulated, the original data has to be extracted, and extracting it cleanly is its own discipline. A ROM is a dump of a cartridge's memory; a disc image is a dump of an optical disc. Two community databases set the standard for what a correct dump looks like. No-Intro curates cartridge dumps, with clean naming, region tags, and header corrections so that every copy of a given release hashes to the same value. Redump does the parallel work for optical media, where the physical structure matters more: track layouts, pregaps, mixed-mode audio, and copy-protection artifacts all affect the checksums, so a disc must be modeled as a physical object, not just a blob. Both projects publish DAT files, lists of known-good checksums (CRC32, MD5, SHA-1), and explicitly do not host the games. You verify your own dump against the database. Neither distributes ROMs; the value is the reference, not the file.

The feature most players associate with emulation is the save state. Because the emulator already holds the entire machine in its own memory, it can serialize that whole state, every byte of RAM, every register, the exact mid-frame instant, to a file and restore it later. No original console offered this; it is a pure artifact of running on a host that can pause and snapshot the world. Save states transformed how people play old games, enabling tool-assisted speedruns, frame-perfect practice, and casual checkpointing in games that never had it. They also expose a subtlety: a save state from one emulator version, or one core, may not load in another, because it encodes that emulator's internal layout rather than anything the cartridge defined. The convenience is real, and so is the reminder that an emulator's state is its own, not the hardware's.

Cartridges rot. Disc lasers drift, battery-backed saves die, and the small companies that made thousands of games are gone, with no master copies kept. Emulation and verified dumping are, increasingly, the only path by which a great deal of software survives at all. The legal picture is narrower than the technical one. Courts in the United States have held that an emulator built by clean-room design, reverse-engineering behavior without copying the original code, is itself lawful; the games it runs remain under copyright, and distributing those dumps is generally infringement even when the rights holder sells nothing. That gap is the core tension of the field: the tools are legal, the cultural argument for keeping the work is strong, and the legal right to copy the work usually rests with companies that may never reissue it. Preservation projects answer by documenting and verifying rather than distributing, betting that an accurate record now is worth more than a convenient one.