Emulator tests: Difference between revisions
From NESdev Wiki
Jump to navigationJump to search
(→Troubleshooting games: when we help solve, I might put a symptom and the solution here) |
m (moved Emulator Tests to Emulator tests: lowercase is easier to link) |
(No difference)
|
Revision as of 01:45, 8 June 2010
There are many ROMs available that test an emulator for inaccuracies.
Validation ROMs
Multiple
- NEStress partially tests PPU, CPU, and controller operation (old; some tests seem to always fail)
- Blargg's test ROMs partially test APU, misc PPU behavior, sprite 0 hit, and MMC3 operation. Refer to PPU Frame Timing for new information that the PPU ROMs test.
CPU
- nestest fairly thoroughly tests CPU operation (see readme for more)
- instr_test 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).
- instr_misc tests some miscellaneous aspects of instructions, including behavior when 16-bit address wraps around, and dummy reads.
- instr_timing tests timing of all instructions, including unofficial ones, page-crossing, etc.
- cpu_interrupts tests the behavior and timing of CPU in the presence of interrupts, both IRQ and NMI.
- cpu_reset tests CPU registers just after power and changes during reset, and that RAM isn't changed during reset.
PPU
- Sprite 0 Hit test ROMs
- Misc PPU Tests
- PPU VBL/NMI Timing test ROMs
- PPU sprite overflow flag timing tests ($2002 bit 5), covering general operation, timing, and obscure pathological behavior (discussion).
- tvpassfail: NTSC color and NTSC/PAL pixel aspect ratio test ROM
Mapper
- mmc3_test tests the scanline counter and IRQ generation, not much else currently
Hard-to-emulate games
- Balloon Fight relies on reading the nametables through $2007 to twinkle the stars in the background. (The code is at $D603.)
- Among the most popular NROM games, which are generally the first targets against which an emulator author tests his or her work, Super Mario Bros. is probably the hardest to emulate. It relies on JMP indirect, correct palette mirroring, sprite 0 detection, the 1-byte delay when reading from CHR ROM through $2007, and proper behavior of the nametable selection bits of $2000 and $2006.[1] In addition, there are several bad dumps floating around, some of which were ripped from pirate multicarts whose cheat menus leave several key parameters in RAM.
- Adventures of Lolo 2, Spelunker rely on 1 cycle NMI delay when $2002 bit 7 gets set inside vblank (if $2002 has not been read yet)
- Battletoads needs precise CPU and PPU timing
- Bee 52 needs accurate DMC timing and relies on $2002 bit 5 as well
- Cobra Triangle, Iron Sword relies on the dummy read for the sta $4000,X instruction to acknowledge pending APU IRQs.
- Fire Hawk needs accurate DMC timing and does mid-frame palette changes
- Micro Machines requires correct values when reading PPU $2004 during rendering, and also relies on proper background color selection when rendering is disabled and the VRAM address points to the palette
- Ms. Pac-Man (Tengen) relies on being able to read $2002 bit 7 as true before NMI occurs
- Super Mario Bros. 3 relies on an interaction between the sprite priority bit and the OAM index to put power-ups behind blocks
Game Bugs lists games that have glitches on NES hardware, so you won't go "fixing" them while breaking your emulator.
Troubleshooting games
If a scroll split doesn't work, and a garbage sprite shows up around the intended split point, then the game is probably trying to use a sprite 0 hit, but either the wrong tile data is loaded or the background is scrolled to a position that doesn't overlap correctly. This could be a problem with nametable mirroring, with CHR bankswitching in mappers that support it, or with the CPU and PPU timing of whatever happened above the split. Battletoads, for one, uses 1-screen mirroring and requires exact timing to get the background scroll position dead-on.