nesdev.org

(You meant 1-screen, not 4-screen)

rainwarrior wrote:MMC1 isn't the most straightforward to use

For me it's the serial interface that kills it.

MMC1 - PRG banking, CHR banking, PRG RAM, H/V software controlled mirroring.

The CHR banking is not particularly useful though, since the smallest bank size is 4KB. You can mix and match background tile sets and sprite sets, but doing animations (one of the biggest advantages of CHR-ROM) would result in a monumental amount of repeated tiles. CHR-RAM is way more versatile than this.

FrankWDoom wrote:MMC1 also does 4 screen mirroring, which MMC3 doesn't.

Every mapper can do 4-screen mirroring, you just have to put the memory in the cartridge and bypass the mapper mirroring. Also, if the MMC3 is connected differently, you can halve the amount of accessible CHR-ROM (to the same 128KB of the MMC1) and have complete control over mirroring (horizontal, vertical, diagonal, 1-screen...).

tokumaru wrote:Every mapper can do 4-screen mirroring

This is sort of true. The iNES format lets you specify 4-screen mirroring in the header, which should in theory allow 4-screen mirroring with most mappers. In practice, though I think emulator support for that is a bit spotty (mostly because very few games used it). YMMV; depends where you want your game to be run.

Bootgod's page lists 3 games as having 4-screen mirroring. Gauntlet (mapper 206), Rad Racter II (MMC3), and Napoleon Senki (mapper 77)

lidnariq wrote:(You meant 1-screen, not 4-screen)

I did mean 1 screen, thanks

FrankWDoom wrote:I did mean 1 screen, thanks

OK, but the MMC3 can also do 1-screen mirroring if you wire it as in mapper 118.

The MMC-1 can bankswitch in 32KB chunks if for some reason you wanted or needed that. MMC-3 cannot.

I think the MMC1 is a reasonable setup but like tokumaru said the serial interface is annoying. However you could make a MMC-1 variant that actually eliminates the serial interface so that only 1 write is needed per register which would make it so much easier and faster to work with. It would actually be faster than MMC-3 which requires more effort than a single write as well.

MottZilla wrote:you could make a MMC-1 variant that actually eliminates the serial interface so that only 1 write is needed per register

Yeah, but you're asking to implement a whole new mapper just to save like 10 lines of uncomplicated code? Sure, the serial interface is an unpleasant compromise with the hardware makers of the time, but it does the job just fine in hundreds of games, and it's already supported by every NES emulator.

If decompressing data in one bank relies on a lookup table in another bank, that's a lot more practical in UNROM than in MMC1 unless you can A. somehow fit a copy of the lookup table in RAM, or B. store the half-decompressed data in RAM, switch, and make a second pass over that data. An example is an e-book reader where the list of unique words is in one bank and the actual text is stored as word numbers in another.

For the most part, games usually only use one memory layout (i.e. they usually don't switch from UNROM-like banking to BNROM-like banking, or from MMC1/VRC1 CHR banking to CNROM-like banking)

(Exception: Because of MMC3's non-uniform CHR banking, games may well swap between "more banks for sprites" and "more banks for background")

MMC1 basically provides three independent features:
* PRG banking: UNROM or BNROM or m180
* PRG RAM decoding and protection
* Choice of
*- CHR banking: Sunsoft1=VRC1=NINA-001/CNROM or
*- PRG RAM banking: window of 8 KiB, up to 32 KiB total

All of these feature exists on multiple other boards, although not all in all combinations.

tepples wrote:If decompressing data in one bank relies on a lookup table in another bank, that's a lot more practical in UNROM than in MMC1 unless you can A. somehow fit a copy of the lookup table in RAM, or B. store the half-decompressed data in RAM, switch, and make a second pass over that data. An example is an e-book reader where the list of unique words is in one bank and the actual text is stored as word numbers in another.

Another possibility in this case is if the compressed data is in CHR ROM but the lookup table is in PRG ROM; however this has its own disadvantages such as cannot be used during rendering, and cannot be used as easily if it doesn't do both PRG and CHR bankswitching. However, it has the advantages that it can be used even if the mapper does not bank multiple PRG ROM banks in at once, and that address increment is automatically done for you. This seems simple enough with MMC1 (hopefully). But it might not be what you require.