nesdev.com

Thanks for the explanation.

I also see that MMC3 has switching CHR banks of 1KB, while MMC1 4KB. I have not tried the MMC3 yet, so occasionally I will ask if the MMC3 needs to be specially initiated at the beginning of the code? I am talking about switching on a method similar to UNROM.

MMC3 init is 28 bytes and needs to be somewhere in $E000-$FFFF.

Last I checked, the biggest advantage of MMC1 (or the similarly capable Action 53 mapper) over MMC3 was that MMC3 needed a more expensive CPLD. Is this still the case?

Well, in my current codebase, after I finish to init the nes, I init my banks because I want to access specific data but except for that, the last bank it set at $E000 and second last bank at $C000 (default setting, it could be at $8000 if you set differently).

As for chr, if I was stuck at 4k switch, that would be a pain ^^;;; I use 2k/2k for BG and 1k/1k/1k/1k for sprites but the opposite is possible too.

Tepples mentioned the price but unless you plan to mass produce it and have some kind of super hit or something.. Don't worry about that Most of the time people now run with an emulator and with those flash cartridge, compare to 10+ years ago, the need to make carts is different. But it always depends what is your goal. In my case, I prefer a mapper that offer more flexibility than price since I'm not expecting cart release anyway.

Is it correct?




I want to change the unrom and use a mapper that has WRAM and mirroring control. And the most important thing is to be able to use 512KB PRG (when needed).

Mapper 2 (UxROM) can be extended to 512KB without problems, and WRAM can be added to any cartridge regardless of the mapper. May I ask why you need mirroring control?

I believe that even with the classic iNES header you can specify a mapper 2 ROM with 512KB of PRG-ROM, WRAM and 4-screen. In some cases, 4-screen eliminates the need for configurable mirroring, and it's extremely simple to implement on hardware if you're already using CHR-RAM.

To control the direction of screen scrolling (H/V).
Unrom equires a soldering iron to switch mirroring.

I am currently using UNROM-512. However, I have a project in which I use WRAM, and needs mirroring control.

Somewhere is a diagram on how to connect WRAM to unrom? (If it requires adding something more than the wram itself.)

Although I would rather use a mapper, which is commercial and generally available so that if necessary you do not have to combine too much to write the game on the card. (example: MMC1 when PRG up to 256, MMC3 when 512).

The reason I'm asking is because there's no rule saying that you have to use a particular type of mirroring to achieve a particular type of scrolling... After all, there are games using 2 name tables that scroll in 8 directions just fine without ever changing the mirroring. You may need to use a few tricks to make 8-way scrolling 100% glitch-free, but it's possible.

I also mentioned 4-screen as an alternative to mirroring control. With 4 screens, you can have glitchless scrolling in any direction without tricks, and it's incredibly simple to add to a CHR-RAM cartridge: use a 16KB or 32KB CHR-RAM chip (which are way easier to find than 8KB anyway) and solder a wire to tell the NES not to use its internal RAM for name tables. It's a permanent setting, and the same chip will be used for pattern tables and name tables (4 of them).


You do need a chip to handle the logic of when to enable the WRAM chip. The wiki has a page about this: https://wiki.nesdev.com/w/index.php/PRG_RAM_circuit


The MMC3 is a very nice mapper overall, but it may increase manufacturing costs unnecessarily if you you're not using some of its more advanced features, such as the fine CHR switching or scanline IRQs.

The features you don't use don't increase manufacturing costs, though. If you don't need the IRQ you wouldn't need to accomodate it in the CPLD. If you don't need all the bankswitching register they can be omitted. Etc.

I think some subsets of MMC3 are actually really sensible to build.

Yeah, it's worth remembering that if you just need an UNROM-like subset of MMC3 ... it will only be roughly as expensive as INL's SNROM repro cart, and the programmer's interface will be nicer.

The same is true for every mapper: choosing a subset of an existing mapper makes development easier, and hardware cheaper.

Yeah, if whoever is manufacturing carts for you can customize the mapper yo remove unused features and bring costs down, that's great.