nesdev.org

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?

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

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.

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.