Emulator tests
There are many ROMs available that test an emulator for inaccuracies.
Validation ROMs
Note: Most of these test roms can also be found at https://github.com/christopherpow/nes-test-roms
CPU Tests
Name | Author | Description | Resources |
---|---|---|---|
branch_timing_tests | blargg | These ROMs test timing of the branch instruction, including edge cases | |
cpu_dummy_reads | blargg | Tests the CPU's dummy reads | thread |
cpu_dummy_writes | bisqwit | Tests the CPU's dummy writes | thread |
cpu_exec_space | bisqwit | Verifies that the CPU can execute code from any possible memory location, even if that is mapped as I/O space | thread |
cpu_flag_concurrency | bisqwit | Unsure what results are meant to be, see thread for more info. | thread |
cpu_interrupts_v2 | blargg | Tests the behavior and timing of CPU in the presence of interrupts, both IRQ and NMI; see CPU interrupts. | thread |
cpu_reset | blargg | Tests CPU registers just after power and changes during reset, and that RAM isn't changed during reset. | |
cpu_timing_test6 | blargg | This program tests instruction timing for all official and unofficial NES 6502 instructions except the 8 branch instructions (Bxx) and the 12 halt instructions (HLT) | thread |
coredump | jroatch | Coredump tool for displaying contents of RAM | thread |
instr_misc | blargg | Tests some miscellaneous aspects of instructions, including behavior when 16-bit address wraps around, and dummy reads. | |
instr_test_v5 | blargg | Tests official and unofficial CPU instructions and lists which ones failed. It will work even if emulator has no PPU and only supports NROM, writing a copy of output to $6000 (see readme). This more thoroughly tests instructions, but can't help you figure out what's wrong beyond what instruction(s) are failing, so it's better for testing mature CPU emulators. | |
instr_timing | blargg | Tests timing of all instructions, including unofficial ones, page-crossing, etc. | |
nestest (doc) | kevtris | fairly thoroughly tests CPU operation. This is the best test to start with when getting a CPU emulator working for the first time. Start execution at $C000 and compare execution with a known good log (created using Nintendulator, an emulator chosen by the test's author because its CPU was verified to function correctly, aside from some minor details of the power-up state). | |
ram_retain | rainwarrior | RAM contents test, for displaying contents of RAM at power-on or after reset | thread |
PPU Tests
Name | Author | Description | Resources |
---|---|---|---|
color_test | rainwarrior | Simple display of any chosen color full-screen | thread |
blargg_ppu_tests_2005.09.15b | blargg | Miscellaneous PPU tests (palette ram, sprite ram, etc.) | thread |
full_nes_palette | blargg | Displays the full palette with all emphasis states, demonstrates direct PPU color control | thread |
nmi_sync | blargg | Verifies NMI timing by creating a specific pattern on the screen (NTSC & PAL versions) | thread |
ntsc_torture | rainwarrior | NTSC Torture Test displays visual patterns to demonstrate NTSC signal artifacts | thread |
oam_read | blargg | Tests OAM reading ($2004), being sure it reads the byte from OAM at the current address in $2003. | thread |
oam_stress | blargg | Thoroughly tests OAM address ($2003) and read/write ($2004) | thread |
oamtest3 | lidnariq | Utility to upload OAM data via $2003/$2004 - can be used to test for the OAMADDR bug behavior | thread 1 thread 2 |
palette | rainwarrior | Palette display requiring only scanline-based palette changes, intended to demonstrate the full palette even on less advanced emulators | thread |
ppu_open_bus | blargg | Tests behavior when reading from open-bus PPU bits/registers | |
ppu_read_buffer | bisqwit | Mammoth test pack tests many aspects of the NES system, mostly centering around the PPU $2007 read buffer | thread |
ppu_sprite_hit | blargg | Tests sprite 0 hit behavior and timing | thread |
sprite_overflow_tests | blargg | Tests sprite overflow behavior and timing | thread |
ppu_vbl_nmi | blargg | Tests the behavior and timing of the NTSC PPU's VBL flag, NMI enable, and NMI interrupt. Timing is tested to an accuracy of one PPU clock. | thread |
scanline | Quietust | Displays a test screen that will contain glitches if certain portions of the emulation are not perfect. | |
sprdma_and_dmc_dma | blargg | Tests the cycle stealing behavior of the DMC DMA while running Sprite DMAs | thread |
sprite_hit_tests_2005.10.05 | blargg | Generally the same as ppu_sprite_hit (older revision of the tests - ppu_sprite_hit is most likely better) | thread |
sprite_overflow_tests | blargg | Generally the same as ppu_sprite_overflow (older revision of the tests - ppu_sprite_overflow is most likely better) | thread |
tvpassfail | tepples | NTSC color and NTSC/PAL pixel aspect ratio test ROM (older revision of the tests - 240p Test Suite is most likely better) | thread |
vbl_nmi_timing | blargg | Generally the same as ppu_vbl_nmi (older revision of the tests - ppu_vbl_nmi is most likely better) | thread |
APU Tests
Name | Author | Description | Resources |
---|---|---|---|
apu_mixer | blargg | Verifies proper operation of the APU's sound channel mixer, including relative volumes of channels and non-linear mixing. recordings when run on NES are available for comparison, though the tests are made so that you don't really need these. | thread |
apu_phase_reset | Rahsennor | Tests the correct square channel behavior when writing to $4003/4007 (reset the duty cycle sequencers but not the clock dividers) | thread |
apu_reset | blargg | Tests initial APU state at power, and the effect of reset. | |
apu_test | blargg | Tests many aspects of the APU that are visible to the CPU. Really obscure things are not tested here. | |
blargg_apu_2005.07.30 | blargg | Tests APU length counters, frame counter, IRQ, etc. | |
dmc_dma_during_read4 | blargg | Tests register read/write behavior while DMA is running | |
dmc_tests | ? | ? | |
dpcmletterbox | tepples | Tests accuracy of the DMC channel's IRQ | |
pal_apu_tests | blargg | PAL version of the blargg_apu_2005.07.30 tests | |
square_timer_div2 | blargg | Tests the square timer's period | |
test_apu_2 (1-10) (11) | x0000 | 11 tests that verify a number of behaviors with the APU (including the frame counter) | thread |
test_apu_env | blargg | Tests the APU envelope for correctness. | |
test_apu_sweep | blargg | Tests the sweep unit's add, subtract, overflow cutoff, and minimum period behaviors. | |
test_apu_timers | blargg | Tests frequency timer of all 5 channels | |
test_tri_lin_ctr | blargg | Tests triangle's linear counter and clocking by the frame counter | |
volume_tests | tepples | Plays tones on all the APU's channels to show their relative volumes at various settings of $4011. Package includes a recording from an NES's audio output for comparison. |
Mapper-specific Tests
Name | Author | Description | Resources |
---|---|---|---|
31_test | rainwarrior | Tests for mapper 31 (see thread for ROMs in various PRG sizes) | thread |
BNTest | tepples | Tests how many PRG banks are reachable in BxROM and AxROM. | thread GitHub |
bxrom_512k_test | rainwarrior | Similar to the BxROM test in BNTest above. | thread |
FdsIrqTests (v7) | Sour | Tests various elements of the FDS' IRQ | thread |
exram | Quietust | MMC5 exram test | |
famicom_audio_swap_tests | rainwarrior | Hotswap tests for Famicom expansion audio (5B, MMC5, VRC6, VRC7, N163, FDS) | thread |
fme7acktest-r1 | tepples | Checks some IRQ acknowledgment behiaviors of Sunsoft FME-7 that emulators were getting wrong in 2015. | thread |
fme7ramtest-r1 | tepples | Checks how much work RAM the Sunsoft FME-7 can access | thread GitHub |
Holy Mapperel | tepples | Detects over a dozen mappers and verifies that all PRG ROM and CHR ROM banks are reachable, that PRG RAM and CHR RAM can be written and read back without error, and that nametable mirroring, IRQ, and WRAM protection work. (Formerly Holy Diver Batman) | thread GitHub |
mmc3bigchrram | tepples | MMC3 test for large 32kb CHR RAM with NES 2.0 headers | thread GitHub |
mmc3_test_2 | blargg | MMC3 scanline counter and IRQ generation tests. | |
mmc3irqtest | N-K | MMC3 scanline IRQ test and $C000 glitch investigation. | thread |
mmc5test | Drag | MMC5 scanline counter | thread |
mmc5test_v2 | AWJ | MMC5 tests | thread |
serom | lidnariq | Tests the constraints of SEROM / SHROM / SH1ROM variations of the MMC1 boards. | thread |
NES 2.0 Submapper Tests | rainwarrior | 2_test - Mapper 2, Submappers 0, 1 and 2 | thread |
rainwarrior | 3_test - Mapper 3, Submappers 0, 1 and 2 | thread | |
rainwarrior | 7_test - Mapper 7, Submappers 0, 1 and 2 | thread | |
rainwarrior | 34_test - Mapper 34, Submappers 1 and 2 | thread | |
test28 | tepples | Tests for mapper 28 | thread GitHub |
vrc24test | AWJ | Detects and tests all VRC 2/4 variants | thread |
vrc6test | natt | VRC6 mirroring tests | thread |
mmc5ramsize | rainwarrior | MMC5 large PRG-RAM support tests | thread |
mmc1atest | tepples | Characterizes behavior of MMC1A vs. MMC1B | thread GitHub |
n163_soundram | rainwarrior | Test for Namco 163 audio sound RAM read-back. | thread |
Input Tests
Name | Author | Description | Resources |
---|---|---|---|
allpads | tepples | Multiple controller test supporting NES controller, Super NES controller, Famicom microphone, Four Score, Zapper, NES Arkanoid controller, and Super NES Mouse; also has raw 32-bit report mode | thread GitHub |
dma_sync_test_v2 | Rahsennor | Tests DMC DMA read corruption | thread |
PaddleTest3 | 3gengames | Test for the Arkanoid controller | thread |
vaus | lidnariq | Arkanoid controller 9-bit result test | thread |
read_joy3 | blargg | Various NES controllers tests, including read corruption due to DMC DMA | thread |
Zap Ruder | tepples | Test for the Zapper, including dual wield but not the serial Vs. variant | thread GitHub |
spadtest-nes | tepples | Super Nintendo controller test (when connected to a NES) | thread |
vaus_test | tepples | Another test for the Arkanoid controller | thread GitHub |
mset | rainwarrior | SNES mouse test | thread |
mict | rainwarrior | Famicom microphone test | thread |
Telling LYs? | tepples | Tests whether input can change on any scanline | thread GitHub |
ctrltest | rainwarrior | Generic log of 16-bit report on all 5 input data lines. | thread |
raw | lidnariq | Immediate state of 32-bit report on all 5x2 input data lines.
Immediate state of 64-bit report on all 5x2 input data lines. |
thread |
zapper tests | rainwarrior | Simple tests for displaying output of zapper reads. | thread |
powerpadgesture | tepples | Gesture test for Power Pad displaying log of presses and releases. | thread |
POWERPAD.NES | Tennessee Carmel-Veilleux | Old simple test for Power Pad. | powerpad.txt |
Misc Tests
Name | Author | Description | Resources |
---|---|---|---|
240pee-0.22 | tepples | 240p Test Suite (an NES version of the 240p Test Suite by Artemio Urbina), including an MDFourier tone generator | thread GitHub |
characterize-vs | lidnariq | VS System tests | thread |
NEStress | Old test - some of the tests are supposed to fail on real hardware. | ||
oc-r1a | tepples | Detects and displays accurate clock rate of the NES (since incorporated into 240p Test Suite) | thread |
nes-audio-tests | rainwarrior | NSF and NES ROM tests for expansion audio sound, NSF behaviour, and other various audio related things. |
Automated testing
It's best if your emulator can automatically run a suite of tests at the press of a button. This allows you to re-run them every time you make a change, without any effort. Automation can be difficult, because the emulator must be able to determine success/failure without your help.
The first part of automated testing is support for a "movie" or "demo", or a list of what buttons were pressed when. An emulator makes a movie by recording presses while the user is playing, and then it plays the movie by feeding the recorded presses back through the input system. This not only helps automated testing but also makes your emulator attractive to speedrunners.
To create a test case, record a movie of the player activating all tests in a ROM, take a screenshot of each result screen, and log the time and a hash of each screenshot. The simplest test ROMs won't require any button presses. ROMs that test more than one thing are more likely to require them, and an actual game will require a playthrough. Then to run a test case, play the movie in fast-forward (no delay between frames) and take screenshots at the same times. If a screenshot's hash differs from that of the corresponding screenshot from when the test case was created, make a note of this difference in the log. Then you can compare the emulator's output frame-by-frame to that of the previous release of your emulator running the same test case.