Emulation Accuracy

From Emulation General Wiki
Jump to: navigation, search

An emulator is accurate when an instruction given to both the program and the hardware results in both outputting the same result. That means accurate emulators produce much less audio and video glitches at the cost of more processing power needed. It's often achieved by using tighter synchronization.


Low accuracy[edit]

An emulator isn't accurate when it has a large amount of visual and audio glitches and favors performance as much as possible. To work around these glitches, emulator developers typically include game-specific hacks (and prioritize popular games) to skip over problems, such as compatibility issues that can cause games to break. Many times, these emulators will be deemed incompatible with the less popular games. As byuu explains in a 2011 Ars Technica article linked below, "Speedy Gonzales: Los Gatos Bandidos" will soft-lock towards the end due to a specific hardware edge case that isn't emulated in ZSNES or Snes9x, but is properly dealt with in his own emulator higan due to his documentation of the system. This can also become very problematic when ROM hacks abuse software errors to create otherwise impossible behaviors to achieve what they can. When a ROM hack can only be used in that one specific emulator, he explains, it becomes incompatible with real hardware (either through a flash cart or printed), and that such an issue has occurred with ZSNES before and continues to occur with Nintendo 64 ROM hacks.

Newer emulators tend to favor High Level Emulation (HLE) as opposed to Low Level Emulation (LLE), which results in lower accuracy. While emulators like Dolphin favor accuracy but still retain HLE for performance and have successfully used it to an advantage, these types of exceptions are uncommon and it can still hinder accuracy.

Medium accuracy[edit]

Most emulators headed by multiple developers tend to have fewer glitches, but still have many problems.

High accuracy[edit]

Emulator developers often strive for high accuracy when the system cannot effectively be cycle accurate. Their emulator replicates the components of the original system as closely as possible, and as byuu explains it's that reason that more processing power is required to do so. The result is fewer audio and visual glitches, and better handling of edge cases used by creative game programmers. An emulator with high accuracy may or may not be cycle-accurate and sometimes, they achieve 100% compatibility with commercially released games.

Cycle accuracy[edit]

Perfectly emulating timings right down to the per-cycle accesses results in cycle-accurate emulation. Each individual component is emulated at exactly the right time, in perfect sync and so on, which has a high CPU cost. The speed of the emulation depends on the way cycle-accuracy is implemented, and it doesn't necessarily mean 100% accuracy. Even higan still has issues with the ROM Hack "Mario and Luigi: Kola Kingdom Quest," where it doesn't emulate the text glitch of the level's title.

Chip accuracy[edit]

By simulating each logic chip on the board individually, this not only takes a tremendous amount of processing power or specialized hardware to run (as in, even emulating something from the 1970s on a chip accurate level would need AAA-level system requirements to run at a good speed), but it also requires an incredible amount of effort to make, and it's also almost useless. Although it is the only way to achieve true hardware simulation, cycle accurate emulation can already achieve virtually indistinguishable accuracy from the real hardware, aside from a very negligible set of edge cases. In addition, cycle-accurate emulators have much lower system requirements and programming difficulty. The only chip accurate emulators that are currently usable run on Field Programmable Gate Arrays, or FPGAs, which are essentially custom programmable chips. Machines dedicated to this type of emulation exist, such as the Analogue NT Mini by kevtris or the RetroUSB AVS by bunnyboy. Other examples of chip accurate emulation can be found in flash carts such as the SD2SNES, where various add-on chips are emulated on the included FPGA.


This type is unique in that its method, DICE, emulates arcade machines from the early 1970s. The architecture of these systems is different from a modern architecture, mostly because they don't have a CPU. DICE emulates the discrete logic components of the machines at a circuit level and, although the results are accurate, you need a fast 64-bit PC to run these arcade games at full speed.


The accuracy debate has very clearly split into two sides.

The ones that don't favor accuracy argue that emulators do not need to be as accurate as possible if it can play all the games they need. And because these games tend to be the most recognized alongside the console, there shouldn't really be an interest in making more games work since those ones do. A more compelling point is that as long as an emulator plays the majority of games at full speed on most computers and devices without too many obvious glitches, it doesn't matter how accurately it replicates the original hardware and its many quirks and functions. The faithfulness of the emulator to the console it's emulating comes second to its overall ability to play games.

The ones that favor accuracy explain their view for an entirely different reason; archival. Emulator projects should ultimately strive to recreate the hardware as much as possible; that's the only way for it to be compatible, and that's the only way to preserve the hardware. Speed and scalability to most devices is a lower priority to accuracy to the real console, both for purposes of compatibility and preservation.

Even within the second side, however, there is some disagreement as to just how much accuracy is actually needed. On most platforms, after obtaining a certain amount of accuracy, going further requires an exponential growth in system requirements, the results of which may not be noticeable to the vast majority of users. Cycle accuracy in particular has been hotly debated in regards to its usefulness, due to how such an extreme level of accuracy requires a lot of extra processing power for relatively few gains in compatibility.

Simply put, it's a disagreement between wanting 'good enough', 'good for all cases', and 'good for the future'.

Console revisions[edit]

Many consoles have different internal hardware revisions which degrade accuracy or change the consoles' behavior in another way, such as the SNES 1CHIP (various games have minor issues, such as a small mess of pixels at the top of the screen in games such as Super Ghouls 'n Ghosts or Demon's Crest), Genesis Model 3 (fixed a bug that some games such as Gargoyles used), various Commodore 64 revisions (fixed a useful bug that allowed for smooth horizontal scrolling), or PS2 SCPH-750XX (less compatibility with some PS2 games and PS1 games). These specific consoles are not generally emulated in their respective emulators, and those emulator developers tend to focus only on one revision. An exception to this is VICE, which tries to emulate as many different revisions of the Commodore 64 as possible and as accurately as possible.

Further reading[edit]