+  RHDN Forum Archive
|-+  Romhacking
| |-+  ROM Hacking Discussion
| | |-+  Doing a ROM Expansion - Which Mapper to Use?
Pages: [1]
Author Topic: Doing a ROM Expansion - Which Mapper to Use?  (Read 2 times)
Karatorian
Guest
« on: March 04, 2008, 02:42:59 am »

I'm considering doing a ROM expansion. The ROM currently uses MMC1 with 16 banks of 16K PGR ROM, CHR RAM, and 8k of SRAM. The game keeps the upper bank mapped at all times and switches out the lower bank. I'm wondering which mapper would be a good choice for such a project.

My priority is mostly good EMU support, with a secondary goal of decent cart availibility. I'm considering using one of the MMC1 variants, but I worry about the fact that they use the same iNES mapper number. Does this create a problem? Or do emulators just assume a larger variant when more program banks are present. Are they well supported?

Due to the fact that the ROM is already very large and I don't need a whole lot more space (a few banks, at most), are there any mappers that support non-power-of-two ROM sizes? While not a priority, it would be nice if I could avoid doubling the size of the image.

Thanks in advance.
KingMike
Guest
« Reply #1 on: March 04, 2008, 10:03:30 am »

I don't think you could find such a mapper, as I'm pretty sure ROM chips (which the mappers were originally designed to interact with) don't come in non-power-of-2 sizes.  Tongue
(yeah, there's some ROMs with sizes like 160KB, 192KB, 384KB. But that's because they used two ROMS of different sizes, with one holding the graphics data, and the other holding everything else.)

Expanding a 256KB MMC1 ROM to 512KB is possible, but it's also a unique and more difficult expansion.
deespence2929
Guest
« Reply #2 on: March 04, 2008, 10:04:39 am »

Is there a hack ideas thread on this forum?
« Last Edit: March 04, 2008, 10:10:54 am by deespence2929 »
KingMike
Guest
« Reply #3 on: March 04, 2008, 10:08:31 am »

There's already a hack ideas thread.

...somewhere around here.
Disch
Guest
« Reply #4 on: March 04, 2008, 10:49:30 am »

Quote from: Karatorian on March 04, 2008, 02:42:59 am
My priority is mostly good EMU support, with a secondary goal of decent cart availibility.

If you want emu support and cart availability, then go MMC3 (mapper 004).  The one problem with it is that it can't do 1-screen mirroring like MMC1 can -- but only a small handful of games use that (I'm assuming the game you're hacking doesn't use it)

Quote
I'm considering using one of the MMC1 variants, but I worry about the fact that they use the same iNES mapper number. Does this create a problem? Or do emulators just assume a larger variant when more program banks are present. Are they well supported?

Depending on how the emu supports it.  Most will automatically switch to SUROM when there's more than 256K.  Some will fall back to a CRC check or somesuch.  And some have it a configurable option in the interface.

Anyway... emu support likely won't be a problem.  At least not with modern emus.  However cart availability might be.  SUROM, etc are wired differently than standard MMC1 boards -- and while the mapper itself may be the same, I'm not really sure if you'd be able to use any old MMC1 board.

Quote
Due to the fact that the ROM is already very large and I don't need a whole lot more space (a few banks, at most), are there any mappers that support non-power-of-two ROM sizes? While not a priority, it would be nice if I could avoid doubling the size of the image.

As has been mentioned -- no.  At least none you should consider.  I can only think of two games offhand that have odd ROM sizes and they're both multicarts and pretty obscure.
Karatorian
Guest
« Reply #5 on: March 04, 2008, 07:32:01 pm »

Ok, it looks like MMC3 is the way to go. Mirroring won't be an issue. Looks like it'd do what I need.

I figured the non-power-of-two thing was a long shot. I know that ROM chips come in power-of-two sizes, I just thought there might be some mapper that supported an odd number of smaller chips. Oh well, not a big deal. 512K isn't very large by today's standards. (Besides, zero filled banks should compress well, so it's proabably irrelevant.)

Thanks again.
SMB2J-2Q
Guest
« Reply #6 on: March 04, 2008, 07:59:36 pm »

I wonder if the MMC3 thing will come in handy for the likes of re-programming SMB2J to work with Game Genie codes??

~Ben (SMB2J-2Q)
Karatorian
Guest
« Reply #7 on: March 06, 2008, 11:32:44 pm »

A while back, there was a thread about hacking SMB2 (not J) back into Doki Doki Panic. One of the respondants to that thread said it'd proabably be easier to port Doki Doki Panic from the FDS to the NES, and procceed to do some work on doing so. It didn't sound like it was actually that hard to do. (Of course, the poster (I wish I could remember who it was) was an experianced ROM hacker.)

The same sort of techniques could be used to port SMB2J to the NES, which should make it Game Genie compatible. You may want to look into that approch. If you do, MMC3 would proably be a good mapper to use. (Although other mappers may be more suited to the FDS's program structure, I don't know that much about the FDS). It's a rather nice mapper. It's easy to program, has good flexibilty, but isn't loaded with extra features.
Shadowsithe
Guest
« Reply #8 on: March 07, 2008, 12:44:32 am »

I think it was disch actually.
Disch
Guest
« Reply #9 on: March 07, 2008, 12:54:22 am »

Yeah that was me.  I ended up eating my boot on that attempt, though.  Turns out DDP is loaded with a bunch of self-modifying code that made it really hard to convert.  It also loaded its files on odd boundaries (making converting to bankswapping kind of tricky).

At any rate -- a FDS->NES conversion of DDP would probably be easier than a SMB2->DPP conversion in the sense that there are a lot of really small things that were changed between the games -- and if you wanted a "complete" conversion, a lot of stuff would need to be recoded from scratch.  But the FDS->NES would be harder in the sense that it would take a lot of code disassembling and reworking.

In the end I gave up on my conversion attempt simply because it required more work than I was willing to put into it.  Once I found all the self-modifying code I just said "fuck it -- this isn't worth my time -- I'll just play the FDS version" and dropped the project.  I don't even know if I still have my files/notes anywhere... my computer is kind of a mess  =x


And of course one of the big hurdles with the FDS->NES convert that I didn't even get to was the sound.  DDP uses the FDS channel for sound effects and some music.  In SMB2, the sound effects were switched to the DMC, but the music was rescored to not use the FDS channel.
Pages: [1]  


Powered by SMF 1.1.4 | SMF © 2006-2007, Simple Machines LLC