MMC1-5 Graphic Limitations

I have searched the form but I can't find exactly what I am wondering.
It's about the MMC chips and graphic limitations.
MY understanding is that the MMC1 chip could only give you 256 sprite tiles and 256 background tiles. NO MORE.
And if you wanted more sprites use the MMC5, which could give you 16,384 sprite tiles and 16,384 background tiles?
is that correct? or way off.

I ask because I'm not sure how Ghostbusters II used the MMC1 chip, and has about 512 sprite tiles, and probably 1000+ background tiles. Those are a guessed number from looking at the tiles in YY-CHR. But it is def more than 2 sets of tiles for the game. So... really confused if it used the MMC1 chip.

I guess my real question is, is 256 sprites the limit of tiles that a MMC1 chip can handle? Or what am I missing.

The NES, in its pure basic form, supports a total library of 512 tiles.

Either the first or last 256 of those can be used for the background.

The first or last 256 can be used for sprites, OR you can use bigger sprites (automatically gluing two tiles together vertically) and be allowed to use any one of 256 different tile pairs. (256 two-tile pairs is ... 512 tiles).


Now, additional hardware on the cartridge can allow you to draw more than 512 tiles over time.
The first piece of additional hardware allowed the programmer to switch which library of 512 tiles was used at a time. (This first version was what we refer to as mapper 87. Shortly after it was followed by CNROM) But only being able to control groups of 512 tiles is really restrictive...


Later hardware started adding the ability to divide the 512 tile access window into multiple "banks". Many of these early mappers—which includes MMC1—support the ability to control the first and last 256-tile "bank" independently. This means that you could change what set of tiles were used by the background and sprites entirely independently.


Later mappers provided more-and-more fine-grained "banking", ultimately arriving at the "most cost effective" ability to control eight independent 64-tile banks. This allowed for using some tiles for fixed backgrounds, some tiles for animated backgrounds, as well as changing banks according to any given actor is doing on-screen at a time.


The MMC5 supports an advanced mode where an extra six bits per tile selector are made available to select one of 16384 tiles. However, because the MMC5 was so expensive, and the NES graphics weren't improved that much by this feature, and this required twice as much data to be written to update on-screen tiles, it was extremely rarely used.


All of this is entirely ignoring the approximately 25% of all games that used RAM to store their tiles, which allow for much more sophisticated effects, such as in Solstice or Battletoads.

I don't know what "MMC1-5" (Subject) is supposed to mean, especially when compounded with what appears to be (respectfully) misunderstanding of the actual NES's specs to begin with. lidnariq did a great summarised write up, so I'll leave you with documents for each of the Nintendo MMCs so that you can see which ones "extend" the graphical capabilities (hint: only one does):

http://wiki.nesdev.com/w/index.php/MMC1
http://wiki.nesdev.com/w/index.php/MMC2
http://wiki.nesdev.com/w/index.php/MMC3
http://wiki.nesdev.com/w/index.php/MMC4
http://wiki.nesdev.com/w/index.php/MMC5
http://wiki.nesdev.com/w/index.php/MMC6

What prompted this question, especially since this is your very first post on this forum? Are you planning on doing development, or...? If so, and you haven't worked on the console before, I would suggest staying away from MMC5; IMO it doesn't make a good "starter" mapper. Try MMC3 or MMC1.

The standard limitations of 32KB of PRG and 8KB (512 tiles) of CHR exist because that's what the NES was designed to see at any given time. These limitations were adequate for the time when the console was designed, and memory was probably still expensive enough to discourage anyone from considering breaking these limits.

As memory got cheaper, cartridges started to pack more data, but the NES still could only see 32KB of PRG and 8KB of CHR, because that's how the system was designed, so memory mappers were created to change which 32KB of PRG and which 8KB of CHR the NES would be able to see over time.

Most games are restricted to 32KB of PRG and 8KB of CHR at any given time, but they can swap out sections of data and map new data in over time... Sometimes between levels (e.g. you don't need ice graphics mapped in while playing a desert level), sometimes between frames (e.g. if the player is jumping, you don't need its running graphics mapped in) and sometimes even within the same frame (e.g. the gameplay area uses a different tileset from the status bar).

So yeah, if you look at any ROM larger than 40KB (32 + 8) in a tile editor, you're likely to see more than 512 tiles, even though the NES can still only use 512 at a time.

The MMC5 takes the concept of switching tiles mid-frame to a whole new level, by automatically switching between different tilesets depending on what the PPU is processing. The MMC5 is capable of snooping at the PPU's work so it knows when it's reading background tiles and when it's reading sprite tiles, so it can serve different data to the PPU depending on this. The result is the illusion that the NES can see more than 512 tiles at a time, but it's actually just really fast automatic switching. The MMC5 can also add extra bits for background tile selection, making it possible to address 16384 background tiles at any time instead of the usual 256. No other mapper offers enhancements this advanced, AFAIK.

