Speedy Gonzales on the Super NES has no save feature and takes two or three hours to play through. The emulator author byuu wrote in 2011 that it “appears to run fine in any emulator” until stage 6-1, where “there is a switch, required to complete the level, where the game will deadlock if a rare hardware edge case is not emulated”. On a real console the switch works. The fast emulators of the day ran each chip at about the right speed, and this game needed exactly the right one: “Unless the software does everything in the exact same way the hardware used to, the game remains broken.”
Cycle accuracy is the answer to that kind of failure. A cycle-accurate emulator reproduces what every chip in the machine does on each tick of its clock, and keeps the chips in step with one another at that level, rather than running a whole instruction, a whole scanline or a whole frame at a time. Most programs never notice the difference. The ones that do are the ones that pushed the hardware hardest: raster effects, demos, copy protection and games written to the limit of a slow processor.
Fast facts
- Aim: every chip advances cycle by cycle, and they meet where the real ones meet.
- Accuracy vs compatibility: an emulator is compatible if it runs known programs correctly, accurate if it would run an unknown one correctly (NESdev wiki).
- Why it matters: raster effects, timing loops, bus sharing between chips, and timed copy-protection checks.
- Cost: byuu put a speed-oriented SNES emulator at about 300MHz of host processing power and an accurate one at up to 3GHz.
- Games that expose it: Speedy Gonzales and Air Strike Patrol on the SNES; Battletoads, Super Mario Bros. and Crystalis on the NES.
Accuracy and compatibility
The NES development community draws the line on its wiki: “Compatibility is how well an emulator produces the same output as the original system when running a particular known program. Accuracy refers to how well an emulator produces the same output as the original system when running an arbitrary unknown program.” An emulator can have the first without the second. NESticle, the popular NES emulator of the late 1990s, ran a wide range of commercial games while “allowing writes to” the PPU’s data port “at any time, while the NES only allows it during scanlines 240-260 of each frame (vertical blanking)” or with rendering switched off. The bill came later: “Inaccuracies like these led to inadvertent development of programs that the NES itself cannot run during the early years of NES homebrew.”
byuu found the same pattern on the SNES. Fan translations of Dragon Quest I & II, Dual Orb 2, Sailor Moon: Another Story and Ys IV “all suffered invisible text issues as a result of writing to video RAM while the video processor had it locked out”, because their authors had only tested them on emulators that allowed it. The popular speed-oriented emulators kept compatibility high another way. ZSNES and Snes9x, byuu wrote, “contain internal lists of the most popular fifty or so games”, and adjust their timing when one of them is loaded.
Accuracy is hard to prove. The NESdev wiki says flatly that “Accuracy cannot be measured directly”, and its footnote explains that doing so would amount to solving the halting problem. In practice emulator authors use test programs that check one behaviour at a time on real hardware, and lists of games known to break.
What depends on the exact cycle
Most software is forgiving. byuu estimated that most programs appear “to be functioning normally even if timing is off by as much as 20 percent”, which is why a fast, approximate emulator can run most of a library. The exceptions fall into a few groups.
Raster effects. A program that changes a video register while the picture is being drawn needs the change to land at the right point on the line. On the Commodore 64, opening the side borders needs one write in one cycle of the line: in Christian Bauer’s 1996 description of the VIC-II, the change “has to be exactly in cycle 56” (see open borders). On the SNES, Air Strike Patrol draws the shadow under the player’s plane by writing to the screen brightness register “multiple times per scanline”, and without it the shadow that shows where bombs will land simply vanishes.
Games that wait for the hardware. The NESdev wiki keeps a list of games that break when timing is approximate. Battletoads is “infamous among emulator developers for requiring fairly precise CPU and PPU timing (including the cycle penalty for crossing pages)”: it turns the picture on partway down the screen, and if the background lands too high or too low, “a sprite zero hit will fail to trigger, hanging the game”. Super Mario Bros. freezes on its title screen without sprite 0 detection. Crystalis uses the MMC3 scanline counter to split the screen, and “incorrect MMC3 timing will create a moving seam as you wander up and down the map”. The same list advises newcomers to start with something from 1984 or earlier, such as Donkey Kong.
Demos. The C64 demo scene built a literature on cycle counting, gathered on the Codebase64 wiki: Marko Mäkelä’s “Making stable raster routines”, Pasi Ojala’s “Missing Cycles - Syncing with a sprite” from C=Hacking 3, and articles on “cycle exact measuring of routine execution times”. Code written to them relies on the VIC-II taking its stolen cycles exactly where the chip does (see stable raster).
Copy protection. Some protection checks timed the hardware. Rob Northen’s Copylock wrote one sector of a disk with a smaller bit cell and then timed how long it took to read: “I think the ‘slow’ sector had to take at least 15% longer to read than the other sectors or it failed the protection test.” An emulator that returns every sector at the same speed fails the check, which is why preservation disk formats record how each track was written as well as what it holds (see disk protection).
Chips that share the bus
Timing matters because the chips in these machines shared memory and took turns, and their makers documented the rules.
Amiga. The Amiga Hardware Reference Manual (1989) gives each scan line “227.5 ‘color clocks’, or memory access cycles”, each “approximately 280 ns in duration”. Disk, audio, display and sprite DMA have the highest priority, then the Copper, which “has to perform its operations at the same time during each display frame to remain synchronized with the display beam”, then the blitter, and the 68000 last. With four or fewer low-resolution bit-planes the processor gets alternate memory cycles; with more, “bit-plane DMA will begin to steal cycles from the 68000 during the display”, half of its free slots on a six-plane screen. An emulator that ignores the slot allocation runs code at the wrong speed whenever the display is busy. See Agnus.
ZX Spectrum. The ULA shares the Spectrum’s lower 16K of RAM with the Z80, and it does not ask the processor to wait. Chris Smith’s reverse-engineering of the chip describes Richard Altwasser’s solution: it “works by stopping the clock signal it sends to the Z80 at strategic T-states, whenever it detects a contention condition is about to occur”. Smith also records that the contention logic went through “several revisions during the ZX Spectrum’s manufacture”, so an accurate Spectrum emulator has to decide which version of the chip it is copying.
Commodore 64. The VIC-II needs extra memory accesses on the first line of each row of characters, the so-called Bad Lines, and Bauer notes that it stops the processor “for 40-43 cycles” to get them. Sprites take more.
The cost
Keeping chips in step is where the processing power goes. byuu’s 2011 article for Ars Technica, “Accuracy takes power”, counted how often the SNES emulator ZSNES synchronised its chips each second against the author’s own bsnes: 903,720 times against 92,106,544. The processor alone went from 600,000 to 21,477,272, once per tick of the console’s 21.47MHz master clock rather than once per instruction. “Although bsnes runs ten times slower than ZSNES, it is literally up to one hundred times more precise.” A speed-oriented emulator could run at full speed on about 300MHz of processing power; bsnes wanted 2 to 3GHz, depending on the game. byuu’s rule of thumb: “Making an emulator twice as accurate will make it roughly twice as slow.”
Other emulators paid the same price. When Toni Wilen added near cycle-exact processor and blitter emulation to WinUAE, it fixed “most programs that expect correct cpu and blitter speed (PP Hammer, many demos etc..)”, and he warned that it needed at least 50 per cent more processing power. VICE’s manual warns that its accurate x64sc C64 emulator “requires a much faster machine than the old x64”. Before any of this, Amiga Format’s 1998 feature on UAE had shown what the missing accuracy looked like: Workbench’s pointer and icons flickered because Kickstart’s code for avoiding the display beam could not work, since “real Amiga programs rely on exact synchronisation which UAE simply cannot deliver”.
Accuracy sometimes reproduces things nobody wants. byuu found that the attract-mode demo of Super Bonk “actually desynchronizes” on most real consoles, leaving Bonk stuck near a wall, and that Star Fox slows down badly in places; an accurate emulator shows both. The inaccurate one got other things wrong in the opposite direction. On ZSNES the spinning triforces in The Legend of Zelda: A Link to the Past’s opening finished too early, because the emulated processor ran “well over 40 percent faster than a real SNES”.
“As accurate as you can get”
The goal was stated in print while bsnes was still young. Richard Bannister, who had ported 28 emulators to the Macintosh starting with the C64 emulator Frodo, told Retro Gamer in 2005 that the work he was proudest of was “the cycle-exact emulators I’ve converted. Traditional emulators often take shortcuts to run at acceptable speeds on today’s hardware. Although this rarely affects emulated software, it’s nice to see all these hacks removed for true authenticity. The most recent example from me is BSNES, which only attains full speed on the fastest Macs Apple has produced, but the end result is as accurate as you can get.” bsnes was the work of byuu; Bannister’s was the Mac port. byuu’s own case for the cost was preservation: once the last working consoles have gone, “emulators are the only way to experience those old games, so they should be capable of doing so accurately”.
On some machines cycle accuracy became the expected standard. The ZX Spectrum Next wiki, explaining why the Next’s own emulators were not yet exact, called cycle-accurate emulation “a ‘norm’ for classic ZX Spectrum after two decades of emulators development” (see Fuse).
It is still not the end of the road. Nintendo’s own development manual warned licensees that on the first version of the SNES processor, if an HDMA transfer starts just as an ordinary DMA finishes, “sometimes the CPU will cease to operate properly”. Decades later the Super Famicom Development Wiki’s list of “Open Problems in Accurate SNES Emulation” still asks “What exactly happens in the DMA crash bug on the v1 CPU?”, and notes that “most of these problems require access to a logic analyzer”. Below cycle accuracy lies simulation of the chips’ circuits themselves. byuu pointed to DICE, which simulates early arcade games at the level of their logic circuits and in 2011 needed a 3GHz processor to run Pong at 5 to 10 frames a second.
Sources
- Byuu, “Accuracy takes power: one man’s 3GHz quest to build a perfect SNES emulator”, Ars Technica, 9 August 2011, pages 1–3 (web, secondary; the author’s own account): Speedy Gonzales, Air Strike Patrol, Super Bonk, Star Fox, the Zelda triforces, fan translations, the synchronisation counts and processing requirements, DICE. https://arstechnica.com/gaming/2011/08/accuracy-takes-power-one-mans-3ghz-quest-to-build-a-perfect-snes-emulator/
- NESdev Wiki, “Accuracy”, “Tricky-to-emulate games” and “FDS audio” (web, secondary): https://www.nesdev.org/wiki/Accuracy and https://www.nesdev.org/wiki/Tricky-to-emulate_games
- Amiga Hardware Reference Manual (Addison-Wesley, 1989), chapter 6, “Blitter Operations and System DMA”: bus priorities, color clocks and the time-slot allocation.
- Chris Smith, The ZX Spectrum ULA: How to design a microcomputer (ZX Design and Media, 2010), chapter 18, “CPU Clock and Contention”.
- Christian Bauer, The MOS 6567/6569 video controller (VIC-II) and its application in the Commodore 64 (1996), sections 3.5 (Bad Lines) and 3.14.1 (opening the side border).
- Codebase64 wiki, “Interrupts and timing” article index (web, secondary): https://codebase64.org
- Rob Northen, interviewed by Codetapper (web, secondary): the Copylock read-timing check. http://www.codetapper.com/amiga/interviews/rob-northen/
- Amiga Format issue 108, March 1998, pp. 21–23, Simon Goodwin, UAE feature.
- WinUAE source code,
od-win32/winuaechangelog.txt(web, secondary): the near cycle-exact beta and its requirements. https://github.com/tonioni/WinUAE - VICE manual (web, secondary):
x64scand its requirements. https://vice-emu.sourceforge.io/ - Retro Gamer issue 21, 2005, feature on Macintosh emulation: Richard Bannister.
- ZX Spectrum Next wiki, “Emulators” (web, secondary): https://wiki.specnext.dev/Emulators
- Nintendo, Super NES Development Manual, Book I, “Documented Problems”: the DMA fault on S-CPU version 1.
- Super Famicom Development Wiki, “Open Problems in Accurate SNES Emulation” (web, secondary): https://wiki.superfamicom.org/open-problems