NES extra cartridge ROM instead of RAM?

I'm sorry if this has been answered before, but I looked and couldn't find it. Could it be possible for an NES cartridge to use extra ROM instead of RAM at address space $6000-$7FFF to make a larger game without bank switching as much? is there any circuitry in the NES that can 'detect' whether an address is ROM or RAM and change how it's treated? (That doesn't seem likely.) If this is possible, are there any games that do it?

It's possible but bankswitching offers more memory so everyone does that instead.

See: https://wiki.nesdev.com/w/index.php/NROM-368

The proposal was NROM-368, using a comparator to decode PRG ROM at $4800-$7FFF. But I don't remember ever seeing a report of a successful hardware build in the topic where NROM-368 was proposed. As pubby pointed out, NROM-368 probably failed to catch on because the only thing it offered over bank switching was ability to address limits of the memory model of the cc65 C compiler.


No. All CPU reads and writes go to the cartridge. This is how MMC5, for example, can snoop on CPU's writes to PPU ports $2000 and $2001 to determine when to change the MMC5's own mode.

Yes. ROM and RAM are more or less interchangeable. Anywhere you could put one, you can put the other.

Pubby linked that NROM-368 idea. Nobody ever used it, though, this was just people openly speculating that you could.

The FME-7 mapper could switch between a page of ROM or RAM at $6000. That's really the only one I can think of that actually did put ROM down there.

The Famicom Disk System actually did a weird thing where it put an 8k BIOS at $E000, and then 32k of RAM at $6000, turning it into an NROM-sized RAM that you could load and reload from disk.


There's a reason it isn't done, though. As pubby suggested, bankswitching is more versatile. It's also easier to build. Every bit you need to disambiguate takes more logic hardware...

Dividing the 64k memory space into two 32k halves only takes 1 bit of address to tell the ROM which half it's in (i.e. whether to activate the ROM for this read, or not). That's plain NROM.

Dividing it into 16k pieces takes 2 bits of address to tell which quarter something is in.

For the NROM-368 idea, it gets progressively more difficult to add smaller and smaller pieces of memory:

• Getting down to $6000 takes 3 bits.
• $5000 takes 4.
• $4800 takes 5.
• $4400 takes 6.
• $4200 takes 7.
• $4100 takes 8.
• $4080 takes 9.
• $4040 takes 10.
• $4020 takes 11.

$4010 would collide with the audio registers, so we have to stop there.

With all the logic it takes to disambiguate where to put the ROM, though, you could have spent an equivalent amount of logic and just got bankswitching instead, giving you much more space for the same complexity. BxROM gives you 512k for a single 74161 4-bit latch. I think for roughly equivalent price/parts you can probably get 40k of extended NROM at $6000? Would you rather pay the same price for a flat 40k or a switched 512k?

NROM-368 was what fell out of my brain when Shiru asked the exact same question that gravelstudios did.

In practice, logistics of PCB design have much more to do with what preexisting parts are available than number of bits; the single 74'85 used by NROM-368, 5 bits, is comparable in cost to the single 74'161 used by BNROM or GNROM, 4 bits. Routing difficulty is basically identical, too: it's really wrong to say that it's "harder" than bankswitching hardware.

Because you have to compare real costs, not hypothetical bits, it's more correct to compare 128KiB BNROM or 128+32KiB GNROM to the 46KiB in NROM-368.

Yes, I was oversimplifying... Bits are not created equal and of course there's ROM cost etc. I just wanted to give a rough / simple insight as to why it's a much better trade to just bankswitch. Your more accurate comparison is welcome.

Mapper 055 sort-of implements the idea of unbanked PRG-ROM >32 KiB, though it only adds a few more KiBs instead of the whole 14 KiB as NROM-368.

In my case, I would love to bankswitch both of them to have access to extra data at the same time, to simplify some data access. The extra bank at $6000, even coming from another rom would be useful in many case. Not sure how it would be done though (mm3 for normal prg-rom and something else for this specific chip, hmm).

If you want bankswitching and ROM at $6000, look at FME-7.

oh, I see. I knew that this mapper was able to do more but wasn't aware it was at that location. I will look at it to learn more about this mapper then. Still, since it's a very uncommon mapper to get (?), I guess a clone of it would be necessary to use in that case.

While FME-7 and/or Sunsoft 5 ICs aren't exactly common, INL already has a CPLD-based FME-7 clone.

I just finished to check the wiki and it seems like an interesting mapper, I like it. The first thing I would have done is check if INL made one clone and you already answered it before I asked some questions about it

I don't want to derail that thread too much even though it's a nesdev "tradition" (^^;;) and may ask more details in another one but the only thing different from mmc3 is the counter is CPU based compared to scanline based. Since I mostly used the mmc3, I don't know yet what are the advantage of such counter (more precise than scanline, I guess?).

We really ought to have an article about that on the wiki... I don't think we do, though.

The two biggest things are:
+ Cycle-based IRQs work even when the PPU is off.
- As implemented in the NES, most cycle-based IRQs are subject to "creep" or "drift", where the 6502's NMI/IRQ entry adds a random offset to each subsequent IRQ.
(For example, if the NMI were asserted at cycle 0, the first instruction in the NMI could happen anywhere from 7 to 15 cycles later, depending on where in and what instruction the NMI interrupted. Say after 20 cycles it then starts an IRQ for 5000 cycles later. The IRQ will be asserted somewhere around cycle 5020 to 5035, but for the same reason it could take somewhere between 7 and 15 cycles before the first instruction of the IRQ executes: at cycle 5027 to 5050. If that IRQ then schedules another IRQ, it keeps on adding up.)
-+ Some cycle-based IRQs won't drift if the period isn't changed, such as the VRC4/6/7 or SS88006.

FME-7 IRQ can be made not to drift if subsequent IRQs in a frame have a period of a multiple of 256 cycles. That's one thing that was hammered out in this topic.

Another annoyance with FME-7 IRQ compared to that of MMC3 is that the IRQ has to restore the value in the select register even if it does not bankswitch, as you need to write to register $D to acknowledge the IRQ.