albailey wrote:
I'm curious about the technical aspects of making the multi-cart. I've never used MMC1 before so I'm only going by what I read in a doc by firebug.
The info for a lot of mappers in Firebug's doc is slightly outdated. When in doubt, I'd be more inclined to trust NESdevWiki articles such as
MMC1, which incorporate newly discovered information.
Quote:
I see from your asm code you use 32K bankswitching (bit 3 of register but you do not do this for Zelda.
For Zelda, I jump to where Zelda expects to jump.
Quote:
You mentioned something about the Zelda init code. Is this how you are able to deal with Zelda's vectors (NMI, reset, etc..) if you dont clobber 0xFFFA-0xFFFF.
Zelda's mapper init code lies in the $FFxx page. Right when it's about to load a bank into $8000-$BFFF and jump to the main code, I patch it to switch a different bank (the menu) into $8000 and jump to a different address (part 1 of the menu).
The menu has three parts:
- BOOTCODE: Loader for part 2, running in ROM
- RAMCODE: A trampoline that copies CHR data from ROM to RAM and switches banks, running in RAM
- CODE: The menu proper
Part 1 copies part 2 from ROM to RAM, sets up part 3 as the desired ROM to run, and jumps to part 3.
Quote:
I assume you are able to use the NROM 128 games because you ensure that the 16K goes into the $8000-$FFFF memory and it doesnt matter what goes in the $000-7FFF bank. Are there "known" games where this is not a safe assumption.
You mean loading 16 KB into $C000-$FFFF and not into $8000-$BFFF. Yes, some NROM-128 games depend on $C000-$FFFF being mirrored down into $8000-$BFFF. But as far as I can tell, Mario Bros. and Ice Climber are not two of them, and those were my main impetus for developing this multi.
In fact, I could probably replace one of the NROM-128 games with an NROM-256 game by implementing some simplistic CHR compression. Contra used a form of RLE compression, and so did my Who's Cuter demo. But I probably won't bother, nor will I bother about Galaxian.
