Originally posted by Disch

---

adding more PRG/CHR is one thing (and is actually not that hard if you have the idea)

Actually USING that new space is something else entirely, and it often isn't easy. For extra PRG... whenever you wan to use the new space you must swap in the desired bank, do whatever work you want to be done, then swap back in the original bank before returning to the game's original code. This takes not only a decent understanding of 6502, but also of the mapper's registers and swapping abilities.

Using extra CHR is easier -- since all you need to do is swap to the desired bank. For things like animation done through CHR swapping, you'd need to add/modify an existing routine in the game to constantly swap in new CHR banks (animating tiles which use that bank). But still, to do this you have to actually know what you're doing.

As was already mentioned... most mappers need to have a power-of-2 PRG/CHR size. So if a game has 256k PRG and you want to expand it... you'll have to bump it up to at LEAST 512k of PRG -- even if you only want a few extra bytes (there are exceptions to this rule, some rare mappers can have abstract PRG/CHR sizes).

Also beware of mapper limitations. Not only do PRG/CHR sizes have a limit, but some mappers also lack on board cartridge RAM (no ram @ $6000-$7FFF), and some mappers have bus conflicts, so the value you write to the mapper register must match the value read from that address.

---

Originally posted by HyperHacker

---

Actually, most games I've seen use 00 instead of FF.

---

Originally posted by Disch

---

As was already mentioned... most mappers need to have a power-of-2 PRG/CHR size. So if a game has 256k PRG and you want to expand it... you'll have to bump it up to at LEAST 512k of PRG -- even if you only want a few extra bytes (there are exceptions to this rule, some rare mappers can have abstract PRG/CHR sizes).

Also beware of mapper limitations. Not only do PRG/CHR sizes have a limit, but some mappers also lack on board cartridge RAM (no ram @ $6000-$7FFF), and some mappers have bus conflicts, so the value you write to the mapper register must match the value read from that address.

---

Originally posted by HyperHacker

---

Actually, most games I've seen use 00 instead of FF.

---

Originally posted by DahrkDaiz

---

Originally posted by HyperHacker

---

Actually, most games I've seen use 00 instead of FF.

---

Actually, the way a PROM works is that there are fuses on a cartridge that are blown out. A non-blown fuse = a 1, a blown fuse = 0. So since we can't un-do a blown fuse it's sensible to leave unused bytes with all fuses intact, rather than blowing them all out, so if there's a byte in a PROM that's not used, all of it's fuses are left intact, thus, an unused bytes in a PROM are FF, not 00. An NES cartridge probably doesn't use fuses, but the concept is still the same. Chunks of FF = free data.

Anyways, expanding NES ROMs is rather easy but like Disch said, using that data is the hard part. I'll walk you guys through a quick run down of how I expanded SMB3 for Luigi vs Mario.

First, I found out that for the MMC3, the last 16K of PRG-ROM is "hard wired" into the ROM, meaning that this code will exist at all times and cannot be swapped out. MMC3 has options as to where to put this unswappable code and SMB3 chooses to put the first 8K at $8000-$9FFF and the last 8K at $E000-$FFFF. Thus, $A000-$DFFF will change through out the game.

So anyways, since the last 16K of space won't ever be changed out and it needs to STAY the last 16K, I realized you need to add your free space between the last 16K (which for SMB3 starts at 0x3C010) and the rest of the ROM, so I had to add the space between at 0x3C010, pushing the last 16K further down the road. Now, MMC3 requires that the PRG-ROM be at 128K, 256K or 512K. That's how the MMC3 works. So since PRG-ROM for SMB3 was already 256K, I extended it to 512K. So I inserted 256K of the byte 0xFF at 0x3C010.

Now, emulators need to know how much PRG-ROM there is. The iNES header format has the amount of 16K PRG-ROM banks numbered at the 4th byte. Let's do a byte of math. I now have 512K of PRG-ROM. Divide that up by 16: 512/16 = 32. So 32 in hex is 0x20. I enter 0x20 for the 4th byte to show there's 32 banks of 16K of PRG-ROM in this newly expanded ROM.

Tah-dah! The ROM has now been expanded. Now how do I use this newly found ROM area? What I wanted to do with Luigi vs Mario was to have seperate paths for each character, and since the game divides up each level "type" (Plains, Hills, Sky, Underground, etc) into it's own seperate 16K bank, I could do that easily. I copied over all the level data to the new expanded area (0x1e010-0x30010). Then, I made an ASM hack. When the game switches banks to load level data from the proper bank area, I did a small check. If the game is being played by Mario, I jumped to a new routine that loaded a different bank number for Mario. The bank number it loaded would be in the area of the newly expanded ROM area. Then, I made a small program that would copy the normal level data of one rom over to the new level data in the expanded area of another rom. I made a copy of my hack, a Luigi side and a Mario side. When I edit the ROM for the Mario side, I just run the program once and it copies over the Mario side into the new level data area of the main rom. Then when I play the main hack rom and am Mario, my routine will switch in a different bank and with the same pointers, I get two different levels with each character.

This just goes to show the amount of work needed to pull off ROM expansion. It takes a lot of patience, but it's not THAT hard. I made a lot of mistakes and errors before I got SMB3 expanded and working like this, but I kept at it and within 2 hours, I had it all done.

---