nesdev.com

Usually, homebrewers use NROM first, and then jump to MMC1 or MMC3, or perhaps UxROM, when they need more ROM space.

But I was thinking about the SMB/Duck Hunt cart, and it uses a very simple switch all $8000 PRG and/or switch all $2000 CHR register.

But very few (10?) games used the mapper 66 GxROM. Apparently Color Dreams / Wisdom tree used a very similar mapper (11).

And both mappers (11,66) are offered by Infinite NES lives.

So, my dumb question is, why not use it? It's simple as can be.

_________________
nesdoug.com -- blog/tutorial on programming for the NES

I'm inclined to agree with you.

I think I could argue that na_th_an also agrees, because he made a GNROM-with-MMC3 IRQ board.

There's a whole bunch of pretty sensible discrete logic mappers. If you're asking why more people aren't using them, I'd actually say that the reason might just be that there's more discrete mappers than homebrew that needs them.

Another reason is that a lot of these mappers don't use all the bits in their registers, and often have pretty low ROM size limitations. Stuff like AxROM / BNROM / UxROM where there's a single register and all the bits go to one place are easier to extend to larger ROM sizes. When the register contents are more mixed, it gets less straightforward, and with all of these you tend to run into emulators that only implement as many bits as actually were used on extant games.

Also having to bank the whole CHR-ROM at once is a bit limiting for its purpose, you need to either have things very well separated, or otherwise a lot of redundancy wasting ROM space. Having a few blank frames to unpack CHR-RAM is sort of a wash compared to that, espceially if SRAM isn't particularly expensive compared to EPROM.

I think that when homebrewing first became a thing and people needed to test their programs on hardware, they had to resort to cannibalizing existing cartridges. You can't cannibalize SMB+DH easily, since most copies use glop tops, so other common cartridges with simple mappers were better choices for going beyond NROM.

Similarly, there are many advanced mappers with features superior to those of the MMC3 (more versatile IRQs, finer CHR switching, more PRG windows, etc.), such as the Bandai mapper that's exclusive to Japan, but people still often go for the MMC3 when they need raster effects and fine CHR switching, probably because of availability.

It turns out that earlier CNROM boards—NES-CN-ROM-256-01 through -05—can be trivially modified to become MHROM. (Like the famicom version of the cart, CPU D4 still goes to the '161, and the latched copy goes to the hole marked for D2)

But that doesn't mean people knew it was an option.

There's also the fact that most people tend to not to change the purpose of things. If they're looking for examples of bankswitching for a game, they're gonna look at what's been used in games, they're not gonna look at what multicarts do.

It's a good question, the fact that lots of other people moved from NROM to UxROM in the past has a lot to do with it. People simply following in the same path as people before them.

While cost is very comparable if not equal, CHR-RAM is generally be more versatile than CHR-ROM. Additionally there seems to be a preference towards UxROM over BNROM because of UxROM's fixed 16KB PRG-ROM bank. There hasn't been much for discrete mappers with 16KB PRG-ROM banks, and CHR-ROM. Is there even a discrete mapper out there with 16KB PRG-ROM banking and CHR-ROM?

Based on some arguments here I've come to believe 32KB PRG-ROM banking is more versatile than 16KB, but seems like most don't agree or fully understand what to do in order to take advantage of 32KB banking.

People may also not realize how easily mapper 11 can be extended to 512KB PRG-ROM. While homebrews have been utilizing 512KB UxROM for years. My discrete mapper boards support 512KB PRG-ROM & 128KB CHR-ROM mapper 11, but I don't have them listed for sale and rarely get requests for them.

I am aware of a few recent projects that are utilizing mapper 11, it's especially handy when creating multicarts of simple NROM games.

EDIT: All told I think my personal discrete mapper of choice would be 128-512KB BNROM, but 32KB of banked CHR-RAM. It's a single chip mapper and still has 2 register bits available for other potential features including single screen mirroring (would be better defined as AxROM). Toss a tiny cheap little 74LVC1G97 multifunction gate on the board and you could have software selectable H/V mirroring or 4-screen mirroring. But once you get into non-standard mapper design it can cause more obstacles to development than it's worth..

_________________
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers

Seven.

That's a nifty table! Didn't realize it existed.

_________________
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers

As someone around during that time period: this is correct. NROM, MMC1, specific models of UxROM, CNROM, and (to a lesser degree) MMC3 were the most prevalent cartridges you could find en masse (read: cheap and common). Switching to smaller font for some early nesdev and emulation history:

And in the early days, MMC3 wasn't even a viable choice -- nobody had figured it out reliably yet, especially the IRQ functionality (the nuances of which documented in the Wiki should act as proof). I know this factually because MMC3 + battery-backed SRAM was the dev cart type I wanted from near the very beginning (and nobody had written a sane/clear document on how to rewire MMC3 to use EPROMs. I will never forget how many people told me "it's not hard, just wire the pinouts accordingly" (this was horseshit then and still is -- it's more complicated than that)); I actually bought several Crystalis NES cartridges for this very purpose. There were always the "special snowflakes" who wanted MMC2 details (for emulating Punch-Out!! reliably) and then later, MMC5 (which is still a major sore spot to this day).

Most of the early homebrew efforts did not involve extensive hardware folks (e.g. kevtris), they involved dumping carts and disassembling ROMs and making some educated guesses, solely for the purpose of achieving emulation. Alex Krasivsky (Landy) and Marat Fayzullin (RST38h) were two of the original pioneers. Kevin's efforts (particularly his mapper document) revolutionised things because for the first time we had an actual (and excellent quality) HW person, who also knew 6502, doing excellent analysis. There were other people doing these types of efforts at the time (especially for Famicom-centric mappers like Konami's VRC2 and VRC4) -- guys like Goroh, and then later, Firebug -- but it wasn't until much later that this information arrived in a digestible form.

