Expanding the PRG-ROM for Mapper 66

Pennywise · Post by **Pennywise** » Sun Apr 17, 2011 5:00 pm

Hi all,

I recently expanded the PRG-ROM from 128K to 256K for Dragon Ball and did a bank swap to utilize the extra space. I tested it in FCEUX and it works fine, but when I tried it out in Nestopia it crashed when the code got to the bank swap.

Does this mean my hack won't work on hardware? Or is it an Nestopia issue similar to certain modified Konami games not working...

Dwedit · Post by **Dwedit** » Sun Apr 17, 2011 5:17 pm

Code: Select all

  $8000-FFFF:  [..PP ..CC]
    P = Selects 32k PRG @ $8000
    C = Selects 8k CHR @ $0000

Mapper #66 (GNROM) doesn't appear to support more than 128k of PRG. Maybe some emulators are extending the number of PRG bits to 4.
Hack the mapper to something else. Data breakpoints and disassemblies will help here.

tokumaru · Post by **tokumaru** » Sun Apr 17, 2011 5:18 pm

The documentation I have read says that there are only 2 bits dedicated to selecting the PRG-ROM page, meaning that the maximum PRG size is indeed 128KB (4 x 32KB) in an actual cart (FCEUX is just "being nice" and letting the program use more bits, while Nestopia is more strict and prefers to stick to the limit), so your hack wouldn't work if you just swapped ROMs. With some rewiring and the replacement of a chip in the cart you can get it to work on a cart though.

Pennywise · Post by **Pennywise** » Sun Apr 17, 2011 6:28 pm

Alright, changing the mapper sounds like a plan. Ideally I'm looking for another mapper that selects 32k for the PRG, but has 4 bits dedicated to it. Regardless, would anyone have any suggestions for potential mappers that would be less painful to implement? If I'm reading the details correctly mapper 79 might be a candidate.

Post by **tepples** » Sun Apr 17, 2011 7:03 pm

You could mapper hack it to MMC1. It has modes for 32 KiB PRG and 8 KiB CHR bankswitching, and it supports up to 256 KiB of PRG and 128 KiB of CHR. I'd recommend it unless the game uses mid-frame bankswitching as a raster effect.

tokumaru · Post by **tokumaru** » Sun Apr 17, 2011 8:24 pm

MMC1 does sound like a good option, because of how common it is. The problem with MMC1 is that mapper writes must be done 1 bit at a time, so the writes are slower than in any other mapper, which is why tepples doesn't recommend it if the game uses bankswitches for graphical effects, because those would probably glitch up.

Dwedit · Post by **Dwedit** » Sun Apr 17, 2011 8:53 pm

It's Dragon Ball, it rarely bankswitches. Not like other games that bankswitch many times per frame, this one just bankswitches when it switches between different types of screens.

Post by **tepples** » Sun Apr 17, 2011 10:00 pm

Then MMC1 would be the perfect fit.

Pennywise · Post by **Pennywise** » Mon Apr 18, 2011 4:24 pm

Thanks, I think I'll go with the MMC1 then.

While I'm at it, changing mappers is a new concept for me. I get that I'd have to change the swapping routines, but what about something like a startup routine? Currently it seems that only 16K of the PRG is in the PRG-ROM when I change the mapper info in the header. So from that I take it my first goal should be to have the game work on startup. Anyone have any advice or a direction they can point me in? Thanks

tokumaru · Post by **tokumaru** » Mon Apr 18, 2011 5:57 pm

You need to initialize the mapper's register on start up. Look at the MMC1 documentation and see everything that you have to change in order to make it behave like the original mapper of the game you're hacking. You need to set up 32KB PRG-ROM mode (I believe the default is 16KB with a fixed bank), mirroring, things like that.

qbradq · Post by **qbradq** » Tue Apr 19, 2011 12:50 pm

Don't forget to put the mapper init code within the fixed bank (that is, the bank that is fixed on power-up). You may have to alter the reset vector to point to your mapper init code in the fixed bank, then JMP from there to the real reset vector for the game.

Post by **Memblers** » Tue Apr 19, 2011 3:11 pm

To make things more fun, not all revisions of the MMC1 have a fixed bank. Some of them start in a random bank. Plain MMC1 seems to be like that, and some MMC1A parts are like that. Won't matter on emulators, but it will on the real hardware.

Post by **tepples** » Tue Apr 19, 2011 3:39 pm

Which only means that you'll have to somehow clean out $BFF0-$BFFF and $FFF0-$FFFF of every bank and fill them with a stub. This may require relocating a few things. This stub makes sure that the last 16 KiB of PRG ROM is in $C000-$FFFF.

Post by **Memblers** » Wed Apr 20, 2011 2:50 pm

I think it was 32kB bank mode at startup, but I'm not sure. The best thing to do probably would be to look at the startup code for games that used them - for the 2 times I've experienced that the carts were Rad Racer (Playchoice version, probably the same as the NES release) with a 'plain' MMC1 and Ultima: Exodus with an MMC1A.

Reason I suspect it was 32kB was because years ago I hacked a bunch of 32kB NROM games onto that Ultima: Exodus cart. Whenever turning the system on, it would start in a game randomly (never crashed once, as it would have in 16kB mode). Given enough power cycle resets it would eventually start in the menu.

qbradq · Post by **qbradq** » Wed Apr 20, 2011 3:41 pm

Memblers,

That is an awesome idea for a project! The random game cart