Understanding banks/pages

Hi, I just trying to get a few things clear as I cannot find a definitive answer, so I'm hoping you guys and gals can clear this up for me.

The NES has 2 'pages' for storing graphics. So what do we mean when we speak about 'banks'?

1) banks mean we can store those 2 pages and another 2 pages become available for use in another bank?

OR

2) the 2 already and only available pages are split up into 'sections' otherwise called a bank. So two character sprites are on one page, but only one character was needed, so instead of loading the whole page, you could just load up the bank with the sprites/tiles needed.?

I'm confident it's 2) but just want reassurance, thanks.

I believe "page" and "bank" are both generic terms that can change depending on context.

You talk about "2 pages for graphics" -- I believe you're talking about pattern tables, which could be CHR-ROM or CHR-RAM.

The term "bank" is sometimes ambiguous/vague, but in most contexts it refers to PRG-ROM or CHR-ROM banks. Let's talk about them:

PRG-ROM: the NES has 32KBytes of memory space for code and data in $8000-FFFF (CPU space). 32KB might not be enough for a single game though -- maybe you need 64KB. Given there's only 32KB of memory space available, how would you access the "other" 32KB (of 64KB)? You have to use a mapper that can switch in/out which PRG-ROM bank is actively "mapped" to $8000-FFFF. The size of the PRG-ROM bank varies per mapper -- 32KB, 16KB, and 8KB are common. You can then choose which bank gets mapped to what region of CPU memory (the regions vary per mapper).

CHR-ROM: the NES has 8KBytes of memory space for pattern table data ("graphics") in $0000-1FFF (PPU space). What if you needed 16KB for more graphics? The process is identical/same as what's described above for PRG-ROM, but instead for CHR-ROM and pattern tables. The size of the CHR-ROM bank varies per mapper -- 8KB, 4KB, 2KB, and 1KB are common. You can then choose which bank gets mapped to what region of PPU memory (the regions vary per mapper).

