Recreating NES limits; loading tiles

[Marscaleb]

I've been thinking about a side-project to create an RPG following the limitations of the NES as closely as I can.
To be clear, I'm talking about creating a game using modern architecture but designed to mimic the NES, not creating an actual NES ROM. Even so, I want to follow as many of the hardware restrictions as I am capable of. The more I've studied what most of these limits are, and as I've examined how NES games worked within those limits, the more I want to work within the limits myself. That being said, all the questions I have about these limitations should assume I am talking about the limitations from officially licensed hardware from the era. (Though it is fun to learn what other things were/are possible, so I'm not opposed to learning extra information.)

I've already found and examined a lot of information about how it handles and draws sprites and backgrounds. What I do not understand are things about how it loads and stores tiles.
I do understand that the system had two banks for tiles, each capable of storing 256 tiles, which comes out to the equivalent of two 128x128 images worth of tiles (as each tile is 8x8.) (Edit; fixed the number.)
What I do not understand is what restrictions the system has in regards to how it fills those banks with data. I was on a forum on another site and someone tried to explain a lot of it to me, but I didn't understand much of it, and the fellow never replied to confirm or explain anything.

First of all, I have questions about exactly where a tile is loaded. By which I mean, what order a particular tile may be in the memory. If we think of the banks as literally a 128x128 image, are there restrictions about where on that image a tile could be? Let's say in one part of the game, I load a bunch of forest tiles, and then in another part of the game, I load a bunch of city tiles, and in both areas I have some tiles that are used in both areas. Do those tiles that are used in both areas have to appear in the same location on the 128 image, and be all in the same order? Or would having them be in a different location/order mean that I have to create a whole new set of tiles or a new tileset or such thing? And to what extent do any such restrictions apply? Would this apply to both banks as if they were one? Or to each bank individually as a whole unit? Or perhaps just it just applies to a group of 64 tiles? Or are such restrictions irrelevant, and if I wanted to load a forest area, and then bring in just one single tile from the city area, I could so that without impacting how I have to arrange everything?
Granted, there is something to be said about the ease of always knowing that the tile you want is always in a given location. But knowing how these restrictions are set up will be important for knowing what combinations of enemies I can have in a battle.

Next question, if I say the term "tileset," exactly what am I referring to? It was really hard to write that section about without using it, but I want to make sure it refers to what I think it refers.

Next set of questions, which I suspect impacts the answers to my first set of questions. On the other forum a guy talked about how a game could load tiles into memory from either RAM or ROM. This very much intrigued me, but I was left with far too much that I didn't understand. First of all, is this an option that is set permanently for a cartridge, or something can be changed at a reasonable point in the game? Now, he said that with using ROM for tile data, the entire tileset could be switched out each frame. A lot of games use this to animate backgrounds. But the trade-off is that a game can't mix up what tiles are in a tileset as freely. Whereas if it loads the tiles from RAM, it can mix the tiles more freely, but it has limits about how many tiles it change out per frame. And I assume these limits are dependent on what MMC the cart uses. But even so, I am curious what all of these limitations actually are. It was suggested to use RAM loading for an RPG because it allows me to more freely customize what combination of enemies appears in a battle. But if I can load an entire bank of tiles into the memory for each frame, what's really stopping me from just creating a lot of pre-made tilesets for each possible combination of enemies I could want? What harm does it do me to load a bank of tiles that is only one tile different from another bank? He also made it sound like games that use the RAM loading method were pretty much incapable of animating backgrounds (at least by changing what tiles are loaded; there still is the possibility of using palette animations, and I'm guessing tilemap animating should be a thing.) But if the RAM method simply slows down the speed at which tiles can be loaded, what's wrong with just keeping the number of animated tiles limited to how many can be loaded per frame? Why couldn't I animate just the water tiles? Or load a whole new image for the player each frame?

And finally, although not really related to loading tiles, I would like to know: is there really any disadvantage to using the 8x16 sprite mode?
I can see how it can cause problems with having too many sprites on one scanline, since even if a row is transparent it still counts toward that limit. So if you were building a character that was, say, 24 pixels tall, you could run into the flickering problem a little easier since there are an extra 8 pixels floating above (or below) the part that is actually visible. And if you want to build a character with multiple palettes, you will have to fit those palettes into 8x16 sections instead of 8x8 sections. But those are relatively minor trade-offs compared to being able to effectively double the number of sprites on the screen. Is there some other disadvantage that I am unaware of? Also, can the game switch between the sprite mode at any given time, or is it set permanently in the cartridge, or what?

Those are all of the questions I have at this time. Thank you for your time.

[tokumaru]

I do understand that the system had two banks for tiles, each capable of storing 256 tiles

The tiles are divided in 2 banks because one is supposed to be used for the background while the other is supposed to be used for sprites. However, this is configurable, so you can have different settings like both sprites and the background using tiles from the same bank (while the other bank is not used at all), or you can use 8x16 sprites and have them use tiles from both banks, or you can even change these settings while the screen is rendered.

