The basic idea
An emulator is a program that makes one computer behave like another. A modern PC running a console emulator reproduces what the original machine’s processor, graphics chip, sound chip and controls did, so that software written for the old system runs on the new one. The game itself is not changed. It is fed to the emulator, which translates its instructions into something the host computer can carry out.
This is possible because computers are general-purpose. Any machine that can compute can, in principle, imitate any other, given enough speed and the right instructions. The practical question is how faithfully and how quickly.
What an emulator has to imitate
A console is more than one processor. A typical system has several parts working together:
- A main processor that runs the game’s code.
- A graphics unit that draws the picture.
- A sound unit that produces audio.
- Memory and input handling for controllers.
- Sometimes special chips inside the cartridge itself.
The emulator needs a software version of each part and must keep them in step with each other. Old hardware often relied on tight timing between components, so getting those relationships right is much of the work.
Ways of imitating
Emulator authors choose different approaches, which trade accuracy against speed.
High-level emulation imitates what a component does rather than how it does it internally. For example, instead of copying a graphics chip circuit by circuit, it may reproduce the effect of its commands. This is faster and works on modest computers, but can miss odd behaviour that games sometimes depend on.
Low-level emulation imitates the hardware’s inner workings more closely, down to the timing of individual operations. It tends to be more accurate and more demanding on the host computer.
Many emulators sit somewhere in between, and developers often improve accuracy over years as they learn more about how the original hardware behaves. People also talk about simulation and recreation, for instance running a game’s logic on new hardware designed to behave like the old, but the terms are used loosely.
Why accuracy is hard
Documentation for old hardware can be incomplete or unavailable. Developers often work out behaviour by testing, by studying released games, and by examining real chips. Some titles use undocumented tricks or even bugs in the hardware as part of how they work, and an emulator that does not reproduce those can break the game. Because of this, an emulator may run most games well and still have problems with a few, and “it runs” is not the same as “it behaves exactly like the original”.
Timing is another issue. Original machines ran at fixed speeds tied to the display. Modern computers do not, so the emulator has to pace itself, and small differences can change how a game feels. This is related to the input latency players notice on modern setups, which can be a little higher than on the original system.
Emulation versus related ideas
Emulation is sometimes confused with other ways to play older games:
- Backward compatibility is when a newer console is built to run older games itself, either by including similar hardware or by official built-in software support.
- Ports and re-releases are new versions of a game prepared for a different system; they are explained in the comparison of remakes, remasters and ports.
- Compatibility layers translate software calls from one operating system to another, rather than imitating a whole device.
Official collections of classic games sometimes use emulation under the hood, so the line between “emulated” and “official” is not always clear to players.
Why it matters for preservation
Hardware wears out, and few people can maintain old consoles indefinitely. Emulation offers a way to run old software after the machines have failed. Researchers and archivists also use it to study games, test whether a preserved copy works, and document how systems behaved. That is part of the broader challenge described in why old games are hard to preserve.
Emulators themselves need preserving too. Software written for today’s operating systems can eventually stop working, and a good emulator project usually publishes its source code and documentation so it can be maintained.
The legal and ethical questions
This is the most contested part, and it varies by country, so the following is general information, not legal advice.
- The emulator program. Writing an emulator from scratch is generally treated differently from copying a company’s own code. Courts in some places have considered emulators lawful in particular cases, but the details depend on how they were made.
- The game software. Games are copyrighted. Having a copy of a game does not automatically give you the right to make or share further copies, even for preservation. Rules differ on whether making a personal backup is permitted.
- System firmware. Some systems need a copy of the original machine’s internal software to start. That firmware is also copyrighted, which complicates matters.
- Distribution. Sharing game files online is a frequent source of disputes, including for titles that are no longer sold, as discussed in the article on delisted games.
Different groups hold different views. Rights holders emphasise their control over creative works and ongoing sales of re-releases. Preservationists emphasise that unplayable games are lost to history. Players often just want to play something they cannot buy. These positions are not easy to reconcile, and the legal rules continue to evolve.
What to expect as a user
Emulators range from simple to highly demanding, and quality varies. A newer, very detailed emulator may need a powerful machine, while a simple one runs almost anywhere. Features such as saving at any moment, adjusting image sharpness or changing controls are common, and some of these change how a game plays compared with the original. Players interested in the look of the original screens should also read about CRT displays, since emulated pictures on a modern monitor can look quite different.