nesdev.org

With these needs, which mapper would you recommend:

I think I'll be ok as far as graphics space, I simply need more space for code.

I haven't looked at the process of making this into a physical cartridge, but when that day comes, would certain maps make this easier?

How big is your code already? By "more space" do you mean like 128 KB or like 2 MB?

CHR-RAM.

I recommend UNROM if NROM isn't enough. If UNROM isn't enough, it depends on what features you need what way you should go. All the mappers have their uses. There is no best mapper.

I was using NROM, which looks like it won't quite cut it (my code is approaching $FD00 in the PRG.

I would expect another 32KB would do it for the code. I thought that even an extra 16KB would work, but with 32, I would be set.

Tepples, hope to see you again this year at MGC.

Have you made a game before? Never seen you hang here. Wouldn't be the...lets guess....blow into cart alcohool game? X)

I second MottZilla's recommendation of UNROM. You lose about 4 to 6 KiB of PRG ROM off the bat compared to NROM because you have to copy or decompress the CHR data and write it to CHR RAM, but the 64, 128, or 256 KiB capacity of the PRG ROM makes up for that.

UNROM is indeed the logical choice if you're reaching the limits of NROM. Since it uses CHR-RAM, the simplest thing to do would be to copy 8 KB of CHR data to the pattern tables right at the start of the program and never touch them again, so it will essentially feel like 8KB of CHR-ROM, like in NROM.

As for the PRG, the last 16KB are always mapped to $C000-$FFFF. Your Reset, NMI and IRQ routines should be in this bank, so that they are always available to the CPU. You will probably have to rearrange the rest of your code a bit, putting in different 16KB banks parts of the program that don't need to be mapped at the same time (for example, music code and data is usually very independent from the rest of the program).

For now, you could have a 64KB ROM with banks arranged like this:

bank 0: 8KB of CHR and a routine to copy them to VRAM;
bank 1: code independent from bank 2;
bank 2: code independent from bank 1;
bank 3 (fixed): routines pointed by the CPU vectors and code that needs access to the other banks.

You could also keep all of your code in the fixed 16K bank and only access data and subroutines in the other banks. Many games function like this.

UxROM really is a handy mapper as 256K should be enough for a lot of types of games. It all depends on the features you need of course. If you find there is something you can't do that you need to, then you might consider getting something more complex. But if you were using NROM, UxROM is perfect. You get both more Code/Data space AND could use more CHR space as you game is no longer limited to 8K of CHR.

Well, first I must say UNROM is NOT a mapper but a board, the mapper is mapper 2. (a mapper is a concept, not a PCB !!)

The big difference is that UNROM boards require 128k PRG-ROM while mapper 2 can take any value, so it's more generic (but I'd recomand avoiding non-power-of-two values. Non power-of-two ROM sizes are feasible in hardware but it'd be complex to do, and emulation support is not guaranteed).

If you need 64k of PRG-ROM you could go with mapper 2, as the other says, have 1 fixed bank and 3 bankswitchable banks. I also think mapper 2 supports 8kb of (fixed) CHR-ROM, while UNROM board obviously does not (that's the second reason I don't advice you to use "UNROM" because this is a board name that is too specific).

Another better option (IMO) would be to use mapper 66, which allows you to have exactly two 32k PRG-ROM banks and one 8k CHR-ROM bank, as you said you wanted. Also, CHR-ROM support on this mapper is official, and not hacky as it is in mapper 2, so emulator support will be complete.

Now if you want a cool/crazy option you could do like Dragon Quest, use mapper 3 and store mainly program data in the additional 3 CHR-ROM banks, however this is only if you feel like doing something experimental and funny (which I how I always feels haha). The reason this was used is that back in 1986 larger ROMs were very expensive, tended to become hot etc... so it was simpler to make a clever use of two smaller ROMs.

If you need code to be present at all times in the ROM just put it at the same adress in both banks.

I consider UxROM is to be mapper. No one calls it "mapper 2" other than as the iNES implementation. You could call it 74*161/32 but that isn't as nice of a title.

Bregalad wrote:Well, first I must say UNROM is NOT a mapper but a board, the mapper is mapper 2. (a mapper is a concept, not a PCB !!)

I usually call it UxROM. To me, iNES numbers are just meant to be used in headers.

Another better option (IMO) would be to use mapper 66, which allows you to have exactly two 32k PRG-ROM

