MMC2 sanity check -> MMC3 general query

[LoneKiltedNinja]

Original question/context:

Despite my various weird musical tech demos, I haven't worked directly with anything but mapper0 in ages.
I have a crazy notion for a project for which MMC2/mapper9 seems to be a perfect fit; I just want to confirm one detail:

Someone PLEASE tell me that the memory-mapped register behavior smearing 6 registers across the whole $A000-$FFFF space is only in the write direction. Because that would be sane. That would mean that the hardware basically uses the top 3 address bits of the write lines to mux to 6 writable regs while reads actually hit the fixed banks as documented ( http://wiki.nesdev.com/w/index.php/MMC2 ) and life is good and I don't need to get a MMC3 headache without nbasic asprin.
If, rather, you can use up to 128k of PRG so long as all execution at a given time fits within an 8k chunk that you're constantly swapping out from under yourself... to be fair, I could still FIND use cases, but just ow.

Am I sane? (or as sane as I can be contemplating "NES" and "Hatsune Miku" in the same sentence...) Or was the tech world mad in 1987 in a way that is likely to prove contagious by written exposure?

Per the below, MMC2 won't work. But having confirmed my sanity w/r/t registers, one MMC3 question:
What is loaded into $8000-$CFFF at power-on? Is $8000-$FFFF just the last 4 banks in the ROM (assuming a sane 128k/256k/512k footprint) or do I need to plan on an entry vector in the $E000+ range and bootstrap all the other swappable banks in by hand?

[lidnariq]

Yeah, almost all NES mappers only happen on writes. The MMC2 is no exception.

[LoneKiltedNinja]

Yokatta. Thank you. ... However I just noticed a glaring problem with MMC2 for my intended use case May need to change the thread name and reconsider my question...

[lidnariq]

or do I need to plan on an entry vector in the $E000+ range and bootstrap all the other swappable banks in by hand?

Yes. Warm reset doesn't change anything, and on cold boot registers often (but not always) contain all 0s... so it's best just to assume the contents are invalid and initialize in the Reset vector.

[LoneKiltedNinja]

alrighty then. Thanks!
Yeah, as a first pass I took the existing iteration of my (mapper0) asm and flipped it around so the main executable was .bank 3 .org $E000 and the data was up top. Running as mapper0 as a sanity check, all was good.

I then tentatively switched to .inesmap 4 and it ran just fine, so apparently Nestopia at least will map all 4 banks of a 4-bank MMC3 ROM into the address space in sequential order.

I then upped the game from .inesprg 2 to .inesprg 4 and inserted dummy .bank 0 - .bank 3, shifting the others to .bank 4 - .bank 7. I.e. my main executable section starts at .bank 7 .org $E000. nesasm was happy, Nestopia says the result's garbage. Which I find odd, since shouldn't the last bank in the ROM always show up at $E000? I popped the binary into a hex editor, and the start vector is pointing to $E000, and the executable code does begin there, but still no dice...
...
Er...
Okay, nevermind that. It apparently helps to some great extent when I don't leave my CHR data at .bank 4 when PRG is at .bank 0-7.
Nestopia now runs the binary, and as predicted, it stumbles through the first bit of data nominally parked in .bank 4-6, and then nosedives, probably due to dangling/ambiguous bank mapping.

Edit: confirmed. Manually swapping banks 4 & 5 into $8000 and $A000 at the top of execution cleans things up nicely. Thank you, lidnariq, you have hopefully enabled the future blowing of minds outside the dev community and rolling of eyes within it, because if all my maths are correct, I can now pull off something ridiculous.