Emulators such as Higan are cycle-accurate and thus have full compatibility with all existing software. In a 2011 Ars Technica article, much was said about cycle accuracy and how it preserves games by allowing them to run flawlessly.

In the interest of performance, emulators often implement the processor's instruction set directly. This means instructions are executed instantly, as if they were atomic operations. In fact, they are executed over many cycles. This breaks software that takes advantage of this fact in some creative way. So, by emulating a processor cycle-by-cycle instead of instruction-by-instruction, accuracy increases.

What I don't understand is how an entire emulator can be cycle-accurate. What do people mean when they say that? There are multiple components in the system and they're all running at different clock rates, so I'm not sure what exactly cycle is referring to.

What does an emulator have to do in order to be classified as cycle-accurate?

  • 2
    Great question, and welcome to Retrocomputing!
    – JAL
    Commented Jul 26, 2016 at 22:36
  • 1
    I shared this question on reddit and got some great responses from Dolphin and Higan developers.
    – JAL
    Commented Sep 20, 2016 at 1:29
  • 2
    @JAL It would be great if some of them answered here. More answers, and more knowledgeable users! :-)
    – wizzwizz4
    Commented Sep 20, 2016 at 17:55
  • 1
    see Question about cycle counting accuracy when emulating a CPU. Using better timing enables low level HW stuff like custom loaders, interfacing HW like FDD etc ... with cycles precision only you need to hack all that instead.
    – Spektre
    Commented Sep 20, 2017 at 9:40

4 Answers 4


For an emulator to be "cycle accurate" means the interactions between the components are timed accurately enough so that the emulation behaves the same way as the original machine for any given input. I mean "input" in the general sense -- both external inputs such as keyboards, joysticks, buttons, etc. and the program (or programs) being run, the data available on devices and so on.

Early (late 1970s to early 1980s) game consoles and home computers almost always ran off a single base clock frequency that was divided down by various factors to run the main CPU, graphics, sound and other systems. In those cases a cycle would refer to the highest clock frequency which is typically that provided to the graphics system. So, for example, there was often an exact number of CPU cycles per video frame.

As you point out, for systems with multiple clocks the notion of a cycle doesn't make any real sense. But each subsystem driven by a clock will operate in fixed steps so we stretch the term "cycle accurate" to mean that each part of the system will perform its operations in the same amount of real time as the original and the interactions between each subsystem are such that they will seem the others running at the same relative speed.

For most of an emulator's operation timing accuracy is not a concern. If the CPU stores 7 into a memory location it doesn't matter exactly when it happens because the change cannot be noticed by anything else in the system. But if the processor changes a video memory location then timing may make the difference between the video output changing or not.

The other side of cycle accuracy is duration. If the emulated CPU runs faster than a real CPU (perhaps because it takes few cycles for some or all instructions) then a game may be seen to run too quickly. For the most part such timing is easy to get right and is usually made inaccurate by not modelling interactions with RAM or devices. Sometimes the CPU is slowed down a little bit when it reads/writes memory. That can be difficult to emulate correctly but without that bit of accuracy games or other applications will run too quickly. Not generally a problem for a word processor, but for games or more highly interactive applications it will be noticable to the experienced user.

Component Interactions

Except for RAM, interaction between the CPU and supporting subsystems is mostly one way. ROM only returns values as asked. Sound systems only change their output based on what the CPU tells them. Joysticks and keyboards only report user input to the CPU. Graphics only change when the CPU sends new data. BUT, only mostly.

Graphics systems can tell the CPU when a new frame has started. Sound systems might report when they have finished playing a bit of audio. Any time a component can give feedback to the CPU there may be a need for timing accuracy. But how much accuracy is required really depends on the particular device and the program's use of that device.

For instance, in a simple game the positions of various sprites (player and enemies) on screen might be updated once per frame. In that case cycle-level accuracy isn't needed. All you need is for the "start frame" indication to come by at a frequency that is close enough to the original for a human to think it exact and the CPU runs fast enough to make the change before the frame drawing begins.

More complex games might change sprite positions while the graphics display is drawing them. Typically the graphics processor will help out by giving an indication of when each line starts. Now cycle accuracy is more important. If the CPU runs a bit slower than it should the sprites will be updated too late causing them to flicker or briefly appear distorted. There isn't an intrinsic difference between this and the "once per frame technique" from an emulator perspective. It's just that the times involved are smaller and thus small timing inaccuracies can make a big difference.

Looking at that you might think that running the CPU a bit more quickly than usual might be fine. Indeed, it might. But then you run into a program which gets the "new line" signal an intentionally delays before changing the sprites. This works because the the hardware only looks at new sprite values at the start of the line. If the changes happen while the line is drawing the changes won't show up until the next line which is what the program expects. Unless you want to program your emulator to have special cases for each game (a viable but time consuming strategy) you learn that your best bet is to be "cycle accurate" so that these different things all work properly.