Working with switchable 32KB banks can be hard for a beginner though... Using trampoline routines and things like that is not so trivial. Having a fixed bank makes things easier.

Sorry this just struck me as odd...

Bregalad wrote:Well, first I must say UNROM is NOT a mapper but a board, the mapper is mapper 2. (a mapper is a concept, not a PCB !!)

You must be the only one that thinks of it like this... So if someone asked you which mapper you were using you'd respond "mapper 0" because NROM is technically a board???

Even the god (wiki: http://wiki.nesdev.com/w/index.php/MMC) disagrees :
"A mapper is a piece of hardware soldered to a cartridge's printed circuit board that performs address decoding, bank switching, and possibly other tasks."

Including a list/links of "concepts" by providing their "boards" as yo see it? Most people would say it's a list/link of *mappers* by *name*...


But as for the actual topic:

rizz1010 wrote:I haven't looked at the process of making this into a physical cartridge, but when that day comes, would certain maps make this easier?

Most of the discrete mappers are pretty simple to make/manufacture. UxROM, AxROM, BNROM could be considered simpler because you would only have to program one chip compared to GNROM or similar. However UxROM one more part (a '161 and '32 vice just the '161 like most others). Keep in mind the UxROM is simpler to program for the reasons everyone is pointing out with the fixed bank. Most other mappers don't have a fixed bank and would require slightly more complex code structure without that fixed bank.

If you really conscious of manufacturing you could also look at cost comparison between CHR RAM vs ROM. and Memory sizes for PRG. Maybe even look at part count and board size. Either way though most of these shouldn't have too extreme of a cost difference.

Thanks for the input everyone. I'm leaning toward UNROM, and it appears to have a couple of great nesdev wiki pages for guidance.

Tokumaru, I really like that idea with bank0 (for putting the chr into place, and then that bank goes away). Thanks!

Bregalad, I appreciate you pointing out that mapper 66 as well. There were complexities mentioned, and I would have guessed that duplicate code in both banks would take care of these complexities (as you mentioned at the end of your post). Either way, it appears I'm moving forward using UNROM.

3gengames, I haven't been on the forums much lately. The good news is that I haven't had many questions (I'm always grateful for the regulars who are quick to answer questions). It was great to meet Memblers, Tepples & Clueless last year at the Midwest Gaming Classic, and more great news - if all goes well, I plan to show my brand new game at this year's MGC which is happening in about a month. It got started around September last year (I have a joint NES project that is currently on hold). Hope I'll see some of you there - feel free to PM or just point out if you'll be there (I might only be there on Sunday though).

You must be the only one that thinks of it like this... So if someone asked you which mapper you were using you'd respond "mapper 0" because NROM is technically a board???

You guessed it.

"A mapper is a piece of hardware soldered to a cartridge's printed circuit board that performs address decoding, bank switching, and possibly other tasks."

Yeah this makes the mapper either a hardware chip (like the MMC1) or a set of chips (for example HC161+HC32) hooked in a certain way, which are basically equivalent to a concept. (I think an electric schematic is a concept).

Calling mapper 2 "UNROM" is definitely an abuse of language everyone on NESdev does (incluind possibly me too), but it remains an abuse of language.

There is several different ways you can get the same mapper behavior. In the case of mapper 2 UNROM is only one of the many ways to get mappre 2 functionality. There is also UNROM-style 3rd party boards (Konami, etc...), UOROM, Camerica boards, and probably a lot of other stuff I forgot.
Mapper 2 can also have 8k CHR-ROM, have 4-screen mirroring, have battery backed SRAM, have any size of PRG-ROM, all this the UNROM board can't, unless its hevily modified.

Also mapper 2 is only one of the two mappers the UNROM board can implement, UNROM can also be mapper 180 (replace the '32 by a '08 and gate and the hardwired bank is at $8000-$bfff).

This is why calling mapper 2 "UNROM" is clearly wrong - mapper 2 is not necessarly UNROM, and UNROM is not necessarly mapper 2.
I don't think it's I who made this up it's just facts. I just pointed this abuse of language that's all. The name UNROM is just a random chain of characters Nintendo put on some boards, it doesn't have much meaning anyways.

UxROM is slightly less wrong, but it implicitely exclude for example 64KB or 512 KB PRG sizes, or the additional features mentioned above, which are all possible with mapper 2.

In summary I know this is a big mess but here are my $2 about this. Sorry for getting off topic.