Difference between revisions of "Quirks by difficulty"

Revision as of 20:09, 17 November 2020

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 has significantly more test-worthy quirks, particularly GBC DMA, it's safe to repeat the test that.

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.

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. We're not aiming for a time-consuming exhaustive test like ZEXALL.

• 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