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
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	?	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 log from Nintendulator, an emulator whose CPU is known to work correctly (apart from some details of the power-up state).

PPU Tests

Name	Author	Description	Resources
blargg_ppu_tests_2005.09.15b	blargg	Miscellaneous PPU tests (palette ram, sprite ram, etc.)	thread
full_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
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
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
ppu_sprite_overflow	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.
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
sprdma_and_dmc_dma	blargg	Tests the cycle stealing behavior of the DMC DMA while running Sprite DMAs	thread
tvpassfail	tepples	NTSC color and NTSC/PAL pixel aspect ratio test ROM	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 (with various NES 2.0 headers for PRG ROM sizes)	thread
BNTest	tepples	Tests how many PRG banks are reachable in BxROM and AxROM.	thread
bxrom_512k_test	rainwarrior	Similar to the BxROM test in BNTest above.	thread
exram	Quietust	MMC5 exram test
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
Holy Diver Batman	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.	thread
mmc3bigchrram	tepples	MMC3 test for large 32kb CHR RAM with NES 2.0 headers	thread
mmc3_test	blargg	MMC3 scanline counter and IRQ generation tests.
serom	lidnariq	Tests the constraints of SEROM / SHROM / SH1ROM variations of the MMC1 boards.	thread
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
vrc6test	natt	VRC6 mirroring tests	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	thread GitHub
dma_sync_test_v2	Rahsennor	Tests DMC DMA read corruption	thread
mousetest		Test for a Super Famicom mouse wired in a Famicom expansion port as controller 3
PaddleTest3	3gengames	Test for the Arkanoid controller	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

Misc Tests

Name	Author	Description	Resources
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	thread

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.