How Emulation Saved Retro Gaming (and Why It Still Matters)

There is a hard truth at the center of game preservation. The vast majority of arcade games released between 1972 and 1995 — by some estimates over 90% — would be lost forever if not for emulation. Original arcade boards rotted in warehouses. Cartridge ROMs degraded. Master tapes in publishers' vaults were thrown out during corporate moves. The entire industry's first 25 years exists today only because volunteers, working without funding or legal cover, reverse-engineered hardware their manufacturers had abandoned. This is the story of how that happened and what it means.

The accidental beginning: 1989-1995

The first widely-distributed video game emulator was almost certainly Bernie Stolar's VICE, an emulator for the Commodore 64 that started development in 1992. The C64, by then, was a "dead" platform — Commodore was bankrupt, the hardware was hard to find, and a generation of kids who'd grown up with their family's C64 wanted to play those games again. VICE, written by a team of Scandinavian and German developers, ran a complete C64 in software on a PC. It was free. It included no games. The user had to provide their own ROM files dumped from physical cartridges or floppy disks they owned.

The model — emulator separate from games, BYO-ROM — was set in 1992 and is still the technically and legally cleanest version of the practice 33 years later. Every reputable emulator project since (MAME, Dolphin, RPCS3, etc.) has used the same model.

NESticle: 1997, the leap to mainstream

Marat Fayzullin's iNES (1996) was the first technically credible NES emulator, but it was slow and rough. The breakthrough was NESticle, written by Icer Addis (alias of bloodlust software) and released in April 1997. NESticle ran almost full-speed on a Pentium 90, supported full-color rendering, included savestates (the first major emulator to do so), and crucially — it was free, easy to install, and worked.

NESticle's releases were crude. The default cursor was a cartoon hand giving the middle finger. The "save state" feature gave the savestate file an extension of .SS6 — the joke being a nod to "Storm Shock 6" or, depending on who you ask, "Schutzstaffel" — Addis was 20 years old and the early Internet rewarded edgy humor.

None of that mattered. NESticle let an entire generation of college students play Super Mario Bros., Zelda, and Mega Man on whatever PC they could find. By late 1997, it had been downloaded an estimated 1.5 million times worldwide — a remarkable number for any software in 1997 — and the practice of "ROM downloading" entered the mainstream Internet vocabulary.

ZSNES vs. Snes9x: the SNES wars

SNES emulation was harder than NES because the SNES had multiple coprocessors. Two competing projects emerged in 1997. ZSNES, written entirely in 32-bit x86 assembly by zsKnight and _Demo_, prioritized speed: it ran SNES games at full framerate on a Pentium 200 when no other emulator could. Snes9x, written in portable C++ by Gary Henderson and Jerremy Koot, prioritized accuracy and cross-platform support.

For five years (1997-2002), ZSNES dominated. It was simply faster. Most users didn't notice or care that ZSNES achieved its speed by approximating timings — the SNES's actual hardware was much more complex than ZSNES emulated, but for 95% of games the approximation was good enough. ZSNES's UI was iconic: a deep blue background with mode-7-rotated menu fonts, written in assembly to fit in tiny binaries. Its team eventually disbanded in 2007 amid an internal feud over Linux porting.

Snes9x's portability won the long game. The same code that ran on Windows ran on Linux, macOS, the original Xbox (modded), the PSP, the Nintendo DS via homebrew, and eventually the libretro framework that powers RetroArch today. Snes9x is still actively maintained in 2026 and is what most people are using when they "use ZSNES" — most users haven't actually touched ZSNES in 15 years.

MAME and the arcade preservation crisis

MAME (Multiple Arcade Machine Emulator) launched February 5, 1997 with a single arcade game emulated: Pacman. Project lead Nicola Salmoria's stated mission was, from day one, preservation rather than play: "MAME exists to document the inner workings of these arcade machines so the data is not lost."

"We are not trying to make a games platform. We are trying to make a museum."

The scale of what MAME has done is hard to overstate. As of 2026, MAME emulates over 38,000 distinct arcade machines, ranging from 1972's Pong to the early-2000s NAOMI/Atomiswave era. Each machine is documented in source code: chip layouts, video output timing, audio synthesis, button mappings, dip switch settings. MAME's source is essentially a textual record of arcade hardware history.

The corporate response was mixed. Capcom, Konami, and Atari Games quietly accepted MAME's existence — most of the boards being preserved were 20+ year old products no one was selling commercially anymore. Sega initially threatened legal action in 1999 then backed off. Nintendo has consistently opposed MAME and refuses to license its arcade games for inclusion. As a compromise, MAME ships emulation for Nintendo arcade games (Donkey Kong, Mario Bros., Punch-Out!) but the ROMs themselves must be obtained separately, never bundled.