CHR-RAM: similar to CHR-ROM, except instead of the $0000-1FFF in PPU space being ROM (read-only), it's RAM (read/write). In this scenario, it's up to your program to copy data into the pattern table manually using code. If you wanted to update a single tile/graphic, you could do so (rather than with CHR-ROM, where you'd have to swap in/out an entire bank). There are some more exquisite mappers that let you do swapping/banking of CHR-RAM, but usually banking is limited to CHR-ROM.

To understand the difference between CHR-ROM vs. CHR-RAM, see this wiki page, as both models have pros/cons: https://wiki.nesdev.com/w/index.php/CHR_ROM_vs._CHR_RAM

The important thing to understand about mappers and bank switching: this is accomplished not by "copying data", but by the hardware itself actually changing/manipulating address lines and where they "point" in an actual chip (mask ROM) themselves. It's instantaneous. That's the one drawback CHR-RAM has vs. CHR-ROM: it takes CPU time to actually copy data.

Finally: the term "page" is also sometimes used to refer to "bank", but it depends on context. On the 6502 CPU, for example, the term "page" refers to 256 bytes of memory (ex. "zero page" referring to memory from $0000 to $00FF). So, sadly, you have to go off of context when seeing the word "page" or "bank". If the person using the term isn't clear, then ask them what they mean.

Edit: adding URLs and grammatical fixups.

Page has a couple of different definitions depending on where it's used.

But in this case, the two "pages" are 8k of PPU memory, divided into two 4k pieces. The background can see one of them, and the sprites can see one of them (8 pixel mode) or both (16 pixel mode). You can choose which of the two pages either uses with the control register at $2000.

Banking, in this context, is something the mapper does to transform that 8k of space by swapping different blocks in and out of that memory. Depends on the mapper, but there might be 1k banks (i.e. 1/4 of a "page"), or 2k blocks (1/2 of a page), or sometimes 4k or 8k, and sometimes different combinations of these. It all depends on the specific mapper you're using.

For example, MMC3 has 6 different CHR banks. Each of them is mapping a 1k or 2k block of CHR-ROM into a fixed region of those base 8k pages.

The exact meaning of "bank" will vary from mapper to mapper, but generally speaking, a bank is a piece of a larger memory chip than the NES can normally see, that can be made visible in "windows" within the memory that the NES can see.

The NES was designed to see only 8KB of CHR memory(512 tiles), which are divided in 2 pages because 256 tiles are used for the background and the other 256 for sprites. That was fine for earlier games and all, but developers soon felt the need to use more than 512 throughout their games, but since you can't change e amount of tiles the PPU can access, the only choice was to make different sets of 512 tiles visible at any time. This is called bankswitching.

In it's simplest form (as seen in mappers like CNROM), CHR bankswitching means selecting which 8KB section of a larger CHR chip is mapped (hance the name "mapper") to the 8KB window that the NES can see. The PPU itself is unaware that the tiles are changing, it's just accessing graphics within the 8KB range it has access to, but hardware inside the cartridge can redirect those accesses to different chunks of a larger memory chip, and these chunks are chosen by the game program.

As games became more complex, programmers started desiring for more control over which tiles were mapped where in the 8KB range of memory that the PPU sees, instead of just being able to swap all 512 tiles at a time. This meant that instead of a single 8KB window, the PPU addressing space was broken up in smaller windows as small as 1KB (64 tiles), that could be mapped to different banks independently from each other.

I'd like to think of it as the PPU having 2 "windows" for viewing 2x4kB:s of chr-rom/ram; 4 in each, just like the CPU has a PRG-ROM window. A mapper might have more CHR-ROM or CHR-RAM banks than that or define bank sizes differently, but you can only view 8kB at any one time through that double window.

Understanding that a page is 256 bytes is for example important when uploading characters from PRG-ROM to CHR-RAM. Since you wrap around the address offset from 255 to 0, you need to iterate your upload loop 16 times to fill one full 4kB window of CHR-ram, if you load all at once in bulk. It also makes it convenient to replace one strip/row of characters at one time by iterating the loop just once.

Oh my goodness, so many of you responded! Thank you very much.It's a lot to take in, I understand the bank swapping, and the mappers that you speak about, so here's my thinking.

As standard(early days of nes life) 1 page (or bank) 256 x 8x8 tiles for background tiles, and 1 page(or bank) for sprites 256 x 8x8 tiles(meta tiles) stored in chr rom.

Later life
More graphics needed so space was made in chr prg for extra graphics and stored there by different sizes, The mappers then pointed to those graphics on the fly through code. I may have got chr prg and chr rom the wrong way round, but that's the gist yes?

That said would it be safe to say you could have have 2 pages/banks of 256x 8x8 for sprites and 2 pages of 256x 8x8 tiles for backgrounds, but you would have to right the other 2 pages to a different rom/prg and have the mappers reference them?

Sorry, I've created a tile set and I fear I may have to many for the standard 2 pages, but if it is possible to do as I've mentioned above then I can breath I sigh of relieve. thanks everyone, I real,y do appreciate your time here answering my questions.

Under normal, basic circumstances, yeah, there are 256 tiles you can use for the background, and 256 tiles you can use for the sprites, all simultaneously viewable. Some games do tricks to get more out of it, but let's not focus on that for now. What most games resort to is switching out those tilesets between scenes, levels, areas or game modes.

A tile is 16 bytes large (2 bits per pixel, 64 pixels per tile, so 128 bits / 8 bits on a byte = 16).
So a page of tiles is really just 16 tiles (256/16: a page of 256 bytes / 16, the size of a tile).



That depends on the mapper. Like stated, the PPU can view 512 tiles at once, which is split half and half between background and sprites. A mapper like CNROM may have more CHR-ROM banks for the PPU to choose from which to view. The basic NROM mapper has not. Then, mappers like UNROM have CHR-RAM instead of CHR-ROM, that is, memory you can rewrite on the fly. You can then freely dedicate any amount of program ROM (PRG-ROM) for graphics instead, but must have routines that can upload this data to CHR-RAM; preferrably when rendering is turned off.


This is a technicality, but "meta tile" does not refer to sprites per se, even if the concepts are related. Metatiles are like dictionary entries. They're keywords that hold content/information about actual tiles - like ID and properties. Or you could describe them as objects for organizing tiles for practical use in the game. The exact definition of a metatile may vary from game to game depending on how you implement one such scheme - it is completely handled in software, unlike background and sprite tiles, which are largely handled by hardware.

For a game i'm working on, here's the definitions that game is using:

Just to add a bit.

If using CHR-RAM the graphics can be compressed, saving space, but adding to the loading time.

Also, if you have 300 BG tiles and only 50 Sprite tiles, you can (for example) put the title screen tiles in the same tileset as the sprites, changing PPU control settings to point BG to that set for title, and then pointing it to the other set for the rest of the game.

I see, so when or where did the mappers then appear? Did different model NES systems have different mappers on separate production, or where they coded within the cartridges? PAL version NTSC versions have different mappers, or where they developer extensions?

It's hard to decide on which is the most relevant way to go when creating assets, or which to bear in mind, go with the original original, only 512 tiles, or stear more towards the lower end mapper, and get away with doing a little bit more without the worry of it being considered ' not true NES' graphics, I suppose I'm trying to find the balance, and have genuine/authentic assets that are actually workable and not 'NES like'

Sorry to be a pain, but I do find it very interesting.

A mapper is a circuit design or device on the pcb of the cartridge that expands the capabilities of the NES, mostly in the form of rerouting addresses so that larger programs are possible.

While NROM may be called a mapper in the context of emulators, what it really is is a cartridge PCB with no mapper at all. So that is the original configuration.

Some more answers:

-no, mappers aren't something the game programmer programs. it's something in the cartridge hardware that the programmer may be able to interface with, though.
-no, NES:es have the same capabilities regardless what. There are some subtle, obscure and hardly used differences between NTSC and PAL versions, but that's not terribly important. What changed is the capability of the cartridges as years went by. It was pretty ingenious, actually. Every game could carry its own expansion this way. Only problem, as later technologies would prove, is the price of manufacture vs cd-rom, a digital download, an online hosted game and so on.

Ok, that's great!, thanks everyone for the feedback and the valuable information provided by all!, this will truley help me going forward from here on. Hope I haven't been giving you all the hump with my noob questions. It's an education, learning pixel art over the last few years and working within hardware limitations and really understanding the systems themselves it just makes me appreciate how incredible clever it all is, why it was the way it was back then, from design to everything else to producing the games themselves.

Thank you!

If you're approaching this from an artist's perspective, meaning you need to know how many tiles you have available at any given time, you and the programmer (if that's not you) will have to agree on a mapper and both work within the limits of that mapper.

Most homebrewers start working with the assumption that they have 256 tiles for the background and 256 tiles for sprites which can be changed between levels or screen transitions (any point where the screen is blank). That's because all simple mappers are able to do that, regardless of whether they use CHR-ROM or CHR-RAM.

Mappers only start making a big difference when you need access to more than 512 tiles in shorter periods of time without any screen blanking, such as in the same frame (e.g. complex cutscenes) or a couple of successive frames (e.g. characters with more animation frames than can be combined in 256 tiles), because then the amount of tiles you can change at a time and how fast you can do it matters.

Switching CHR-ROM is instantaneous and can be done at any time, but the size of the windows that can can be individually manipulated varies from mapper to mapper (as low as 1KB in more advanced mappers to the whole 8KB in simpler mappers), and to do it mid-screen you need to synchronize the PPU with the PPU somehow, so the switch happens at the correct place. The most common methods of synchronization are sprite 0 hits (which every PPU can do) and mapper IRQs, which obviously vary from mapper to mapper but are generally much more versatile.

CHR-RAM on the other hand is normally not switched at all (although it most certainly can be, but that wasn't common back in the day), it's rewritten by the program on the fly, byte by byte. This means that there's no lower limit on how many tiles can be changed, but every byte changed takes time, and it can only be done during vblank (short period between frames where VRAM can be accessed by the CPU) or forced blanking (rendering is turned off). Since the vblank period is quite short, you can realistically change about 8 tiles (128 bytes) from one frame to the next while also updating other things, such as sprite positions and background layouts for scrolling. If you orchestrate things well, that's enough for animating a few characters' sprites and smaller background areas.

What program are you using for level design? Or are you doing it manually?