Emulator tests

From Nesdev wiki
Jump to: navigation, search

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-v1.0 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  ? 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).
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_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
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
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
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
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
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
240pee-0.15 tepples 240p test suite (an NES version of the 240p test suite by Artemio Urbina) thread
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.