Skip to main content
NESdev Wiki
Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Back to homepage

Emulator tests

There are many ROMs available that test an emulator for inaccuracies.

Validation ROMs

Some of the download links below are currently dead, but many have been archived at https://github.com/christopherpow/nes-test-roms.

CPU Tests

NameAuthorDescriptionResources
branch_timing_testsblarggThese ROMs test timing of the branch instruction, including edge cases
cpu_dummy_readsblarggTests the CPU’s dummy readsthread
cpu_dummy_writesbisqwitTests the CPU’s dummy writesthread
cpu_exec_spacebisqwitVerifies that the CPU can execute code from any possible memory location, even if that is mapped as I/O spacethread
cpu_flag_concurrencybisqwitUnsure what results are meant to be, see thread for more info.thread
cpu_interrupts_v2blarggTests the behavior and timing of CPU in the presence of interrupts, both IRQ and NMI; see CPU interrupts.thread
cpu_resetblarggTests CPU registers just after power and changes during reset, and that RAM isn’t changed during reset.
cpu_timing_test6blarggThis 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
coredumpjroatchCoredump tool for displaying contents of RAMthread
instr_miscblarggTests some miscellaneous aspects of instructions, including behavior when 16-bit address wraps around, and dummy reads.
instr_test_v5blarggTests 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_timingblarggTests timing of all instructions, including unofficial ones, page-crossing, etc.
nestest (doc)kevtrisfairly 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_retainrainwarriorRAM contents test, for displaying contents of RAM at power-on or after resetthread

PPU Tests

NameAuthorDescriptionResources
color_testrainwarriorSimple display of any chosen color full-screenthread
blargg_ppu_tests_2005.09.15bblarggMiscellaneous PPU tests (palette ram, sprite ram, etc.)thread
full_nes_paletteblarggDisplays the full palette with all emphasis states, demonstrates direct PPU color controlthread
nmi_syncblarggVerifies NMI timing by creating a specific pattern on the screen (NTSC & PAL versions)thread
ntsc_torturerainwarriorNTSC Torture Test displays visual patterns to demonstrate NTSC signal artifactsthread
oam_readblarggTests OAM reading ($2004), being sure it reads the byte from OAM at the current address in $2003.thread
oam_stressblarggThoroughly tests OAM address ($2003) and read/write ($2004)thread
oamtest3lidnariqUtility to upload OAM data via $2003/$2004 - can be used to test for the OAMADDR bug behaviorthread 1 thread 2
paletterainwarriorPalette display requiring only scanline-based palette changes, intended to demonstrate the full palette even on less advanced emulatorsthread
ppu_open_busblarggTests behavior when reading from open-bus PPU bits/registers
ppu_read_bufferbisqwitMammoth test pack tests many aspects of the NES system, mostly centering around the PPU $2007 read bufferthread
ppu_sprite_hitblarggTests sprite 0 hit behavior and timingthread
sprite_overflow_testsblarggTests sprite overflow behavior and timingthread
ppu_vbl_nmiblarggTests 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
scanlineQuietustDisplays a test screen that will contain glitches if certain portions of the emulation are not perfect.
sprdma_and_dmc_dmablarggTests the cycle stealing behavior of the DMC DMA while running Sprite DMAsthread
sprite_hit_tests_2005.10.05blarggGenerally the same as ppu_sprite_hit (older revision of the tests - ppu_sprite_hit is most likely better)thread
sprite_overflow_testsblarggGenerally the same as ppu_sprite_overflow (older revision of the tests - ppu_sprite_overflow is most likely better)thread
tvpassfailtepplesNTSC color and NTSC/PAL pixel aspect ratio test ROM (older revision of the tests - 240p Test Suite is most likely better)thread
vbl_nmi_timingblarggGenerally the same as ppu_vbl_nmi (older revision of the tests - ppu_vbl_nmi is most likely better)thread

APU Tests

NameAuthorDescriptionResources
apu_mixerblarggVerifies 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_resetRahsennorTests the correct square channel behavior when writing to $4003/4007 (reset the duty cycle sequencers but not the clock dividers)thread
apu_resetblarggTests initial APU state at power, and the effect of reset.
apu_testblarggTests many aspects of the APU that are visible to the CPU. Really obscure things are not tested here.
blargg_apu_2005.07.30blarggTests APU length counters, frame counter, IRQ, etc.
dmc_dma_during_read4blarggTests register read/write behavior while DMA is running
dmc_tests??
dpcmletterboxtepplesTests accuracy of the DMC channel’s IRQ
pal_apu_testsblarggPAL version of the blargg_apu_2005.07.30 tests
square_timer_div2blarggTests the square timer’s period
test_apu_2 (1-10) (11)x000011 tests that verify a number of behaviors with the APU (including the frame counter)thread
test_apu_envblarggTests the APU envelope for correctness.
test_apu_sweepblarggTests the sweep unit’s add, subtract, overflow cutoff, and minimum period behaviors.
test_apu_timersblarggTests frequency timer of all 5 channels
test_tri_lin_ctrblarggTests triangle’s linear counter and clocking by the frame counter
volume_teststepplesPlays 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

