Console Accuracy Adventures in Wario Land II

Console Accuracy Adventures in Wario Land II with TiKevin83

Wario Land II was a popular release for the original Game Boy, enough so that it was re-released in color similar to Link's Awakening's DX release.  This concerns the original GB release.

Recently, TASVideos community member jlun2 became interested in improving and resyncing the Wario Land II tool assisted speedruns so that they could be played on the Game Boy Player with use of Extrems' Game Boy Interface.

This console playback requires very precise cycle accuracy for much of the Game Boy library, as the original Game Boy can turn off the LCD and effectively make "frames" no longer a thing and leaving only lengths of cycles while the LCD is disabled.

Such a level of accuracy is available in BizHawk's Gambatte or GBHawk emulators in the GBA as GBC mode, and may require flashing the cartridge's save RAM to match the emulated default being filled with 0xFF.  About 15 games have been tested good with this method, and several have published TASes.

There is one known scenario where non-deterministic behavior can occur outside the initial save RAM state.  The game Donkey Kong '94 seeds its RNG from uninitialized RAM.  Any game that seeds RNG this way would be unable to console verify unless a TAS could line up behavior across all possible RNG states, of which there are 16 in Donkey Kong '94.  Wario Land II does not do this, so initial thoughts were promising.

The first few stages did match between console and emulator as expected, but unfortunately in stage 2-3 the console Wario hit a coin where the TAS expected to be jumping through empty space while setting up an out of bounds warp to the end of the level.

Alyosha, an emulator dev in the TASVideos scene, was able to identify that the inaccuracy was not related to the out of bounds, but rather a quirk in the timing of a precise VRAM read that happens on the frame of the desync.

Typically the GB CPU is unable to read VRAM during each scanline and then has a brief period to do so before the next scanline begins.  If it requests a read too early, the PPU is supposed to return 0xFF instead of the value stored in the VRAM.

What the Wario Land II TAS uncovered was that if you happened to ask for VRAM at the exact moment that access is handed back to the CPU, you can get something other than 0xFF or the intended value in VRAM.

A test ROM of this scenario made by mattcurrie was able to establish that on the original GB you'd get a stale bus value, whatever the PPU happened to access last.  On GBC and GBP systems, you instead get 0x00 the first time you encounter this scenario and the correct VRAM read each time after.

An implementation of this has matched the GBC and GBP behavior observed in mattcurrie's testROM, and the same fix causes the emulator to desync for Wario Land II in the exact way observed in the console verification.

In implementing the fix, I also alerted the Gambatte Speedrun devs including Entrpntr, who validated the fix against Gambatte's existing testROM suite.  This uncovered another slight quirk.  If the GBC CPU is switched into double speed mode when it does this exact end of line read, the switch can cause something called "odd mode" where the reads are operating one double-speed cycle later than usual.  This offsets the read enough to avoid the corner case that Wario Land II hits.  By accounting for the timing introduced by double speed mode, the Gambatte Speedrun test suite was passed in addition to fixing the behavior seen in Wario Land II and in the new test ROM from mattcurrie.

You can check out the code change necessary to account for the testROMs and the observed console behavior here
https://github.com/TASVideos/BizHawk/pull/2034/files