ROMs and Mappers: Why NES Games Can Be So Different On The Same Hardware
time for another LONG POST
The Nintendo Entertainment System, as all gaming fans know, was a hugely successful console despite not being especially powerful even when it was new. Its popularity endures decades later. Its 2A03 processor ran at less than two megahertz, and it had exactly two kilobytes ā yes, two kilobytes ā of general purpose RAM. If youāre a retro gaming fan, youāve doubtlessly played games that seem far too complex and technically impressive to possibly work under such constraints. How did they manage it?
If youāve played many NES games, youāve also noticed that they vary vastly in graphical quality and how much content they have to enjoy. Some of them are just cheapie budget games of course, but thereās more to it than that. Letās compare some of the first few games Nintendo itself published with some of the last.
Here are screenshots of some of the first few games Nintendo published for its own console:
And here are some of the last few games Nintendo published for the NES:
The early games donāt look badĀ per se, but their visual language is overall much more limited. The backgrounds are very minimal, mostly just black voids. The screenshots of the early games are representative of what those entire games look like, while the screenshots of the late games show just a fraction of what there is to enjoy. I especially encourage you to look at a video of Kirbyās Adventure if you havenāt seen it before: it practically could pass as a 16-bit SNES platformer!
Now, of course some of this difference just comes from the ever-increasing experience of people working on games. Over the course of the NES era, artists came around to the conclusion that outlined sprites look much better than flat color sprites. Compare Super Mario Bros 1 with Super Mario Bros 3, which has much more visual clarity. Thatās something that they could have, in principle, done from the beginning, but it had to be learned from experience. They also learned lessons about how to put together easy-to-use menus and interfaces.
Most of the differences however cannot be accounted for by learning alone. The NES was well-designed: highly affordable, with minimal hardware, but a special trick up its sleeve. The game cartridge can bring its own expansion hardware!
If you look at a physical NES cartridge, you will see that it has a wide connector with manyĀ āpinsā. The console and the cartridge can two-way communicate over these pins. This is different from media such as compact discs, which the console can read from but not write to. If you open up a cartridge, you will find an entire circuit board inside. This circuit board can have basically anything that you can put in a full 8-bit computer attached to it. Even more RAM! In fact, this is how saving works on the NES games (such as Legend of Zelda) where you can save your game: it has extra RAM on the cartridge, and a watch battery to keep the RAM contents from fading when itās not getting external power. (In modern times, we use flash storage, which doesnāt need to be kept powered.)
I said that the NES has two kilobytes of built-in general RAM, but that doesnāt mean it can only count to two kilobytesā worth. The NES has a largeĀ āwindowā of address space which is available for the cartridge to fill how it sees fit. Specifically, there is a 32 kilobyte window for the gameās program code and an 8 kilobyte window for its graphics. TheseĀ āwindowsā can be filled with ROM (read only memory) or RAM on the cartridge. The NES itself doesnāt really know or care. The real magic is this: a cartridge can have more thanĀ 32 kilobytes of code or 8 kilobytes of graphics. It just has to switch out the code and graphics in chunks. It has to do this itself with a microcontroller on the cartridge connected to the ROM and RAM chips. This microcontroller is called the mapper.
Super Mario Bros 1 is an instructive game to look at because itās essentially the most complicated a NES game can be without a special mapper. Nintendo called mappersĀ āmemory management controllers,ā or MMCs. We say a cartridge hasĀ āMMC0ā (thatās a zero) if it doesnāt actually have anything special toĀ ābankswitchā between different ROM and RAM chips. If you look at a ROM file that youād use in an emulator, youāll see that Super Mario Bros 1 is 41 kilobytes. Take off one kilobyte because thatās the header added so that the emulator knows how to load the game. That leaves 40 kilobytes: 32 kilobytes of program ROM and 8 kilobytes of graphics ROM. That fills the cartridge memory window exactly.
How much graphics is 8 kilobytesā worth? Itās exactly 512 tiles, which are 8x8 pixels each, supporting four colors per tile. The 512 tiles are divided into twoĀ āpagesā: 256 for sprites and 256 for backgrounds. Super Mario Bros 1 is a masterclass in getting the most gameplay out of the fewest graphical components. Famously, the bushes and clouds are actually the exact same graphical tiles with different color palettes applied. (If I went into how coloring works on the NES, weād be here until the sun goes supernova. Suffice to say, the cloud/bush tiles only need to be stored once, not twice, despite appearing in two different colors.)Ā
Literally dozens of different mappers were developed and in fact are still developed to this day by pirates and homebrew enthusiasts. The completely plug-and-play nature means thereās nothing stopping someone making a new mapper with new features, and the NES will happily work with it. Part of the reason emulators often have trouble with obscure or pirated games is that the emulator needs specific support for every mapper, since itās emulating the mapper chip itself as well as the NES. Some mappers are much more common than others of course; many of the best-known games use MMC1 or MMC3.
Super Mario Bros 3 is an MMC3 game. If you check the ROM file, it is a little less than 400 kilobytes. Quite a bit of that, 128 kilobytes, is different pages of graphics. SMB3 has much, much more graphical variety than SMB1. The different worlds actually look like completely different places, rather than the same place but in a different color. 256 kilobytes contain all the code and non-graphical data such as the music. Again, only 32 kilobytes of it can be loaded at a time. The game code tells the mapper microcontroller what changes to make as it executes.
Thereās more to MMC3 than just facilitating this swapping around. It brings entirely new hardware features to the NES. The NESā built-in support for timers isā¦ extremely limited. MMC3 has its own timer that can be used to achieve special graphical effects. It may be trifling by modern standards, but on the NES, having a status bar that stayed still while the game background scrolled was a special effect! This timer is also at play during the minigames in Super Mario Bros 3 which split the screen three different ways. It was a very impressive effect at the time.
So, now you know how cartridges can bring their own hardware to bulk up the NESās meager capabilities. You may be wondering: why didnāt they just do this all the time? Why didnāt Super Mario Bros 1 have the same fancy mapper as Super Mario Bros 3?
The answer is raw monetary cost. ROM and RAM chips cost an appreciable amount of money, but, that cost dropped rapidly over the NESās lifetime. Each year, you could fit more kilobytes of ROM on your cartridge for the same price. Hence, Super Mario Bros 1ā²s design of exactly filling up the memory window and not one byte more was the best financial decision at the time, but the wise cartridge design of the NES meant that games could and did get steadily larger and more complex. Homebrew and multicart games can reach into the megabytes, which is on par with the small end of entirely modern games. The Game Boy had the same type of cartridge design and followed the same arc.
It really is incredible how much an 8-bit toy computer can achieve!
If youād like to learn more technical details, check out the nesdev wiki. This post was written out of my personal experience as a hobbyist programmer for NES.
