Accuracy: Difference between revisions

From NESdev Wiki
Jump to navigationJump to search
(Removed GBA-style register names)
(As far as I'm aware, Mesen is maintained more than the others)
 
(10 intermediate revisions by 4 users not shown)
Line 1: Line 1:
'''Compatibility''' is how well an emulator produces the same output as the original system when running a particular known program.
'''Compatibility''' is how well an emulator produces the same output as the original system when running a particular known program.
'''Accuracy''' refers to how well an emulator produces the same output as the original system when running an arbitrary unknown program.
'''Accuracy''' refers to how well an emulator produces the same output as the original system when running an arbitrary unknown program.
An emulator can be highly compatible without being very accurate; Nesticle was this way back in the 1990s.
An emulator can be highly compatible without being very accurate; NESticle was this way back in the 1990s, running a wide selection of popular North American commercial games.


Accuracy cannot be measured directly. Compatibility with [[Emulator Tests|ROMs designed to test obscure behaviors]] is a good (though not perfect) predictor of accuracy.
Accuracy cannot be measured directly.<ref>Measuring an arbitrary emulator's accuracy reduces to the [[wikipedia:Halting problem|halting problem]] over [[wikipedia:Linear bounded automaton|linear bounded automata]], which is intractable. It'd be easier to [[wikipedia:Formal verification|formally prove]] equivalence to the netlist of [[Visual circuit tutorial|Visual 2A03 and 2C02]].</ref> Compatibility with [[Emulator tests|ROMs designed to test obscure behaviors]] and [[Tricky-to-emulate games|games relying on obscure behaviors]] is a good (though not perfect) predictor of accuracy.


In many cases, an emulator is more forgiving than the hardware, especially in when a program is allowed to write to a register.
In many cases, an emulator is more forgiving than the hardware, especially in when a program is allowed to write to a register.
Nesticle, for instance, allowed writes to [[PPU registers|$2005]] at any time, when the NES allows it only on or after line 241 of each frame (vertical blanking) or when $2001 & $1E == 0 (forced blanking).
NESticle, for instance, allowed writes to [[PPU registers|$2007]] at any time, when the NES allows it only on or after line 241 of each frame (vertical blanking) or when $2001 & $1E == 0 (forced blanking).
Most emulators allow the program to twiddle PPU registers immediately, while the NES PPU [[PPU power up state|ignores most writes for the first frame after a reset]].
Most emulators allow the program to twiddle PPU registers immediately, while the NES PPU [[PPU power up state|ignores most writes for the first frame after a reset]].
Inaccuracies like these led to inadvertent development of [[Program compatibility|programs that the NES itself cannot run]] during the early years of NES homebrew.


Whenever you discover a difference in behavior between the NES and best-of-breed emulators (like Nintendulator and Nestopia), you can help emulators become more accurate.
Whenever you discover a difference in behavior between the NES and best-of-breed [[emulators]] (like Mesen, Nintendulator, and Nestopia), you can help emulators become more accurate.
First reduce your program to a minimal test case: keep removing things while the program continues to exhibit this difference.
First reduce your program to a [http://sscce.org/ minimal test case]: keep removing things while the program continues to exhibit this difference.
Then characterize the behavior difference as best you can and add it to the [[Emulator Tests|test suite]].
Then characterize the behavior difference as best you can, add it to the [[Emulator tests|test suite]], and notify emulator developers through their projects' issue trackers.
 
Some emulators attempt to [[enhancement|enhance]] the games to make them appear more appealing than they did on the original NES.
 
== See also ==
 
* [[Emulator tests]]
* [[Tricky-to-emulate games]]
* [[Game bugs]] - Accurate emulation should correctly reproduce known software bugs.
* [[Program compatibility]] - Homebrew games that may suffer from compatibility problems.


== References ==
== References ==
*[http://nesdev.parodius.com/bbs/viewtopic.php?t=5797 Topic on forum]
<references />
*[https://wiki.mozilla.org/QA/Minimal_Test_Cases How to make a minimal test case] (focuses on HTML, but applies to any virtual machine]
*[https://forums.nesdev.org/viewtopic.php?t=5797 Topic on BBS]
*[https://forums.nesdev.org/viewtopic.php?p=30784#p30784 Different grades of accuracy on BBS]
*[https://wiki.mozilla.org/QA/Minimal_Test_Cases How to make a minimal test case] (focuses on HTML, but applies to any virtual machine)

Latest revision as of 15:27, 8 June 2019

Compatibility is how well an emulator produces the same output as the original system when running a particular known program. Accuracy refers to how well an emulator produces the same output as the original system when running an arbitrary unknown program. An emulator can be highly compatible without being very accurate; NESticle was this way back in the 1990s, running a wide selection of popular North American commercial games.

Accuracy cannot be measured directly.[1] Compatibility with ROMs designed to test obscure behaviors and games relying on obscure behaviors is a good (though not perfect) predictor of accuracy.

In many cases, an emulator is more forgiving than the hardware, especially in when a program is allowed to write to a register. NESticle, for instance, allowed writes to $2007 at any time, when the NES allows it only on or after line 241 of each frame (vertical blanking) or when $2001 & $1E == 0 (forced blanking). Most emulators allow the program to twiddle PPU registers immediately, while the NES PPU ignores most writes for the first frame after a reset. Inaccuracies like these led to inadvertent development of programs that the NES itself cannot run during the early years of NES homebrew.

Whenever you discover a difference in behavior between the NES and best-of-breed emulators (like Mesen, Nintendulator, and Nestopia), you can help emulators become more accurate. First reduce your program to a minimal test case: keep removing things while the program continues to exhibit this difference. Then characterize the behavior difference as best you can, add it to the test suite, and notify emulator developers through their projects' issue trackers.

Some emulators attempt to enhance the games to make them appear more appealing than they did on the original NES.

See also

References

  1. Measuring an arbitrary emulator's accuracy reduces to the halting problem over linear bounded automata, which is intractable. It'd be easier to formally prove equivalence to the netlist of Visual 2A03 and 2C02.