By 2010, the arcade preservation crisis had crystallized: most surviving arcade boards were physically failing. Capacitors degraded. EPROMs lost charge. Mask ROMs developed bit-rot. MAME was, in a real sense, an emergency archaeology project — a race against entropy. Multiple games in MAME today exist only because volunteers physically dumped one of perhaps three surviving cabinets in the world before the cabinet failed for the last time.

byuu and the cycle-accurate revolution

By 2005, the SNES emulation community had a problem: ZSNES and Snes9x were "good enough" for most games but failed mysteriously on perhaps 50 specific titles. Star Fox, with its Super FX coprocessor, never ran exactly right. Tales of Phantasia's music skipped on emulation in ways it didn't on real hardware. The community accepted these as "edge cases."

One developer, working under the pseudonym byuu (later revealing his name as Near), decided edge cases weren't acceptable. byuu's project, bsnes (later renamed higan), aimed to emulate the SNES so accurately that every single game would run identically to original hardware, cycle-by-cycle.

The cost was enormous. bsnes-accurate, the cycle-accurate mode, required a 3 GHz CPU to run a SNES at full speed in 2008. The NES emulator that came packaged in higan needed a 2 GHz CPU. byuu spent years debugging individual instruction timings, often discovering documentation errors in Nintendo's official chip datasheets. He single-handedly identified bugs in the SNES's PPU that had been mispredicted by every previous emulator and every Nintendo SNES Classic Mini's official Nintendo emulator.

byuu's work mattered for two reasons. First, accurate emulation became a precondition for academic study of how the SNES worked. Modern SNES homebrew (like the recent Sword of Lutis, 2024) was built using bsnes as the development target. Second, byuu's efforts forced the broader emulation community to take preservation accuracy seriously. The shift from "fast enough" to "accurate enough" was largely his.

Tragically, byuu died in 2021. His work continued through a successor project, ares, that maintains his accuracy standards across multiple platforms.

Project64 and the N64 problem

The Nintendo 64 was, technically, harder to emulate than any console that came before it. Its custom Reality Coprocessor (RCP) was a programmable graphics pipeline — every game potentially used it differently. Standard PC graphics APIs like Direct3D and OpenGL had no equivalent for the RCP's microcode, which meant N64 emulators had to maintain hand-written compatibility lists for individual games.

The first credible N64 emulator was UltraHLE in January 1999. It was, at launch, a sensation: it ran Super Mario 64 at full speed on a Pentium III. It also caused legal panic at Nintendo. UltraHLE used "high-level emulation" — instead of emulating the actual N64 hardware, it intercepted N64 microcode calls and translated them into PC API calls. This was technically more efficient but reproduced specific game logic in a way that approached "porting" rather than emulating.

Within four months, UltraHLE's developers (Epsilon and RealityMan) discontinued the project under unstated legal pressure. Their successor projects — Project64, 1964, Mupen64 — used cleaner low-level emulation approaches and have continued development through 2025.