NameAuthorDescriptionResources
31_testrainwarriorTests for mapper 31 (see thread for ROMs in various PRG sizes)thread
BNTesttepplesTests how many PRG banks are reachable in BxROM and AxROM.thread GitHub
bxrom_512k_testrainwarriorSimilar to the BxROM test in BNTest above.thread
FdsIrqTests (v7)SourTests various elements of the FDS' IRQthread
FDS-Mirroring-TestTakuikaNinjaTests the FDS' nametable arrangement/mirroring switching functionality ($4025.D3 write, $4030.D3 read, $4023.D0=0 write)thread GitHub
FDS-4023-TestTakuikaNinjaDisplays the state of FDS registers when toggling $4023 bitsthread GitHub
FDS-Audio-RegistersTakuikaNinjaDisplays the state of FDS audio registers when toggling $4023.D1thread GitHub
FDS-4030D1-AddrTakuikaNinjaVisualises IRQs generated by the FDS' DRAM refresh watchdog, reported in $4030.D1thread GitHub
exramQuietustMMC5 exram test
famicom_audio_swap_testsrainwarriorHotswap tests for Famicom expansion audio (5B, MMC5, VRC6, VRC7, N163, FDS)thread
fme7acktest-r1tepplesChecks some IRQ acknowledgment behiaviors of Sunsoft FME-7 that emulators were getting wrong in 2015.thread
fme7ramtest-r1tepplesChecks how much work RAM the Sunsoft FME-7 can accessthread GitHub
Holy MappereltepplesDetects 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
mmc3bigchrramtepplesMMC3 test for large 32kb CHR RAM with NES 2.0 headersthread GitHub
mmc3_test_2blarggMMC3 scanline counter and IRQ generation tests.
mmc3irqtestN-KMMC3 scanline IRQ test and $C000 glitch investigation.thread
mmc5testDragMMC5 scanline counterthread
mmc5test_v2AWJMMC5 teststhread
seromlidnariqTests the constraints of SEROM / SHROM / SH1ROM variations of the MMC1 boards.thread
NES 2.0 Submapper Testsrainwarrior2_test - Mapper 2, Submappers 0, 1 and 2thread
rainwarrior3_test - Mapper 3, Submappers 0, 1 and 2thread
rainwarrior7_test - Mapper 7, Submappers 0, 1 and 2thread
rainwarrior34_test - Mapper 34, Submappers 1 and 2thread
test28tepplesTests for mapper 28thread GitHub
vrc24testAWJDetects and tests all VRC 2/4 variantsthread
vrc6testnattVRC6 mirroring teststhread
mmc5ramsizerainwarriorMMC5 large PRG-RAM support teststhread
mmc1atesttepplesCharacterizes behavior of MMC1A vs. MMC1Bthread GitHub
n163_soundramrainwarriorTest for Namco 163 audio sound RAM read-back.thread
n163_soundram_initrainwarriorTest for Namco 163 audio sound RAM contents at power-on.thread

Input Tests

NameAuthorDescriptionResources
allpadstepplesMultiple 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 modethread GitHub
dma_sync_test_v2RahsennorTests DMC DMA read corruptionthread
PaddleTest33gengamesTest for the Arkanoid controllerthread
vauslidnariqArkanoid controller 9-bit result testthread
read_joy3blarggVarious NES controllers tests, including read corruption due to DMC DMAthread
Zap RudertepplesTest for the Zapper, including dual wield but not the serial Vs. variantthread GitHub
spadtest-nestepplesSuper Nintendo controller test (when connected to a NES)thread
vaus_testtepplesAnother test for the Arkanoid controllerthread GitHub
msetrainwarriorSNES mouse testthread
mictrainwarriorFamicom microphone testthread
Telling LYs?tepplesTests whether input can change on any scanlinethread GitHub
ctrltestrainwarriorGeneric log of 16-bit report on all 5 input data lines.thread
raw

pack2

lidnariqImmediate 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 testsrainwarriorSimple tests for displaying output of zapper reads.thread
powerpadgesturetepplesGesture test for Power Pad displaying log of presses and releases.thread
POWERPAD.NESTennessee Carmel-VeilleuxOld simple test for Power Pad.powerpad.txt
d34testrainwarriorGeneric log of 32-bit report on D3 and D4 data lines, with 16-bit report on D0.thread
kmbtestrainwarriorInput test for a proposed USB Keyboard and Mouse interface.thread
Hori TrackerTakuikaNinjaInput display for the Hori Track.forum post GitHub

Misc Tests

NameAuthorDescriptionResources
240pee-0.22tepples240p Test Suite (an NES version of the 240p Test Suite by Artemio Urbina), including an MDFourier tone generatorthread GitHub
characterize-vslidnariqVS System teststhread
NEStressFlubbaOld test - some of the tests are supposed to fail on real hardware.
oc-r1atepplesDetects and displays accurate clock rate of the NES (since incorporated into 240p Test Suite)thread
nes-audio-testsrainwarriorNSF 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.

See also

Edit this page on GitHub