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

Choosing a new mapper

Choosing a new mapper
by on (#44599)
So for a while, I've been working on my project ChateauLevania. I want this to be a really professional looking game that basically shows what I can do, and shows what people wouldn't believe the NES can do. For this, I decided I needed lots of PRG, CHR RAM, and SRAM.

The perfect board, I thought would be FF3j's board, as it allows for 512k of PRG, CHR RAM, and SRAM. Also it allows for 8k PRG bankswitching and a scanline counter, which is great. So I started building my project around this board.

However, now I realize that this board really isn't that great. I don't use the scanline counter and don't even plan on it, and besides sacrificing FF3j's board sounded fine at first but now I'm reconsidering. I do want people to be able to purchase this game when I'm finished with it, but I don't want it to end up being super expensive. Now that I think about this, I should probably change mappers.

So what's a mapper/board that I could use that would allow for lots of PRG, SRAM, and CHR RAM that wouldn't be so hard to come by? I would need all of those things (PRG space, CHR RAM and SRAM), along with good bankswitching capabilities.

I did, while reading Disch's mapper docs come across a very -lovely- mapper that has everything I need and more, however I feel it might be really hard to find. It has great bankswitching capabilities, CHR ROM and CHR RAM, a cycle based IRQ counter (how wonderful; I'd actually use it), SRAM, and a game that has 512k of PRG. This is the one and only N106. It also has extra audio of course, which leads me to believe that this mapper is famicom/Japan only, is it not? This mapper's awesomeness, assuming it isn't TOO rare, might be worth using regardless of its cost/rareness.

EDIT: Crap, I think I lied about the 512k of PRG. But it might be possible to still make good use of this mapper, as I can store stuff in CHR ROM and still use CHR RAM.