There was little if any communication between all the folks doing the RE work, so everyone seemed to be working independently -- this was one of several reasons why my nestech.txt never contained mapper details (I intentionally didn't include such, because information was coming from several conflicting sources).

In later days, some random tidbits of mapper details started trickling out of Japan (US/EU folks were operating independently of JP; neither had any idea the other were doing the same stuff at the same time for unrelated reasons, but language barrier was a big one).

Not to brag or toot my own horn, but this was why nestech.txt was "revolutionary" -- I became a sort of de-facto guy who tried to organise all the (non-mapper) information into a centralised document that was easy for both emulator authors and homebrewers to use. The only other thing at the time (early and mid-days) was Marat Fayzullin's NES.DOC. All the super precise details of the system didn't come until way later, long after the early emulation heyday.

Furthermore, re: mapper 11, nobody in the early days had gone to great lengths to reverse-engineer Color Dreams' stuff. The more "obscure" games' mappers came much later, as the cartridges weren't as prevalent (read: more rare, thus worth more).

NES emulation was what drove about ~80-85% of this effort, not homebrew. Everyone had different hobbies/interests -- I happened to fall into both categories -- but the NES homebrew scene did not really come to fruition until maybe the middle of NESticle's lifetime. Small font again:

In contrast, the SNES homebrew scene in the early 90s was significantly different because emulation wasn't on anyone's radar -- nobody was even considering it back then (systems were too slow, and nobody really cared, to be honest). All people wanted then was CPU documentation (tons of it available thanks to the Apple IIGS), MMIO register documentation (early days were a single document by some Amiga dudes named Dax & Corsair, later stuff was my SNES documentation, and then within a couple years people started getting their hands on official SNES documentation from leaked sources, but several revisions all mixed together, so it was even more chaotic to follow than what's out there now), and SPC documentation (official docs had this but it's sub-par, and I didn't do sound stuff (I still don't), so SPC homebrew stuff was done by mainly the elite), and console copiers (for homebrew and playing games).

1.copy some bank switch code into the RAM
2.jump there to switch banks, then jsr to a entrance code part of the bank, which reads the game state and uses a jump table to get to the appropriate subroutine
3.have a reset code in every PRG bank which can return you to the main bank, if the user presses reset.

The advantage of 32k PRG banks would be to have a contiguous code block or data block that doesn't need to be split awkwardly.
Music code and data might benefit from having its own 32k block.

The disadvantage would be, DMC samples might have to be copied in more than 1 bank, wasting space.
And, CHR banks are less efficient, if you have the same graphics partially copied in multiple 8k CHR banks.

I suppose, you lose mirroring changes, without the MMC. And no scanline counter.

EDIT - every bank needs an NMI handler too, which does not bode well for "all in the NMI" style programs

_________________
nesdoug.com -- blog/tutorial on programming for the NES

Remember that test ROM you commissioned from me, called Holy Mapperel? Remember what it used to be called?

Holy Diver and Uchuusen Cosmo Carrier, which differ in whether the mirroring control bit controls H/V or 0/1.


Agreed. It's just that by the time you're past 128 KiB PRG ROM, you need something with slightly more finer grained CHR banking than 8 KiB.


Which is within your definition of oversize mapper 11. But 8K banking has its limits unless you're just doing one bank for playfield and one for status bar.

Yes simple as it sounds I think it's what some people see an an avoidable hurdle by sticking with UxROM they're already familiar with. But I've also heard these folk complain about how precious their limited 16KB fixed bank is...

This is arguably a bigger problem on traditional UxROM as samples must take up precious fixed bank space $C000-FFFF.


There's always software select-able mirroring with mapper 78 (which could be extended to most discrete mappers), and DMC IRQ abUSE.

_________________
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers

Well, I used mapper 11 for Attribute Zone. (Note that, depending on the program, whether the CHR bankswitching is the high bits or low bits it might be better one way or other, although you can easily work with either one in either way anyways, by adding a few extra instructions.)

_________________
.

Speaking entirely for myself, the choice of going with MMC3 is pretty basic.
It's a very versatile mapper with the incredibly useful added functionality of a scanline counter, and it is one of the most common mappers out there. And with that I'm not talking about cannibalizing other cartridges, but simply that I think it's extremely representative of what the NES had to offer during my favourite years of its life time. There are tons of uncommon mappers from unlicensed games etc. that do other interesting things such as using all four nametables, etc. but personally I feel like that's doing something too different from what I am actually interested in.