'Bank Switching' Sprites on old NES applications

Question

I'm currently writing in C# what could basically be called my own interpretation of the NES hardware for an old-school looking game that I'm developing. I've fired up FCE and have been observing how the NES displayed and rendered graphics.

In a nutshell, the NES could hold two bitmaps worth of graphical information, each with the dimensions of 128x128. These are called the PPU tables. One was for BG tiles and the other was for sprites. The data had to be in this memory for it to be drawn on-screen. Now, if a game had more graphical data then these two banks, it could write portions of this new information to these banks -overwriting what was there - at the end of each frame, and use it from the next frame onward.

So, in old games how did the programmers 'bank switch'? I mean, within the level design, how did they know which graphic set to load? I've noticed that Mega Man 2 bankswitches when the screen programatically scrolls from one portion of the stage to the next. But how did they store this information in the level - what sprites to copy over into the PPU tables, and where to write them at?

Another example would be hitting pause in MM2. BG tiles get over-written during pause, and then get restored when the player unpauses. How did they remember which tiles they replaced and how to restore them?

If I was lazy, I could just make one huge static bitmap and just grab values that way. But I'm forcing myself to limit these values to create a more authentic experience. I've read the amazing guide on how M.C. Kids was made, and I'm trying to be barebones about how I program this game. It still just boggles my mind how these programmers accomplisehd what they did with what they had.

EDIT: The only solution I can think of would be to hold separate tables that state what tiles should be in the PPU at what time, but I think that would be a huge memory resource that the NES wouldn't be able to handle.

Answer 1

wSo after a night of thinking and re-reading documents, I think I came up with a perfect solution. A matrix!

Given the following data:

 3, -1, -1, -1, -1
-1,  0,  1,  2, -1
-1, -1, -1,  3, -1
-1, -1,  5,  4, -1
-1, -1, -1, -1, -1

I can use this information to access information within lookup tables to determine what information I need. The first entry (0,0) defines the whole map, where as the other values define what is needed in that particular screen.

MAP ARRAY    PALETTE   MUSIC   TILESET  STARTINGSCR
   0            0        0        1           4
   1            4        3        2           2
   2                         etc.
   3

So when loading the map, I look at item (0,0). It will say I need to load X tiles into the PPU, use Y color pallete, Z tileset, and A music. It will also say that screen 0 is the starting screen and that the level starts there - position the character accordingly.

   SCREEN     PALETTE    TILESET   MUSIC   TILEDATA  SCROLLL SCROLLR SCROLLU SCROLLD  
      0           0          1       2         4       true     true    true    true
      1                   etc
      2           2          1       2         3       false   false     false  true

Now lets say I need to transition screens. I can look at the current screen vs the target screen. If the new screen needs information not in the PPU, I can initiate a transition that will load the data during it. I can also see if I can scroll into that direction; e.g., if the target screen is -1, I cannot scroll that direction. I can also store a flag somewhere to determine that if scrolled onto that screen, I cannot scroll back. E.g, I can go right into screen #2 but cannot scroll left into screen 1.