by on (#44600)
Yes the N106 is Famicom/Japan only, and it should be very hard to make your repro as the vast majority of games using that mapper are made exculsively of epoxy blobs you can't replace.

I guess the MMC3 sounds fine but if you're not using the scanline counter at all and don't mind a different bankswitching sheme you'd want to go for MMC1, SUROM like DW3 and DW4. You can mod a simple common Zelda cart in order to get such a configuration.

by on (#44601)
Ah, I figured there would be some disappointing news about N106; it sounded too good to be true :).

MMC1 seems to have a strange bankswitching scheme. I would prefer as little fixed bank-ness as possible. 8k PRG banks are ideal for me, and what I liked about the N106 is that only $E000-$FFFF is fixed.

Hmm, Mapper 32 seems to allow for lots of PRG banks, 8k, as the switching register is 8 bits wide. I'm not sure if it can have SRAM/CHR RAM though. Those two things are an even bigger must than anything PRG related. I guess I'll keep looking.

by on (#44602)
Well in the MMC1 16kb are switched and 16kb hardwired, but if you use 512k you have two different "hardwired" banks, one for each 256k page.

The advantage of big fixed banks is that you can fit plenty of routines in them, and you'll find yourself bankswitching less often and gaining some speed.

Mapper 32 looks like it is an obscure japanese mapper but if you somehow manage to make a devcard from it I'd say go for it. However it looks like it's a CHR ROM mapper so maybe you haven't investigated enough.

In fact I'd almost say the vast majority of mappers were designed to work with CHR-ROM. Mappers 1, 2, 4, 7 and 34 (GNROM) are more or less the only ones that supports CHR-RAM (there may be a few other rare/funky mappers as well).

by on (#44603)
I'll assume you mean mapper #4 (MMC3), not #3 (CNROM).

by on (#44604)
Well, perhaps I'm best sticking with the MMC3 FF3j cart. It's probably not THAT hard to make copies of, as you can modify boards and rewire to do it. I just thought I'd see if there was an easier solution. Oh, but now I'm quite envious looking at N106 and its IRQ counter/bankswitching capabilities. With that you could actually have PCM playing in real time (though you'd basically allow the rest of the code only a small amount of time).

by on (#44608)
Perhaps it's about time to make a cost effective homebrewed mapper that will support all your (and other nesdev developers) needs? That way you don't need to worry about which donor cart to use.

I think we should start to think seriously about it. This topic comes back so often.

by on (#44615)
I've always wondered why emulator authors haven't sat down together somewhere (IRC?) and actually discussed inventing an emulator-specific mapper that would meet the needs of emulator-centric game programmers. Seriously, pick an unused mapper number (is there one?!), and go for it. Sounds like a job for the Wiki if you ask me! ;-)

That might induce the question "so then how do we get said games to run on actual hardware?", and the answer would be "find someone who does EE and has great familiarity with an FPGA". :-)

To Celius: go with MMC3. It's supported everywhere (emulator-wise) fairly well, and the chips for it (on PCBs) should be easily obtainable (it was a common mapper). I don't know if it supports up to 512KB of PRG/CHR swapping though -- you might have to cut your game down in size, or consider using some software compression (especially of tiles).

by on (#44620)
Quote:
Perhaps it's about time to make a cost effective homebrewed mapper that will support all your (and other nesdev developers) needs? That way you don't need to worry about which donor cart to use.

I'm pretty sure nobody will agree on what features are essencial and what features aren't, and in the end nothing serious will be done. Also, too many people seems to be under the impression that to do a good game you need a good mapper. This is wrong, SMB is the proof. If you say "yes but this is a very simple game" you are right, then take DW4, it's really a complex game with a vast world, many unrelated quests, etc... and it is a MMC1 game, they did not need any complex mapper to do it. I have yet to see any NES homebrew games that is significantly more complex than SMB anyway.

The MMC5 has any features and nothing really better could exist (or anyone complainig about the lack of a 4-color mode 7 for the NES ?), but it only allows for CHR-ROM, altough many advantages of CHR-RAM can be compensated with the possibilities of the MMC5.

by on (#44625)
koitsu wrote:
I've always wondered why emulator authors haven't sat down together somewhere (IRC?) and actually discussed inventing an emulator-specific mapper

Because Bananmos would have told us to stop developing for an NES emulator and start developing for DirectX or Java or .NET or something.

koitsu wrote:
That might induce the question "so then how do we get said games to run on actual hardware?", and the answer would be "find someone who does EE and has great familiarity with an FPGA". :-)

That, or we should design an MMC3 class or FME-7 class mapper specifically to fit in a CPLD. Once that mapper is available on new boards with a CIClone, then I would feel justified in assigning a mapper number to it.

Bregalad wrote:
many advantages of CHR-RAM can be compensated with the possibilities of the MMC5.

Not so easily for Videomation or Qix or Hatris.

by on (#44628)
Maybe we'll see the FME-7 cloned and you could use that. ;) It would be nice.

by on (#44631)
koitsu wrote:
To Celius: go with MMC3. It's supported everywhere (emulator-wise) fairly well, and the chips for it (on PCBs) should be easily obtainable (it was a common mapper). I don't know if it supports up to 512KB of PRG/CHR swapping though -- you might have to cut your game down in size, or consider using some software compression (especially of tiles).


FF3's board supports 512k of PRG data. $8001 is the bank selection register, and it's 8 bits wide. If I'm not mistaking, that could select up to 256 different 8k banks, which would make the max size 2048k. Either way, 512k is possible because FF3 has it, and 512k is enough. I plan to have 256k of that data be CHR data. And I need it uncompressed because the NMI routine can update CHR data from ROM during Vblank, and if the data was compressed that wouldn't fly so well.

The idea of a new mapper is pretty cool, but Bregalad is right in saying that you don't need a mega-mapper to make a good game. I'm not exactly using a mega mapper (though 512k of PRG data is a lot, kind of), and I hope to blow everyone away with what I come out with. Though it would be hard to make emulators support a new mapper. And there are a bunch of values for the mapper ID that aren't used, but while everyone's adding support for a new mapper for all these emulators, the NES header format should be updated because there are a lot of flaws with it.

by on (#44634)
MottZilla wrote:
Maybe we'll see the FME-7 cloned and you could use that. ;) It would be nice.

Well not in discrete chips I assure you, it was just way too painful. Perhaps the next RetroUSB thing will be what you guys are looking for if it's reconfigurable. If I ever go back to my game, it will surely use a subset of FME-7 too.

by on (#44637)
Celius wrote:
And I need it uncompressed because the NMI routine can update CHR data from ROM during Vblank, and if the data was compressed that wouldn't fly so well.

Decompress them to RAM during draw, and copy them to CHR RAM during vblank.

Quote:
And there are a bunch of values for the mapper ID that aren't used

We'd have to check with the ones still dumping new carts that use new mappers, such as Sanchez (Санчез), before filling it with fairy-dust mappers.

by on (#44639)
tepples wrote:
Decompress them to RAM during draw, and copy them to CHR RAM during vblank.


The amount of time and extra RAM it would take to do that isn't worth it. The amount of time my game logic takes is too much to stick that in. Now all I have to do is specify a bank number, PPU address, and address of the tile data. I have an area set aside for dynamic tile data that it can read from, so it's technically possible to decompress data to that section and put it on the screen. But I don't feel it's necessary given the amount of space I can work with. And cutting down from 512k to 256k is a really big decision that I don't think I'm going to make.

tepples wrote:
We'd have to check with the ones still dumping new carts that use new mappers, such as Sanchez (Санчез), before filling it with fairy-dust mappers.


This is even more proof that the iNES format should be updated. There are 8 bytes in the header that aren't even used; a lot could be done with these. And why do they have to be clear in order for games to work?? It's not like a game relies on these unrelated bytes being 0...

by on (#44640)
Celius wrote:
There are 8 bytes in the header that aren't even used; a lot could be done with these. And why do they have to be clear in order for games to work?? It's not like a game relies on these unrelated bytes being 0...

Because emulators use the later bytes being clear as a heuristic for byte 7 being valid and not part of the string "DiskDude!".

by on (#44642)
tepples wrote:
Because emulators use the later bytes being clear as a heuristic for byte 7 being valid and not part of the string "DiskDude!".


Wow... That's super retarded. An emulator should be able to assume that the ROM given isn't corrupted, and not have to go the extra mile to see if it is.

by on (#44646)
Celius wrote:
Wow... That's super retarded. An emulator should be able to assume that the ROM given isn't corrupted, and not have to go the extra mile to see if it is.

Should be. In practice, a lot of ROM images in the wild have trash in the reserved bytes. Adding a check for known corruptions greatly improves the user experience, rather than just giving her some kind of unexpected behaviour.

by on (#44702)
Bregalad wrote:
Quote:
Perhaps it's about time to make a cost effective homebrewed mapper that will support all your (and other nesdev developers) needs? That way you don't need to worry about which donor cart to use.

I'm pretty sure nobody will agree on what features are essencial and what features aren't, and in the end nothing serious will be done. Also, too many people seems to be under the impression that to do a good game you need a good mapper. This is wrong, SMB is the proof.


I wholeheartedly agree with that. Building some kind of super-mapper is somehow undermining the whole point of coding for an obsolete game system, because if you want better graphics or sound, then choose a modern platform. I mean, shouldn't it be about the challenge to see what you could have done if you were a NES developer back in the day? What creative way you can come up with to deal with the limitations of this old architecture? Perhaps even design a good game while you're at it?

Designing a good game is the hardest part of all, and no extra RAM or super mapper will help you much with that if your idea sucks. People underestimate how much work went into the design of those classic games, thinking they can surpass those efforts with additional hardware.

by on (#44707)
But most people aren't looking for a super mapper, they are looking for something around MMC3 level. While I haven't yet seen a homebrew that actually needs something that big I am sure a few people are working on games that do. SMB shows a good game can be basic hardware, but SMB3 shows a good game can be more advanced hardware too.

by on (#44805)
Bunnyboy, since MMC3 and FME7 mappers have been created for the PowerPAK FPGA, does that help you in being able to eventually make a reproduction board of MMC3 with a CPLD or some other device? It's pretty cool that the MMC1 board is available, but I've wondered why MMC3 hasn't followed, is there some technical limitation in the way?

by on (#44811)
Perhaps because it can't fit onto the same CPLD he's got stocked, MMC3 takes a little over 80 macrocells (need XC95108), MMC1 is just shy of 30 (need XC9536). It could also be because a true, non-hacked IRQ counter hasn't been worked out, MMC3 is still buggy on the PowerPak for me :?

by on (#44822)
Would an MMC3 without CHR bank switching fit?

Take the MMC3, and fix its CHR banks to values that span 8 KiB (0, 2, 4, 5, 6, and 7). For example, a CHR RAM game such as MM4, MM6, or FF3 might use them this way. That frees up 48 flip-flops: 46 for the CHR bank registers and 2 for bits 2-1 of $8000. Now how many macrocells are left? Is it one macrocell for each flip-flop?

by on (#44827)
MottZilla wrote:
It's pretty cool that the MMC1 board is available, but I've wondered why MMC3 hasn't followed, is there some technical limitation in the way?


I think that he CAN make MMC3 boards, but doesn't advertise this as nobody has wanted/needed one and that the cost is much higher. Like $40 for parts?

by on (#44834)
tepples wrote:
Would an MMC3 without CHR bank switching fit?

Not likely into a XC9536:

-5 config/index bits
-6 & 6 PRG bits
-1 mirroring, 1 SRAM enable bit
-8 IRQ reload, 8 IRQ counter, 1 IRQ enable flag, 1 IRQ flag bits
------------
37 bits and it doesn't account for the line detection logic which itself is a small counter.

A scaled down MMC3 would certainly fit in a XC9572 which I'd guess is used for the PowerPak Lite. Perhaps a '72 is also used on the MMC1 "repro" board.

Quote:
Is it one macrocell for each flip-flop?

For the most part, sometimes there are a few macrocells of interconnect overhead as well.

Sivak wrote:
I think that he CAN make MMC3 boards, but doesn't advertise this as nobody has wanted/needed one and that the cost is much higher. Like $40 for parts?

Just $1-2 higher for a larger CPLD.