If you've poked around this site, you've probably met virtual machines and containers — the two standard ways of running one computer inside another. Emulators are the third sibling in that family, and by far the most extreme: an emulator is a program that pretends to be an entirely different machine, down to the chips.
That difference matters more than it sounds. A VM on your PC runs software built for the same kind of CPU your PC already has — the hypervisor mostly steps aside and lets the guest's instructions run directly on the real processor, which is why VMs are fast. A Super Nintendo game, though, was built for a CPU your PC has never heard of: a Ricoh 5A22 running a 65C816 instruction set. Nothing about it runs natively on an x86 or ARM chip. Every single instruction has to be translated in software. That's emulation, and it's why your laptop can run a dozen Linux containers without noticing but starts sweating when you ask it to be a GameCube.
How the translation works
There are two classic strategies, and most serious emulators use both.
Interpretation is the straightforward one: read the next console instruction, do the equivalent thing in software, repeat, millions of times per second. It's simple and precise, and it's slow — every emulated instruction costs dozens of real ones.
Dynamic recompilation (a "dynarec," or just-in-time translation) is the fast one: instead of interpreting instructions one at a time, the emulator translates whole blocks of console code into native code for your CPU the first time it sees them, caches the result, and reuses it every time that block runs again. It's the same fundamental trick a JavaScript engine uses on web pages. Dynarecs are how a phone emulates a PlayStation 2 — and they're also a big reason emulators are complicated, because translated code has to behave exactly like the original, edge cases included.
flowchart LR ROM[Game code for the console CPU] --> DEC[Emulator reads a block] DEC --> JIT[Translates it to native code] JIT --> CACHE[Caches the translation] CACHE --> RUN[Runs it on your real CPU] RUN --> SYNC[Syncs with emulated GPU and audio timing] SYNC --> FRAME[One frame on your screen]
It's never just the CPU
Here's the part that separates emulation from every other kind of virtualization: a console isn't a CPU, it's an orchestra. A fixed, known set of chips — processor, graphics chip, audio chip, memory controllers, timers — all running in lockstep, forever, in every unit ever sold.
Game developers exploited that certainty ruthlessly. They counted exact clock cycles. They raced the television's electron beam, changing video settings mid-scanline for effects the hardware nominally couldn't do. A game doesn't ask the SNES nicely for a result — it knows the answer arrives exactly 4 cycles from now and has already moved on.
So a good emulator doesn't just translate instructions; it recreates time. Every chip has to advance in step with every other chip, at the right relative speeds, or games glitch in bizarre ways — audio drifts, physics break, some titles just hang. This is why "cycle-accurate" emulation is so expensive: one famous analysis by the developer of the bsnes emulator put honest SNES accuracy at roughly 3GHz of modern CPU — about a hundred times the horsepower of the machine being emulated. The gap isn't waste; it's the cost of simulating an orchestra with software musicians.
High-level vs low-level emulation
There's a shortcut, and most 3D-era emulators take it. Instead of simulating the console's chips faithfully (low-level emulation), you can intercept what the game is trying to do — "draw this triangle," "play this sound" — and hand it to your PC's real GPU and audio stack (high-level emulation). HLE is dramatically faster and is how Nintendo 64 and PlayStation emulators became playable on ordinary late-90s PCs. The trade-off is accuracy: games that talked to the hardware in unusual ways break, and emulator developers spend years chasing those corner cases.
This is also where BIOS files come in. Some consoles (the PlayStation line especially) have a chunk of Sony-written startup and system code on a chip inside every unit, and an emulator needs that behavior to run games. Some emulators reimplement it in software (HLE again); others need a copy of the real thing — which is copyrighted code with rules about where you can legally get it. We wrote a whole doc on the legal side because it deserves honest treatment, not a wink.
Why the ladder gets steep
Roughly speaking, each console generation multiplies the emulation workload:
- Atari 2600 through the 16-bit era — trivial to run, surprisingly hard to run perfectly (those cycle-counting tricks). A Raspberry Pi handles these in its sleep.
- PlayStation 1 and N64 — the jump to 3D; HLE makes them easy for any modern machine.
- PS2, GameCube, Wii — multiple exotic processors working in parallel; a mid-range PC handles them well today.
- PS3 — the wall. Its Cell processor was a famously strange design: one general-purpose core juggling seven specialized number-crunching units, all of which games used directly. Emulating it means simulating eight things happening at once, precisely synchronized — which is why RPCS3 wants a genuinely strong multi-core CPU and why PS3 emulation makes gaming rigs earn their keep.
The pattern to remember: emulation difficulty tracks the original hardware's weirdness, not its age or its polygon count.
Cores, front-ends, and why RetroArch looks the way it does
One last piece of vocabulary. Writing an emulator means solving the same boring problems every time — video output, controller input, save states — so the community standardized them. libretro is a common interface; a "core" is an emulator compiled to speak it; and RetroArch is the front-end that hosts the cores, giving you one interface, one controller setup, and one save-state system across forty-odd machines. Library managers like LaunchBox sit a level above that, organizing your collection and launching the right core per game. It's the same layered architecture you see everywhere in software — the emulator is the engine, RetroArch is the chassis, LaunchBox is the garage.
The bottom line
An emulator is the most ambitious form of virtualization there is: not sharing a machine, not partitioning a machine, but impersonating a different machine entirely, chip by chip, cycle by cycle. That it works at all — that a $70 single-board computer can convincingly be a dozen consoles from gaming history — is one of the genuinely great engineering stories in software. And everything it runs in our lab comes off our own shelf: games we bought, on consoles we own. More on exactly how that works in the legal companion doc.