Emulation

Programs are almost always written for a specific device. A game for a 30-year-old console expects exactly its components and its instructions. On a computer today, none of that matches up, so the game simply wouldn’t start. Emulation solves this by having a program recreate the old device piece by piece. It pretends to the outside world that it is the console: it accepts the same instructions and reacts in the same way. The game doesn’t notice the difference and keeps running as if everything were normal.

Why old software doesn’t simply disappear

Hardware doesn’t last forever. Consoles, arcade machines, and industrial computers break down, and replacement parts are no longer manufactured. The programs running on them, however, are often still valuable. Emulation separates the software from the machine and thereby keeps it alive.

This affects far more than just video games. Banks, insurance companies, and government agencies sometimes still use software from the 1970s and 1980s. These programs today often no longer run on real mainframes, but rather in an emulation on ordinary servers. Rewriting them would be expensive and risky, because no one fully understands all the edge cases anymore.

Museums and archives also rely on this. A digital art installation from 1995 can only be shown if its operating system still runs somewhere. Emulation is a form of heritage preservation here. Without it, a large part of computer history would be practically unreadable.

Recreating instead of translating: the price of accuracy

An emulator reads the instructions of the foreign program one by one. For each instruction, it calculates what the recreated device would have done with it. It keeps a kind of ledger of the old machine’s state: which numbers are stored in its memory cells, what the screen displays, which key is pressed. Not only the main processor is recreated, but also graphics, sound, and controls.

This translation work costs computing time. For a single old instruction, the emulator often needs dozens of its own computing steps. That’s why there’s a rule of thumb: you need significantly faster hardware than the original. Emulating a console from the 1990s is easy today, whereas one from the 2010s is demanding.

It’s important to distinguish this from virtualization. In virtualization, the software runs on a processor it already understands; only access to it is shared. This is almost as fast as running it directly. Emulation, on the other hand, recreates a different architecture and is therefore slower. Another common misconception is that an emulator comes with the games included. It only provides the device; you have to own the programs yourself.

From mobile games to chip design

The best-known emulators are for old game consoles on PC or smartphone. Manufacturers themselves use them too: when Nintendo or Sony re-release classics, an emulator is often behind it rather than new programming work. Legally, the emulator itself is usually permitted, but copying other people’s games generally is not.

In software development, emulation is an everyday tool. Anyone programming a mobile app first tests it on an emulated phone on their laptop. You can immediately see how the app looks on various screen sizes without having to buy ten devices.

In the chip industry, even more money is at stake. A new processor is emulated for years before the first real one is manufactured. Only this way can it be checked whether operating systems will run on it. In tech news, the term often comes up during a switch of processor architectures, for instance when Apple moved from Intel chips to its own: older programs continued to run emulated as a stopgap, so users wouldn’t have to wait for new versions.