Mode 20 vs. Mode 21 (aka LoROM vs. HiROM)

As I understand it, the difference between LoROM and HiROM memory models on the Super NES is roughly analogous to the difference between UNROM and BNROM on the NES: same capability, slightly different memory addressing scheme. Someone recently held a Super NES video game development competition, and some of the entries were LoROM and others were HiROM. Is there a noticeable advantage to one memory model over the other?

32kb banks versus 64kb banks. You can fit more data into a bank before having to use the next bank which might be nice depending on what you are doing. I don't think there is any other particular advantage.

LoROM lets you use 2-byte pointers to refer to registers while HiROM sometimes requires 3-byte pointers, so the former will be 1cy faster. This is probably insignificant because for anything where that might matter you should be using DMA.

Isn't the main difference that the clock speed used to access both is different? (used by Nintendo to allow starting with cheaper slower ROMs and then go with faster ones once they price dropped later in the SNES lifetime) Or am I getting confused with something else?

I think you're confusing with SlowROM and FastROM, which is unrelated.

In summary, SNES games can be :
- LowROM SlowROM
- LowROM FastROM
- HiROM SlowROM
- HiROM FastROM
- Special (DSP-1, SuperFX, etc....)

Doesn't HiROM allows for larger overall ROMs than LoROM ? Since banks are 2x wider, we could fit a ROM twice as big for a constant # of banks where ROM is mapped in. I was under this impression but I might have been wrong.

That's SlowROM and FastROM difference.

As always, I try and discourage using these terms as much as possible. Along with the special rules for S-DD1 / >4MB games, you end up with terms like "ExHiROM" and "ExLoROM" if you choose to go that route. Better to just describe the actual behavior, it's not that complex.

Actual mapping is a lot more complicated. There are hundreds of variations to where ROM/RAM appears on the bus and how it is mirrored. Since this board is primarily about making reproduction carts, that's a somewhat important detail.

For one example, Ys 3 mirrors RAM to $70-7f:0000-ffff, but Fire Emblem Thracia 776 maps RAM to $70-7f:0000-7fff, and ROM to $70-7f:8000-ffff. Both games will break if you reverse that. Yet both are considered to be LoROM.

Many games map ROM to both $00-3f,80-bf:8000-ffff and $c0-ff,40-7f:0000-ffff. Some do not map $80-bf and/or $c0-ff at all (SuperFX games), some do not map $40-7f at all (actually, most don't. Tales of Phantasia and Dai Kaijuu Monogatari II put stuff there.)

There are also >2MB games that map the contents to $00-7f:8000-ffff and/or $80-ff:8000-ffff. So don't treat A22 as being significant here (eg don't presume $c0-ff is always a direct mapping of the ROM in 64K granularity.)

The way I like to frame this is the behavior of address pin 15, or A15.

"Linear" is where A15 is -omitted from- or -not connected- to the address given to the ROM chip. Each address possible to reference is a linear byte in the ROM. I say the ROM contents are addressed in "linear" fashion here.
Bus $008000 = ROM $000000
Bus $00ffff = ROM $007fff
Bus $018000 = ROM $008000

"Shadow" is where A15 is -connected- to the ROM address pins. Since the ROM is always in $xx:$8000-ffff on the bus here, it's always high. So in effect, you can't access the low 32KB of each 64KB bank from these regions, you have to access that data via $c0-ff or possibly $40-7f. I say that the data provided on the bus is a "shadow" of the linear regions in $c0-ff,40-7f.
Bus $008000 = ROM $008000
Bus $00ffff = ROM $00ffff
Bus $018000 = ROM $018000

Hope that helps.

So let me see if I have the coprocessor-less configurations straight:
LoROM: 32 KiB banks, PRG A15-A21 = CPU A16-A22
HiROM: 64 KiB banks, PRG A15-A21 = CPU A15-A21
47 Mbit: One 2 MiB LoROM at banks $00-$3F and one 4 MiB HiROM at banks $40-$7D

LoROM is called LoROM because it's intended to be accessed starting at $008000 and going up. HiROM likewise because it starts at $400000, which is higher than $008000. But if I were making up the terms, I would have called them "32K banks" and "64K banks".

As I understand it, just having read about it and not tried it, a HiROM game can use the 2-byte addresses to write to MMIO ports (PPU at $21xx and CPU at $43xx) as long as the code is running in the second half of a 64 KiB bank. This works because $40-$7D is mirrored down to $00-$3D. And given that in theory a properly abstracted program is going to be doing direct access to I/O registers in a very small part of the program, this shouldn't be too much of a constraint. The first half of each such bank can be used for big blocks of data.

I just asked which is "better" because for future compos, the organizer could specify whether entries should use LoROM or HiROM so as to avoid the problem that someone is having.

Wow. I just uncovered a new behavior I wasn't aware existed.

It appears to be reverse LoROM granularity. You can see it in SHVC-1A0N boards.

$c0:0000-7fff mirrors $c0:8000-ffff (ROM 0000-7fff)
$c1:0000-7fff mirrors $c1:8000-ffff (ROM 8000-ffff)

> As I understand it, just having read about it and not tried it, a HiROM game can use the 2-byte addresses to write to MMIO ports (PPU at $21xx and CPU at $43xx) as long as the code is running in the second half of a 64 KiB bank.

Again, it's not that simple. What you call LoROM can be mapped in 40-7f and c0-ff. And what you call HiROM -is- mapped in 00-3f and 80-bf. It has to be for the game to boot at all (reset vectors are forced to be at $00:ffc0-ffff)

