In 1997 Edge put the puzzle plainly. Old arcade machines “generally took up less than 50K of memory” and ran at clock speeds of a few megahertz. So why had it taken so long to run Galaxian properly on a 100MHz PC? The answer is that an emulator does not run the game. It runs the machine: every chip the game touches, doing what the real chip would have done, early enough for the result to matter. This entry explains the main techniques. The Emulation entry tells the history and covers the law.
Emulate the hardware, not the game
Chris Hardy, who wrote Windows 95 emulators of the arcade games Phoenix and Pleiades, gave Edge the working rule in 1997: “As long as the programmer emulates the hardware so that the game thinks it’s running on a real machine, then the game will run exactly like the real thing. You don’t have to worry about what to do with the sprites, what’s important is that the emulator knows.”
Emulating the hardware brings everything the hardware had, including features the player never saw. Arcade cabinets had hidden controls that, as Amiga Format put it, let “game speed and difficulty levels be tuned to maximise profit without driving away beginners”. When MAME emulated the board for Tehkan’s Bomb Jack, Edge noted in 1998, players could “alter the tenacity of the pursuing mechanical bird, the number and speed of more generic assailants, and the appearance and frequency of coveted ‘E’ and ‘S’ coins”.
It also means the emulator can be built from parts. Arcade makers reused processors and sound chips across many boards. Nicola Salmoria, Amiga Format explained, saw that “the underlying hardware was little changed between games” and built MAME as “a collection of software components to simulate classic arcade hardware”. It had processor emulators for the Intel 8080, Z80, 6502, 6809 and 68000, plus graphics and sound. A driver for each board describes how those parts are wired together, and the emulator expects each ROM image under an exact file name: “You must get these right or the game won’t run.”
Running the old processor’s code
Interpretation
The simplest method is to read each of the old processor’s instructions, work out what it does, and do it. Simon Goodwin, reviewing Amiga MSX emulators for Amiga Format in 1999, compared this to “reading a foreign book by looking up each word in a dictionary as you go along”. It “is enough to get you started fairly promptly, but soon gets bogged down. Programs are often reread as they run, and the ‘words’ seem simple compared with the effort of looking them up.” Interpreting Z80 emulators, he wrote, “must laboriously look up code for each Z80 instruction”.
How the interpreter is written matters. Amiga Format found in 1997 that ArcEm, an Amiga arcade emulator with “a hand-coded 8080 emulator”, “runs rings around compiled C versions”, while MAME, written in portable C, needed a fast Amiga. UAE’s key parts had likewise been “rewritten in Intel assembly code” to speed it up on PCs.
Interpretation has advantages beyond simplicity. The Amiga port of UAE interpreted 68000 instructions even though the Amiga’s own processor could have run them directly. Amiga Format explained why: it could “trap errors that would crash a real Amiga, simulate RAM or ROM memory anywhere and retarget graphics to any display”.
Dynamic recompilation
The alternative, in Goodwin’s analogy, is “translating the entire text and then working from the translation”. A dynamic recompiler turns blocks of the old program into the host machine’s own code as they are first used, keeps the translations, and runs them again at full speed. Hans Guijt’s fMSX2 did this for the Amiga, and on an A4000 with a 68060 processor Goodwin found it “almost 20 times faster than the original Unix code on a SPARC 2 workstation”. It could run MSX games at full speed on an ordinary A1200 with fast memory. By default it kept 512K for recently translated code and a 16K hash table to find it again.
Goodwin named the traps. “A compiler must work hard before its output is any use at all.” And “Programs, unlike books, can change themselves as they go along. A useful compiling emulator must check for this, or else it will carry on running the old code after it’s been replaced.” fMSX2 handled both: translation delays were “swamped by the time saved when code doesn’t need to be re-interpreted”, and it “tracks code invalidation”. The cost was memory, “for dynamically-generated 68020 code, typically more verbose than the Z80 equivalent”.
Rebuilding the display
Old display hardware rarely looks like a modern screen. Lee Taylor told Edge in 1997 that Galaxian, “like many other arcade games, used both character and sprite displays”. While the aliens flew in formation they were characters, but when one attacked, it was “deleted from character RAM and a sprite is put in exactly the same place”. A PC has one bitmapped display, so the emulator has to rebuild both layers in software and combine them.
The Amiga made this harder. Amiga Format pointed out in 1998 that scrolling two playfields in opposite directions “takes the A500 mere microseconds, but requires an emulator to read, mix and write up to 100Mb of video data every second”. UAE built one image of the whole Amiga display, “mixing sprites and playfields together and adjusting colours, position and resolution for Copper effects”. Bernd Schmidt sped it up by “skimping exact hardware emulation on display lines where nothing tricky happens”.
Keeping the chips in step
A computer is several chips working at once, and programs rely on when things happen, not only on what happens. Amiga Format explained in 1998 that the Amiga’s processor was “just one of four large chips that operate simultaneously”. The 68000 “can program the blitter to program the copper to program the blitter, and then get on with something else”, leaving “100,000 or so graphic operations chugging away automatically every second, in perfect synchronisation”. UAE could not yet match that: Workbench’s sprites and icons flickered as they moved, because “the emulated display is not scanned at the original rate, and real Amiga programs rely on exact synchronisation which UAE simply cannot deliver”.
The fix is to emulate time as well as behaviour, advancing every chip clock cycle by clock cycle. It is expensive. When Toni Wilen added “unoptimized near cycle-exact cpu and blitter emulation” to WinUAE, he warned that it needed at least 50 per cent more processing power. Richard Bannister, who converted emulators to the Macintosh, told Retro Gamer in 2005 that “Traditional emulators often take shortcuts to run at acceptable speeds on today’s hardware”. His example of the opposite was the SNES emulator bsnes, “which only attains full speed on the fastest Macs Apple has produced, but the end result is as accurate as you can get”. The cycle accuracy entry goes further.
A slower old machine brings the opposite problem: a fast host has to be held back. Goodwin noted that most MSX games “run synchronously with the NTSC or PAL display”, so fMSX2’s speed regulation kept “authentic timing on accelerated Amigas”.
High-level emulation
For machines whose chips were too complex to copy in real time, some emulators stopped imitating the hardware and imitated the software instead. UltraHLE, released in January 1999, ran Nintendo 64 games on a PC in a program of “around 220K”. Instead of emulating the console’s processors instruction by instruction, it intercepted the far fewer calls the games made to Nintendo’s software libraries and reimplemented those libraries, drawing the graphics through the Glide interface of the PC’s 3Dfx card. The approach is known as high-level emulation, or HLE. It was fast, but it only worked for what it recognised: UltraHLE implemented only the calls its target games needed, so at release it ran about 20 games well, and games that used other parts of the hardware needed changes to the emulator.
Six years later the same choice faced programmers porting emulators to Sony’s PSP. The programmer Lantus told Edge in 2005 that emulating the Nintendo 64 there “would require the PSP’s 3D API to be exposed”, using “HLE [High Level Emulation] methods and/or dynamic recompilation. But this functionality requires memory, and lots of it.”
Reading the original media
An emulator also needs the program, and getting it off the original media is its own problem. Arcade games came on ROM chips that could be copied, or “dumped”, into files. Disks were harder. In 1998 Amiga Format reported that UAE could not properly emulate the Amiga’s floppy hardware “because other computer floppy controllers lack the required bit-by-bit control”, so “Protected A500 programs are inaccessible”. The answer came later, from disk images that record a track as it was mastered rather than just its data; the disk protection entry explains how.
Sources
- Edge issue 46, June 1997, “The forgotten history of the videogames industry”, part 2: memory and clock speeds of old coin-ops, Chris Hardy on the method, Lee Taylor on Galaxian.
- Edge issue 61, August 1998, MAME feature: the Bomb Jack operator settings.
- Amiga Format issue 105, Christmas 1997, pp. 22–23, Simon Goodwin, “Arcade Emulators”: operators’ hidden controls, MAME’s design and processor emulators, ROM file names, ArcEm’s hand-coded 8080 emulator.
- Amiga Format issue 108, March 1998, pp. 21–23, Simon Goodwin, UAE feature: the Amiga’s simultaneous chips, 100Mb of video data a second, how UAE builds its display, Schmidt’s line-by-line shortcut, Intel assembly, the Amiga port’s interpretation, synchronisation and flicker, floppy disk limits.
- Amiga Format issue 124, June 1999, pp. 52–53, Simon Goodwin, “MSX Nostalgia”: interpretation and dynamic recompilation, fMSX2 by Hans Guijt, its speed, cache and hash table, speed regulation.
- WinUAE source code,
od-win32/winuaechangelog.txt(web, secondary): the near cycle-exact beta and its requirements. https://github.com/tonioni/WinUAE - Retro Gamer issue 21, 2005, feature on Macintosh emulation: Richard Bannister on cycle-exact emulation and bsnes.
- Edge issue 69, March 1999, news, “N64 emulator thrills PC gamers”: UltraHLE’s release, size and 3Dfx requirement.
- Wikipedia, “UltraHLE” (accessed September 2026) (web, secondary): the library-replacement method, Glide, and the roughly 20 playable games at release. https://en.wikipedia.org/wiki/UltraHLE
- Edge issue 153, September 2005, PSP homebrew feature: Lantus on HLE and dynamic recompilation.