Changes

;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. ;In the world of computing, terms like "[[Hypervisors|hypervisors]]", "[[Simulators|simulators]]", "[[Compatibility_layer|compatibility layers]]", "[[Wrappers|wrappers]]", "[[FPGA|FPGA-based hardware cloning]]" and "[[:Category:Emulators|software emulators]]" are often used interchangeably, leading to confusion. While they share some similarities, each technology serves a distinct purpose and operates at different levels. Within the realm of computer science, emulation occupies a niche distinct from virtualization or other techniques. Whereas hypervisors usually used for partitioning physical hardware resources among multiple guest operating systems, and simulators where developers build virtual replicas of specific environments or processes, emulation endeavors to recreate an entire historical architecture. This digital reconstruction seeks to faithfully capture the instruction set, timing behaviors, hardware features and even peripheral nuances of a bygone hardware platform. Unlike compatibility layers, which translate software instructions to a native format, emulation builds a virtual stage upon which the software itself can perform authentically. Emulation'Accuracy''' s intricate tapestry sometimes intertwines with threads of other technologies though. Notably, certain emulators leverage hypervisors for a more efficient handling of resource allocation and isolation. Additionally, some emulators employ compatibility layers as subcomponents, acting as translators for specific libraries or APIs that might otherwise be incompatible with the host environment. Think of these layers as linguistic bridges, allowing the emulated software to converse fluently with the modern system hardware. By strategically merging these techniques and the help of skilled use of [[High/Low_level_emulation|HLE and LLE or Hybrid]], [[Dynamic_recompilation|compiler techniques]] and using specific features such as Fast Memory Access[https://github.com/PCSX2/pcsx2/pull/5821][https://github.com/PCSX2/pcsx2/pull/7295][https://yuzu-emu.org/entry/yuzu-fastmem/#what-is-fastmem][https://dolphin-emu.org/blog/2016/09/06/booting-the-final-gc-game/] and instruction set support (such as [https://whatcookie.github.io/posts/why-is how -avx-512-useful-for-rpcs3/ AVX-512 for RPCS3]) and other various optimizations[https://yuzu-emu.org/entry/yuzu-progress-report-dec-2023/#android-adventures-and-kernels-with-benefits], certain emulators achieve impressive levels of performance and compatibility, further unlocking the doors to historical software [[Preservation_projects|preservation]].[https://youtu.be/cCXri4yDHmU] So in summary, an accurate the emulator is when an instruction given to both the program and the original hardwareresults in both outputting the same result. Accuracy is most often achieved by tighter syncing. More accuracy That means less graphics accurate emulators produce much fewer audio and audio video glitches, usually at the cost of additional CPU more processing power required to run needed. It's often achieved by using tighter synchronization. The more accurate an emulator is, the lesser deviations there is from real hardware behavior but the game at fullspeedmore demanding it is. There are hopes Ironically, that less CPU power will aspect might at times be needed 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 more accuracy later consoles may be at odds with the emulator's usability, especially with the use 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 tighter programmingthe experience the user values more. ==Types:==Emulators tend to favor [[High/Low level emulation|High-Level Emulation (HLE) as opposed to Low-Level Emulation (LLE)]] for hardware demanding systems to emulate, <abbr title="This shouldn't be confused with compatibility though.">which results in lower accuracy</abbr> 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 [[High/Low_level_emulation#Examples|successfully used it to an advantage]], these types of exceptions are uncommon, and it can still hinder accuracy. 

Low ===Medium accuracy===Medium accuracy finds itself in between, think of it as the middle ground. Emulators with medium-level accuracy emulators will have a large amount decent level of visual compatibility with commercially released games and audio glitchesshould be able to get the job done for the most part. They will typically use various speedhacks Emulators with medium accuracy don't cover some of the more advanced nuances of the hardware it seeks out to skip over problemsimitate, as but this shouldn't matter a result many games simply run due to whole lot for a variety good number of patches while others don't work at allgames. This can become very problematic when ROM hacks use these speedhacks to run by abusing the errors to create otherwise impossible behaviour. This means that the romhack can only be used in that one specific emulator. Such an issue has occured with [[ZSNES]]Most high-level emulators may fall into this category.

===Medium In summary, emulators with medium-level accuracy===Medium accuracy emulators will have fewer glitchesare passable. They aren't the worst, but will still have many problems. Most emulators fall into this categorythey aren't fantastic either, they sit in the middle.

High accuracy emulators try to replicate is a level of precision that emulator developers strive for when achieving [[#Cycle_accuracy|cycle accuracy]] or even [[#Partial cycle-accuracy|partial-cycle accuracy]] is not practical or necessary. This approach focuses on replicating the original system 's components as closely as possible, and for that reason take aiming to faithfully reproduce its behavior while staying mindful of hardware demands. Though it may demand more CPU processing power compared to do so. They will have lowly accurate emulators, pursuing a more accurate emulation experience can pay off in the form of fewer audio and /visual glitchesand better handling of niche scenarios that creative programmers often implement. High Though they don't mimic every clock cycle as precisely as cycle-accuracy , highly accurate emulators may or may not be cycle 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 accurateemulators, this heightened level of accuracy often involves more sophisticated techniques, demanding increased computational resources. ===100% Game compatibilityCycle accuracy===Some high Cycle accuracy is a more stringent form of emulation accuracy that seeks to precisely replicate the timing and execution of each individual cycle of the original hardware. This type of emulation accuracy aims to match the appropriate timing and execution of each cycle. The authenticity and performance of the emulator in question depends in how cycle accuracy is implemented. Typically, emulators with this level of accuracy ensure that situations where precise timing is required are properly dealt with. So, in summary, we can achieve 100% compatibility with commercially released gamestalk 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.

===Cycle accurate=Partial cycle-accuracy====Cycle accurate emulation is basically trying to perfectly emulate timings right down to per-cycle accesses. So each individual component is emulated at exactly This focuses on replicating the right time, timing of instructions and in perfect sync etc.key internal operations, which takes a performance hitwhile simplifying or skipping some less critical details. The size of This can lower the performance hit depends on the way requirements compared to full cycle accuracy . Remember, just because an emulator is implemented partially cycle-accurate doesn't necessarily make it more accurate than a highly accurate emulator. For example, CEN64 only emulates the CPU pipeline cycle-accurately and that's all, on the skill other hand Simple64 is more accurate in terms of the codertiming for specific tasks like certain DMA transfers, even though it doesn't achieve partially cycle-accurate emulation.The accuracy :Examples of these partially cycle-accurate emulators are close to perfection, but at a steep CPU cost[https://old.reddit.com/r/emulation/comments/vy8cg7/ares_v129_has_been_released_crossplatform/ig4da06/ bsnes] and [https://discord.com/channels/976404869386747954/976463759935696977/1106700321222299762 CEN64].

===Chip accurate=Cycle-based accuracy====Chip accurate This type of emulation works by simulating accuracy aims to reproduce the system's functional behavior within a specified number of cycles without necessarily adhering to the exact timing of each logic chip on individual cycle. Since this method doesn't go out of its way to mimic the board individuallyprecise timing and execution of each cycle, it may not be able to handle all hardware edge cases. Not only does this take :An example of a tremendous amount 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.:[https://old.reddit.com/r/emulation/comments/vy8cg7/ares_v129_has_been_released_crossplatform/ig4da06/ Examples of fully cycle-accurate emulators: higan and ares]. ===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 run (as inlow. Therefore, even emulating something as simple 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 [[wikipedia:Zilog_Z80|Z80]] processor offers an example of this: almost all inputs are sampled on a Pong cabinet rising clock, but the WAIT signal is sampled on a chip accurate level requires falling clock. E.g. in a pretty highstandard three-clock-cycle memory access machine cycle the WAIT line is sampled on the final falling clock — 0.5 cycles before the end system 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 full speed1Mhz 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, but they also require will observably trigger interrupts a incredible amount cycle late from the point of view of effort the CPU. In practice, this can cause some copy protection mechanisms to codefail. This  Impinging upon chip accuracy method is pretty much useless, some chips, such as the Commodore 64's [[wikipedia:MOS_Technology_SID|SID]] are part digital and part analog. Although The analog part can be emulated in a discrete fashion, but it is technically often desirable to take those discrete steps at a multiple of the clock rate. However, the only way difference is usually not observable to achieve true 100% other components in the emulated machine so although this is subcycle accuracyas some part of the state of the chip is known as a precision of greater than one cycle, cycle it doesn't tend to affect the design of the emulator as a whole. Example of a subcycle accurate emulator is BeesNES. ===Gate-level accuracy is already near===Gate-perfectlevel 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 point intricacies of individual transistors. This level of system emulation is suitable for scenarios where any inaccuracies present in cycle 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 are pretty much invisible 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 end user (ecost of increased computational complexity, way more than that of gate-level accuracy.g. there are no known discrepancies between BSNES/Higan This method is the most accurate representation of the electrical characteristics and interactions within a real SNES). Not 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 thatbecause of its abysmal performance, but cyclealso 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-accurate 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 much lower system requirements a CPU. DICE emulates the discrete logic components of the machines at a circuit level and programming difficulty, although the results are accurate, you need a fast 64-bit PC to run these arcade games at full speed. There It's not as deep as chip-level emulation for other systems because chips are currently no publiclystill 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-released chip based consoles by Analogue. Just because an emulator claims to be "cycle accurate video game emulators " or "100% compatible" does not mean that said emulator is flawless. This even includes situations in existencewhich 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 [[wikipedia:MOS_Technology_6502|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 there will most likely never while perfection may be nearly impossible at the moment, that doesn't mean that games can't be oneenjoyed. 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.

There are basically two camps The ones that favor accuracy explain their view in that when it comes playing a game with inaccurate emulation the experience may sometimes be quite different to the issue of accuracy. One side argues that as long as an emulator plays the majority of real thing, particularly with games at full speed focused on most computers and devices without too many obvious glitches, it does not matter how accurately it actually replicates the original hardware and its many quirks and functionssplit-second reactions. The faithfulness of the emulator to the console it There is emulating comes second to its overall ability to play gamesalso an entirely different reason: archival. The other side argues that an emulator Emulator projects should ultimately strive to simulate recreate the hardware as much as possible, as ; that is 's the only way for it to achieve as much compatibility as possiblebe compatible, as well as and that's the only way to preserve the hardware. Thus, speed Speed and scalability to most devices takes is a backseat lower priority to accuracy to the real console, both for purposes of compatibility and preservation.

Even within the second campside, 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 still 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 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 battle disagreement between those who feel wanting 'good enough' is , 'good for all cases', and 'good for the goal and those who want nothing but 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 pinnacle top of perfection no matter the costscreen 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.

*[http://arstechnica.com/gaming/2011/08/accuracy-takes-power-one-mans-3ghz-quest-to-build-a-perfect-snes-emulator/Accuracy takes power: one man’s 3GHz quest to build a perfect SNES emulator] - Byuu (now known as Near) ([[higan]] developer), 2011*[https://www.youtube.com/watch?v=oQZMVo_Fmrs Pokémon glitches and emulation accuracy] - TheZZAZZGlitch

===Accuracy Tests===*[[http:PS1 Tests]]*[[GB//tasvideos.org/EmulatorResources/NESAccuracyTests.html NES Accuracy C Tests]]*[[GBA Tests]]

===TASVideos===*[http://tasvideos.org/EmulatorResources/NESAccuracyTests.html NES Accuracy Tests]*[http://tasvideos.org/EmulatorResources/GBAccuracyTests.html Game Boy Accuracy Tests]*[http://tasvideos.org/EmulatorResources/SNESAccuracyTests.html SNES Accuracy Tests]