Hi all! First time poster here. Hoping y'all can provide some insight.
There's an issue in my project (Mapper 30) where the top row of pixels of each sprite is the wrong color. In case it's relevant, I'm doing a screen split with a mid-frame palette swap, but the issue occurs even with the screen split / palette swap disabled. The issue appears in multiple emulators (Mesen, FCEUX, OpenEmu) so is not emulator-specific. Also, the issue only affects sprite tiles. Background tiles display normally, and both types of tiles are copied to CHR-RAM in the same fashion.
When copying each sprite tile to CHR-RAM, the first write to PPUDATA auto-increments the VRAM address as expected, but it seems that no data is actually written. (The remaining 15 bytes of each tile are written without issue.) This is speculation on my part since the first byte of each tile represents bit 0 of the color index for the top row of pixels, so if this byte isn't written to CHR-RAM, it would be consistent with the observed behavior.
As a test, I attempted to fill the pattern tables completely with $ff values, which should assign color 3 to every pixel in every tile; however, the CHR viewer in Mesen shows that the top row of each sprite tile has color 2, i.e. bit 0 is not set. It would seem this could only happen if some of those writes to PPUDATA failed to update VRAM.
Is there some known combination of timing, register settings, etc. that would cause such a failure to occur?
There's an issue in my project (Mapper 30) where the top row of pixels of each sprite is the wrong color. In case it's relevant, I'm doing a screen split with a mid-frame palette swap, but the issue occurs even with the screen split / palette swap disabled. The issue appears in multiple emulators (Mesen, FCEUX, OpenEmu) so is not emulator-specific. Also, the issue only affects sprite tiles. Background tiles display normally, and both types of tiles are copied to CHR-RAM in the same fashion.
When copying each sprite tile to CHR-RAM, the first write to PPUDATA auto-increments the VRAM address as expected, but it seems that no data is actually written. (The remaining 15 bytes of each tile are written without issue.) This is speculation on my part since the first byte of each tile represents bit 0 of the color index for the top row of pixels, so if this byte isn't written to CHR-RAM, it would be consistent with the observed behavior.
As a test, I attempted to fill the pattern tables completely with $ff values, which should assign color 3 to every pixel in every tile; however, the CHR viewer in Mesen shows that the top row of each sprite tile has color 2, i.e. bit 0 is not set. It would seem this could only happen if some of those writes to PPUDATA failed to update VRAM.
Is there some known combination of timing, register settings, etc. that would cause such a failure to occur?
Statistics: Posted by Zimsky — Sat Jun 15, 2024 10:21 pm — Replies 2 — Views 211