Thank you for all the information guys. I was asking from an artist point of view, not programmer... I have lil knowledge about the hardware, which is why I'm trying to figure out what my limitations are for drawing sprites and was wondering how other games got more than 250 after peaking at some from a rom. Yes this is my first post, I have been drawing for years, but never looked into how the NES works until this week. Gotta start somewhere. Not sure why asking about MMC1 or MMC5 is a weird first question? Are the chips not what's giving sprites limitation? good to know if you ask me : / Anyways, now I know more, thanks : )

If you make a game for MMC5, it will be limited to emulators - no (new) physical carts for that mapper.

Not necessairly, doing new physical carts for MMC5 would be very difficult but not impossible - the Power Pak already supported an unnoficial MMC5 subset that was enough to get Just Breed working fine, if I remember well.

I intend on keeping it simple either way, trying to figure out my best options are with graphics and such. For now I'll stick with drawing 256 spites and same for background to get started. Knowing whats going on with the hardware is a good reality check for artist.

If you use some tiles only at the beginning of a level and other tiles only at the the end, you can rewrite CHR RAM mid-level. Haunted: Halloween '85 does this, and it's on the simplest possible mapper (BNROM workalike). The limit is 256 background tiles visible at once.

Not really. The great majority of mappers does very little to improve the graphical capabilities of the system. The MMC5 is one big exception. Others only offer more subtle features, such as IRQs (useful for timing raster effects) and the ability to switch blocks of tiles instantly, or nothing at all. One of the most impressive games on the system, Battletoads, uses a mapper that offers absolutely no graphical enhancements at all. It simply used RAM for tiles instead of ROM (as did ~25% of the library), allowing the game to manually overwrite tiles little by little over time. All effects in that game are pulled off without any assistance from the mapper.

Better than looking at games in a tile editor, using an emulator to debug the PPU as the games are running will give you a much better understanding of how NES graphics work. Use FCEUX's PPU viewer and name table viewer while a game is running and you'll have a much better understanding of what games do with their tiles over time. Older games like SMB will have static tiles all throughout the game, but many newer games will dynamically change the tiles as they run.

Many artists feel tempted to use the MMC5 when they first learn about the limitations of the NES, so that the constraints aren't so severe, but the MMC5 is a poor representation of what the NES is all about. It wasn't a common mapper, meaning that there are few of them floating around, it's a very complex piece of hardware (compared to other mappers), so support for it in flash cards and such is limited, and nobody has made a proper replica it to put in new cartridges yet. If an artist or coder feels like he absolutely needs to use the MMC5, that might mean they choose the wrong platform for their game.

Well I choose the Nes because I WANT the restrictions. It's an interesting challenge. It's the whole reason I started this project. I plan on avoiding mmc5 anyway. I assume people think I'm trying to look for a way to get the most sprites possible, but that's not the case and defeats the purpose of working with the NES - Couldn't agree more. The only reason I compare mmc5 with MMC1 is because I was trying to find out how some games had more than 256 sprite tiles, a middle ground, between 256 tiles and 16384 tiles. lol Just a bit of fun for me guys, reflecting and learning how the developers used to make my favorite games as a kid. I appreciate all the replies and patience. I'm not trying to figure out how to program the NES myself, but it's a nice thing to understand the basic so I'm not over drawing and wasting a programmers time. No need to have a convo about the challenge of finding a programmer. I already know a couple who work with the system, just trying to get some knowledge before having a chat with them. I'd like a nice set of tiles to start with. Which all comes back to this post you guys have been guiding me through, Thanks!

Edit: thanks for the FCEUX's PPU viewer idea! I will def give that a look. This whole thing went from me trying to draw some sprites to gaining interest how it was all put together! good times.

Just in case it's unclear; I didn't see anyone else mention it.

The NES can only produce 64 sprites on any given frame. This is either 64 or 128 tiles (depending if the double-height sprite mode is enabled).

Oh yeah. 256 tiles is what you have available to use on sprites at any given time, but since calculating their positions and fetching their graphics takes time from the PPU, it can only handle so many actual sprites per screen. The maximum is 64 sprites, but since they can be configured to be either 8x8 or 8x16 pixels, the total amount of visible sprite tiles can be 128.

Another important sprite limitation is that you can only have 8 of them visible in the same scanlines. If you try to put more, they won't show up. Keep this on mind when designing the game, to avoid placing many wide characters/objects in a row.

Nice, and that is what causes the flickering? or no?

