Emulator tests: Difference between revisions

From NESdev Wiki
Jump to navigationJump to search
(To get all the test ROMs working, you're going to need movie support anyway. Describe movie support first, and that'll simplify the rest of the description.)
(Remove hard-to-emulate games section as it has been moved to its own page)
Line 31: Line 31:
* [http://blargg.8bitalley.com/parodius/nes-tests/mmc3_test_2.zip mmc3_test] tests the [[MMC3]] scanline counter and IRQ generation, not much else currently
* [http://blargg.8bitalley.com/parodius/nes-tests/mmc3_test_2.zip mmc3_test] tests the [[MMC3]] scanline counter and IRQ generation, not much else currently
* [http://pics.pineight.com/nes/bntest.zip BNTest] tests how many PRG banks are reachable in [[BxROM]] and [[AxROM]]
* [http://pics.pineight.com/nes/bntest.zip BNTest] tests how many PRG banks are reachable in [[BxROM]] and [[AxROM]]
== Hard-to-emulate games ==
* ''Adventures of Lolo 2'', ''Ms. Pac-Man'' (Tengen), and ''Spelunker'' rely on 1 cycle NMI delay when $2002 bit 7 gets set inside vblank (if $2002 has not been read yet), in which $2002 bit 7 can be read as true
* ''Balloon Fight'' relies on reading the nametables through $2007 to twinkle the stars in the background. (The code is at $D603.)
* ''Bases Loaded II'' glitches after a pitch is thrown ([[:File:Bases Loaded 2 without re-NMI.jpg|screenshot]]) if writing $00 then $80 to $2000 during vertical blank does not cause an additional [[NMI]]
* ''Battletoads'' requires fairly precise CPU and PPU timing and a fairly robust sprite zero implementation. It leaves rendering disabled for a number of scanlines into the visible frame to gain extra VRAM manipulation time and then enables it. If the timing is off so that the background image appears too high or too low at this point, a sprite zero hit will fail to trigger, hanging the game. This usually occurs immediately upon entering the first stage if the timing is off by enough, and might cause random hangs at other points otherwise.
* ''Bee 52'' needs accurate DMC timing and relies on $2002 bit 5 as well
* ''Bill & Ted's Excellent Adventure'' depends on obscure [[MMC1]] behavior where writes on successive cycles are ignored; see [[iNES Mapper 001]] (the talk page for that page might be informative too). This game also turns off and re-enables rendering midframe to switch CHR banks (e.g. in the black border above dialog boxes).
* ''Cobra Triangle'', ''Iron Sword'' relies on the dummy read for the sta $4000,X instruction to acknowledge pending APU IRQs.
* ''Crystalis'', ''Fantastic Adventures of Dizzy'', ''Fire Hawk'', and ''Super Off Road'' do mid-frame palette changes
* ''Fire Hawk'', ''Mig 29 Soviet Fighter'', and ''Time Lord'' need accurate DMC timing because they [[APU DMC#Usage of DMC for syncing to video|abuse APU DMC IRQ]] to split the screen
* ''Galaxian'' requires proper handling of bit 4 of the [[CPU status flag behavior|P register]] for /IRQ.
* ''Huge Insect'' depends on obscure OAMADDR ($2003) behavior; see [[PPU_registers]].
* ''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
* ''Paperboy'' relies on the open bus behavior of controller reads and expects them to return exactly 0x40 or 0x41; see [[Standard controller]].
* ''Punch-Out!!'' requires fetching the 34th tile; otherwise, the ring will be glitched.
* ''Puzznic'' uses [[Programming with unofficial opcodes#Watermarking instructions|unofficial]] opcode $89, which is a two-byte NOP on 6502 and BIT #imm on 65C02. ([http://tasvideos.org/forum/viewtopic.php?p=306520#306520 tasvideos discussion])
* ''Slalom'' does a JSR while the stack pointer is 0, so that half of the return address ends up at $0100 and the other half at $01FF.
* ''Super Mario Bros.'' is probably the hardest game to emulate among the most popular [[NROM]] games, which are generally the first targets against which an emulator author tests his or her work. It relies on JMP indirect, correct palette mirroring (otherwise the sky will be black; see [[PPU_palettes]]), sprite 0 detection (otherwise the game will freeze on the title screen), the 1-byte delay when reading from CHR ROM through $2007 (see [[PPU_registers#The_PPUDATA_read_buffer_.28post-fetch.29|The PPUDATA read buffer]]), and proper behavior of the nametable selection bits of $2000 and $2006.[http://nesdev.org/bbs/viewtopic.php?p=22022#22022] 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.
* ''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 [[mapper]]s 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.


== Automated testing ==
== Automated testing ==

Revision as of 13:55, 2 April 2013

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

Validation ROMs

There is a substantial archive of test roms available at https://github.com/christopherpow/nes-test-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. 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, whose CPU works (apart from some details of the power-up state).
  • 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). 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_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_v2 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

APU

  • apu_test tests many aspects of the APU that are visible to the CPU. Really obscure things are not tested here.
  • apu_mixer 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.
  • apu_reset tests initial APU state at power, and the effect of reset.
  • volume_tests 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

  • mmc3_test tests the MMC3 scanline counter and IRQ generation, not much else currently
  • BNTest tests how many PRG banks are reachable in BxROM and AxROM

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.

Retrieved from "https://www.nesdev.org/w/index.php?title=Emulator_tests&oldid=2082"