The N64 emulation community is the most fragmented in retro gaming. There is still no single "definitive" N64 emulator in 2026. Mupen64Plus via the libretro framework is closest, but specific games (Conker's Bad Fur Day, the Banjo series, Indiana Jones and the Infernal Machine) require specific compatibility tweaks. The community's pragmatic answer: use whatever works for the game you're playing. There is no global solution.

The legal landscape (2025)

The legal status of emulation has been settled, repeatedly, by US courts:

• Sony v. Connectix (2000) — the Ninth Circuit ruled that reverse-engineering the PlayStation BIOS to build the Virtual Game Station emulator was fair use under copyright law. This is the foundational ruling for all subsequent emulation. Sony lost.
• Sony v. Bleem (2001) — Sony lost again, this time over Bleem's PlayStation emulator's screenshots. Bleem won the right to use Sony screenshots in advertising under fair use, then went bankrupt anyway from legal costs.
• The DMCA Anti-Circumvention provisions (1998) — make it illegal to circumvent copy protection on copyrighted works. This affects emulation because ROM dumping for some platforms (Wii, Switch) requires bypassing copy protection. The Library of Congress has periodically granted DMCA exemptions for game preservation but the exemptions are narrow.

The summary as of 2025: writing an emulator is legal. Distributing ROMs of games you don't own is not. ROM dumps you make yourself from cartridges you legally own occupy a gray area that varies by jurisdiction but has never been criminally prosecuted in the US.

What about Nintendo's lawsuits?

Nintendo has filed multiple high-profile lawsuits in the past five years that scared a lot of people. The reality:

Nintendo v. Yuzu (2024) — Nintendo sued Yuzu, a Switch emulator, claiming it required circumventing copy protection. Yuzu settled for $2.4 million and shut down. The takedown was based on DMCA anti-circumvention, not on the legality of emulation itself. Yuzu's developers had been distributing decryption tools alongside the emulator, which was the actual violation.

Nintendo v. Tropic Haze / Citra (2024) — same outcome, same legal theory, same shutdown.

Nintendo v. EmuParadise (2018) — never reached court. Nintendo sent DMCA takedowns; EmuParadise voluntarily removed all ROMs. The site survived as a Wikipedia-like database of game metadata.

None of these cases challenge the legality of emulation itself. They challenge specific behaviors: distributing decryption keys, bundling ROMs with emulators, willful copyright infringement at scale. The 1990s rulings (Sony v. Connectix) remain controlling law on emulation as practice.

The emulator builders

Emulation is, almost without exception, volunteer labor. The major emulators of 2026 — MAME, Dolphin (GameCube/Wii), PCSX2 (PS2), RPCS3 (PS3), DuckStation (PSX), Citra/Yuzu (3DS/Switch), bsnes/ares (SNES) — are open-source projects supported by Patreons, donations, and the personal time of developers who work other day jobs.

The economics are brutal. Dolphin's lead developers receive about $5,000-8,000/month combined from Patreon, split among multiple contributors. RPCS3 receives about $4,000/month. MAME, with 30,000+ machines emulated, receives less than $2,000/month total.

Many key contributors have day jobs at major game companies. Several Dolphin developers work at Nintendo or Microsoft. RPCS3's lead has worked at Sony. The open secret: people who work on the games industry's mainstream care deeply about preservation, often more than their employers, and contribute on weekends.

Browser emulation: the modern era

The shift you've witnessed if you visited any retro gaming site in the past 5 years: emulators that run inside the browser. JavaScript and WebAssembly have made it possible to run a full SNES, Genesis, or N64 inside Chrome with no installation. The emulator that powers most browser-based retro gaming sites — including the one you're reading this on — is EmulatorJS, a wrapper around the libretro framework compiled to WebAssembly.

EmulatorJS is the most accessible emulation environment ever built. A child with a Chromebook in a school library can play Super Mario World without installing anything. The cost: browser sandboxing limits some performance optimizations, and audio latency on some platforms (particularly iOS Safari) is higher than native emulation. The benefit: emulation has gone from "needs a Windows PC and 30 minutes of setup" to "click play."

The next frontier is cycle-accurate browser emulation. As of 2026, cycle-accurate SNES (bsnes) is borderline-feasible in WebAssembly on a high-end laptop. Cycle-accurate N64 is not — but with continued WebAssembly performance improvements, it should be possible by 2028.

Why this matters

The practical case for emulation has three parts:

Preservation. Without MAME, an estimated 30,000+ arcade games released before 1995 would be functionally lost — playable only by the dwindling number of cabinet-collectors who own original boards. Without console emulators, every game released for a console older than the Nintendo 64 would be inaccessible to anyone who didn't already own original hardware. The legal alternative — Nintendo's Virtual Console / Switch Online — covers maybe 200 games out of 50,000+ classic console games released. The math on commercial preservation simply doesn't work; only volunteer emulation has the breadth.

Accessibility. Emulation makes gaming accessible to people who would otherwise be excluded. Players with disabilities can use savestate features that don't exist on original hardware. Players in regions where original consoles were never sold (Latin America didn't get an official Sega Master System; most of Africa never got SNES) can play canonical games for the first time. Players who are children of immigrant parents who couldn't afford original consoles in the 90s can experience the games their American peers grew up with.

Modification and study. ROM hacking, fan translations, romhacks like Pokémon Crystal Clear or Super Mario World: The Second Reality Project — these only exist because emulation made them possible. Academic study of game design by university researchers depends on emulators. The entire field of speedrunning depends on cycle-accurate emulators that match real-hardware behavior.

The future

The next decade of emulation faces three challenges. First, the Switch era is harder to emulate than any predecessor — its ARM64 architecture is closer to a smartphone than a console, and its games rely on online services (eShop, Save Cloud) that don't have offline equivalents. Second, the legal landscape is tightening as Nintendo specifically gets more aggressive about defending its IP. Third, the volunteer pipeline is aging: the developers who built MAME, Dolphin, and bsnes are mostly in their 40s now. A new generation of emulator builders has not yet fully emerged.

What will keep the work going is the same thing that started it: a small number of people who think the games industry's first 50 years are worth preserving, and who are willing to do the work without compensation when no one else will. As long as those people exist, the games survive. When they stop, the games go away.

That's the actual stakes. Not "can I play Mario for free." It's whether the cultural artifacts of an entire art form — the medium millions of us grew up on — get to remain in the world after their original commercial life ends. Emulation is the answer the industry never built but desperately needed.

Try emulation directly in your browser, no downloads needed: SNES library, Genesis library, N64 library, Game Boy library, or Arcade games. Powered by EmulatorJS, all running locally in your browser.