I don't understand. Isn't that what I said? Or am I missing something even more subtle?

On this subject, I don't think Nintendo ever used the terms LoROM and HiROM. I think they just had mapping modes/models. LoROM/HiROM might have come from pirates that designed copiers.

If so, then "vertical mirroring" also came from the pirates, as Nintendo's NES discrete boards used "arrangement" nomenclature (H pad = horizontal arrangement of nametables = vertical mirroring). So did "mapper 4". Yet Virtual Console uses the pirates' format.

That said, are there clearer terms than "32K banks" and "64K banks"? Or any reason to prefer the use of one or the other for contributions to a multicart? It's not as simple as it is on the NES, where a typical homebrew game is expected to fit in a single 32K bank.

Isn't Nintendo used Mode 20 and Mode 21 terms instead than LoROM/HiROM in their docs? Not sure, though.

They call it "Map Mode". Mapping Modes that exist according to Nintendo:

Mode 20
Mode 21
Mode 22 (Reserved)
Mode 23 (SA-1)
Mode 25

I think that Mode 20 is what we refer to as LoRom and Mode 21 is what we call HiRom.

So, if I'm understanding it right, the SNES allowed cartridges to remap pretty much everything and each game had a completely custom configuration? WTH Nintendo? This starts looking worse than the situation with NES mappers.

I wonder if this was Nintendo's idea to thwarting copiers, since something like this would effectively make it impossible to hardwire a setting that would work with almost everything. Not like it stopped anybody from trying...

No. Nintendo had standards. And it's very clear that copiers did and still do exist. Developers couldn't just randomly map things where ever. Nintendo still made the cartridges.

I've come up with a much better explanation of this after spending some time on it.

There are two primary ways ROMs can be mapped on the bus:

Mode 0:


Mode 1:


The lefthand side reflects the native area, where ROM is mapped to linearly (each address is one byte further into the ROM.)
The righthand side is the "secondary" area.

Mode 0 never connects A15 to the ROM address lines. So the address is {A22-A16, A14-A0}
Mode 1 always connects A15 to the ROM address lines. So the address is {A21-A0}
By not connected, I mean the bits in the address are shifted right to compensate, so it's like A15 does not exist at all.

So in mode 0, the effect is that Bus 008000 = ROM 000000, Bus 018000 = ROM 080000, etc for the left-hand side. And Bus c00000 == Bus c08000 == Bus 008000, etc.

And in mode 1, the effect is that the left-hand side is linear: Bus c00000 = ROM 000000, Bus c08000 = ROM 008000. And the right-hand side has A15 always forced high because you can only access ROM in $xx:8000-ffff there. So Bus 008000 = ROM 008000, Bus 018000 = ROM 018000, etc.

Now of course, there are special case variations to this. Different PCBs will change where RAM is mirrored, some won't map anything into c0-ff:0000-7fff, some won't even map c0-ff at all (SuperFX), etc.

But we can narrow down LoROM vs HiROM to whether or not A15 is connected to the ROM pins. We don't need the complexity of "linear" and "shadow", or all that LoROM and HiROM entails. We simply need to provide where the ROM appears on the bus, and whether A15 is used or ignored. And that's enough to describe every commercial board ever released.

byuu, you're such a programmer

I kind of consider what has been said incomplete and overcomplicated; technically LoROM can straightforwardly map up to 63.5 Mbits.

Heres my explanation:

LoROM / Mode 20: 00-FF:8000-FFFF (except for the two RAM banks where /ROMSEL isn't asserted), mirrored into 0000-7FFF on many banks (40-7F, C0-FF) where /ROMSEL is asserted because of partial decoding via A15.

HiROM / Mode 21: 00-FF:0000-FFFF (the entire address space, except for the 33 Mbits where /ROMSEL isn't asserted), this has a consequence of mapping ROM into banks (00-3F, 80-BF) where 0000-7FFF is not accessible so it must be accessed at a mirrored location where it is or significant ROM is forfeited.

The vectors in HiROM games must be placed at FFF? in ROM, LoROM needs them at 7FF? like a NES game.

All other mapping is achieved through secondary address decoding (partial and/or full) and scheme mixing.

So semi-related n00b question: how does what cartridge you have in the cart slot remap/mirror the RAM that's inside the system?

It doesn't remap the RAM. Parts of the ROM that map to areas occupied by internal memory, such as banks $7E and $7F and the first half of banks $00-$3F and $80-$BF, are just made inaccessible by the address decoder.

Hrm, I'm not sure I quite understand. Forgive me if I'm being thick, but Byuu sez:



Is that just a typo - did Byuu mean "Different PCBs will change where ROM is mirrored?"

But then he also says:



Or maybe he's talking about on-cart SRAM?

Or is the SNES wired somehow so that "failed" reads/writes to the cartridge slot can/do loop around to RAM or something?

It seems like the CPU should just be blindly "asking" the cart for a particular address - asserting (if that's the right term) certain lines on the cartridge slot and waiting for a response back from the cartridge slot on the next clock tick or whatever. How could those responses come from internal RAM, depending on the cart design? Rather, I would think that the SNES' wiring, before the cartridge even comes into play, should forward read/writes to the cart slot or to RAM based on the particular address requested.

Yes, the same sort of RAM that's traditionally mapped to $6000-$7FFF on an NES. As I understand it, mode 21 games map this to $306000-$307FFF, $316000-317FFF, ..., $3F6000-$3F7FFF.


I think that's what the /CART signal between A23 and D4 is for: an enable for the PRG ROM.