This whole post is contingent on that i've gotten a thing or two about the PPU right and that ocular observation in emulators is worth something, but..
The two most significant bits in stored palette data are never used. If you toggle them on/off, the colour is the same. I'm assuming the PPU is discarding those. You can use this bitspace to include some metadata on how to handle the colours themselves, or some hardware register. Either immediately when loading, or for later if stored in a buffer in RAM. On top of my head, it might make sense to use the sign flag bit (msb) for either:
-toggling of BGR bits
-enable/disable switches for palette buffer animation
you could also rotate/shift bits in/out to produce an alternate palette from the same, but it doesn't seem very practical.
So in my palette data, i might store something like this
There's no reason you can't store information about emphasis bit toggling or how to enable colour animation in some other scheme, but having it organized in the same place makes sense to me.
For the emphasis scheme especially, I think the 1st byte in the strip should reserved for enabling the other BGR bit readings, thus selecting if its particular BGR setting should be used or not. By manually writing an enable bit into any of the 8 subpalette strips stored in the buffer, you could hypothetically keep all 8 combinations in the buffer at once, even if it's highly unlikely (no bits set is the most useful setting, after all). You can also encode the first byte directly in data if you actually want it to always take mandate, which might be the case sometimes.
Alternately, you could maybe use it to let your engine make assumptions. "If this palette is used, we want to set vertical mirroring", or the like.
The two most significant bits in stored palette data are never used. If you toggle them on/off, the colour is the same. I'm assuming the PPU is discarding those. You can use this bitspace to include some metadata on how to handle the colours themselves, or some hardware register. Either immediately when loading, or for later if stored in a buffer in RAM. On top of my head, it might make sense to use the sign flag bit (msb) for either:
-toggling of BGR bits
-enable/disable switches for palette buffer animation
you could also rotate/shift bits in/out to produce an alternate palette from the same, but it doesn't seem very practical.
So in my palette data, i might store something like this
Code:
SIGN = %10000000
(...)
MyPalette:
.db $00, $01, $11, $21 | SIGN
(...)
MyPalette:
.db $00, $01, $11, $21 | SIGN
There's no reason you can't store information about emphasis bit toggling or how to enable colour animation in some other scheme, but having it organized in the same place makes sense to me.
For the emphasis scheme especially, I think the 1st byte in the strip should reserved for enabling the other BGR bit readings, thus selecting if its particular BGR setting should be used or not. By manually writing an enable bit into any of the 8 subpalette strips stored in the buffer, you could hypothetically keep all 8 combinations in the buffer at once, even if it's highly unlikely (no bits set is the most useful setting, after all). You can also encode the first byte directly in data if you actually want it to always take mandate, which might be the case sometimes.
Alternately, you could maybe use it to let your engine make assumptions. "If this palette is used, we want to set vertical mirroring", or the like.