questions on the unreroutable PPU range $3F00-3FFF

The value of this inquiry might be little, but...

How come they decided to let the largely unusable PPU range $3000-3EFF be reroutable, but not the potentially useful range of $3F00-3FFF (palette registers)? It seems they deliberately prohibited precisely that, for some reason.

Palette memory is a separate 28x6-bit SRAM on the PPU die, as opposed to the rest of video memory which is outside the PPU. It needs to be far faster than the rest of video memory because it's read every dot, unlike the rest of video memory that's read only every second dot. And it needs to be separate anyway because it's read at the same time as the rest of video memory.

Thanks for the concise explanation! All right, that makes a lot of sense. Keeping it on the die might additionally have saved some cost (less pins, no separate chip).

As far as I know, external memory at $3F00-$3FFF can be read, but not written.

And, sometimes the PPU address space at $3000-$3EFF is used. Such as if a mapper maps battery-backed CHR RAM to the entire PPU address space, then you can store stuff there. A hypothetical mapper I made up out of a AY-3-8910 (with no glue logic) uses that part of the address space to control expansion audio and bankswitching (although reading from or writing to that part of the address space still accesses the CIRAM mirrors).

So, the cpu might be able to read memory range as if it were ROM via the ppu, provided it is nonvolatile and some data is written to it at burn time?

Or do you actually mean the ppu could theoretically read it aswell (provided it meets the mentioned requirements)?

I'd be hard pressed to come up with a pragmatic use of the former that can't be solved some easier way, but the latter (if possible) could yield some spectacular results if combined with remapping control, and even more so with a timer/irq. Provided it would work at all, it'd work like chr-rom banking, except the palette entries are so small you could have ~50 banks per 1k which would substitute the lack of ability to write new palette entries. The benefit would be mid-screen palette swaps without pain (resulting in more colourful screens), and palette swaps in general without messing with the PPU registers. It'd also be faster than writing a series of palette entries.

The memory region at $3F00-$3FFF still enqueues a read as normal. It's just that while the address pointer is $3Fxx reads don't return the read buffer but instead palette memory.

So writing a palette range address to $2006, reading from $2007, writing a different non-palette address to $2006, and then reading from $2007 will let you get the value underlying palette memory. In practice, that's just basically not useful.

Alright, so all in all it's possible for the CPU to read the current data kept in that range of an ExRAM, if one would ever want to - but for rendering purposes it's impossible for the PPU to "see" any other palette data than that kept on the internal on-die palette SRAM, besides the very hypothetical outlook of modifying this hardwiring in a FPGA clone to some separate SRAM entity... kind of what the AVS does with the scanline memory to double the amount of sprites per scanline.

If these assumptions are correct, My confusion with what zzo38 wrote stems from me interpreting it as the PPU theoretically fetching that range if it could be physically allocated to a separate hi-speed memory.