And there can be even more extreme cases. Some graphics hardware only gives the "new frame" indication. But sprites can be changed on a per-line basis. Very clever programmers will use the "new frame" signal then go into a CPU delay loop precisely timed to wait until, say, half-way down the screen where they'll update the sprites. That's only going to work if the relative timing of the CPU and graphics is exact and the count of cycles per instruction is perfect.

The point being that component interactions can happen because of explicit feedback (e.g., the graphics saying a new line has started) or because of implicit knowledge (e.g., the CPU knows exactly what portion of the display is being shown because it can mark time).

  • So, the cycles of the highest clock component in the system can be understood as the "atoms" of time, since they have the highest resolution? Can the timing of other components be accurately expressed in terms of those atoms? Commented Jul 27, 2016 at 13:11
  • Can you please give more details regarding when changes in a component's state can and can't be observed or acted upon by other components in the system? What determines that? The specification of thr system? Intrinsic properties of each component? I ask because some SNES games apparently do things they're "not suppposed to", like writing to video registers during horizontal scan to achieve special effects. If an emulator claims to be cycle-accurate, then it necessarily implements even potentially unspecified behavior? Commented Jul 27, 2016 at 13:30
  • Yes, with a single clock the highest used frequency can give a "atom" (or perhaps "quanta" is a better work) of time that will suffice to track the timing of each component. With multiple clocks you could use some common denominator as the quanta but most often there are not strict dependencies on the relative timing of components with different clocks. That is, any code that depended on some consistency there would either not function or exhibit inconsistent behaviour. I'll edit the answer to cover your second question. Commented Jul 27, 2016 at 22:13
  • 2
    I haven't looked at Higan's source code, but I'd guess the synchronization with the real world is minimal -- buffering audio and doing one frame per 1/60th of a second. I do know that the overhead adds up. At the cycle level dynamic code translation isn't available and one is hard-pressed to do better than a 10:1 slowdown when interpreting instructions. Also consider that drawing a full screen at a time is a lot faster than a line at a time and that is faster than a pixel at a time. Sounds reasonable and one could only answer by writing a faster version with the same level of accuracy. Commented Jul 28, 2016 at 20:48
  • 1
    Many games on old systems would "race the beam" that is draw ahead of the refresh of the CRT screen based on intimate knowledge of the CPU cycles and the bus frequency to manage flicker free graphics on slow systems. I've seen games do this on the C64, A2, and the classic (B&W) Macs. Given how slow old computers are it's amazing that 60 FPS graphics could be managed at all using the screen refresh, even using bare metal CPU cycles to synchronize. Commented Aug 3, 2016 at 14:10

Video game systems are generally designed to be connected to a CRT display whose beam will scan from top to bottom 50 (PAL) or roughly 60 (NTSC) times per second, and left to right 15,650 (PAL) or roughly 15,750 (NTSC) times/second. During each instruction cycle, the beam will move a certain distance, and the effects of certain operations may be affected by the location of the beam when they are performed. What is important with a cycle-accurate emulator is typically not that things are performed in real time on a microsecond-by-microsecond basis, but rather that the effects of various operations done by the code are consistent with what would have happened on a real system if the operations were performed with the beam at the position it would have on a real system.

It's possible that emulators that allow real hardware to be plugged into them will require real-time cycle-by-cycle emulation, but meeting that requirement on any platform that isn't 100% devoted to emulation while it's running is apt to be difficult.


For "cycle accurate" emulation, an emulator needs to make sure that software using delay loops (or carefully timed assembly instructions) gets a reaction after the same number of cycles as on a real system.

In many (especially old) systems, peripherals are clocked by the main CPU, e.g. the old ISA bus traditionally just used whatever frequency the CPU had (until CPUs got too fast and an indirection had to be introduced). This establishes a pretty good baseline clock for emulation (for device register access etc.), but that's actually the easy part. Most peripherals are timed by external, physical, elements such as rotating platters, or incoming bits on a wire. In most cases, an emulator would not physically model those, but instead do anything from completely ignoring the problem, adding fixed delays, to precise CPU cycle counting.

In that context, "cycle accurate" just means that the emulator has a mechanism in place that matches the speed of the emulated peripheral to the emulated CPU so that software running on the emulated CPU can't tell the difference.


I'm not an expert in emulators, but a cycle obviously refers to a clock cycle. So if a 6502 takes 3 cycles to perform a specific operation and it is being clocked at 1Mhz (1 million cycles per second) then that operation should take 3 millionth of a second to execute. This was pretty important back in the day as it was the only way of accurately timing anything. If you took a game written with the assumption the the main clock was running at 1MHz and then ran it on a machine (or emulator) running at 2Mhz, everything would suddenly be running twice as fast (which is cool for spreadsheets, but not cool for space invaders).

I would further extrapolate that a cycle-accurate emulator would be sensitive not only to spending the right amount of time performing each operation, but also to what happens during each cycle. For example, an opcode might fetch on the first cycle, update memory on the second cycle and set status registers and increment the program counter on the third cycle (so the emulator would try to do exactly the same thing).

You can further apply this to support hardware, co-processors, synthesizer chips, etc. Everything being emulated could be emulated cycle-accurately.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .