$E000-$FFFF bank?

Does CPU $E000-$FFFF accept PRG bankswitching? In case of yes (game?), how'd be fetched the RESET/NMI vectors?

I assume if you have a mapper that supports bankswitching that section, it could work. (This guess is based on mapper 180's $C000-$FFFF bankswitching ability.)


This would depend on the mapper's startup state; in a real world situation, you'd probably include a common stub or something in each bank meant for $E000-$FFFF.

Keep in mind this is all speculation and guesses. Someone with better hardware knowledge than I can probably give you a more definitive answer.

BNROM, GNROM, and ANROM are all well-known discrete logic mappers that support banking $E000-$FFFF (albeit at the same time as the rest of $8000-$FFFF).

The 74'161 used by these discrete logic mappers is most likely to power up with all 0s, but the value is unchanged on reset. A debugging emulator should probably randomize the bank on powerup. An emulator trying to not tickle any bugs should probably cold boot into bank 0.

For mappers that support banking the upper 8KiB of CPU address space but are not based on the 74'161 (e.g. MMC1, MMC5, m97, 137, 138, 139, 141, 246) the behavior differs.

Cheetahmen II bankswitches the entire 8000-FFFF region, and a certain Nerd reports that the power up state may cause it to boot in later levels randomly.

Off the top of my head, these support 32K bank switching as one of their modes if not the only mode:
MMC1 (1)
ANROM (7)
Color Dreams (11)
BNROM (34.2)
NINA-001 (34.1)
GNROM (66)

Mappers made for multicarts can also switch $E000-$FFFF along with everything else:
100-in-1 Contra Function 16 (15)
Action 53 (28)
Nintendo World Championships (105)
Multicarts including Nintendo World Cup (37, 47)
Caltron 6-in-1 (41)
Action 52 (228)
Quattro (232)
Maxi 15 (234)

At all times, all three vectors depend on whatever values are currently at $FFFA-$FFFF. If a game uses a mapper that can bankswitch $FFFA-$FFFF (whether it's via 32k mapping, 16k mapping, etc) but does not contain any circuitry to initialize the bank to a known state on startup, it's common practice to put a reset-stub in all banks that will swap the correct starting bank in and jump to the intended reset code, and to put a valid reset vector at the end of each bank to point to this stub.

Also interesting to note: on powerup and reset, the NES automatically sets the I flag (interrupts disabled) and disables the vblank NMI, so if you use NMIs and can guarantee that the NMI will fire only in certain banks, you will only need to worry about the reset stub in all banks.

In contrast, and inconveniently, the Famicom doesn't.

If that's the case, this wiki page needs to be updated to reflect the differences in a very clear, user-friendly way (see this for an example of what I mean, re: wiki table use, for both systems, and what the behaviour is on reset vs. power-on). Folks should be sure to see Note #2 in that wiki page, BTW.

NMI generation is part of PPU state, not CPU state. Wiki: PPU power up state does mention that the Famicom does not reset the PPU at all, though it is a bit further down the page in the midst of other notes.

I don't know where it would be appropriate to mention the NMI flag in the Wiki: CPU power up state article, but maybe a better suggestion would be to merge both of the articles, since they're both short, and since the two operations are so directly related to each other they might as well be together?

Ahh, no need to change anything then. Thanks for pointing this out.

I think on power up it probably does, but when the reset button is pushed it only resets the CPU (and the state of the PPU (including NMI state) is not reset; this can be seen from the schematics). Therefore, what I have done is for my program to disable NMI first thing upon CPU reset, before doing anything else (and if the PPU did reset too, then it is presumably harmless because the PPU will ignore the setting and the NMI will already be disabled).

It does already say on the wiki:(So, it isn't only the RF Famicom that does this)

Wow, I forgot all about that. On the Famicom, what I said is true for power-on, so let's examine reset.

Power isn't disconnected from anywhere during a reset, so memory isn't affected and the currently swapped-in bank stays there. If we assume the game was functioning normally before the reset, then the NMI wouldn't have a chance of firing in an invalid bank, because a "good" programmer would disable the vblank NMI before swapping in a bank that doesn't contain an NMI handler, or such a bank's NMI vector would simply point to an RTI (which I think it should anyway, but some coders might not do this).

On reset, if an NMI happens directly after the reset vector is jumped to, then the NMI must've been enabled before the reset, meaning the game was expecting vblank NMIs with whatever bank was last swapped in. The memory will still hold a valid state, so the NMI should execute with no problems. There's no chance of the NMI executing with incomplete memory for two reasons:
1) Part of the NMI handler should be a "did the game finish executing a frame before I ran?" check before doing anything that requires game state information. (games that don't have this would crash or glitch out during slowdown)
2) The first thing a reset routine should do is disable all interrupts before initializing any memory.

Therefore, reset on a Famicom isn't a show stopper, and what I mentioned in my previous post would still work on reset, but only by chance.

This is false. Discrete logic mappers use R+C+Diode circuit on M2 line to detect reset, so memory got unchanged but chips that are sensible on reset and holds bank data are reset thus currently swapped bank might get changed.

Most pirate multicart mappers have the R+C+diode.

Most single-game and/or licensed mappers don't.

Are you asking about switching a 8kb bank at $E000-$FFFF particularly, or any swapping that affect the vectors ?

The MMC5 supports a mode where four 8k banks are individually swappable, it's the only "large" mapper to support swapping a 8k bank at $E000-$FFFF as far as I know. But many mappers allow (or even force) to swapp a larger region including the CPU vectors.

If you look at games using CHR-ROM with large granularity, you'll notice many graphics are repeated among banks. For instance, the main character's sprites might appear in multiple banks, this is due to the fact he has to be used almost all the time, while the other content of the pattern tables changes. For CPU vectors when either the last PRG-ROM region or the whole PRG-ROM region is bankswitched it's exactly the same - you'll repeat your Reset, NMI and IRQ routines along with the vectors in all banks, so they are always there.