Emulation accuracy: Difference between revisions
No edit summary |
No edit summary |
||
| Line 2: | Line 2: | ||
;It's important to know that emulation accuracy and compatibility are two different things; while how closely an emulator mimics the original hardware is important, don't mistake that for compatibility. Whether games run properly is a separate concern, accuracy can sometimes influence it. See [[#Perfection.3F|"perfection"]] and [[#Controversy|"controversy"]] sections. | ;It's important to know that emulation accuracy and compatibility are two different things; while how closely an emulator mimics the original hardware is important, don't mistake that for compatibility. Whether games run properly is a separate concern, accuracy can sometimes influence it. See [[#Perfection.3F|"perfection"]] and [[#Controversy|"controversy"]] sections. | ||
If emulators are accurate enough, it produces much fewer audio and video glitches, usually at the cost of more processing power needed. It's often achieved by using tighter synchronization. This means the more accurate an emulator is, the lesser deviations there are from real hardware behavior but the more demanding it is. In another way, instructions given to both the program and the hardware (original intentions) results in both outputting the same result (mimics). Ironically, that aspect might at times be at odds with how authentic the experience is, when it introduces [[input lag]]. A similar debate surrounds [[Shaders,_filters,_and_sound|CRT shaders]] as well. Not to mention the hardware intensive nature of very accurate emulators for later consoles may be at odds with the emulator's usability, especially with the recent collapse of Moore's Law (in layman's terms, you can't just "buy a better PC" if semiconductor technology does not catch up fast enough with what it takes for accurate emulation that makes zero compromises for optimizing speed). As a result, accuracy and emulator authenticity continue to be controversial subjects and highly a matter of opinion depending on what aspect of the experience the user values more. | If emulators are accurate enough, it produces much fewer audio and video glitches, usually at the cost of more processing power needed. It's often achieved by using tighter synchronization. This means the more accurate an emulator is, the lesser deviations there are from real hardware behavior but the more demanding it is. In another way, instructions given to both the program and the hardware (original intentions) results in both outputting the same result (mimics). Ironically, that aspect might at times be at odds with how authentic the experience is, when it introduces [[input lag]]. A similar debate surrounds [[Shaders,_filters,_and_sound|CRT shaders]] as well. Not to mention the hardware intensive nature of very accurate emulators for later consoles may be at odds with the emulator's usability, especially with the recent collapse of Moore's Law (in layman's terms, you can't just "buy a better PC" if semiconductor technology does not catch up fast enough with what it takes for accurate emulation that makes zero compromises for optimizing speed). As a result, accuracy and emulator authenticity continue to be controversial subjects and highly a matter of opinion depending on what aspect of the experience the user values more. | ||
Revision as of 16:04, 28 November 2025
- For detailed explanation of emulation approach and which methods are implemented for mimicking the original hardware behavior, see High and low-level emulation.
- It's important to know that emulation accuracy and compatibility are two different things; while how closely an emulator mimics the original hardware is important, don't mistake that for compatibility. Whether games run properly is a separate concern, accuracy can sometimes influence it. See "perfection" and "controversy" sections.
If emulators are accurate enough, it produces much fewer audio and video glitches, usually at the cost of more processing power needed. It's often achieved by using tighter synchronization. This means the more accurate an emulator is, the lesser deviations there are from real hardware behavior but the more demanding it is. In another way, instructions given to both the program and the hardware (original intentions) results in both outputting the same result (mimics). Ironically, that aspect might at times be at odds with how authentic the experience is, when it introduces input lag. A similar debate surrounds CRT shaders as well. Not to mention the hardware intensive nature of very accurate emulators for later consoles may be at odds with the emulator's usability, especially with the recent collapse of Moore's Law (in layman's terms, you can't just "buy a better PC" if semiconductor technology does not catch up fast enough with what it takes for accurate emulation that makes zero compromises for optimizing speed). As a result, accuracy and emulator authenticity continue to be controversial subjects and highly a matter of opinion depending on what aspect of the experience the user values more.
Types
Emulators tend to favor High-Level Emulation (HLE) as opposed to Low-Level Emulation (LLE) for hardware demanding systems to emulate, which results in lower accuracy because instead of mimicking the hardware these games were released on, High-Level emulators mimic how the games themselves behaved on the desired system. 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.
Low accuracy
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 (obscure) games. As Near (then known 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 (emulator oversights) 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.
Medium accuracy
Medium accuracy finds itself in between, think of it as the middle ground. Emulators with medium-level accuracy have a decent level of compatibility with commercially released games and should be able to get the job done for the most part. Emulators with medium accuracy don't cover some of the more advanced nuances of the hardware they seek out to imitate, but this shouldn't matter a whole lot for a good number of games. Most high-level emulators may fall into this category.
In summary, emulators with medium-level accuracy are passable. They aren't the worst, but they aren't fantastic either, they sit in the middle.
High accuracy
High accuracy is a level of precision that emulator developers strive for when achieving cycle accuracy or even partial-cycle accuracy is not practical or necessary. This approach focuses on replicating the original system's components as closely as possible, aiming to faithfully reproduce its behavior while staying mindful of hardware demands. Though it may demand more processing power compared to lowly accurate emulators, pursuing a more accurate emulation experience can pay off in the form of fewer audio/visual glitches and better handling of niche scenarios that creative programmers often implement. Though they don't mimic every clock cycle as precisely as cycle-accuracy, highly accurate emulators capture the essence of the original hardware very well. Also achieving 100% compatibility with commercially released games is a common goal for emulators with high accuracy. Some of these emulators represent an even more meticulous level of precision in replicating the original system compared to other highly accurate emulators, this heightened level of accuracy often involves more sophisticated techniques, demanding increased computational resources.
Cycle accuracy
A machine cycle is like the heartbeat of your device's CPU (Central Processing Unit). It's the sequence of actions your device's CPU goes through to process instructions and perform tasks. Think of it as a choreographed dance that your CPU performs for every command it receives. A machine cycle is made up of three stages:
- Fetch: The control unit finds the memory address of the next instruction using the program counter register (PC). It then requests the instruction from the main memory and stores it in the instruction register (IR).
- Decode: The control unit examines the instruction in the IR and determines what needs to be done. For example, if the instruction is to add two numbers, the control unit will interpret the binary instruction to determine this.
- Execute: The control unit sends signals to the ALU, memory, and other components to perform the correct action.
The CPU is constantly retrieving, decoding, and running instructions during the machine cycle. Cycle accuracy is a level of emulation accuracy that puts a big emphasis on precisely replicating the timing and execution of a hardware's machine cycles. Depending on how this method of emulation is implemented, cycle accuracy ensures that instructions are being executed at the right time, which is great for scenarios where precise timing is required.
In summary, we can talk about three types of cycle emulation: "partial cycle-accuracy", "cycle-based accuracy" and "full cycle-accuracy". These can be considered as subsets of "cycle accuracy." Due to technical challenges and performance considerations, emulators often employ either "partial cycle-accuracy" or "cycle-based accuracy" depending on the specific requirements.
Mesen, BlastEm, NanoBoyAdvance, Azayaka, MartyPC and Stella are recognized for their cycle-accurate emulation, though for knowing the specific degree of cycle-by-cycle precision for each needs further research.
Partial cycle-accuracy
This focuses on replicating the timing of instructions and key internal operations, while simplifying or skipping over some less critical details. This can lower the performance requirements compared to full cycle accuracy. Remember, just because an emulator is partially cycle-accurate doesn't necessarily make it more precise than a highly accurate emulator. For example, CEN64 only emulates the CPU pipeline cycle-accurately and that's all, on the other hand Simple64 is more accurate in terms of timing for specific tasks like certain DMA transfers, even though it doesn't achieve partially cycle-accurate emulation.
Cycle-based accuracy
This type of emulation accuracy attempts to do work in cycle-sized units, where all work that would happen in a cycle happens as a single unit.
- An example of a cycle-based emulator is jgnes with its cycle-based emulation of the Ricoh 2A03 and PPU.
Full cycle-accuracy
This aims to mimic every aspect of the CPU's timing and behavior, including internal operations and interactions with other components like memory and I/O devices. This demands the highest processing power for emulation among the cycle level accuracy subsets.
M-cycles vs. T-cycles
Many systems differentiate between multiple types of hardware "cycles", which can cause confusion when discussing cycle-accuracy. Two of the most common terms used in emulation, especially for systems like the Game Boy, are the machine cycle (M-cycle) and the clock cycle (T-cycle).
- T-cycle (clock cycle)
- A T-cycle (sometimes called a *T-state*) is the smallest timing unit generated by the hardware clock.
- For example, the Game Boy’s CPU runs at ~4.19 MHz, meaning it completes ~4.19 million T-cycles per second.
- Some hardware events (memory access phases, interrupt sampling, or PPU timing) occur at specific T-cycle boundaries.
- M-cycle (machine cycle)
- An M-cycle is a higher-level cycle composed of multiple T-cycles.
- On the Game Boy, 1 M-cycle = 4 T-cycles.
- CPU instructions are usually measured in M-cycles (e.g., a 1-byte load instruction may take 2 M-cycles = 8 T-cycles).
Emulators that simulate only M-cycles group all four T-cycles into a single unit of work, which simplifies execution but may obscure timing-sensitive behavior. Emulators that simulate T-cycles can update hardware every single clock tick, enabling more precise behavior such as correct interrupt timing, LCD effects, and edge-case hardware interactions.
In short:
- T-cycle accuracy = updates each clock tick → highest timing precision.
- M-cycle accuracy = updates once every group of clock ticks → simpler, faster, but less precise.
These concepts are important when distinguishing between partial cycle-accuracy, full cycle-accuracy, and subcycle accuracy.
| Feature | T-cycle (Clock Cycle) | M-cycle (Machine Cycle) |
|---|---|---|
| Basic definition | Smallest unit of time generated by the hardware clock | A group of T-cycles used by the CPU to perform a complete internal operation |
| Typical duration | 1 clock tick (e.g., on Game Boy ≈ 238 ns) | Several T-cycles bundled together (Game Boy: 4 T-cycles) |
| Hardware significance | Memory access phases, interrupt checks, PPU/graphics timing, bus states | CPU instruction steps such as fetch, decode, or execute phases |
| Example (Game Boy) | CPU runs at ~4.19 MHz → ~4.19 million T-cycles per second | 1 M-cycle = 4 T-cycles → ~1.05 million M-cycles per second |
| Emulation cost | Highest performance cost – must update every clock tick | Lower performance cost – allows batching of work |
Subcycle accuracy
The heartbeat of an IC is its clock signal; a full cycle of the clock signal involves two transitions: from low to high and then back from high to low. Therefore, even a chip that is fully synchronized to its clock may not be emulated accurately if it is emulated with only cycle precision as it'll have to bundle together both its rising and falling actions.
The Z80 processor offers an example of this: almost all inputs are sampled on a rising clock, but the WAIT signal is sampled on a falling clock. E.g. in a standard three-clock-cycle memory access machine cycle the WAIT line is sampled on the final falling clock — 0.5 cycles before the end of the machine cycle. If the Z80 is required to wait, it will sample the WAIT line again at cycle intervals until it spots that it is no longer asserted and complete 0.5 cycles after that. Therefore, an emulator that only cycles accurately will have to sample it either 0.5 cycles early or 0.5 cycles late and will stop waiting either 0.5 cycles early or 0.5 cycles late, causing a phase error with whatever it was sampling.
Worse than that, as the Z80 tests WAIT only once every machine cycle, not every clock cycle, missing it as a result of sampling at the wrong time can cause a net error of four or more cycles.
Using the broad brush of cycle accuracy can also cause problems in machines with multiple clock signals — component A being accurate only to the complete clock cycle can leave it as observably inaccurate if component B is running with a quicker clock. A simple example of this can be found in the BBC Micro, where the 6522 timer chips run at 1Mhz while the CPU runs at 2Mhz. 6522s generate an interrupt half a cycle after they underflow. Therefore, if the 6522s in a BBC Micro are emulated only in whole-cycle steps, they will observably trigger interrupts a cycle late from the point of view of the CPU. In practice, this can cause some copy protection mechanisms to fail.
Impinging upon chip accuracy, some chips, such as the Commodore 64's SID are part digital and part analog. The analog part can be emulated in a discrete fashion, but it is often desirable to take those discrete steps at a multiple of the clock rate. However, the difference is usually not observable to other components in the emulated machine so although this is subcycle accuracy as some part of the state of the chip is known as a precision of greater than one cycle, it doesn't tend to affect the design of the emulator as a whole.
Example of a subcycle accurate emulator is BeesNES.[1]
Gate-level accuracy
Gate-level accuracy focuses on operating at the level of logical gates within a digital circuit. In this approach, the focus is to replicate the behavior of the system by emulating the interactions and operations of logic gates. This level of abstraction allows for a more efficient imitation of digital circuits, as it does not delve into the intricacies of individual transistors. This level of system emulation is suitable for scenarios where a higher-level understanding of circuit behavior is sufficient. This method of hardware imitation should not be recommended for general purposes (for example, casual gaming), because of its rather poor performance as a result of the emulator mimicking the desired machine at a very low level, and as such, requires loads of computational power to function.
Examples of gate-level emulators are Breaknes and GateBoy.
Transistor-level accuracy
Transistor-level accuracy represents a more granular emulation accuracy level that delves into the behavior of individual transistors within a digital circuit. This approach aims to replicate the electrical characteristics and interactions of transistors, offering a higher degree of accuracy at the cost of increased computational complexity, way more than that of gate-level accuracy. This method is the most accurate representation of the electrical characteristics and interactions within a machine's circuit, but due to its extremely demanding nature, it should not be recommended for most people looking to play their childhood video games not only because of its abysmal performance, but also because it requires way too much computational power to execute. This type of hardware emulation is great for hardware enthusiasts and homebrew developers who want to get a deep understanding of the functionality and behavior of the hardware in question at a very detailed level.
Examples of transistor-level emulators are MetalNES and Visualnes.
DICE
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 CPU (for single thread performance) to run these arcade games at full speed. It's not as deep as gate or transistor-level emulation for other systems because chips are still treated as black boxes, though.
Perfection?
While it may be theoretically possible to have a 100% perfect emulator, that feat is very rare (if not nearly impossible), even for some highly regarded emulators such as higan or kevtris's work on the various FPGA-based consoles by Analogue. Just because an emulator claims to be "cycle accurate" or "100% compatible" does not mean that said emulator is flawless. This even includes situations in which all emulator accuracy tests (i.e. PS1 Tests) are passed, as these tests cannot cover every single edge case, and some of these tests may even fail on real hardware, leading to even more confusion. Some things are nearly impossible to perfectly emulate, such as some of the illegal opcodes of the 6502, where the results are completely unpredictable on hardware, and different hardware revisions have different results and different illegal opcodes. The closest one could get to writing a perfect emulator would be if someone were to exactly copy an original ASIC map or a decap onto an FPGA, and even then, that isn't always a magic bullet.
While any given emulator may not be perfect, that does not mean that the emulator is bad by any means. Writing an accurate emulator is extremely hard work, and while perfection may be nearly impossible at the moment, that doesn't mean that games can't be enjoyed. Work on archival via emulation has come a very long way since the emulators of the 1990s, and things are only getting better from here, with excellent emulators such as the previously mentioned higan and kevtris's FPGA cores being available to use right now. In other words, "good enough" goes a long way.
Controversy
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 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 in that when playing a game with inaccurate emulation the experience may sometimes be quite different to the real thing, particularly with games focused on split-second reactions. There is also 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 regard 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
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), 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.
Further reading
- Accuracy takes power: one man’s 3GHz quest to build a perfect SNES emulator - Byuu (now known as Near) (higan developer), 2011
- Pokémon glitches and emulation accuracy - TheZZAZZGlitch
- Dolphin Blog: 2409-161 version - Fix Some Common Opcode Decoding Errors by Tilka
See also
- Frames per second
- Input lag
- Computer specifications
- Displays
- High/Low level emulation
- Computer specifications