This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

New PPU quirk while swapping palettes mid-frame?

New PPU quirk while swapping palettes mid-frame?
by on (#240056)
So I noticed something pretty odd with my palette swapping routine on real hardware. Sometimes, when I swap palettes mid-frame, the background colour is wrong.

https://cdn.discordapp.com/attachments/ ... 000309.jpg
https://cdn.discordapp.com/attachments/ ... 001405.jpg

Here's how it should look like
https://cdn.discordapp.com/attachments/ ... 001531.jpg
https://cdn.discordapp.com/attachments/ ... 001541.jpg

Turns out it goes away if I write to $2006 before reenabling the background. (Doing 7>1>6>6 does the glitch, but 7>6>6>1 doesn't).
Also, it only happens sometimes. Sometimes it swaps the palettes as it should. By the way this was tested on a real board and on an INL board (MMC3). Is this a new quirk?
Re: New PPU quirk while swapping palettes mid-frame?
by on (#240057)
Is it just color index zero that is the wrong color?

If so. It could maybe be fixed by having the last write be the correct color to one of the mirrors of 3f00
Re: New PPU quirk while swapping palettes mid-frame?
by on (#240068)
Mid-frame palette changes are full of "gotchas", so I wouldn't hurry into calling any odd behavior a new quirk. First we'd have to take a look at the actual code doing the palette changes, how it's timed, and try to understand why it works some of the time.
Re: New PPU quirk while swapping palettes mid-frame?
by on (#240069)
Other things I'd try testing:

Does it glitch if you try 7>6>1>6? 7>waste four cycles>1>6>6 ?

I can't think of a way that the known existing glitches would cause a palette write to have failed, but I could be forgetting something.