Flicker happens when games alter the order in which sprites are drawn from one frame to the next to keep a different set of 8 sprites in front. Otherwise, sprites or parts of sprites would just become flat-out invisible at times ("drop-out"). Collisions with an invisible enemy are infuriating "bullshit", as the Angry Video Game Nerd would call it. Flicker is probably the least bad way to handle the PPU's sprite limit without dropping sprites down to 8 pixels wide (as was done in Smash TV). But at least be grateful that the NES PPU has enough sprite slots that the flicker isn't quite as bad as in Pac-Man for Atari 2600.

Like tepples said, sprite flicker is not automatic. Every scanline, the PPU searches through a list of 64 sprites (OAM) looking for the ones it must display, from slot 0 to slot 63. When it finds 8 sprites, it simply stops looking, so any sprites after that are not visible all.

This means that lower numbered sprites have higher priority, and higher numbered sprites have lower priority. Programmers explicitly cycle the priorities of the sprites every frame so that different sprites are dropped each frame, and this is what causes flicker.

Very cool. OK so I hate to beat a dead horse, but I'm trying to give myself a "guideline template" if you will, to work within.
This is obviously a dumb down over look, but hopefully serve as a kind of reference guide for someone more interested in the art limitations and not deep understanding of specs. So forgive me, and all corrections of my ignorance is welcome : P

256 tiles for movable sprites.
256 tiles for background.
Sprites can be built with 8x8 or 8x16 pixels, depending on preference.
128 total visible tiles on screen at a time.
More than 8 on the scan-line will result with flickering. decent to keep in mind when thinking about level design and how not to piss players off : )

Depending on hardware and programmer, you can rewrite CHR RAM mid-level. Which means you can have more sprites if you need? So with rewriting in mind, would it be safe to say, an artist could draw 512 movable sprite tiles, and 512 background tiles that could be used in the game?

It's worth noting that this setting is universal, you can't mix 8x8 with 8x16 sprites, it's either one or the other.


This is for sprites, if you use all 64 8x16 sprites.


CHR-RAM can be changed mid-level, but it's slow and not many programmers are willing to deal with the complications. Alternatively, a mapper like the MMC3 can instantly switch chunks of 64 or 128 tiles at a time, and this was commonly used for animating backgrounds or a select number of objects (mainly the player).


If you're gonna be rewriting CHR-RAM or bankswitching CHR-ROM, the total number of tiles you can have is only limited by the final ROM size. These numbers you have are actually quite small considering that many games had 128KB (8192 tiles) or 256KB (16384 tiles) of CHR.

Ah yes, I just tried to keep a small number for beginners. But thanks for your input good sir : ) Think there is anything missing? For an artist to keep in mind or should be concerned about?

At the moment, I can only think of limitations related to scrolling. Are you planning on scrolling? In how many directions? How big will leveled be?

Actually, I assume it is scrolling yes. In the question I mention ghostbusters II, that is because, the first two levels are similar to how I plan on my first two levels. One level is "run and gun" - go left or right, and the second level you are in a car, still the basic same type of scrolling? That's my starting point for sprites. I would like to mention, because I like seeing it, is anything complicated involved when you see inside a house like Friday the 13th? Maze-like walls. I wouldn't mind a couple parts like that, but that is just ideas floating for later.

Edit: I did think of something to ask, how about overlapping tiles? is that common? It's something to think about while designing tiles and how they will fit together as a sprite.

Perspective walls? It's "complicated" as you aren't just copying a tilemap so much as deciding what to copy. Art-wise…well, I haven't

Palette limitations.

Background tiles can have one color shared between all, and each 16x16 grid square can have one of the four palettes, each of which has three other colors.

Similarly, sprites all have transparent and their own separate four three-color palettes. (Each sprite picks one palette.) Of course, these don't have to be aligned to any grid.

These colors are drawn from the…52? colors total that the NES PPU allows. I don't have the palette handy, as they tend to vary by TV.

You can overlap sprites (Megaman does this to give his face extra colors, using sprites with different palettes) but it counts no less against the per-line and total spritelimits.

Scrolling doesn't impact the design of the graphics very much, but scrolling in multiple directions can be complicated, and some programmers may ask artists to design the levels in more specific ways in order so the scrolling code can be simpler. If you plan to scroll in one axis only (either horizontally or vertically, never diagonally), you don't have much to worry about.


It's not particularly common because of the 8 sprites per scanline limit, which is met quicker if you start stacking many sprites.

That true! how can we forget the color palettes! lol I have that stuff stored in my brain now, should have thought to put it here.

Yeah I wanna just side to side anyway, should make things easier.