which comes out to the equivalent of two 512x512 images worth of tiles (as each tile is 8x8.)

What do you mean 512x512? each tile is 8 x 8 = 64 pixels. Since each bank is 256 tiles, that's 256 x 64 = 16384 pixels per bank. A square image with that many pixels would be 128x128, not 512x512. So what you really have is the equivalent of 2 128x128-pixel images.

First of all, I have questions about exactly where a tile is loaded.

That depends on the type of CHR memory the game has. The part of the video memory where the NES fetches tiles from is called pattern tables. It's a window of 8KB of memory (8192 / 16 = 512 tiles) that's filled in different ways depending on what kind of memory the cartridge puts in there.

Games that use CHR-ROM never "load" tiles per se, they just "map" a part of a ROM chip containing tile data to that window. Games with CHR bankswitching can map different parts of the chip to different parts of the pattern tables. Games change which tiles are mapped where for various purposes, like animating the background, rendering a new level, or animating sprites.

Games that use CHR-RAM map a RAM chip to the pattern table area. This means that the pattern tables are just a big blank when the console is first turned on, and the game program is responsible for writing (or loading) tile data to that memory. This is much slower than simply mapping part of a ROM chip, but gives the programmer complete control over the tiles, being able to even generate tiles dynamically.

Most systems (e.g. Game Boy, SNES, Master System, Genesis) only have the equivalent of CHR-RAM, because this RAM is inside the system itself. The NES is a rare exception, because the designers decided to route the tile memory to the cartridge instead of putting it inside the console, giving each game the option to use one type of memory or the other (ROM or RAM).

Let's say in one part of the game, I load a bunch of forest tiles, and then in another part of the game, I load a bunch of city tiles, and in both areas I have some tiles that are used in both areas. Do those tiles that are used in both areas have to appear in the same location on the 512 image, and be all in the same order? Or would having them be in a different location/order mean that I have to create a whole new set of tiles or a new tileset or such thing? And to what extent do any such restrictions apply? Would this apply to both banks as if they were one? Or to each bank individually as a whole unit? Or perhaps just it just applies to a group of 64 tiles?

This all depends on the mapper and type of CHR memory. CHR-RAM imposes no restrictions at all, you can copy any tile from anywhere in the PRG-ROM to anywhere in the pattern tables, so you can combine tiles however you like. The only drawback is that since this is done byte by byte, it takes the CPU a long time to transfer new graphics into the pattern tables.

CHR-ROM makes changing tiles much faster (practically instantaneous, actually), but the ability to mix and match tiles greatly depends on the mapper. The most advanced mappers (e.g. FME-7, MMC5) can break the pattern table area into 8 1KB (i.e. 64 tiles) pieces. The simplest mappers will only allow you to swap the whole 8KB, meaning that to load tiles for a new level you need to replicate common tiles such as the main character and items across all 8KB banks.

Or are such restrictions irrelevant, and if I wanted to load a forest area, and then bring in just one single tile from the city area, I could so that without impacting how I have to arrange everything?

With CHR-RAM, yes. You just won't be able to load many new tiles from one frame to the next. Realistically speaking, you can update maybe 8 tiles each frame while still running the game and updating other parts of the video, such as sprites or the tile map. With CHR-ROM you're restricted to the granularity of the mapper you're using (the minimum you can load is 64 tiles), but there are practically no restrictions to how many tiles you can change from one frame to the next, or even in the same frame.

Next question, if I say the term "tileset," exactly what am I referring to?

A tileset is just what the name says, a set of tiles. The NES has this somewhat fixed length of 256 tiles per set, but it's not like it forces you to use them all, and with mappers you can access more than that, so the size of the set is somewhat flexible.

On top of that, most games don't address tiles directly, because that would make maps take a lot of memory (1KB per screen). Instead, they use metatiles, which are larger blocks constructed from tiles. The most common metatile sizes are 16x16 and 32x32 pixels, but there are all sorts of variations really. These sets of metatiles can also be called tilesets.

First of all, is this an option that is set permanently for a cartridge, or something can be changed at a reasonable point in the game?

Normally, a cartridge has either CHR-ROM or CHR-RAM, but a couple of games are crazy enough to have both. How these are mapped to the pattern tables will depend on the mapper.

Now, he said that with using ROM for tile data, the entire tileset could be switched out each frame. A lot of games use this to animate backgrounds. But the trade-off is that a game can't mix up what tiles are in a tileset as freely. Whereas if it loads the tiles from RAM, it can mix the tiles more freely, but it has limits about how many tiles it change out per frame.

Yes, like I said above.

But if I can load an entire bank of tiles into the memory for each frame, what's really stopping me from just creating a lot of pre-made tilesets for each possible combination of enemies I could want? What harm does it do me to load a bank of tiles that is only one tile different from another bank?

