Does anyone knows a game or even a homebrew demo that use the MMC1's high bank switching mode (bank $c000-$ffff switched instead of the typical $8000-$bfff) ? I'd be curious to see an use of it.
Advantages :
- This allow you to have multiple IRQ and NMI handling when switching banks.
- This allow you to have loads of DPCM data.
Cons :
- This FORCES you to have IRQ/NMI vectors in each ROM bank.
- You're not sure in wich state the MMC1 is at reset or power-on, and if the bank #0 is always switched at $8000-$bfff, so maybe it is needed to have the reset code in normal more, then switch to that particular mode ?
Bregalad wrote:
- This FORCES you to have IRQ/NMI vectors in each ROM bank.
- You're not sure in wich state the MMC1 is at reset or power-on, and if the bank #0 is always switched at $8000-$bfff, so maybe it is needed to have the reset code in normal more, then switch to that particular mode ?
On most mappers in general (when the reset vectors aren't on a fixed page), those 2 problems are the same. It forces you to take care of the reset vector too in every bank (wouldn't want execution getting stuck in a bank). I think the safest way is to set aside the $FFE0+ area (or however more you need) and have your reset vector and bankswitch config code there in every 16kB/32kb bank (depending on page size).
BTW, multiple NMI and IRQ handling can always be done with only 3 cycles of overhead. Put a JMP to your routine in RAM, and point the vector to that instruction in RAM. I started using that a lot. It's a pretty desperate situation when 3 vblank cycles start to matter, and I want more IRQs than there are banks.
With the intermediate JMP approach, you can eliminate any decision logic from the IRQ handler itself, instead encoding that into the address to jump to. For example if you normally did X or Y in the handler, based on some zero-page variable, you'd just change the JMP address when this zero-page variable changed. This would be faster than the original code.
I wasn't asking how to have a variable IRQ handler, but if any commercial or non-commercial MMC1 games have ever seriously used that feature (other than for test purposes).
I'd ask myself how to use it benefically, but it is definitely possible to make a good use of this hardware bankswitching. Of course the jmp indirect is almost the same approach, exept that it is independant from banks.
It is good for DPCM data like you said, but I don't know of any games that used more than 16kB of it.
At least Brian Provinco seems to have found that interesting :
http://www.bripro.com/low/mappers/index.php?page=nes-unrom
Interesting, actually I've seen that page quite a few times but never really noticed that part. I might try that on my UNROM cart.
(I am strictly intending NPOV here - I'm not saying anything is good or bad.)
...and according to the wiki, that changes the mapper into
INES Mapper 180, right?
Yes. That's cool, I didn't know there was a mapper # for it already. It gives an answer to Bregalad's question too (besids the MMC1 part) - Crazy Climber. Now I wonder why they did that? I've played the arcade version, but never tried the Famicom one.
Ah, so that is the answer. I'll check that. Because I find the modification interesting (and it would be quite easy to simulate a modded UNROM board with a MMC1), I don't think Brian Provinco did just put that to show off he knows how to deal with AND and OR gates, but in the order to provide usefull information.
EDIT : I've downloaded Crazy Climber, and found out it was an incredibly disappointing game. Also, it doesn't seem to swap any interupt vectors. It use DPCM for some screams, but nothing will exess 16kb.