The History of Emulation: Preserving Gaming's Hardware Before It's Gone

Emulation exists because software is written against a machine contract that may disappear. Arcade boards fail, media and connectors degrade, batteries die, online services close, and supported operating systems move on. Reproducing hardware behavior in software can keep original code executable, but preservation also needs verified media, firmware, documentation, peripherals, context, and lawful stewardship.

MAME: the project that made emulation a preservation discipline

On December 24, 1996, Italian programmer Nicola Salmoria began writing individual emulators for classic arcade boards, starting with games in the Pac-Man family under the working name “Multi-Pac.” Rather than keeping these as separate programs, Salmoria merged them into a single, unified framework, released publicly as MAME 0.1 on February 5, 1997, supporting Pac-Man, Rally-X, New Rally-X, and Lady Bug. In April 1997, Salmoria stepped back from active development for a period to fulfill his national service commitment, handing the project’s stewardship to fellow Italian developer Mirko Buffoni.

MAME’s explicit purpose, stated from early on, was preservation: arcade boards are custom hardware, produced in limited runs, and progressively fail with age and use — MAME’s stated goal was documenting and reproducing their exact behavior in software before the originals disappeared entirely. That framing — emulation as an act of preserving a specific, finite, decaying set of physical artifacts, not merely a convenience for playing old games — became the standard justification the rest of the emulation scene organized around, for consoles and computers as much as arcade hardware.

MAME’s own documentation is careful about the boundary. The project aims to document hardware and preserve software history, but it does not distribute copyrighted game data. A machine marked working means its emulated devices meet a practical compatibility level, not that every electrical behavior is proven. Source comments, device models, software lists, ROM-region definitions, and regression work form a technical record alongside the executable.

Emulation predates one preservation project

Compatibility layers, terminal emulators, microcomputer simulators, and commercial products had already reproduced older or foreign environments. The 1990s console scene also produced many independent emulators. MAME’s historical importance is not that no one had emulated before 1997; it is the durable, multi-machine documentation project and preservation mission it helped institutionalize.

As home computers became fast enough, projects could trade shortcuts for more complete device models. Internet collaboration let developers compare test programs, schematics, die photographs, captures, and behavior across regions and revisions. Open source made obscure findings reviewable and survivable beyond one author’s interest.

A parallel, separate legal question

Emulation’s legal questions were highly visible in the 1990s, but no single case made every emulator, firmware image, game dump, or distribution method lawful. Connectix Corporation built Virtual Game Station, an independently implemented PlayStation emulator. During development it copied and analyzed Sony’s BIOS; the shipped product did not contain that BIOS. In 2000, the Ninth Circuit held that the intermediate copying at issue was fair use in the circumstances and reversed a preliminary injunction.

The ruling is important for reverse engineering and interoperability, alongside Sega v. Accolade. Its scope is equally important: it did not authorize downloading or distributing copyrighted firmware and games, and it did not erase anti-circumvention, contract, trademark, or jurisdiction-specific questions. Preservation institutions and individuals still need provenance, rights analysis, and access policy for each artifact.

The field broadens: DOS, then everything else

Emulation’s scope quickly extended beyond arcade and console hardware. Dutch programmers Peter “Qbix” Veenstra and Sjoerd “Harekiet” van der Berg began building DOSBox after finding that Windows 2000 had dropped meaningful DOS compatibility, releasing it in 2002 specifically to keep the enormous library of MS-DOS-era games and software runnable on modern operating systems. A different kind of broadening happened starting in 2010, when developer Hans-Kristian “Themaister” Arntzen began work on SSNES, a lightweight SNES-focused frontend built on libsnes (a decoupled emulation backend by the pseudonymous developer Near) — renamed RetroArch on April 21, 2012, once the project’s ambition grew from “a good SNES frontend” into a general-purpose platform for emulating many different systems through a single, shared interface.

DOSBox demonstrates that preservation may require an environment rather than a console replica: CPU modes, DOS services, timers, sound cards, graphics adapters, and configuration all influence historical software. The result supports games, but also installers, tools, demos, and business programs whose original host assumptions no longer exist on current desktops.

Libretro’s core/frontend split broadened reuse in another direction. A core supplies emulation through a C API, while a frontend supplies input, audio/video presentation, shaders, configuration, and optional services. This architecture does not make every core equally accurate, but it separates machine research from a growing cross-platform user interface and tooling layer.

Accuracy became evidence-driven

Early success was often measured by whether familiar games booted. Mature projects add instruction tests, hardware traces, timing ROMs, audio captures, graphics diagnostics, differential execution, and regression suites. “Cycle accurate” and “hardware accurate” are useful only when tied to a device, revision, behavior, and reproducible evidence.

Projects also learned that convenient formats can discard information. Cartridge overdumps, copier headers, disc audio tracks, subchannels, firmware revisions, encryption, and update partitions complicate the idea of one ROM file. No-Intro, Redump, MAME software lists, and platform-specific dumping communities catalog hashes and provenance without making an emulator itself the source of copyrighted content.

Preservation is larger than playability

A game reaching its title screen proves little about complete preservation. Controllers, light guns, link cables, cameras, microphones, memory cards, network servers, downloadable updates, manuals, packaging, accessibility context, and regional variants can be essential. Some experiences require reconstructing services or documenting what can no longer be reproduced.

Emulators also become preservation objects. Save states, configuration, plugins, shader languages, build dependencies, and host APIs change. Archives should retain source, released binaries, toolchains or reproducible build instructions, test material, and machine-readable metadata. A verified game image without a future decoder is only half a plan.

The strongest projects distinguish an archival master from an enhanced presentation. Higher resolution, texture packs, widescreen patches, rewind, and reduced latency can make old software easier to use, while a separate accuracy profile retains measured hardware behavior. Labeling the difference lets access and preservation coexist.

Why “history” and “preservation” are the same story here

Retrogaming history is the development of a practice: acquire trustworthy artifacts, document machines, implement behavior, test claims, preserve context, and navigate rights responsibly. MAME, DOSBox, Dolphin, PCSX2, libretro, specialist cores, dumping projects, archives, and hardware researchers each solve different parts. Court decisions created important space for interoperable software, but engineering evidence and archival governance determine whether the result remains useful.

Related:

Sources: