This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

Expanding the PRG-ROM for Mapper 66

Expanding the PRG-ROM for Mapper 66
by on (#76898)
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...

by on (#76899)
  $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.

by on (#76900)
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.

by on (#76902)
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.

by on (#76907)
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.

by on (#76912)
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.

by on (#76914)
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.

by on (#76916)
Then MMC1 would be the perfect fit.

by on (#76938)
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

by on (#76944)
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.

by on (#76972)
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.

by on (#76984)
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.

by on (#76987)
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.

by on (#77023)
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.

by on (#77025)

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

by on (#77029)
qbradq wrote:
The random game cart :)
A few years ago I took apart a 2600 pirate multicart. That's how you chose the game — Vcc was hooked to the clock input of a counter chip, and that counter IC was powered through a diode and capacitor.

by on (#77079)
lidnariq wrote:
qbradq wrote:
The random game cart :)
A few years ago I took apart a 2600 pirate multicart. That's how you chose the game — Vcc was hooked to the clock input of a counter chip, and that counter IC was powered through a diode and capacitor.

That is hilarious. And nifty.

by on (#77092)
I clearly remember having several 2600 multi-carts like that (cycle the power to move on to the next game), but until this day I had no idea how the hell that worked.

by on (#77103)
I was just reviewing the mapper docs and found out that Mapper 60 is a four-in-one multi cart that toggles between games with a soft reset :D