Topple Zip accidentally relies on unreadable OAMDATA

[TakuikaNinja]

So it turns out that Topple Zip on the FDS had something more horrifying than "it suffers from PC developer syndrome".

When loading a level for the first time after power-on/reset, an unfortunate codepath (which I haven't analysed in depth yet) results in a sprite object pointer index being fetched from a mirror of OAMDATA during rendering ($D149 = [$2524]):

image_0.png

This causes further fetches for the sprite object to depend on the readability of OAMDATA. If OAMDATA is not readable, then the fetches resolve to a seemingly valid pointer (thanks to PPU open bus returning $92 instead of $FF in the above routine) and none of the sprites look terribly wrong. If OAMDATA is readable, however, then further fetches end up using more reads from PPU register mirrors during rendering ({$0010} = $2CA6):

image_1.png

The garbage sprites created by this bug seem to depend on the stage loaded from the save file, and are likely also subject to OAM decay behaviour. Here's a hardware capture I found where one such garbage sprite lingers on screen for the first level: https://youtu.be/etznl-SjdTc&t=27

Screenshot comparisons from Mesen2 will be posted here soon. Comparisons on original hardware with pre-G v.s. later PPU revisions is greatly appreciated.

[Pokun]

Interesting to find a licensed Japanese game that has trouble with these PPUs. As an owner of such a Famicom myself I should really test this some time.

[TakuikaNinja]

Right, the screenshots. These were captured in Mesen2 on the same frame, 3 NMIs after the first execution of $9BEC (where the OAMDATA read occurs) when starting a new game.

With unreadable OAMDATA:

Topple Zip (Japan)_001.png

With readable OAMDATA:

Topple Zip (Japan)_000.png