An emulation of a physical machine is software that recreates an entire hardware system, allowing programs designed for one platform to run on a completely different one. The emulator acts as a translator, converting instructions meant for the original machine’s processor into instructions the host computer can execute. This makes it possible to run old console games on a modern PC, keep decades-old business software alive without the original hardware, or test mobile apps without a physical phone in hand.
How Emulation Differs From Virtualization
Emulation and virtualization both create virtual environments, but they solve different problems. Virtualization splits one physical computer into multiple isolated environments that share the same underlying hardware directly. A virtualized system runs on the same type of processor as the host, so there’s minimal overhead. Emulation, by contrast, recreates the entire hardware architecture in software, including the processor, memory, and input/output devices. This means emulated software doesn’t need to match the host’s hardware at all.
Think of virtualization as dividing a house into apartments. Everyone shares the same foundation and plumbing. Emulation is more like building a detailed replica of a completely different house inside your existing one. That replica might represent a 1990s game console, an IBM mainframe, or a smartphone, all running inside your laptop’s processor through a translation layer.
What Happens Inside an Emulator
At the core of any emulator is instruction translation. The original machine’s processor speaks a specific language (its instruction set architecture), and your computer’s processor speaks a different one. The emulator bridges that gap using one of two main approaches.
The simpler method is interpretation. The emulator reads each instruction from the original program one at a time, figures out what it means, and executes the equivalent operation on your hardware. This is straightforward to build but slow, because every single instruction goes through a decode-and-dispatch cycle.
The faster method is binary translation. Instead of handling instructions one by one, the emulator translates entire blocks of code from the original format into native code your processor can run directly. There’s an upfront cost to doing this translation, but once a block is translated, it runs at near-native speed. Most modern emulators use a hybrid approach: they interpret code the first time it runs (to discover what needs translating), then translate and cache frequently used blocks for reuse. This is exactly how Apple’s Rosetta 2 works on Mac computers with Apple Silicon chips. When you launch an app built for older Intel-based Macs, Rosetta automatically translates the Intel instructions into ones the ARM-based Apple chip understands. The process is transparent enough that most users never notice it’s happening.
Recreating Hardware in Software
A full machine emulator doesn’t just translate processor instructions. It also recreates the memory system, storage controllers, graphics hardware, and input/output devices, all as software models running on your host computer.
The emulated CPU maintains its own set of virtual registers and executes instructions according to the rules of the original processor. Memory is typically represented as a large block of allocated space on the host, with the emulator managing how the guest system reads and writes to it. For input/output devices like disk controllers, network adapters, or serial ports, the emulator intercepts requests from the guest software and maps them onto real or virtual resources on the host. In some implementations, this works through memory-mapped I/O, where the guest system reads and writes to specific memory addresses that the emulator recognizes as device registers rather than actual memory. The emulator catches those accesses and responds as the original hardware would have.
System firmware also plays a role. Physical machines rely on BIOS or UEFI firmware to initialize hardware and boot the operating system. An emulator needs to provide equivalent firmware so the guest operating system can start up normally. Some emulators include their own firmware implementations, while others (particularly game console emulators) require users to supply firmware files extracted from the original hardware.
Emulation vs. Simulation
These two terms get used interchangeably, but they refer to different things. An emulator replicates both the hardware and software environment of the target machine. It aims to behave identically to the real thing, so software can’t tell the difference. A simulator mimics only the software behavior, skipping the hardware layer entirely.
This distinction matters most in mobile app development. Android emulators replicate the phone’s processor and hardware features through binary translation, letting developers test hardware-dependent functions like motion sensors, battery behavior, and cellular interrupts. Apple’s iOS simulator, on the other hand, runs iOS apps using your Mac’s own processor and operating system. It’s faster because there’s no hardware translation happening, but it can’t test anything that depends on physical hardware. If you need to verify how an app handles a low battery warning or an incoming phone call, the simulator can’t help you.
Game Console Emulation
The most visible use of emulation is running old video game consoles on modern hardware. Each console has its own processor architecture, graphics chip, and audio hardware that an emulator must faithfully recreate. Some of the most actively developed emulators in 2025 include RPCS3 for the PlayStation 3, PCSX2 for the PlayStation 2, Azahar for the Nintendo 3DS, and Gopher64 for the Nintendo 64. Multi-system emulators like Mesen2 can handle several older platforms in a single program.
Console emulation is computationally expensive because the emulator must reproduce the behavior of specialized chips that were never designed to be easily replicated in software. A PlayStation 3 emulator, for example, needs to translate instructions from the Cell Broadband Engine (a notoriously complex processor) into something a standard PC chip can handle. This is why emulating even a console from 2006 can tax a modern computer.
Enterprise and Legacy System Uses
Businesses rely on emulation to keep critical software running long after the original hardware has been discontinued. This is common with IBM Z mainframes, Unisys ClearPath systems, DEC VAX and PDP minicomputers, HP 3000 and 9000 servers, Sun SPARC machines, and DEC AlphaServers. These platforms ran (and in some cases still run) software that organizations spent decades and millions of dollars developing.
Rather than rewriting all that software for modern systems, companies use emulators to run it on current hardware or in cloud environments. AWS, for instance, supports legacy migration strategies where businesses emulate old mainframe hardware on cloud servers. Common scenarios include offloading development and test environments to the cloud using emulators, migrating stable production applications off aging hardware, and shutting down data centers that still house legacy machines. The application code stays the same, the development teams keep their existing tools, and only the underlying hardware changes.
The Performance Trade-Off
Emulation’s biggest limitation is speed. Every instruction the guest system executes must pass through a translation layer, and every hardware interaction must be intercepted and handled in software. Even with optimizations like binary translation and code caching, emulated systems run slower than they would on native hardware. The gap varies widely depending on how different the guest and host architectures are, how complex the original hardware was, and how mature the emulator is.
Rosetta 2 on Apple Silicon demonstrates the best-case scenario: translating between two relatively modern architectures (x86_64 to ARM64) with heavy optimization from Apple’s engineering team. It handles nearly all Intel instructions, including advanced vector processing instructions from the AVX and AVX2 sets, though it draws the line at AVX512. For most applications, the performance hit is small enough that users don’t notice. On the other end of the spectrum, emulating exotic hardware like the Sega Saturn (targeted by the Ymir emulator) requires painstaking accuracy to reproduce quirky hardware behavior, and performance suffers accordingly.
Despite these costs, emulation solves a problem nothing else can: running software on hardware it was never designed for. Whether you’re preserving a classic game, keeping a 30-year-old banking application alive, or testing an Android app without a phone, emulation makes the impossible platform gap disappear.