As of now, the sprites are gonna be stacked together, but I was thinking about a run cycle, the top of the body being 2 tiles and the bottom of the body being 2 tiles, and they meet in the middle making 3 tiles tall, and 2 tiles wide perhaps. From an animation point it would be ideal for me because I always connect my legs with the torso to fit that way lol but before I do it, i'd like to know if thats a pain in the ass to work with lol.

Yes. Haunted: Halloween '85 has a sprite page with 512 different 8x16 pixel sprite tiles, though only about 416 are used. And each of its levels has 300 to 500 8x8 pixel background tiles, though the data conversion tool ensures that more than 256 aren't used on the same 264-pixel sliding window (1 full screen width plus 1 partially displayed tile).

Thanks for that, I been wondering what kinda sprites people have been working with. Very interesting stuff.

You can do that, but keep in mind that in the section where the top and the bottom overlap you're gonna have 4 sprites sharing the same scanlines, and that's half of your entire budget for a scanline, used by a single character. This is not necessarily bad, many games use a lot of sprites in a single character... Astyanax for example, when player attacks with the axe, its graphics use up to 7 sprites in some scanlines, leaving only 1 for everything else! Just be aware that this can greatly increase the presence of flickering.

This is true, I think I'm still underestimating the scanline budget. lol I spent most of last night re designing the tiles to stack instead of layer. I'm finding it's working out better that way, I'm using less tiles (done a lil adjusting so a lot more tiles are duplicates.) Liking it better than the layered sprite first planned : )

4 sprites per scanline on 1 object/character isn't so bad... even Mega Man has frames with 5 sprites on the same scanlines due to the overlaid face. I usually limit my own characters to 4 tiles per scanline, but I try not to worry too much if I have to use 5 or even 6 on some occasional frames. Another game that got away with using a lot of sprites per scanline is Felix the Cat... not only Felix can use all sorts of vehicles and attacks that consume a lot of sprites, but the game can only display 7 sprites per scanline instead of 8, because it uses a tall column of solid black sprites on the far right of the screen to hide background scrolling glitches!

Man i love Felix the cat! I was playing it recently actually loll. Gonna take a look at it again with scanlines in mine.

Be sure to check if your emulador isn't configured to allow unlimited sprites per scanline, sometimes they come like that. It's an "enhancement" that eliminates flickering, but breaks some effects that rely on lower priority sprites disappearing. Felix the Cat is actually an example of this: when Felix goes inside a bag, he's supposed to disappear he moves down, but in many YouTube videos of the game the effect is broken.

Our wiki has a page listing games that have masking effects like this.

EDIT: Koitsu beat me to it.

Re: sprite overflow / unlimited sprites per scanline: here's a list of games that break if you turn such a feature on, and what the effect is: https://wiki.nesdev.com/w/index.php/Spr ... flow_games

I been wondering about that, if emulators affect the game somewhat. I've seen with a couple games the sprites arnt exactly how they are suppose to look. Minimal but notice things looking stretched almost by a pixel or two.

Another common thing they do (also evidenced by YouTube videos) is crop to top and bottom 8 scanlines of the picture, reducing the vertical resolution from 240 to 224. The NES ALWAYS outputs 240 scanlines, but NTSC televisions often hide some of the top and bottom, conveniently hiding glitches that some vertical scrolling games have. PAL televisions usually show the whole picture, though.

Those scanlines never have anything important (developers knew that they could be hidden by the television), so this doesn't affect gameplay in any significant way, but as a developer, I like to see the entire picture that my programs are generating, so I always change this in the emulators I use.


Many emulators don't simulate the correct pixel aspect ratio of the NES. Computer pixels are usually square (1:1), but NES pixels are slightly wider: 8:7. This means that the correct picture is slightly stretched horizontally (reference).

As an artist, another thing you should take into account are NTSC artifacts. The PPU uses some cheap tricks to generate the video signal, and that results in funny effects depending on the colors of neighboring pixels. Always try to preview your graphics under blargg's NTSC filter (many emulator have it, but if for some reason you can't make a ROM with your graphics, you can use this) or on a real NES to make sure that your colors and patterns aren't doing anything undesirable. In many cases you can use the NTSC artifacts to your advantage, because they can create the illusion of more colors and textures (scroll this page down to the Solstice screenshots and look how the composite shot has much more depth, texture and color than the crispy clear alternatives - the folds on his clothes, the volume of the hands, the texture of the block, etc.).

This is the best forum, you guys know everythinggggg, thanks man.



I haven't tried to make a ROM, I do need to learn. I have worked with other stuff that's irrelevant to this forum, but never with NES or assembler, so I wouldn't know where to start to make a ROM yet. But I should start looking into it. Although I wanna put my focus into the art, getting a ROM up and going just to preview art would be ideal. hmm