The total amount of CHR memory you have. The most advanced (non-pirate) mappers can only address 256Kb of CHR memory. Is that enough for all of your combinations?

He also made it sound like games that use the RAM loading method were pretty much incapable of animating backgrounds (at least by changing what tiles are loaded; there still is the possibility of using palette animations, and I'm guessing tilemap animating should be a thing.) But if the RAM method simply slows down the speed at which tiles can be loaded, what's wrong with just keeping the number of animated tiles limited to how many can be loaded per frame? Why couldn't I animate just the water tiles? Or load a whole new image for the player each frame?

Backgrounds can certainly be animated with CHR-RAM, as can the player. You just have to design things in a way that a realistic number of tiles are updated each frame. Let's do the math: there are 2273 CPU cycles during VBlank, which is the time when you can access the video memory. Copying a byte from ROM/RAM to VRAM takes 8 cycles, so if you only do this during VBlank, you can write 284 bytes, or 17 tiles. But you're obviously not going to do only this, you also have to change palettes, set the scroll, update the tile maps, update the sprites... all things considered, if you manage all these updates well, you're looking at 8 or so tiles per frame. Design your animations around that and you'll be mostly faithful to the capabilities of CHR-RAM.

is there really any disadvantage to using the 8x16 sprite mode?

The advantage is that you can cover more of the screen with sprites. At 8x8 x 64 you can only have 4096 sprite pixels (out of the 256 x 240 = 61440 pixels that make a full screen), while 8x16 can cover twice that. In most cases you won't actually cover twice the space, because there will be some blank areas, like you said.

Is there some other disadvantage that I am unaware of?

The only one I can think of is that since sprites can't scroll smoothly from the top of the screen (there are no negative Y coordinates), 8x16 sprites will appear/disappear more harshly at the top of the screen than 8x8 ones.

Also, can the game switch between the sprite mode at any given time, or is it set permanently in the cartridge, or what?

It can be changed freely, but you should avoid changing sprite sizes mid-frame or it can mess with the sprite evaluation process.

[tepples]

I've already found and examined a lot of information about how it handles and draws sprites and backgrounds. What I do not understand are things about how it loads and stores tiles.
I do understand that the system had two banks for tiles, each capable of storing 256 tiles, which comes out to the equivalent of two 512x512 images worth of tiles (as each tile is 8x8.)

That's two 128x128 pixel tile sheets. 256 tiles is 16x16 tiles, each 8 pixels, and 16 times 8 is 128.

First of all, I have questions about exactly where a tile is loaded. By which I mean, what order a particular tile may be in the memory.

If you're using CHR RAM, you can replace a tile at any time. You can replace all tiles while the display is blanked, or you can replace up to 8 tiles per vertical blank (10 if you push it) while the display is running. (The vertical blank is the time between frames when the CPU can load new information into video memory, and it happens 60 times per second.)

If you're using CHR ROM, it depends on the capability of the mapper, the circuit that sits between the PPU and the address lines of the ROM. The mapper controls which parts of the CHR ROM the PPU can use at one time. With a later mapper such as FME-7, you can think of the pattern table as consisting of eight windows, each 64 tiles (128x32 pixels) in size: four for background and four for sprites. Each window can be set to display a separate 64-tile bank of the CHR ROM. You can switch entire banks of tiles in and out of the window more or less instantly, and you can even switch different banks in for the playfield and status bar if your game has a status bar.

If we think of the banks as literally a 512x512 image, are there restrictions about where on that image a tile could be? Let's say in one part of the game, I load a bunch of forest tiles, and then in another part of the game, I load a bunch of city tiles, and in both areas I have some tiles that are used in both areas. Do those tiles that are used in both areas have to appear in the same location on the 512 image, and be all in the same order?

Only if you're trying to share metatile definitions between the two tile sets.

Or are such restrictions irrelevant, and if I wanted to load a forest area, and then bring in just one single tile from the city area, I could so that without impacting how I have to arrange everything?

If you want to mix and match tiles arbitrarily, CHR RAM can do that.

Next question, if I say the term "tileset," exactly what am I referring to?

Do you have NES ROM images stored on your computer? If so, you can load one into an emulator and open the PPU viewer window while to see what tiles are switched in and out of the windows.

On the other forum a guy talked about how a game could load tiles into memory from either RAM or ROM. This very much intrigued me, but I was left with far too much that I didn't understand. First of all, is this an option that is set permanently for a cartridge

The vast majority of cartridges have either only CHR ROM or only CHR RAM. Only a handful of games have both: Pin-Bot, High Speed, and a bunch of China-only games. It can't change at runtime, but we do have evidence of a game changing between the two during development.

• Ports of old cartridge games such as Super Mario Bros. to the Famicom Disk System use CHR RAM, loaded at the start of the game with the data that was previously in CHR ROM.
• Super Mario Bros. 2: Mario Madness was originally a Famicom Disk System game. Nintendo was originally going to use the same CHR RAM-based board that other FDS-to-cartridge ports (The Legend of Zelda, Metroid, and Kid Icarus) used, but in the end, it switched to a CHR ROM board.
• The incredibly rare Nintendo World Championships multicart contains Super Mario Bros. and Tetris, modified to use CHR RAM in much the same way as the ports to FDS, alongside the originally CHR RAM-based Rad Racer.

Now, he said that with using ROM for tile data, the entire tileset could be switched out each frame. A lot of games use this to animate backgrounds. But the trade-off is that a game can't mix up what tiles are in a tileset as freely. Whereas if it loads the tiles from RAM, it can mix the tiles more freely, but it has limits about how many tiles it change out per frame. And I assume these limits are dependent on what MMC the cart uses.

The FME-7 is representative of later mappers, and it lets you switch 64-tile banks.

But if I can load an entire bank of tiles into the memory for each frame, what's really stopping me from just creating a lot of pre-made tilesets for each possible combination of enemies I could want?

Memory cost. Kirby's Adventure is the largest licensed NES game using CHR ROM. It has 256 KiB of CHR ROM, where each KiB (kibibyte, 1024 bytes) holds 64 tiles. The only games with larger CHR ROM are the Japan-only Metal Slader Glory and pirate multicarts.

What harm does it do me to load a bank of tiles that is only one tile different from another bank?

If you duplicate a bank, it will count against the total size of CHR ROM, and most mappers were incapable of switching more than 256 KiB.

He also made it sound like games that use the RAM loading method were pretty much incapable of animating backgrounds (at least by changing what tiles are loaded; there still is the possibility of using palette animations, and I'm guessing tilemap animating should be a thing.) But if the RAM method simply slows down the speed at which tiles can be loaded, what's wrong with just keeping the number of animated tiles limited to how many can be loaded per frame?

Nothing, which is why the CHR RAM-based Battletoads is full of tile animations. It's just somewhat tricky to keep things as interesting by loading only 8 tiles per vertical blank, especially if you have to share those 8 background tiles with loading new sprite tiles.

Why couldn't I animate just the water tiles? Or load a whole new image for the player each frame?

You could, and you could. In fact, the engine of my current NES platformer project loads a whole new image for the player and each enemy every frame, using double buffering so that it can display one frame of animation while the next frame is being loaded in at 8 tiles per vertical blank.

Also, can the game switch between the [8x8 or 8x16] sprite mode at any given time

Yes. The sprite size bit can even be changed partway down the screen, between the status bar and the playfield.

[Kasumi]

I guess I'll avoid being a killjoy. This topic might also be an interesting read for you: viewtopic.php?f=21&t=10808

[Marscaleb]

Whoops! I meant 128x128, not 512x512. I should have checked my notes; 128x128 is what I already have written down. Thanks for the catch!

The tiles are divided in 2 banks because one is supposed to be used for the background while the other is supposed to be used for sprites.

Okay, but since sprites and background tiles can come from either bank, are there any restrictions about how they can be divided up? Because I was under the impression that there was technically no actual restriction, and using one for sprites and one for background is just an arbitrary suggestion. I also was under the impression that I could even use a given tile as both a sprite and a background.

Most systems (e.g. Game Boy, SNES, Master System, Genesis) only have the equivalent of CHR-RAM, because this RAM is inside the system itself. The NES is a rare exception, because the designers decided to route the tile memory to the cartridge instead of putting it inside the console, giving each game the option to use one type of memory or the other (ROM or RAM).

OOOOHHH, that makes so much more sense now!

Also, that totally explains why some dirty connections resulted in funky-looking screens, but yet I never saw that happen with other systems. Because the system functions themselves ran back into the cart, so a bad connection will put lines through everything.

Normally, a cartridge has either CHR-ROM or CHR-RAM, but a couple of games are crazy enough to have both.

Would I be correct in assuming that none were officially licensed for the NES?

The total amount of CHR memory you have. The most advanced (non-pirate) mappers can only address 256Kb of CHR memory. Is that enough for all of your combinations?

Memory cost. Kirby's Adventure is the largest licensed NES game using CHR ROM. It has 256 KiB of CHR ROM, where each KiB (kibibyte, 1024 bytes) holds 64 tiles.

Okay, that's 256Kb of CHR memory, so that means memory just for tiles, right? As opposed to memory that needs to also house all of my program code, music, sound effects, and whatever else.
That puts my game's artwork at an upper limit of 16,384 tiles, or 64 separate 128x128 images. And if I use CHR ROM, then any artwork I would need in multiple scenes would get duplicated multiple times, even the tiles I need for text. Yeah, suddenly CHR ROM sounds like a very bad idea for an RPG.


Okay, now that I have a better understanding of that, I am ready to ask about mappers.

First of all, I read something somewhere that suggested to me that while "mapper" and "Memory Management Controller (MMC)" are used interchangeably, the term "mapper" technically refers to how an emulator handles the tile memory, whereas back in the day developers working with actual cartridges would have called them MMC's. Would the be correct, or did they call them mappers back then too?
(I know it's not really important, kind of like how people use "font" and "typeface" interchangeably, even though they are not technically the same thing. But it still is cool to learn this stuff.)

Next I want to find out what MMC I would want to emulate for my game. But when I read through the information on this site, it is completely beyond me. I guess I'd need to know assembly or something. And the information listed on wikipedia doesn't so much to help me know the technical limits.
But since the MMC5 was a more expensive chip, it seems to be more than what I would want to use. (Although its extended graphic abilities are tempting.) So apart from third-party chips, given the point in time at which this style of RPG began to emerge, I'd probably want to presume it would use the MMC3. (Maybe the MMC1, if I decide that the title was "originally made" in Japan.)
Even so, I think it would be best to just get the relevant information and decide what chip to use as the game develops. But as I said, I can't find a page that shows me the relevant information in a manner that I understand. How many tiles can each mapper load in an average frame? What other unique features do they come with?

Also, while the whole cart may have its highest limit for CHR data at 256 KiB, I suspect that wasn't very common, and possibly wasn't even an option until later in the NES's lifetime. Is there a timeframe of when those memory limits were raised?

[Kasumi]

Okay, but since sprites and background tiles can come from either bank, are there any restrictions about how they can be divided up?

Consider both banks separate. Consider that to access most of this stuff, you'd be writing a single byte. So the range is only 256. For this reason, you couldn't have say... 400 tiles for the background and 112 for sprites. I feel like that's what you're asking. (Well... that's the simplified answer, because you can access more than 256 tiles with certain mappers...)

Sprites and backgrounds can come from either bank, but it's one or the other, not inbetween. I can use bank 0 or 1 for sprites, I can use bank 0 or 1 for the background. So I could use bank 0 for sprites and bank 0 for the background or bank 1 for sprites and bank 0 for the background etc. Only 4 choices, and only 2 effectively unique choices. (A separate bank for both, or the same bank for both.)

8x16 sprites can access both, but again it just uses a byte. A single bit tells the PPU to use 2 tiles from bank 0 or bank 1. All the other bits say which two tiles. This means you can use tiles 0 and 1, or 2 and 3 in either bank to make a sprite, but you cannot use tiles 1 and 2. Allowing this would require a larger number than a byte provides.

Okay, that's 256Kb of CHR memory, so that means memory just for tiles, right?

In the case of CHR ROM, that's what the means. In the case of CHR RAM, all your music, code and whatever else is with your graphics in PRG.

And if I use CHR ROM, then any artwork I would need in multiple scenes would get duplicated multiple times, even the tiles I need for text. Yeah, suddenly CHR ROM sounds like a very bad idea for an RPG.

Not true. If you plan to use tiles in multiple "sets", you could store them once if you plan well. Some mappers allow you to deal with 64 tile sets instead of 256 tile sets. So you could store a reusable part in 64 tiles, leaving 192 for other stuff. Say you had... four sets. A city, a forest, a swap, a mountain. All of them shared no more than 64 tiles.

So... 64 stored once for the reusuable portion.
Then
192 for the city,
192 for the forest,
192 for the swap,
192 for the mountain
= 832 unique tiles that needs to be stored.

Rather than the 1024 that 256 for all of them would take.

To put this set together in PPU memory, you'd swap in the reusuable portion to say... the first 64 tiles, then swap the remaining three 64 tile segments that correspond to the specific map to the last 192 tiles.

Depending on how you arrange things, your font doesn't even need to impact what's displayed for your map. You could have 256 tiles displayed for a map that doesn't include the font at all, and then ALSO have your font on screen. This is done by swapping out the tile sets after part of the screen has been drawn, and this is ONLY possible with CHR ROM.

Smash TV draws more than 256 tiles in its title screen with this method.

But since the MMC5 was a more expensive chip, it seems to be more than what I would want to use.

MMC5 is the one that lets you use 16384 tiles at once, instead of just 256. It also allows all kinds of other things that don't feel very NES, since most games didn't have access to them. I won't say it's cheating, but I'll think it loudly.

How many tiles can each mapper load in an average frame? What other unique features do they come with?

Also, while the whole cart may have its highest limit for CHR data at 256 KiB, I suspect that wasn't very common, and possibly wasn't even an option until later in the NES's lifetime. Is there a timeframe of when those memory limits were raised?

It's not... "loading", it's swapping. Swapping is instantaneous, so you can draw the screen using quite a few different tiles. See Smash TV. And MMC3 is VERY common, but I don't think maxing out the CHR was, no. It first appeared in 1988.

Edit: At any given time while drawing the screen, the PPU is drawing the background from the set of 256 tiles currently in its memory. The thing about is that this set its using to draw can be swapped out while its drawing. Let's just say... the limit is HIGH for what you can do, but for a practical answer assume you get 256 tiles for some kind of HUD (say... your textbox that displays NPC dialog), and a separate 256 tiles for your map that you can have on screen at any given time.

Even so, I think it would be best to just get the relevant information and decide what chip to use as the game develops.

It's easier for you to describe the type of gameplay you want, and we can tell you what will allow that. What NES can do is very fluid.

[Dwedit]

Since a picture is worth a thousand words, let's illustrate CHR bankswitching with Megaman 5:



I highlighted the pieces that can be switched in and out in red. Left side has two parts that can be switched, right side has 4 parts that can be switched.
On the left side, this game switches the second page to animate the tiles.
On the right side, it switches the top page when Megaman's animation sequences change, switches the second page when a different weapon is selected, and switches the fourth page for different kinds of enemies in the room. (no enemies are there, so it just selected Megaman's graphics instead)

[Joe]

Normally, a cartridge has either CHR-ROM or CHR-RAM, but a couple of games are crazy enough to have both.

Would I be correct in assuming that none were officially licensed for the NES?

Nope! High Speed and Pin-Bot are two (the only two?) officially licensed NES games that contain both CHR-ROM and CHR-RAM.

This is done by swapping out the tile sets after part of the screen has been drawn, and this is ONLY possible with CHR ROM.

Some mappers (including TQROM, used by High Speed and Pin-Bot) allow you to switch banks of CHR-RAM mid-screen. Of course, you still need to wait for vblank to upload tiles to CHR-RAM.

[Drew Sebastino]

Out of all the games to use CHR ROM and RAM, they where pinball games. Wow.

[tepples]

The tiles are divided in 2 banks because one is supposed to be used for the background while the other is supposed to be used for sprites.

Okay, but since sprites and background tiles can come from either bank, are there any restrictions about how they can be divided up? Because I was under the impression that there was technically no actual restriction, and using one for sprites and one for background is just an arbitrary suggestion. I also was under the impression that I could even use a given tile as both a sprite and a background.

The background uses only 256, and 8x8 sprites use only 256. In 8x16 sprites you can use all 512 tiles. But in mappers with an interval timer that counts scanlines using PA12 rises, scroll splits require the background to be in pattern table 0 and the sprites to be in pattern table 1, and one of those mappers is the very common MMC3. No other common mapper has this limit, especially not FME-7. A workaround on MMC3 is to switch the same 64-tile bank into both one of the sprite windows and one of the background windows.

Okay, that's 256Kb of CHR memory, so that means memory just for tiles, right?

Yes, for the most part. A few games that were just barely over a power of two in PRG ROM size stored music, sound effects, or level maps in the CHR ROM. I can think of at least Super Mario Bros. (title screen map in CHR ROM), Galaxian (music in CHR ROM), Milon's Secret Castle and Dragon Warrior (a bunch of stuff in CHR ROM), and Big Bird's Hide and Speak (shorter voice samples in CHR ROM). Reading CHR ROM is as slow as writing to CHR RAM: only about 128 bytes (8 tiles) can be read out into RAM per vblank.

That puts my game's artwork at an upper limit of 16,384 tiles, or 64 separate 128x128 images. And if I use CHR ROM, then any artwork I would need in multiple scenes would get duplicated multiple times, even the tiles I need for text.

If you put the text on a separate scanline, such as in the status bar, you can switch a different set of banks in for the status bar.

I read something somewhere that suggested to me that while "mapper" and "Memory Management Controller (MMC)" are used interchangeably, the term "mapper" technically refers to how an emulator handles the tile memory, whereas back in the day developers working with actual cartridges would have called them MMC's. Would the be correct, or did they call them mappers back then too?

MMC was the brand name for Nintendo's ASIC (application-specific integrated circuit) mappers, which were the most common ASIC mappers among licensed NES games. Konami's ASIC mappers were called VRC series, Namco/Tengen had one called MIMIC-1, Sunsoft's most famous was called FME-7, etc. Though plenty of Famicom games use non-Nintendo ASIC mappers, only a handful of licensed NES games do so, because it was easier to get Nintendo Co. Ltd. to approve Famicom mappers than to get Nintendo of America or Nintendo of Europe to approve NES mappers. Some simpler mappers, used especially early on in the NES's life, are made out of 7400 series discrete logic chips rather than an ASIC. But the only RPGs I know of on discrete mappers are Japanese: the Japanese version of Dragon Quest and legendary crap game Stargazer.

So apart from third-party chips, given the point in time at which this style of RPG began to emerge, I'd probably want to presume it would use the MMC3. (Maybe the MMC1, if I decide that the title was "originally made" in Japan.)

Most MMC3 games use CHR ROM. The only ones I can think of that use CHR RAM are Mega Man 4, Mega Man 6, Ninja Crusaders, and the Japan-only Final Fantasy III. Pin-Bot and High Speed have both CHR ROM and CHR RAM.

Also, while the whole cart may have its highest limit for CHR data at 256 KiB, I suspect that wasn't very common, and possibly wasn't even an option until later in the NES's lifetime. Is there a timeframe of when those memory limits were raised?

You could try searching NesCartDB for CHR ROM sizes and finding when those games were first published.

Is a "swap" a swamp?

[Marscaleb]

Sprites and backgrounds can come from either bank, but it's one or the other, not inbetween. I can use bank 0 or 1 for sprites, I can use bank 0 or 1 for the background. So I could use bank 0 for sprites and bank 0 for the background or bank 1 for sprites and bank 0 for the background etc. Only 4 choices, and only 2 effectively unique choices. (A separate bank for both, or the same bank for both.)

But then how do some games...

8x16 sprites can access both, but again it just uses a byte. A single bit tells the PPU to use 2 tiles from bank 0 or bank 1. All the other bits say which two tiles. This means you can use tiles 0 and 1, or 2 and 3 in either bank to make a sprite, but you cannot use tiles 1 and 2. Allowing this would require a larger number than a byte provides.

...oh that's how.
And actually that makes a lot of mathematical sense. Since 8x16 mode assumes that you are taking a tile and the one right after it, you technically only need to point to half as many tiles. Or more smartly, you can point to 128 tiles in one bank, and 128 tiles in the next bank. Pretty clever.

But this ultimately means that while I can fill my sprite data form either bank (when in 8x16 mode) I still can only fill my backgrounds with tiles only from one bank.

This is unfortunate, because I'd need to build all my text and my enemies as backgrounds, since I can't have more than eight sprites per scanline. So I need to learn more about the tricks to maximize my background data.

In the case of CHR ROM, that's what the means. In the case of CHR RAM, all your music, code and whatever else is with your graphics in PRG.

Well f*** me; how much space is there in PRG? And on average, how much of that is used up my music and sound and programs and stuff?

Not true. If you plan to use tiles in multiple "sets", you could store them once if you plan well. Some mappers allow you to deal with 64 tile sets instead of 256 tile sets. So you could store a reusable part in 64 tiles, leaving 192 for other stuff. Say you had... four sets. A city, a forest, a swap, a mountain. All of them shared no more than 64 tiles.

Okay, that's good news. What mappers do that?

Hmm... A full set of letters (with upper and lower-case) including the menu borders is already going to take up 96 tiles.
I could fit it into 64 if I have literally only two punctuation marks, if I didn't need a tile for blank space. That still doesn't really work...

Depending on how you arrange things, your font doesn't even need to impact what's displayed for your map. You could have 256 tiles displayed for a map that doesn't include the font at all, and then ALSO have your font on screen. This is done by swapping out the tile sets after part of the screen has been drawn, and this is ONLY possible with CHR ROM.

Smash TV draws more than 256 tiles in its title screen with this method.

Hmm, okay, but if I did that, the text box would have to fill literally the whole screen, would it not? We draw out the normal screen so far, swap tiles, and then draw the text box. That would be fine for the battles (in fact, I could do a lot in the battles if it is possible to swap multiple times) but everywhere else it would look out of place. All the other RPGs have text boxes that just float in the screen, and you can see stuff around them.

What else could I do to get more distance with my backgrounds? (Other than use MMC5, which I have not forgotten about.)

It's easier for you to describe the type of gameplay you want, and we can tell you what will allow that. What NES can do is very fluid.

in the simplest terms? Another Dragon Quest clone.

[Marscaleb]

But the only RPGs I know of on discrete mappers are Japanese: the Japanese version of Dragon Quest and legendary crap game Stargazer.

That might explain why the tiles on the original Japanese Dragon Quest were so... limited.
A legendary crap game? Sweet!
*looks up gameplay videos*
...Woooowwwwwww!

Most MMC3 games use CHR ROM. The only ones I can think of that use CHR RAM are Mega Man 4, Mega Man 6, Ninja Crusaders, and the Japan-only Final Fantasy III. Pin-Bot and High Speed have both CHR ROM and CHR RAM.

Holy crap, how do you guys know all this stuff right off-hand?

[lidnariq]

This is unfortunate, because I'd need to build all my text and my enemies as backgrounds [...] So I need to learn more about the tricks to maximize my background data.
[...]
What else could I do to get more distance with my backgrounds? (Other than use MMC5, which I have not forgotten about.)

There are two major exceptions. One is the MMC2 and MMC4 mappers, which extend the number of tiles for the background to 510... but you have to have horizontal strips from the same bank.

The MMC2 was used in Punch-Out!!, where its primary function was the big portraits of the fighters.
The MMC4 was used for a number of Japanese-only CRPGs, where it's useful (for example) for dialog boxes that are not the full width of the screen.

The other is the aforementioned MMC5.

how much space is there in PRG? And on average, how much of that is used up my music and sound and programs and stuff?

The practical upper limit is 512 KiB, but there are a small handful of games that exceed that. (There is no theoretical upper limit: one could put a SD card inside an NES cartridge and use all of for a single game.)

[tokumaru]

But this ultimately means that while I can fill my sprite data form either bank (when in 8x16 mode) I still can only fill my backgrounds with tiles only from one bank.

Unless you use CHR-ROM and bankswitch mid-screen, right between the gameplay and text areas.

Another option to get more background tiles, if you're willing to sacrifice sprite tiles, is to steal part of the sprite pattern table for text, for example, and swap which pattern table is used for the background mid-frame. That would work even with CHR-RAM.

Well f*** me; how much space is there in PRG? And on average, how much of that is used up my music and sound and programs and stuff?

Most official mappers top at 512KB of PRG, but the MMC5 can go up to 1MB. Music code and data doesn't typically occupy more than 32KB (unless there's a lot of samples), but this can vary a lot from game to game. Storage is hard to estimate because every game uses different formats for the various kinds of data they need. And since you'll not be using 6502 assembly, you definitely shouldn't expect your code to occupy a similar amount of space to 6502 machine code.

Hmm... A full set of letters (with upper and lower-case) including the menu borders is already going to take up 96 tiles.
I could fit it into 64 if I have literally only two punctuation marks, if I didn't need a tile for blank space. That still doesn't really work...

Not really a problem for CHR-ROM, since you can change the entire tileset instantaneously mid-screen. But should you decide to simulate CHR-RAM you can steal the necessary tiles from the sprite pattern table like I suggested above.

All the other RPGs have text boxes that just float in the screen, and you can see stuff around them.

Maybe you're thinking of SNES RPGs? I don't really like RPGs, so I don't know them as well as I know other games, but text boxes on the NES typically occupy the whole width of the screen. They sometimes scroll in smoothly so they look like they're floating, but there's nothing actually visible around them. Games that do have stuff around their text boxes probably make everything fit in 256 tiles somehow.

Now that I think of it, there's one mapper (MMC2, I think) that can switch patterns automatically when certain tiles are drawn. Something like that could possibly allow you to use a different tileset in the middle portion of the screen, if you used the tiles on the edges of the text box to do the pattern switching. I don't know if any games do that, though.

EDIT: Oh, so it's MMC2 and MMC4 that switch tiles automatically. The problem is that those mappers use 4KB CHR banks, which suck for combining tiles, specially considering that the maximum CHR-ROM they can have is 128KB (32 4KB pages).

[Kasumi]

Well f*** me; how much space is there in PRG? And on average, how much of that is used up my music and sound and programs and stuff?

Like everything else, it depends on the mapper. You can usually see the max you can use on the mapper's page. MMC3 can have 512KB of PRG. In theory it could support 2048KB of PRG, but I believe you wish to stick to official implementations.

How much space things take up is hard to give a number for. Music size depends on what's supported by the music engine, for instance. Code size depends on how simple your logic is.

And even though using CHR RAM effectively keeps you from using the 256KB of CHR ROM space in MMC3, one of the benefits of CHR RAM is that your graphics data can be compressed.

Hmm... A full set of letters (with upper and lower-case) including the menu borders is already going to take up 96 tiles.
I could fit it into 64 if I have literally only two punctuation marks, if I didn't need a tile for blank space. That still doesn't really work...

Well, like I said, you could have 256 characters in your font and still use 256 tiles for your map.

Or with CHR RAM, you could only store the tiles for the text currently being display in the PPU set. Super Bat Puncher (homebrew) does this.

The benefit to this method is that you can have the rest of your map around the textbox. If you want to use a different set of characters for your font than your map using CHR ROM, nothing else can occupy the same horizontal lines as the text.

Here's an example of CHR ROM swapping

Note that none of the map set contains any letters, but as a consequence the text boxes must cover the map entirely.

Hmm, okay, but if I did that, the text box would have to fill literally the whole screen, would it not?

No, see the above. Again, you can swap out the 256 tiles the PPU uses to draw from while it's drawing the screen.

Edit: Oh wait, reading again you know this. I'll say that RPGs that have floating textboxes like Super Bat Puncher's tend to suffer from simplicity in graphics precisely because they need to dedicate so much space to font, but that's also because most don't do it with CHR RAM like Super Bat Puncher does. But your text boxes must be small, or a Super Bat Puncher style thing will use even more tiles than just storing all the letters.

What else could I do to get more distance with my backgrounds? (Other than use MMC5, which I have not forgotten about.)

You can swap out tiles a bunch of times if you want. Here's Smash TV's title screen:

But all those unique tiles are of course using CHR space.

in the simplest terms? Another Dragon Quest clone.

Then MMC3 would be fine for you. Perhaps even overkill. The Dragon Warrior games like "worse" mappers.

Holy crap, how do you guys know all this stuff right off-hand?

It's fairly easy to look up: http://bootgod.dyndns.org:7777/advanced.php

But anyone who's done this has for a while has likely studied and will remember how certain games did things.