When Nintendo developed the Famicom in 1983, they chose a derivative of the MOS 6502, called the Ricoh 2A03, as the CPU for the system. This was a very reasonable and safe choice for multiple reasons.
1) The 6502 had been developed by MOS Technology specifically to be economical for low MSRP devices.
2) Six years earlier, the Atari 2600 had basically established the home video game market and was still dominant. The Atari 2600 also used a derivative of the 6502 for the CPU, called the 6507.
3) The simple instruction set for the 6502 made it fairly easy for programmers to write games in raw Assembly code.
4) Since the data bus for the 6502 uses 8 pins, it is called an 8-bit processor. However, there are 16 address pins, which means that the 6502 can directly address 65,536 bytes of information, or 64 KiB in modern tech parlance. This may not seem like a lot in 2021, but it was plenty in 1983.
(In the interests of legibility, the unit representing 1024 bytes — “kibibyte” or “KiB” — will be abbreviated as “K” for the remainder of this article.)
The claim in reason 4) is the crux of the whole thing, and it deserves a little bit of a detailed explanation. Consider the fact that the two best-selling Atari 2600 games of all time (Pac-Man and Pitfall!) were both released in 1982, and both fit onto 4 K cartridges. Pac-Man sold 7,700,000 copies and Pitfall! sold 4,000,000 copies. For reasons slightly more technical than I wish to go into here, 4 K is the natural limit on the size of an Atari 2600 game, which was typically housed in a single chip inside the cartridge.
So, Nintendo concluded, 64 K should be plenty! After all, it was sixteen times more than what was needed for the top two games from their main competitor. In fact, they were so confident that it would be enough that they, like Atari, gave up a factor of 2 and accepted a 32 K limit on the game size for reasons explained down below. Unlike the single ROM chip inside an Atari 2600 cartridge, standard Famicom games took physical form in two chips: PRG-ROM and CHR-ROM; I.e., program memory and character memory. Program memory is where the code for the game resides, as well as level data, music data, etc. All of the graphics data on an early Famicom game was stored in character memory.
Generously (or so they thought), Nintendo allocated 8 K for CHR-ROM, for a grand total of 40 K of ROM available on a standard Famicom game cartridge. The 8 K of CHR-ROM is further split into two 4 K chunks, corresponding to background graphics and sprite graphics. The Famicom also has 2 K of RAM on the motherboard that the CPU can use for game state. The remaining 30 K of CPU address space was either wasted (“mirrored”), available only with some sort of memory mapper/decoder, or spent on I/O port numbers for programs to interface with other components on the motherboard, such as the sound and graphics systems. Altogether, this 40 K of ROM was only ten times more than the maximum 4 K for a standard “large” Atari 2600 game, but ten times sounds pretty good, doesn’t it? Nice round figure that can be thrown around the board room, if not marketing materials. This standard Famicom cartridge configuration came to be known as NROM.
The problem was that Nintendo became too successful with the Famicom. As it turned out, the gods frowned upon Atari and smiled upon Nintendo, because Nintendo developed the Famicom right as the video game market was crashing in the USA. Atari started posting enormous quarterly losses, which put the company on the brink of destruction. After Nintendo re-skinned the Famicom and called it the Nintendo Entertainment System for release in the USA in 1985, it took off in popularity so fast, and so intensely, that it basically sealed Atari’s doom as a console maker.
At this crucial juncture, Nintendo’s Super Mario Bros. came out and took the world by storm. There were some games released by 3rd party developers in this early period of the Famicom/NES, but none of them seem particularly notable compared to the games that Nintendo themselves developed. Other games developed in-house by Nintendo at this time included Duck Hunt, Excitebike, Ice Climber, and Gyromite. All of these games took up 40 K or less of ROM on the cartridge since NROM was the only cartridge type available at the time.
Due to the enormous initial success of both the Famicom and the NES, Nintendo had a difficult decision on their hands when looking to the future. Should they engineer and release a new console, one that would probably have to be incompatible with the old one whose games were selling so well? Should they sell an upgrade module to the original NES? Should they ride the wave of success as long as possible in the hopes they could create the NES’s successor before a competitor swooped in and did to them what they had done to Atari?
As it turns out, they first tried the 2nd option. The upgrade was called the Famicom Disk System, and it was a bulky floppy drive that plugged into the Famicom’s cartridge slot via a special adapter cartridge and cable. The Mitsumi Quickdisk-based floppies for the FDS supplied 56 K per side, and were double-sided; thus FDS games could be up to 112 K in size. That’s almost triple the 40 K ROM size limitation of NROM, so this was a substantial improvement. However, the FDS only had a single drive head, so using both sides required ejecting the disk, flipping it over, and re-inserting it from time to time during the game. (This was common in the 1970s and 1980s with various spinning media.) A few FDS games were shipped on multiple disks, pushing the size (and tedium) even further. Even for the single-disk games, load times were definitely long and very annoying…an experience utterly foreign to those of us that grew up playing games on the NES instead of the Famicom.
It comes as a surprise to many Americans to learn that some of their favorite NES games actually debuted on the FDS. These include some of the most successful and iconic games that established franchises, such as The Legend of Zelda, Metroid, and Castlevania! In particular, the save game features of Zelda and Metroid started off identically, and both relied on writing to the floppy disks. When these games were later ported to the NES, Zelda’s save game feature was adapted to use battery-backed RAM, while Metroid was given the password system treatment instead.
Fortunately or unfortunately, the FDS was never released for the NES. This may have been in part because the cartridge adapter part of the FDS, having been designed for the toploading Famicom, was not a very good fit for the frontloader design of the NES. It was definitely due in part to the fact that mask ROMs became progressively cheaper throughout the 1980s. By 1987 or so, cartridges could be produced profitably that rivaled the 112 K maximum of the FDS disks.
And so, when Nintendo decided to port Zelda, Metroid, and other “large” FDS games to the NES, they had to face the fact that NROM simply wouldn’t do. So they resorted to a technique that was becoming popular in the 8-bit era — bank switching. Bank switching is a memory expansion technique that subdivides the address space of a processor into “banks”, which are mappable to equally sized regions of a larger memory device. The term “larger” here simply means that the ROM or RAM in question contains more data than the processor can natively address. By switching a given bank out for another during execution according to logic programmed into the game, it is possible for the processor to effectively have an expanded address space. Essentially, it’s like upgrading the CPU by adding on to it instead of replacing it outright. It is worth noting that bank switching, while not instantaneous, is very fast — usually measured in tens of CPU cycles. In the context of the NES’s 1.79 MHz CPU, this means a small fraction of a millisecond. Once the switch is complete, all of the data is available for random access. It is therefore quite different than the concept of (serial) “loading”, the way that the FDS operated. Also, note that thinking about loading data from an FDS floppy disk as a “bank switch” would mean that it takes about 1 second to switch out a single 8 K bank. This is about 300,000 times slower than “normal” bank switching on the Famicom/NES in the post-FDS era.
To facilitate this bank switching physically and make it easy for the game programmers to do it, special chips were created called memory mappers. Technically speaking, it is possible to map memory without resorting to bank switching (for example, by facilitating serial loading, or simply having a static mapping). But in the NES development/enthusiast community, the terms are used almost interchangeably in the sense that a memory mapper is assumed to exist primarily in order to allow rapid bank switching. The first two significant and successful memory mappers for the Famicom/NES were called MMC1 and UNROM. After that, it was off to the races; each new memory mapper that was created unlocked more and more potential of the system, ushering in the creation of better and better games.
To give a quick overview of the original Famicom/NES commercial era from the perspective relevant to this article, a reduced list of the memory mappers which were used for various games will be accompanied by a very subjective assessment of the five best (or at least notable) games that used each mapper. The true and full history of this subject is somewhat complex, and probably only interesting to the truly nerdy among us. For instance, technically speaking, the first memory mappers were not single chips…and the first one came out just barely before the FDS. Many memory mappers also provide other enhancements that can improve the graphics and sound in a more direct fashion than simply granting access to more ROM space. However, such features are outside the scope of this post. A simplified narrative captures the essence of the history of gaming on Famicom/NES far better, so no further apology will be given.
NROM (r. 1983) – Maximum of 40 K of ROM — Duck Hunt (24 K), Ice Climber (24 K), Excitebike (24 K), Galaga (40 K), and Super Mario Bros. (40 K)
CNROM (r. 1986) – Maximum of 64 K of ROM — Tengen’s Tetris (48 K), Solomon’s Key (64 K), Mickey Mousecapade (64 K), Mighty Bomb Jack (64 K), and Spy Hunter (64 K)
UNROM (r. 1986) – Maximum of 256 K of ROM — Castlevania (128 K), Rygar (128 K), Metal Gear (128 K), The Guardian Legend (128 K), and Paperboy 2 (256 K)
AOROM (r. 1987) – Maximum of 256 K of ROM — Marble Madness (128 K), Solstice (128 K), R.C. Pro-Am II (256 K), Wizards & Warriors II (256 K), and Battletoads (256 K)
MMC1 (r. 1987) – Maximum of 512 K of ROM — The Legend of Zelda (128 K), Metroid (128 K), Overlord (256 K), Final Fantasy (256 K), and Dragon Warrior III (512 K)
MMC3 (r. 1988) – Maximum of 768 K of ROM – Super Mario Bros. 3 (384 K), Mega Man 3 (384 K), Déjà Vu (384 K), Startropics* (512 K), and Kirby’s Adventure (768 K)
MMC5 (r. 1989) – Maximum of 2048 K of ROM – Castlevania III (384 K), Romance of the Three Kingdoms II (512 K), Uncharted Waters (640 K), Just Breed (768 K), and Metal Slader Glory (1024 K)
* Startropics is technically an MMC6 game, but MMC6 is exactly the same as MMC3 with an additional 1 K of save RAM on the cartridge.
There were many more memory mappers than this used back in the 80s and early 90s, but I have excluded most of them because these were the “main” ones both in the sense that Nintendo themselves made them and in the sense that most of the games released for the system used one of these 7 mappers. (According to one calculation, about 89%.)
A few key observations can be made immediately, simply by looking at the above list:
- As time progressed, new memory mappers were released which provided access to more and more ROM space.
- The games improved dramatically (at least graphically) as that was occurring.
- Mappers always “led” the games; most new games that used a specific mapper did not fully exploit it.
- The engineering of official Nintendo memory mappers for the Famicom/NES halted in 1989, establishing the fun fact that every official Nintendo mapper was created in the 80s.
As I’ve said, the full story is complex. Extra ROM space does not necessarily make a game better, because it depends on how it’s used. The game creators can choose to use that extra space simply to give the game more levels, for instance. Or they could choose to spend it on more sophisticated music. Or, as I’ve implied in the 7-panel image above, they could spend it on more “entropic” (detailed) graphics. Usually, it was a combination of all these things…but not always. The path from the base of the NES mountain to its summit was winding, rocky, and treacherous.
It would be nigh impossible to prove with mathematical rigor, but it is self-evident that a game like Castlevania III is practically out of reach on an NROM cartridge. You simply could not squeeze a sophisticated (and already compressed) game that takes up 384 K into a 40 K space, let alone 512 K, 768 K, or 1024 K. But similar statements hold for most of the games at the 128 K level as well. Because of this practical (if not mathematical) impossibility, most of the games in the NES library released after 1987 would not exist if not for the memory mappers that were used to create them. That set includes the vast majority of the ones you’re likely to remember with fondness. The logic is inescapable — memory mappers define the experience of the NES as much as the base system does!
In other words, size matters.
Mappers matter.
If we exclude NES homebrew, that’s where the memory mapper story ends, because of the advent of the Super NES. The Super Famicom was announced in Japan with images of a prototype in late 1988, with full commercial release occurring in Japan in late 1990. Its re-skinned American counterpart called the Super NES was released in late 1991. It is beyond debate that the SNES was vastly more powerful than the NES in just about every way. Despite this, the NES kept selling consoles and games all the way into 1994 in the USA — and past that point in other parts of the world. But Nintendo released no new mappers for the Famicom/NES in the last 5 years of the system, because they wanted to focus attention on the SNES. On the SNES, the role of memory mappers was greatly diminished because of the nature of its CPU. Nintendo again commissioned Ricoh to create a CPU for them: the 5A22. This next-gen chip was based on the 65C816 — a 16-bit processor that was in turn based on the 6502, and backwards compatible with it. The 5A22 has 24 address pins, thus enabling direct access to hundreds of times more memory than the 2A03.
So out of the gate, the first games on the SNES rivaled the largest NES games in size — and without the help of fancy memory mappers. The very first SNES game, Super Mario World, was 512 K. Again, this doesn’t seem like much these days but it was as large or larger than 95% of the games ever released on the Famicom/NES, and half the size of the largest one — Metal Slader Glory (1024 K). (As of the time of writing, there is an ongoing unofficial project to translate Metal Slader Glory into English and the resultant ROM size is about 1500 K, making it the largest NES game from the original commercial era by a factor of 2.) However, SNES games quickly rose in size and quality, resulting in juggernaut titles like Final Fantasy III and Chrono Trigger by 1994-1995. Those two games, in particular, were 3072 K and 4096 K respectively. The largest game for the system was Star Ocean, and it used hardware-assisted data compression to pack a 12288 K game into a “mere” 6144 K. It qualifies as the largest game for the SNES (technically, the Super Famicom) whether you consider its compressed or uncompressed form.
But what might have happened if the NES had been given comparable ROM sizes…or even bigger? Well, we can get a hint about that alternate timeline by looking at a little something called the TurboGrafx-16. Called the “PC Engine” outside the USA, it was released by NEC in 1987 in Japan, and 1989 in the North American market. (Thus, it directly competed with the Famicom/NES.) This video game console, despite bearing the lauded “16” number in its name, also had an 8-bit CPU based on the 6502 called the Hudson Soft HuC6280. To be fair, the “16” part of the name refers to the graphics subsystem, which was reasonably classified as 16-bit. Its CPU also enjoyed 4¼ times the clock speed of the NES’s — a healthy 7.6 MHz.
At a glance, it isn’t so obvious that the TurboGrafx-16’s graphics system is all that superior to the NES’s. The two systems have almost exactly the same resolution, and comparable color counts. More on that comparison in the next article…
However, for this article, one fact is relevant: the TurboGrafx-16 enjoyed a CD-ROM drive. In fact, it was the first video game console to have one. Initially called the CD-ROM² in expansion form, it was later integrated into the system and released as the TurboGrafx-CD. It debuted in late 1988, and made it possible to bring games to market that were hundreds if not thousands of times larger than typical cartridge games of the time. The result was the release of many games for the system with stunning graphics quality and full motion video cutscenes. Unfortunately, the TurboGrafx-16 was essentially a flop in the USA, selling under a million units for the base system, and about half a million units for the CD-ROM expansion. By comparison, the NES sold over 33 million units in the USA alone, and 62 million units worldwide. So if the base TurboGrafx-16 system was so superior to the NES, and unquestioningly superior with the CD-ROM drive added on, why didn’t it stomp the NES into the ground? After all, the increased ROM sizes for NES games made possible by better and better memory mappers did result in better and better games!
In my opinion, there are three reasons: 1) Marketing difficulties. 2) Game library quality issues. 3) Price.
The TurboGrafx-16 is just one example of a general phenomenon in video game, and indeed computing, history: better hardware does not necessarily sell better. The devil is in the details — especially marketing.
So again, returning to the question in a slightly different way: Given that the NES was able to defeat the TurboGrafx-16 with one hand tied behind its back, what would’ve happened if that other hand had been untied? I.e., what would’ve happened if the NES had had a CD-ROM drive expansion?
That is the question that Something Nerdy Studios intends to answer, and answer in the best way possible: with a brand new game for the NES that is the size of a CD-ROM.
In the next article, I will outline the company philosophy that led to the new MXM-0 memory mapper, and the first game that is being created for it:
Chronicles of Astraea: Former Dawn!
-Jared
Very interesting read, although I did skip a lot of the technical break downs as it goes over my head.
I’ve been eagerly awaiting the release of this game as it looks technically amazing. and the NES is one of my all-time favorite systems and still play it regularly.. well through emulation anyway.
Looking forward to one day buying this gem and I’m really excited to see what the community does with this new mapper once it goes open source. That is super awesome by the way, to invest this much work into something and then just hand it off for anyone to make use of. You know the love for the system is there when you’d rather hand off your hard work for free (the mapper) to see what others end up making with it than just keep it to yourselves.
Big fan and wish you guys all the best.