What's the MOST advanced mapper out there?

I know about the MMC5 and VRC7; those were used in licensed games for some region or other. But what about the unlicensed/pirate/homebrew mappers?

The MMC5 is by far the most advanced, nothing comes near it. Pirate mappers aren't particularly advanced, more often than not they're just common mappers such as the MMC3 wrapped by a simple mapper to allow the use of more memory.

I think the VRC7 is pretty mundane, as things go. It's basically a VRC4 plus a customized YM2413.

Approximately in order of decreasing complexity, I think the most complex mappers are:
* MMC5. (8x8 attributes, expansion audio, 3rd nametable, hardware multiplier, 4bkg+8spr CHR banks, 1MB CHR support)
* Mappers 209/211 ("JY Company") (hardware multiplier, ROM nametables, 4bkg+4spr+4nt CHR banks, 2MB CHR support)
* Namco 163 (expansion audio, ROM nametables, 4bkg+4spr+4nt CHR banks)
* VRC6 (in the modern form we've discovered that the hardware supports, instead of the lesser subset that the games used) (expansion audio, ROM nametables)

See also my list: nesdevwiki:User:Lidnariq/MMC3 Variants


Remember that pirates were usually not making their own software, and making custom silicon requires a relatively large up-front cost before you get anything you can use.

Except for companies like Hummer Team that did their own ports of 16-bit software to the Famicom.

If we're talking homebrew mappers, it's obscure but there is my Squeedo board. It's not really a mapper, as much as it is a coprocessor mapped into memory. It uses a PIC18F4525 (or any the various pin-compatible 8-bit PICs). At 40Mhz, 4 clock cycles per instruction, and 8x8 multiply instruction, it's fairly capable. I had it generating 4 channels of audio, handling PPU-based and CPU-cycle based IRQs, parallel communication with the NES, and serial communication over RS232, all at the same time. Unfortunately, I took an extended break from NESdev stuff instead of finishing the project, but I still have the parts and occasionally I'm tempted to build a small batch for whoever is crazy enough to use it. It was used in one released product, MIDINES by wayfar labs, where it was all his own code in the PIC.

I wouldn't really expect it to be emulated, but for other reasons, kevtris actually made a PIC18F FPGA core, so it maybe it could happen.

In a related question, what additional circuitry in the NES would have rendered mappers virtually unnecessary? It's easy to say that if all the MMC5 circuits were in the NES, that would have taken care of everything. But, no games really took advantage of what MMC5 had to offer. It seems like a scanline interrupt and some generic banking logic may have changed everything.

You'd still need some sort of mapper to control the battery save circuit in the cartridge. Super NES games have little need for mappers, yet even games without a coprocessor still need a MAD-1 for battery RAM protection during power on and power off.

What stuff built into the NES would have made mappers unnecessary?
*Built-in scanline counter and interrupts
*Expanding built-in RAM to 8K instead of 2K
*More address lines and built-in bankswitching

More address lines would have needed either a bigger, more expensive cartridge connector (think Neo Geo AES) or lots of CHR RAM, which was expensive in 1983. The TurboGrafx-16 incorporates most of what Dwedit describes, but it came out years later after costs had decreased somewhat.

Tremendously large connectors is not necessarily needed: instead they could have multiplexed the bus between CPU and PPU, as done by the OneBus VT02/VT03. Multiplexing multiple logical busses over the same physical bus has contemporary examples: the C64 and Intellivision.

However, for the NES's pixel clock, it would have required faster ROMs, and I have no idea how much more expensive a 180ns ROM would have been in 1983.

Wouldn't this have eliminated the need for WRAM? Why didn't they just do this instead of mirroring the RAM 3 times? I know RAM was expensive, but they were able to put WRAM on games like Zelda without too much trouble.

Exactly. WRAM is considered part of the mapper, since there's a need for hardware in the cartridge to control it, and Dwedit's list is precisely about things that would have made mappers unnecessary.


Mirroring it 3 times is not something they actively did, it's just a side effect of mapping a 2KB memory chip to an 8KB address range. Anyway, surely the reason is that 2KB of RAM was significantly cheaper than 8KB.


Yes, but Zelda was released in cartridge form in August 1987, while the Famicom was first released in July 1983. Memory prices can drop a lot in 4 years.

Mostly. We'd probably end up with a lot more games that used password saves, though.
Remember the prices to look at are what were available 6-12 months before the Famicom first came out. A factor of 4 capacity increase is 4x (or more) as expensive.
Cite: http://www.jcmit.com/memoryprice.htm
In 1982, RAM was approximately $10k/MB, so the two 2 KiB SRAMs on the board were probably $20 each. Switching one to an 8 KiB SRAM would have been $60 more expensive.

There's not much to the NES—a few RAMs, a few digital ICs, an RF modulator, and two custom ICs. The PCB, 74xx ICs, and case are (even in 1982) probably not very expensive. Maybe $20 for all the random others? Probably $30 for each of the CPU and PPU.
It's a perfectly valid question to ask why they decoded the memory ranges the way they did—it would have been a lot more convenient if the memory map were shaped slightly more like the Master System. I have to assume they just divided the CPU and PPU into separate design teams and no-one ever really looked at the whole picture.

In a magical alternate universe, I'd have packed the entire NES internal memory map to just a 4 KiB region from $0000-$0FFF, with all the CPU and APU registers mapped in zero page from $0000 to $001F, and RAM decoded from $0020 through $0FFF (where $0820-$0FFF is a mirror). And it'd provide a chip select for the remaining 60 KiB to the cartridge.

And that's why we have the JY Company ASIC (2nd most complex of all time).

Do the Wide Boy and RetroVision count as a mapper? They have a whole separate system-on-chip, including an 8080-derived CPU, a PPU capable of producing a 2-bit grayscale, 160x144 pixel scene, and a frame buffer for interfacing with the NES PPU.

I don't agree - for the Famicom, certainly the cartridge connector would have had to be different, but on the NES, the 12 more-or-less unused expansion port pins could have gone towards six extra address lines per CHR/PRG side. The additional on-board RAM would have been more expensive than having bankswitching hardware and a simple counter for a line interrupt.

This isnt really related to mappers in the sense that it can't be changed, but how much more would it have cost them to make the PPU able to display more sprites on a scanline?

I've read a few theories about this in the past, but I'm not a hardware guy so I can't say anything for sure. I know that memory had a huge impact on cost back then, and more sprites would also mean more memory needed to hold the sprite patterns for the scanline, which could have affected cost, even if they were able to tweak the sprite evaluation logic and pattern fetching to handle more sprites while still fitting in the available time.

I guess these "what if" discussions are kinda pointless though, the system is what it is and there's not much that can be done now to improve the console that doesn't involve very intrusive hardware modifications. Programmers who want to make games for retro hardware nowadays have a lot of different machines to choose from, each with their own strengths and weaknesses, and they should pick the machine that matches the visions of the games they want to make. Picking a lesser platform just to have to battle its limitations trying to implement something beyond its capabilities is hardly the sensible choice.