Changes

An emulator is ;It'''accurate''' when an instruction given s important to both the program know that emulation accuracy and compatibility are two different things; while how closely an emulator mimics the original hardware results in both outputting the same resultis important, don't mistake that for compatibility. That means accurate emulators produce much fewer audio and video glitchesWhether games run properly is a separate concern, usually at the cost of more processing power neededaccuracy can sometimes influence it. See [[#Perfection. It's often achieved by using tighter synchronization3F|"perfection"]] and [[#Controversy|"controversy"]] sections.

Notable accuracy-centric emulators include ;In the world of computing, terms like "[[Nintendo_Entertainment_System_emulators#EmulatorsHypervisors|Mesen2hypervisors]] (NES)", "[[aresSimulators|simulators]] (SNES", N64"[[Compatibility_layer|compatibility layers]]", NGP, WonderSwan)"[[Wrappers|wrappers]]", "[[FPGA|FPGA-based hardware cloning]]" and "[[BlastEm:Category:Emulators|software emulators]] (Sega Mega Drive) among others" are often used interchangeably, leading to confusion. While they share some similarities, each technology serves a distinct purpose and operates at different levels.

The more accurate 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 emulator isentire historical architecture. This digital reconstruction seeks to faithfully capture the instruction set, timing behaviors, the lesser deviations there is from real hardware behavior but 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's intricate tapestry sometimes intertwines with threads of other technologies though. Notably, certain emulators leverage hypervisors for a more demanding it isefficient handling of resource allocation and isolation. IronicallyAdditionally, some emulators employ compatibility layers as subcomponents, acting as translators for specific libraries or APIs that aspect might at times otherwise be at odds incompatible with the host environment. Think of these layers as linguistic bridges, allowing the emulated software to converse fluently with how authentic the experience ismodern system hardware. By strategically merging these techniques and the help of skilled use of [[High/Low_level_emulation|HLE and LLE or Hybrid]], when it introduces [[Input lagDynamic_recompilation|compiler techniques]]and using specific features such as Fast Memory Access[https://github. A similar debate surrounds CRT shaders 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 well[https://whatcookie.github. Not to mention the hardware intensive nature of very accurate emulators io/posts/why-is-avx-512-useful-for-rpcs3/ AVX-512 for later consoles may be at odds RPCS3]) and other various optimizations[https://yuzu-emu.org/entry/yuzu-progress-report-dec-2023/#android-adventures-and-kernels-with the emulator's usability-benefits], especially with the recent collapse certain emulators achieve impressive levels of Moore's Law (in layman's termsperformance and compatibility, 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)further unlocking the doors to historical software [[Preservation_projects|preservation]].[https://youtu.be/cCXri4yDHmU]

So in summary, an accurate emulator is when an instruction given to both the program and the hardware results in both outputting the same result. That means accurate emulators produce much fewer audio and video glitches, usually at the cost of more processing power 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 more demanding it is. 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.

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 [[https://github.com/snes9xgit/snes9x/issues/280 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 (aka. 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.

Newer emulators tend to favor High-Level Emulation (HLE) ===Medium accuracy===Medium accuracy finds itself in between, think of it as opposed to Lowthe middle ground. Emulators with medium-Level Emulation (LLE), which results in lower level accuracyhave a decent level of compatibility with commercially released games and should be able to get the job done for the most part. While emulators like [[Dolphin]] favor Emulators with medium accuracy but still retain HLE for performance and have successfully used don't cover some of the more advanced nuances of the hardware it seeks out to an advantageimitate, these types but this shouldn't matter a whole lot for a good number of exceptions are uncommon and [[High/Low games. Most high-level emulation|it can still hinder accuracy]]emulators may fall into this category.

===Medium In summary, emulators with medium-level accuracy===Most emulators headed by multiple developers tend to have fewer glitches are passable. They aren't the worst, but stillthey aren't fantastic either, have many problemsthey sit in the middle.

Emulator High accuracy is a level of precision that emulator developers often strive for high when achieving [[#Cycle_accuracy|cycle accuracy]] or even [[#Partial cycle-accuracy when the system cannot effectively be |partial-cycle accurateaccuracy]] is not practical or necessary. Their emulator replicates the components of This approach focuses on replicating the original system 's components as closely as possible, and as Near explains aiming to faithfully reproduce its behavior while staying mindful of hardware demands. Though it's that reason that may demand more processing power is required compared to do so. This results lowly accurate emulators, pursuing a more accurate emulation experience can pay off in the form of fewer audio and /visual glitches and better handling of edge cases used by niche scenarios that creative game programmersoften implement. An emulator with high accuracy may or may not be Though they don't mimic every clock cycle as precisely as cycle-accuracy, highly accurate and sometimes, they achieve emulators capture the essence of the original hardware very well. Also achieving 100% compatibility with commercially released gamesis 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.

Emulating components according 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 their per-match the appropriate timing and execution of each cycle accesses results . The authenticity and performance of the emulator in question depends in how cycle-accurate emulationaccuracy is implemented. Each individual component Typically, emulators with this level of accuracy ensure that situations where precise timing is emulated required are properly dealt with. So, in summary, we can talk about three types of cycle emulation: "partial cycle-accuracy", "cycle-based accuracy" and mutually synchronized at single"full cycle-clock resolution, which has a higher CPU costaccuracy". The speed 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 depends , though for knowing the specific degree of cycle-by-cycle precision for each needs further research. ====Partial cycle-accuracy====This focuses on replicating the way timing of instructions and key internal operations, while simplifying or skipping some less critical details. This can lower the performance requirements compared to full cycle-accuracy . Remember, just because an emulator is implementedpartially 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 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.:Examples of partially cycle-accurate emulators are [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]. ====Cycle-based accuracy====This type of emulation accuracy aims to reproduce the system's functional behavior within a specified number of cycles without necessarily mean 100% adhering to the exact timing of each individual cycle. Since this method doesn't go out of its way to mimic the precise timing and execution of each cycle, it may not be able to handle all hardware edge cases.: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.:[https://old.reddit.com/r/emulation/comments/vy8cg7/ares_v129_has_been_released_crossplatform/ig4da06/ Examples of fully cycle-accurate emulators: higan and ares].

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 [[wikipedia:Zilog_Z80|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.

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 [[wikipedia:MOS_Technology_SID|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.

Impinging upon chip accuracy, some chips, such as the Commodore 64's [[wikipedia:MOS_Technology_SID|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 Example of 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 accurate emulator is known as a precision of greater than one cycle, it doesn't tend to affect the design of the emulator as a wholeBeesNES.

===Chip/transistor/logic gate/circuit Gate-level accuracy===By simulating each logic chip Gate-level accuracy focuses on operating at the board individuallylevel of logical gates within a digital circuit. In this approach, this not only takes a tremendous amount the focus is to replicate the behavior of processing power or specialized hardware to run (as in, even the system by emulating something from the 1970s on a chip-accurate interactions and operations of logic gates. This level would need AAA-level system requirements to run at of abstraction allows for a good speed)more efficient imitation of digital circuits, but as it also requires an incredible amount does not delve into the intricacies of effort to make, and <u>it's also almost useless</u>individual transistors. Although it This level of system emulation is suitable for scenarios where a higher-level understanding of circuit behavior is the only way to achieve ''true'' sufficient. This method of hardware simulationimitation should not be recommended for general purposes (for example, cycle accurate emulation can already achieve virtually indistinguishable accuracy from casual gaming), because of its rather poor performance as a result of the emulator mimicking the real hardware, aside from desired machine at a very negligible set of edge cases that rely on real hardware's quirks. In additionlow level, cycle-accurate emulators have much lower system requirements and programming difficulty. An example as such, requires loads of a chip-accurate emulator would be [[MetalNES]]computational power to function.

Contrarily to common misconceptions, [[FPGA]]s don't quite provide for emulation with chip accuracy. Each logic element (LE) on an FPGA consists Examples of multiple inputs, outputs, gate-level emulators are Breaknes and a look-up table (LUT). However, the exact contents of each LUT for each LE is more or less entirely up to the software that's used to synthesize the bitstream for programming the FPGAGateBoy.

The HDL (either VHDL or Verilog) used ===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 define replicate the behavior electrical characteristics and interactions of an FPGA is transistors, offering a series higher degree of accuracy at the cost of (mostly) logicincreased computational complexity, way more than that of gate-related equationslevel accuracy. This method is the most accurate representation of the electrical characteristics and interactions within a machine's circuit, but beyond that due to its extremely demanding nature, it's entirely up should not be recommended for most people looking to the synthesis software how those equations get mapped play their childhood video games not only because of its abysmal performance, but also because it requires way too much computational power to each individual LEexecute. If a pair This type of related AND hardware emulation is great for hardware enthusiasts and OR equations can be mapped into an arbitrary LUT on homebrew developers who want to get a single LE, deep understanding of the synthesis software will produce that, even if functionality and behavior of the original chip had separate gateshardware in question at a very detailed level.

So emulating a chip on a transistor level is something that is still under the purview Examples of CPU-based solutions, and is even more deeply accurate (albeit less performant) than an FPGA. FPGAs don't involve transistor-level emulation, emulators are MetalNES and never haveVisualnes.

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 (iei.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 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.

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.

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 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.