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):

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 sure why asking about MMC1 or MMC5 is a weird first question? Are the chips not what's giving sprites limitation?

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.

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.

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.

Who is online

Users browsing this forum: No registered users and 1 guest

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum