Expansion ROM what is it? ($4020..$5FFF)

I've seen that the memory region $4020..$5FFF is labeled as Expansion ROM.
But haven't seen any description of what expansion ROM is.
Searching for "expansion" won't yield significant results in the wiki or in this forum. (other than referring to expansion audio or expansion port)
The iNES header does not specify presence or absence of such ROM.

So what is it? is it mapper-specific?
Is it a general-purpose ROM that can be supplied in the cart?
How do you know if a cart has expansion ROM?

Where have you seen this terminology?

That region can be used by various mappers in different ways, but it's not necessarily ROM. With most mappers it's nothing. With some mappers, it may be ROM, RAM, or control registers.

This might help: http://wiki.nesdev.com/w/index.php/CPU_memory_map

With the exception of the NROM-368 proposal, no mapper has ever put ROM in that region. And only the MMC5 has put RAM in a portion of it.

In two different docs both named NES documentation by Patrick Diskin and Jeremy Chadwick

Yes I had seen that, but it just labels $4020..$FFFF as Cartridge space: PRG ROM, PRG RAM, and mapper registers not specifying exactly what's below $6000.

So except for NROM-368 and MMC5 my emu could just ignore this memory area completely and get away with it?

Mmm, I didn't say that no mapper put nothing there.
A bunch of mappers put registers there, q.v. nesdevwiki:Category:Mappers using $4020-$5FFF

Oh, that link explains it better!

By the way, I'm only testing mapper 0 games, and Brush Roller tries to write a 0 to $4800, is this right?
Many other games do work, and the CPU passed the Kevtris test so I'm pretty sure it does not mess addresses up.

Hard to know. Without access to the physical hardware, we can't tell if it was supposed to do anything, and even if it didn't in the released cartridge, without talking to the developer it's hard to know what it ever was supposed to do.

The only thing we can say is that the game seems to work fine without doing anything in response.

There are other possible reasons that a program writes to addresses that there is nothing mapped into:

• For debugging purposes; a debugger might be programmed to breakpoint on writes to those addresses (some unofficial opcodes might also be used for debugging purposes in some games)
• For timing purposes; using up an exact number of bytes and an exact number of cycles
• Compatibility with another mapper the game is also designed to work on
• Use with specialized kinds of Famiclone hardware or specialized kinds of emulators
• To support later patching
• As an explicit side-effect of some other code (for example the music engine (but not the NSF) in Attribute Zone will write something both to $00,X and to $4000,X and expect unmapped addresses to do nothing)

What exactly is mapped to actually the entire address space (except the APU registers possibly???) is done by the cartridge, although some things are internally mapped ($0000-$3FFF) and if the cartridge maps stuff there it cannot override the internal mapping.

For example, some believe (I don't know whether or not it is true) that MMC5 maps a write-only register over some of the PPU registers in order to determine how tall the sprites are. Famizork also mirrors mapper registers at $1xxx and $3xxx (as well as $5xxx and $7xxx), not only because this simplifies the hardware, but also to speed up bankswitching.

Occasionally you get strange memory accesses due to a bug in the software, like Low G Man which accidentally ended up relying on the open bus behaviour from out of bounds reads.

Adventures of Lolo has a bunch of leftover FDS audio register writes in its sound initialization code: