Emulator

Lore & Background

Many printers, for example, are designed to emulate HP LaserJet printers because a significant amount of software is written specifically for HP models. Since at least the 1990s, many video game enthusiasts and hobbyists have used emulators to play classic arcade games from the 1980s using the games' original machine code and data. A hardware emulator takes the form of a hardware device, such as the DOS-compatible card installed in some 1990s-era Macintosh computers like the Centris 610 or Performa 630, which allowed them to run PC software programs.

Most emulators emulate a hardware architecture; if operating system firmware or software is required, it must be provided as well. Both the OS and the software are interpreted by the emulator rather than run by native hardware. Sufficient emulation of some platforms requires extreme accuracy down to individual clock cycles, undocumented features, and implementation bugs, particularly with classic home computers like the Commodore 64. In contrast, some platforms like the PlayStation 4 have had little direct hardware addressing, so a simple compatibility layer may suffice.

Video game console emulators are programs that allow a personal computer or video game console to emulate another video game console. They are most often used to play older 1980s to 2000s-era video games on modern systems. Examples include RPCS3, Dolphin, Cemu, PCSX2, PPSSPP, ZSNES, Citra, ePSXe, Project64, Visual Boy Advance, Nestopia, and Yuzu. Due to their popularity, emulators have been impersonated by malware, often making currently impossible claims such as being able to run Xbox One and Xbox 360 games in a single program.

Reader's Guide

Emulation has notable significance in preserving access to software and games designed for older or discontinued hardware. The article notes that since at least the 1990s, video game enthusiasts have used emulators to play classic arcade games from the 1980s by interpreting the original machine code on current-era systems. Emulators also allow developers of software for embedded systems or video game consoles to design and test software on simulators before the final hardware exists in large quantities, avoiding the side effects of a debugger. In many cases, the simulator is produced by the hardware company itself, theoretically increasing accuracy.

Legally, emulation is established as legal within the United States according to precedents such as Sega v. Accolade, Sony v. Connectix, and Sony v. Bleem. However, unauthorized distribution of copyrighted code remains illegal under international copyright law. Under U.S. law, obtaining a dumped copy of the original machine's BIOS is legal as fair use if the user obtained a legally purchased copy of the machine, per Lewis Galoob Toys, Inc. v. Nintendo of America, Inc. The article also notes that the Internet has helped spread console emulators, as most would be unavailable for sale in retail outlets. Emulators have also been impersonated by malware, with some making currently impossible claims about emulating modern consoles.

Did You Know?

• The Church–Turing thesis implies that theoretically, any operating environment can be emulated within any other environment, assuming memory limitations are ignored.
• The first functional simulator was written by Autonetics about 1960 for testing assembly language programs for the military computer D-17B.

The Core Idea and Its Theoretical Foundation

Emulation is the process by which one computing system, the host, imitates the behavior of another, the guest, allowing software and peripherals designed for the guest to function on the host. The Church-Turing thesis provides a theoretical underpinning: given sufficient memory, any operating environment can in principle be reproduced within any other. Yet theory and practice diverge sharply. When the target system's exact behavior is undocumented, engineers must reverse-engineer its quirks. Timing is another critical variable—an emulator that falls behind the original hardware's speed can trigger timer interrupts that cascade into altered program behavior. Hardware emulators take physical form, such as the DOS-compatible cards once installed in 1990s Macintosh models like the Centris 610 and Performa 630, letting those machines execute PC software, or field-programmable gate array-based devices. Software emulators, by contrast, interpret the guest's machine code directly on the host's processor, bridging architectural gaps without dedicated silicon.

A Spectrum of Fidelity

Not all emulation demands the same depth of accuracy. At one extreme, platforms like the Commodore 64 require emulation precise down to individual clock cycles, undocumented hardware features, unpredictable analog behavior, and even implementation bugs. This is because the C64's software ecosystem—game programmers and the demoscene—relied heavily on sophisticated low-level tricks that exploited every quirk of the hardware. At the opposite end, systems such as the PlayStation 4 saw very little direct hardware addressing in their software, meaning a straightforward compatibility layer that translates foreign system calls into native ones can suffice. The Nintendo 64's fully programmable graphics processor illustrates a middle path: although the GPU was theoretically flexible, most titles used a small set of pre-made programs communicating via FIFO, so many emulators skip GPU emulation entirely and simply interpret CPU commands as the original program would. The depth of emulation required is thus dictated by how intimately the target platform's software touches its underlying hardware.

Preservation, Compatibility, and Everyday Use

Emulation has quietly shaped everyday computing for decades. A classic example is printer compatibility: many non-HP printers are designed to emulate HP LaserJet models because a vast body of software was written specifically for HP hardware. Once a printer presents itself as an HP device, any HP-targeted print software produces equivalent results on the non-HP machine. In the gaming world, since at least the 1990s, enthusiasts and hobbyists have used emulators to run classic 1980s arcade games on modern systems, interpreting the original machine code and data without needing the vintage hardware. Math co-processor emulators serve a similar bridging role, letting programs compiled with floating-point instructions execute on CPUs lacking a dedicated co-processor; when the CPU encounters a co-processor instruction it raises a not-available interrupt, the emulator routines handle the computation, and the program resumes. These applications show emulation as a practical tool for extending compatibility across generations and architectures.

Simulators and the Road Before Hardware

Before a chip is fabricated or a console ships, developers need a way to test their software. Simulators—especially accurate emulators often produced by the hardware vendor itself—fill that gap, allowing programmers to build and debug code without the time-consuming process of copying programs to physical hardware or introducing debugger side effects. This is particularly vital for embedded systems and video game consoles, where large hardware quantities may not yet exist. The roots of this practice stretch back to around 1960, when Autonetics wrote the first functional simulator to test assembly-language flight programs destined for the military D-17B computer, enabling those programs to be written, executed, and verified before the hardware was even built. Autonetics also developed a functional simulator for flight programs for later execution in other systems. Logic simulation extends the idea further, using software to model the operation of a digital circuit after it has been described in logic equations but before physical fabrication. Functional simulation, meanwhile, executes symbolic assembly or compiler-language code rather than binary machine code, letting programmers trace specific source sections to hunt for bugs without generating any binary at all.