Quirks by difficulty

I, PinoBatch, am planning a broad-spectrum test ROM for Game Boy disguised as a simple platform game. I intend for it to cover 100 different CPU, PPU, APU, and RAM issues.

Criteria

I'd like to rank each tested behavior by a combination of several factors:

Impact

Things affecting more popular games would rank earlier than things affecting only some obscure Japanese release. Things causing games to fail to boot would rank earlier than (say) noticeable scoring or RNG differences, in turn earlier than things causing only visual glitches. Things not used by any licensed game or notable homebrew game, such as the GBC PCM registers, might rank after the top 100.

Ease of fixing

Expected programmer time and impact on emulation speed from fixing an inaccuracy. For example, things requiring mid-scanline cycle accuracy would be later on the list, as they're less practical to achieve in emulators for MCUs or retro PCs or consoles. Things only BGB and SameBoy get right can rank near the end.

The target audience is maintainers and users of stable emulators, as an example of a game that doesn't work. Some behaviors have so much impact that they're hard to test in anything resembling a game. Thus we can treat any behavior needed to progress through the boot ROM, menu, and early in-game scenes of the most popular games (such as Tetris, Super Mario Land and some version of Pokémon) as a prerequisite. Thus we're looking for things that widely used emulators get wrong, not things that block typical users from even considering using an emulator. There are other, more for early emulator development.

The minimum and maximum achievable scores should be the same on GBC and DMG. Thus for each GBC-only test, there should be a corresponding test of a DMG-only behavior. If one platform variant has significantly more test-worthy quirks, particularly GBC DMA, it's safe to repeat a test that the other platform variant doesn't support the feature in the first place.

The CPU shows whether each test passed or failed by either collecting a coin or stopping its spinning. For this reason, the CPU needs to be able to judge whether each test passed or failed, making some behaviors untestable. This includes video output (such as palettes and pixel response time), audio output (such as noise LFSR lockup, as DMG lacks PCM registers), and some of the PPU-LCD desyncs caused by mid-scanline window manipulation. In addition, I'd prefer tests that complete within one or two frames (about 35,000 M-cycles), not minutes-long exhaustive tests like those in ZEXALL. Slightly longer tests can be justified as "digging" for coins by crouching on an actuator, standing back up, and waiting for the coin to spawn.

I'd like to pick 10 of the easiest and most impactful things that NO$GMB gets wrong and which can be tested on a monochrome (DMG) system. This would keep the player from proceeding past the initial section of the map, which requires at least 5 out of 10 coins to complete.

Ranked

To be written

Unranked

Some of these tests are specified in broad strokes. I encourage emulator developers to explain specific problems they ran into implementing these instructions in order to narrow down what to watch out for.

• Writes to VRAM are processed in modes 0, 1, and 2, and ignored in mode 3.
• Writes to OAM are processed in modes 0 and 1, and something else happens in modes 2 and 3.
• OAM DMA is processed even during mode 3.
• OAM DMA blocks ROM access (Does it on GBC?)
• Writing STAT acts as if $FF were written for one cycle, if and only if running on DMG.
• 114 M-cycles per scanline
• Each sprite extends mode 3 by about 8 cycles. (Lenient)
• More strict mode 3 duration timing based on sprite X in relation to SCX.
• $D000 WRAM banking follows pattern 1, 1, 2, 3, 4, 5, 6, 7, ... (GBC) or 1, ... (DMG).
• daa with select 0-9 inputs, including half carry
• daa with select A-F inputs
• daa with additional A-F inputs
• Timing of serial interrupt with 8.2 kHz internal clock
• N and H flags after various operations
• Audio length counters (May require digging)
• LCD off/on behavior
• DIV write any value should reset
• DIV reset should reset the div increase from that exact cycle
• DIV reset at right time should still increase TIMA
• DIV reset influences APU timing
• TIMA reload and interrupt is delayed by 1 cycle
• Higher bits of IE/IF should be fixed value
• Timing of STOP instruction in GBC when switching to double speed
• Timing of STOP instruction in GBC when switching to single speed
• HDMA targeted to anything that is not VRAM
• HDMA overflow stop
• HDMA start during HBlank
• SB read back seeing shift happening
• Undocumented GBC registers
• Mode1 of MBC1
• Stat irq enable for current mode