mmc3 vs mmc5

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems.

Moderator: Moderators

lidnariq
Posts: 8785
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: mmc3 vs mmc5

Post by lidnariq » Tue Dec 11, 2018 8:58 pm

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.

User avatar
Banshaku
Posts: 2328
Joined: Tue Jun 24, 2008 8:38 pm
Location: Fukuoka, Japan
Contact:

Re: mmc3 vs mmc5

Post by Banshaku » Tue Dec 11, 2018 9:26 pm

@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!

User avatar
Bregalad
Posts: 7767
Joined: Fri Nov 12, 2004 2:49 pm
Location: Chexbres, VD, Switzerland

Re: mmc3 vs mmc5

Post by Bregalad » Wed Dec 12, 2018 12:31 am

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.

Post Reply