Difference between revisions of "Emulation accuracy"

From Emulation General Wiki
Jump to navigation Jump to search
(This section was pointless)
(Cycle accuracy)
(46 intermediate revisions by 21 users not shown)
Line 1: Line 1:
'''Accuracy''' is how accurate the emulator is to the original hardware. Accuracy is most often achieved by tighter syncing. More accuracy means less graphics and audio glitches, at the cost of additional CPU power required to run the game at fullspeed. There are hopes that less CPU power will be needed for more accuracy with the use of tighter programming.
+
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.
==Types:==
+
 
 +
Notable accuracy-centric emulators include [[Mesen]] (NES), [[higan]] (SNES), [[CEN64]] (N64) and [[Exodus]] (Sega Mega Drive) among others.
 +
 
 +
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.
 +
 
 +
==Types==
 
===Low 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 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.
  
Low accuracy emulators will have a large amount of visual and audio glitches. They will typically use various speedhacks to skip over problems, as a result many games simply run due to a variety of patches while others don't work at all. 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 occurred with [[ZSNES]].
+
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 [[High/Low level emulation|it can still hinder accuracy]].
  
 
===Medium accuracy===
 
===Medium accuracy===
Medium accuracy emulators will have fewer glitches, but will still have many problems. Most emulators fall into this category.
+
Most emulators headed by multiple developers tend to have fewer glitches but still, have many problems.
  
 
===High accuracy===
 
===High accuracy===
High accuracy emulators try to replicate the original system as closely as possible, and for that reason take more CPU power to do so. They will have fewer audio and visual glitches. High accuracy emulators may or may not be cycle accurate. Some high accuracy emulators can achieve 100% compatibility with commercially released games.
+
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 less 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===
 
===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 the right time, and in perfect sync etc., which takes a performance hit. The size of the performance hit depends on the way cycle accuracy is implemented and the skill of the coder.
+
Emulating components according to their per-cycle accesses results in cycle-accurate emulation. Each individual component is emulated and mutually synchronized at single-clock resolution, which has a higher CPU cost. The speed of the emulation depends on the way cycle-accuracy is implemented, and it doesn't necessarily mean 100% accuracy.
 +
 
 +
===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 [[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.
 +
 
 +
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.
  
The accuracy of these emulators are close to perfection, but at a steep CPU cost. However, some people believe that the notion of 100% cycle-based accuracy being slow is a misconception, one that people believe because most attempts at a cycle emulator aren't as well-optimized as they could be. MarathonMan, developer of [[CEN64]], is one of the people who believes this. Whether or not this is the case remains to be seen.
+
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.
  
 
===Chip accuracy===
 
===Chip accuracy===
Chip accurate emulation works by simulating each logic chip on the board individually. Not only does this take a tremendous amount of power to run (as in, even emulating something from the 1970's on a chip accurate level would need Dolphin-level system requirements to run at a good speed.), but they also require a incredible amount of effort and money to make. This accuracy method is pretty much useless. Although it is technically the only way to achieve true 100% hardware simulation, cycle accurate emulation can already achieve accuracy which is virtually indistinguishable from the real hardware. Not only that, but cycle-accurate emulators have much lower system requirements and programming difficulty. There are currently no publicly-released chip accurate video game emulators in existence, and there will most likely never be one.  
+
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 <u>it's also almost useless</u>. 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 [[FPGA]]s, 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.
  
 
===DICE===
 
===DICE===
This emulator needs its own section on accuracy, because its accuracy method is unlike any other. Basically, what [http://sourceforge.net/projects/dice/ DICE] does is emulate arcade machines from the early 1970's. The architecture of these systems is very different from a modern architecture, mostly since they don't have a CPU. So the emulator instead emulates the discrete logic components of the machines at a circuit level. Although the results are highly accurate (as in, very highly accurate) the results are quite system intensive. You need a fast 64-bit gaming PC to run these early-1970's arcade games at full speed.  
+
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.
 +
 
 +
==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 (ie. [[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.
  
 
==Controversy==
 
==Controversy==
There are basically two sides when it comes to the issue of accuracy. One side argues 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 does not matter how accurately it actually replicates the original hardware and its many quirks and functions. The faithfulness of the emulator to the console it is emulating comes second to its overall ability to play games. The other side argues that an emulator should ultimately strive to simulate the hardware as much as possible, as that is the only way to achieve as much compatibility as possible, as well as the only way to preserve the hardware. Thus, speed and scalability to most devices is a lower priority to accuracy to the real console, both for purposes of compatibility and preservation.
+
The accuracy debate has very clearly split into two sides.
  
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 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 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.
+
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.
  
Simply put, it's a disagreement between those who believe 'good enough' is the goal and those who want nothing but perfection no matter the cost.
+
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 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==
 +
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 emulators|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==
 
==Further reading==
  
http://arstechnica.com/gaming/2011/08/accuracy-takes-power-one-mans-3ghz-quest-to-build-a-perfect-snes-emulator/
+
*[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 ([[higan]] developer), 2011
 
+
*[https://www.youtube.com/watch?v=oQZMVo_Fmrs Pokémon glitches and emulation accuracy] - TheZZAZZGlitch
[http://tasvideos.org/EmulatorResources/NESAccuracyTests.html NES Accuracy Tests]
 
  
[http://tasvideos.org/EmulatorResources/GBAccuracyTests.html Game Boy Accuracy Tests]
+
===Accuracy Tests===
 +
*[[PS1 Tests]]
 +
*[[GB/C Tests]]
  
[http://tasvideos.org/EmulatorResources/SNESAccuracyTests.html SNES Accuracy 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]
 
[[Category:FAQs]]
 
[[Category:FAQs]]

Revision as of 11:29, 2 February 2020

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.

Notable accuracy-centric emulators include Mesen (NES), higan (SNES), CEN64 (N64) and Exodus (Sega Mega Drive) among others.

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.

Types

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

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

High accuracy

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

Emulating components according to their per-cycle accesses results in cycle-accurate emulation. Each individual component is emulated and mutually synchronized at single-clock resolution, which has a higher CPU cost. The speed of the emulation depends on the way cycle-accuracy is implemented, and it doesn't necessarily mean 100% accuracy.

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.

Chip accuracy

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.

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 PC to run these arcade games at full speed.

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

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

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

Accuracy Tests

TASVideos