Palette color > $3f

I noticed that Mike Tyson's Punch-Out writes a value of $8f into the background palette ($3f00). I assume this value should be masked by $3f and thus displayed as color $0f.

But now I'm wondering, if the value is read back through $2007, do you get $8f or $0f?

You get $0f.
The high 2 bits aren't even stored anywhere.

Also palette read-back in general is somewhat un-reliable.

All right, thanks much.

I thought palette readback was fine (due to use of SRAM) and OAM readback was unreliable (due to a half-@$$ed DRAM controller). Is there a test ROM?

Anyway, assuming that palette readback is reliable: Because palette reads come from inside the PPU, they aren't subject to the 1-byte delay for video memory readback. Bits 5-0 of the read palette value come from CGRAM (the palette memory inside the PPU), and I seem to remember that bits 7 and 6 of the read palette value come from open bus, which is the last value on the data bus (which in this case is $20, the high byte of the address).

From my experience making the PowerPak save state mappers, palette readback doesn't seem to work on all PPU revisions. It does work on PAL PPU.

Here's a relevant post: viewtopic.php?p=64340#p64340

BTW, the post refers to Famicom Titler, which uses the RGB PPU, but I'm pretty sure I've had problems with palette readback on some NTSC composite PPUs also.

Interesting. Palette read is tested in Blargg's palette_ram.nes, so I had assumed it was reliable.

"Open bus" for the PPU is different from the CPU - as I recall, what you actually get for bits 6 and 7 is the last value asserted on the PPU I/O data pins, just like when you read any write-only register.