Drag wrote:How is that a pain in the ass?
Switching back and forth between mirroring modes while using the same scrolling engine would be a pain in the ass, that's what I meant. It would make more sense to just use 1 screen mirroring all the way. Or using whatever other mirroring type you wanted and accepting that the ExRAM wraps around sooner, it's switching back and forth that's a bad idea. Not for different engines in the game (i.e. cutscenes vs. gameplay), of course.
To my knowledge, no. Our current documentation states that exgfx ram access is limited only when exgfx is enabled. Put it in "plain ram" mode and you should hypothetically be able to access it in vblank.
In theory, yes, but would you risk doing that without testing on hardware first to be sure it works? The lack of proper reverse engineering and testing of this mapper is a very good reason to use it with caution, or to avoid it entirely if you can't carry out proper tests.
The MMC5's exgfx is actually more straightforward than the PPU's regular attribute tables, given that you have 1 byte per tile, and you don't have to access it through $2006/2007.
IMO, having to access part of the tilemap in one place (name table) and the rest in another (ExRAM) is not intuitive at all, specially considering that the update logic will be very different without the PPU's auto incrementing feature, and that maybe you have to update each part at different times (if you indeed can only update ExRAM during rendering - hopefully you're right and it's possible to change modes for writing during VBlank).
Think about what you have to do to update one 16x16 attribute region on the vanilla PPU, and then tell me the MMC5 is harder.
It can be quite simple if you have 32x32-pixel metatiles and don't scroll vertically, but I agree that attribute tables can be frustrating at times, specially for beginners.
I really don't want to fight over this. I think the MMC5 is a wonderful mapper, it's amazing how Nintendo managed to cram all those features in the chip and upgrade the capabilities of the system so much, and it's sad that it was so underused. I just don't want to see people using it lightly, like it was the most common and supported mapper ever, for petty reasons like a few misaligned background elements. If you really want to use the MMC5, be my guest, but please, design your graphics around it to properly make use of the enhancements, and PLEASE, PLEASE test your software on a real MMC5, because this mapper has not been dissected enough to be taken for granted.