nesdev.org

There really isn't anything more to it than that.

While the MMC5 is in "extended attribute mode", which one turned on by writing 1 to $5104, all reads from all nametables will have the MMC5's internal RAM used to specify the extra bits for each tile. Regardless of how $5105 says to lay out memory.

It should even work with silly options like the fill-mode nametable; in that case the bottom 8 bits would all be the same (and specified by $5106) but the contents of the extended attribute table will still (top-most two bits) specify palette and (bottom-most six bits) specify 256-tile pages within CHR.

@lidnariq

Thank you for the extra information, it is always appreciated.

I guess I'm always a little slow to get it since I usually cannot visualize in my head properly after reading things that seems complicated at first. Now I'm starting to have an idea how it works with that extra post. The best way will be to get my hands dirty and try it and it will all make sense. For some reason, unless very obvious, if I don't try it, I have a harder time to understand it. It's like I need to touch it and see the results and it becomes clearer.

I should check for some code example then, if any, or just try something simple soon. Unless mistaken, I think no tool similar to nesst support for such data format yet.

Thanks again!

lidnariq wrote:It should even work with silly options like the fill-mode nametable; in that case the bottom 8 bits would all be the same (and specified by $5106) but the contents of the extended attribute table will still (top-most two bits) specify palette and (bottom-most six bits) specify 256-tile pages within CHR.

It's not that silly... In this regards, the ExRAM works as a regular nametable selecting form 64 tiles and with fine-grained colour, and $5106 selects which of 256 "banks" of tiles it picks from. Ok there's not much point in using it that way, but it'd work fine I guess.