Mappers on Famicom, NES, Dandy: where did they come from and why are they needed (part 2/2)
Let's continue detailed conversation about “mappers”—expanded memory management devices on Famicom, NES, and Dandy game consoles. In the second part of the article, we will look at the features of several main types of mappers and their impact on the content of games, programming
Editor's Context
This article is an English adaptation with additional editorial framing for an international audience.
- Terminology and structure were localized for clarity.
- Examples were rewritten for practical readability.
- Technical claims were preserved with source attribution.
Source: original publication
Series Navigation
- Mappers on Famicom, NES, Dandy: where did they come from and why are they needed (part 1/2)
- Mappers on Famicom, NES, Dandy: where did they come from and why are they needed (part 2/2) (Current)

Let's continue detailed conversation about “mappers”—expanded memory management devices on Famicom, NES, and Dandy game consoles. In the second part of the article, we will look at the features of several main types of mappers and their impact on the content of games, programming difficulties, as well as the situation with mappers on other platforms.
▍ Review of mappers
As a result of the ups and downs in the market described in the first part of the article, as well as the participation of pirates, about two hundred varieties of mappers were created - from the simplest on one or two discrete logic chips of the 74th series, to very complex ones on custom LSIs, with a wide variety of capabilities. At first glance, it is not easy to understand this diversity, but the task is simplified by the fact that more than half of all existing games use only four mappers, which have several variations and analogues.
A brief summary of the frequency of use of various mappers:
| iNES | Name | Number of games | Notes |
| 1 | MMC1 | 448 | ASIC mapper |
| 4 | MMC3 | 437 | ASIC mapper |
| 2 | UNROM | 203 | A simple discrete logic mapper |
| 0 | NROM | 149 | Basic console configuration without mapper |
| 3 | CNROM | 122 | A simple discrete logic mapper |
| 7 | AxROM | 43 | Similar to UNROM, but 32 kilobyte banks |
| 16 | FCG | 18 | Similar to MMC3, only used in Japanese Bandai releases |
| 19 | N129, N163 | 16 | Advanced MMC3-like mapper, version N163 has an additional sound synthesizer |
▍ NROM (mapper 0)
The standard configuration in the list of iNES mappers is numbered 0. Therefore, it is often referred to as a “zero” mapper, but in fact this means the absence of a mapper and extended memory. It originated with the console itself and was used in all early games that were released before 1987.

In English-language amateur documentation, it is usually called NROM, after the name of the most common “mapperless” board manufactured by Nintendo. There are many similar boards from other manufacturers, but their names can be found mainly in the cartridge board database. The main identifying feature of boards with a similar configuration is that they only have two ROMs and a regional protection chip installed on the chips (except for the Japanese region, where protection is not applied).
Original NROM boards developed by Nintendo are found in two main versions - NROM-128 and NROM-256, differing only in the amount of ROM code, which is indicated directly in these names (in kilobits). They can be installed with 16 or 32 kilobytes of code ROM and 8 kilobytes of graphics ROM. Thus, the total memory capacity is 16+8 or 32+8 kilobytes.
Technically, NROM allows you to have configurations with a smaller amount of ROM. In this case, the extra lines of the address bus are not connected anywhere, and the contents of the ROM are repeated several times in the address space. Since the iNES format has fixed bank sizes of 16 kilobytes for code and 8 kilobytes for graphics, for configurations with a non-standard amount of memory, the contents of the ROM must be repeated several times, expanding the file to the standard size (the so-called overdump).
NROM does not have software control of the so-called mirroring - the configuration of the console's internal video memory. It is set only by a jumper on the board that selects horizontal or vertical organization. For emulators, this is indicated by the corresponding iNES header flags.
There are several exotic subspecies of NROM. For example, a configuration supported by most emulators with an additional 2 or 4 kilobytes of code RAM in the $6000..$7fff battery-powered region used for Family BASIC.

Running in a NROM configuration for games means they can only have so much code, music, and levels, and to fit more in, developers have had to make big simplifications and use clever compression schemes. For example, making similar locations from large cubes, like levels in Battle City or Nuts & Milk, or describing the differences in generally identical locations, like in Ice Climber. As for graphics, absolutely all of it must be made up of just 512 different blocks of 8x8 pixels. To increase visual diversity, recoloring of otherwise visually very similar locations was often used.
In the past, the main game that fully exploited the potential of the NROM configuration was the well-known Super Mario Bros (1985). Nowadays, a similar high-quality maximum, which raised the bar of what is possible even higher, was achieved in the game Micro Mages (2019), made in a completely different, modern visual style. Both of these games are distinguished by a large number of levels, a variety of game locations, as well as the presence of a full-fledged musical accompaniment, consisting of several fairly long and well-arranged compositions.
Some other famous classic games in this configuration:
- Bomberman (1985)
- Donkey Kong (1983)
- Lode Runner (1984)
- Lunar Ball (1985)
- Popeye (1983)
- Road Fighter (1985)
- Sky Destroyer (1985)
▍ CNROM (mapper 3)
The simplest mapper, born by repeating the first ever Famicom mapper from the game Hyper Olympic Gentaiban! (Track & Field in the USA). Began to be used in April 1986.
CNROM is a Nintendo board that implements a fully compatible but cheaper version of the original mapper. There are also several equally similar analogues from other developers, used on boards with other names. All of them are implemented on one discrete logic chip 74HCT161 (in the original there are two chips) and differ only in the different supported number of ROM banks. These variations are combined in the iNES standard under the common number 3, while their predecessor received the number 87.

CNROM allows you to expand only the graphics ROM capacity, from the standard 8 to 32 kilobytes. It switches memory in banks of 8 kilobytes, that is, only both pages of 256 tiles at once, which leads to inefficient memory consumption. A typical situation for games is that the sprite tiles for the main character and enemies are located on the first page, and the background tiles on the second. If a game requires multiple sets of background graphics, the graphics for repeating sprites in levels will have to be duplicated on every other page. This is done, for example, in Adventure Island. Subsequent, more complex mappers solved this problem by reducing the granularity of banks to 4 kilobytes or less - already with 4 kilobyte banks it becomes possible to select any combination of pages with sprite graphics and background.
The code ROM when using the CNROM mapper remains of the standard size, 32 kilobytes. However, do not forget that video memory is available not only for writing, but also for reading. This allows some data, such as game levels, to be stored in graphics ROM and copied to main RAM as needed. In particular, this is used in the game Milon's Secret Castle.

Games with the CNROM mapper generally remained at the same level as the previous “mapperless” ones, but their visual diversity increased. A striking example is the game Adventure Island - in terms of content, variety of location geometry and volume of music, it is close to Super Mario Bros, but now larger, better animated sprites of the hero and opponents, as well as several different visual settings for locations, have become possible. At the same time, the game is still characterized by high repetition of elements, the levels are very similar to one another.
Other game examples:
- Arkanoid (1987)
- Cybernoid (1989)
- Gradius (1986)
- Karateka (1985)
- Mickey Mousecapade (1987)
- Solomon's Key (1986)
▍ UNROM (mapper 2)
Number 2 in the iNES standard combines mappers and boards of the same type - a family that has the general name UxROM, but is usually called by the most famous variation, UNROM.
Conceptually, UNROM stands apart from other mappers. Its key feature is the use of not a separate graphics ROM for storing graphics, but the main one, in which the code is also stored. The graphics are loaded by the game into the 8 kilobytes of RAM installed on the cartridge board. This system is similar to that implemented in the Famicom Disk System, only there the data was loaded from a floppy disk. Perhaps the very idea of such a mapper was prompted by the advent of FDS.

UNROM implements switching of only one 16-kilobyte window of ROM with code, located in low addresses. The amount of graphic content in the game is limited only by the volume of the ROM code, the maximum volume of which in practice was 256 kilobytes. In addition, it is possible not just to load ready-made sets of graphic elements, but to combine them, or use data compression techniques. The use of RAM has also opened up a completely new technique for working with graphics: you can update some of the graphics dynamically, right while the game is running - for example, loading frames of the main character, which allows you to not keep them all in video memory at the same time, and use the freed up space for other game elements.
Technically, the UNROM mapper is implemented on two discrete logic chips, 74HC161 and 74HC32. The configuration of tile cards is still set by jumpers, that is, it cannot be changed while the game is running.
There are similar concept mappers AxROM and BNROM, differing only in switching banks of 32 kilobytes at once. Also, the possibility of using RAM instead of ROM for graphics is provided in all subsequent, more complex mappers.
Nowadays, hobbyists have developed an improved version of the mapper, known as UNROM 512 (numbered 30 in iNES). It supports up to 512 kilobytes of code ROM, up to 32 kilobytes of graphics RAM with 8 kilobyte banks, and, in some implementations, self-programmable Flash memory for game saves and tilemap configuration management. The mapper has gained great popularity since it is the only one supported in the NESmaker game designer, which made a splash in 2018.

The first game using UNROM was released in June 1986 - the famous Ghosts & Goblins from Capcom. This example alone is enough to understand the significance of the new mapper for games that have reached a qualitatively new level. Now each level of the game has its own unique design, a unique map, complex music, and large, well-animated sprites of the player and opponents.
Although other, even more advanced mappers appeared after UNROM, its capabilities were sufficient for many games almost until the very end of the platform’s commercial life. Among them:
- Castlevania (1986)
- Contra (1988)
- DuckTales (1989)
- DuckTales 2 (1993)
- Jackal (1988)
- Lifeforce (1987)
- Little Mermaid (1991)
- Prince of Persia (1992)
▍ MMC1 (mapper 1)
This Nintendo mapper was first used in Seta's Morita Shougi, released in April 1987.
Compared to previous mappers, MMC1 has significantly more advanced capabilities. It allows you to switch code ROM in two 16 kilobyte windows, as well as graphics ROM in one 8 kilobyte window or two separate 4 kilobyte windows. The maximum size of code ROM is 512 kilobytes, and graphics ROM is 128 kilobytes. Additional battery-powered RAM of up to 32 kilobytes is also supported. With MMC1, software configuration management of tile cards became available for the first time. However, as a rule, games do not take advantage of all the memory management capabilities, preferring a UNROM-like configuration with one switchable bank in the lower 16 kilobytes.

The mapper has extremely unusual controls. All five control registers are sequential: the five-bit value is transferred through the least significant bit in five byte writes to the desired range of the ROM address space. This is quite slow and inconvenient, and is the main drawback of MMC1.
Unlike simpler mappers, MMC1 exists only in the form of an ASIC, that is, a custom chip. There are at least six revisions of it, used in the SxROM family, which includes 25 different boards (SLROM, SOROM and others), as well as on NES-EVENT boards, used exclusively for special Nintendo World Championship cartridges created for the company's public gaming competitions.
The first revision of the chip was produced by ROMH, the MMC1A revision that appeared in 1988 and subsequent versions were produced by another manufacturer, presumably Ricoh. Chinese manufacturers have also created a complete clone of the mapper, known as AX5904. Almost all versions have a “narrow” PDIP-24 package, with the exception of the rare MMC1B2F, which had a SOIC-24 package.

MMC1 had about the same impact on game content as UNROM. However, the capabilities of the mapper made it easier to implement more complex code logic. In-game saves have become available (implemented only in some games). Software management of the tile map configuration made it possible to implement and combine slightly more complex visual solutions than usual. In particular, it has become easier to implement scrolling of a large level map in all 8 directions, which can be seen in the game Blaster Master. Despite some shortcomings, MMC1 has become one of, if not the most popular mapper on the platform.
- Bionic Commando (1988)
- Castlevania II: Simon’s Quest (1989)
- Chip ‘n Dale (1990)
- Chip ‘n Dale 2 (1993)
- Darkwing Duck (1992)
- Double Dragon (1988)
- RoboCop 3 (1992)
▍ MMC3 (mapper 4)
The first game with the MMC3 mapper was another Seta game, 8 Eyes, released in September 1988. However, the foundations of the mapper architecture were laid much earlier, back in 1986, in the Namco N108 mapper - its main functionality is similar, but somewhat simpler compared to MMC3.

A family of a couple of dozen boards based on the MMC3 mapper, differing in configuration and memory capacity, is called TxROM - for example, TLROM, TSROM. All of them are assigned number 4 in the iNES standard. In addition to the standard inclusion, there are several specific alternatives implemented on TxSROM and TQROM boards. They are assigned separate numbers, 118 and 119.
There are at least three revisions of the MMC3 chip, as well as its MMC6 version. All of them are designed as ASICs in a TQFP-44 package. Subsequently, other companies created several of their own ASIC mappers, similar in capabilities, but not software compatible. For example, these are FME-7 from Sunsoft and VRC6 from Konami.
The pirates really loved MMC3 and created many of its modifications, which they even adapted games from other mappers to avoid the hassle of cloning the entire zoo of original chips. The most famous pirate direct clone of the mapper is AX5202P, made in the good old DIP-40 format. Other clones were often made without frames.
In its various configurations, the MMC3 allows the use of 64 to 512 kilobytes of code ROM, as well as up to 256 kilobytes of graphics ROM, with the option of using 8 kilobytes of RAM instead. Battery-powered RAM for saves is supported, although the size is more modest than that of the MMC1 - 8 kilobytes. There is also software management of the configuration of tile maps. Control of the mapper is normal human, with the usual one-time recording of values in several registers, projected to different ranges of the address space.
MMC3 offered more flexible bank management, but without unnecessary complications, optimally suiting the typical needs of game programs that had been defined by that time. The biggest improvement is in the management of graphics ROM banks: there are now as many as six windows available, two of which are two kilobytes in size (128 tiles), and four of which are one kilobyte in size (64 tiles). This opened up the possibility of convenient and fast animation of backgrounds or sprites. For example, these features were used to animate background elements in the games Batman (1989) and Tiny Toon Adventures (1991).
As for the code ROM, MMC3 provides two switchable 8 kilobyte windows in the lower half of the address space - a simple and optimal solution that allows you to store both procedures and their data in different plug-in banks.
The highlight of the mapper is the support for so-called line interrupts, IRQs generated at the beginning of a given line. This made it possible to implement a variety of visual effects, such as multi-plane parallax, with more efficient use of CPU time.

Perhaps the main game that clearly demonstrates the advantage of this mapper is Super Mario Bros 3 (October 1988). A huge amount of content, graphics, animation, music, levels, and everything you can. These capabilities were enough to produce many other top games, and eventually MMC3 and its analogues became a kind of gold standard that lasted until the end of the platform's commercial life. Among the games:
- Batman Returns (1993)
- Bucky O'Hare (1992)
- Contra Force (1992)
- Felix the Cat (1992)
- Power Blade (1991) and Power Blade 2 (1992)
- Super C (1990)
- Super Mario Bros. 2 (1988) and Super Mario Bros. 3 (1988)
- TMNT 2 (1990) and TMNT 3 (1991)
▍ Others
Listing the features of all other existing mappers, of course, is not possible, or even reasonable. But some examples stand out exceptionally and therefore deserve at least a brief mention
First of all, these are, of course, all mappers with expanded sound capabilities. The Famicom allowed analog audio from the set-top box to be passed through a cartridge. Several major Japanese developers took advantage of this and created their own sound synthesizer chips, installed in each copy of the game and greatly improving its sound. Such chips were used only in Japanese versions of games - the ability to connect an external sound source was not implemented in the NES. Of course, now it is possible to add it using the simplest hardware modification inside the console, but in those days this closed the way for games with improved sound in the West.

Mappers containing an additional sound synthesizer and a short list of their capabilities:
- Konami VRC6 - two rectangular channels with variable duty cycle and one sawtooth
- Konami VRC7 - six channels of dual-operator FM synthesis
- Namco 106 - one to eight table synthesis channels
- Sunsoft 5B - essentially everyone's favorite AY-3-8910 (more precisely, YM2149F)
- MMC5 - two rectangular channels, exactly the same as in the main synthesizer
The next mappers that are worth mentioning are MMC2, MMC4 and MMC5 developed by Nintendo itself.
MMC2 and MMC4 are variants of the same mapper with minor differences. Their unique feature is the ability to switch between graphics sets at the moment when the scanning beam reaches one of two special tiles. The mapper switches the graphics ROM in two windows of 4 kilobytes each, for each of them you can select two banks at once, between which you will switch at the right time. This ingenious scheme made it possible to increase the number of tiles displayed on the screen from 256 to 512 without the use of interruptions or other tricks. The mapper was first used in 1987, the most famous games using it are Mike Tyson’s Punch-Out!!! and Fire Emblem.
MMC5 is the most advanced mapper created during the commercial life of the platform, in 1990, and it remains so to this day. It’s not easy to list all of its capabilities, but the most notable is the simultaneous display of up to 16,384 background tiles on the screen with color attributes of 8x8 pixels, and the most unusual is a hardware multiplier that instantly multiplies two 8-bit numbers. In theory, these capabilities can significantly increase the detail and color of graphics, as well as complicate the games themselves. However, for some reason, the dozens of games released that used this mapper hardly reveal even a small part of its potential. The use of such a complex mapper in amateur projects remains commercially unprofitable even today; a replica turns out to be too expensive.
Along with the story about such an advanced mapper, it is appropriate to note that Rare regularly used a simple AOROM mapper, which is a variant of UNROM with 32 KB banks. The lack of advanced features did not stop the company's developers from creating a number of the most impressive games on the platform - for example, Battletoads and Battletoads & Double Dragon.

And at the other extreme in the story about mappers, it’s worth mentioning an extremely interesting mapperless configuration with just one ROM. It was invented by enthusiasts and used in the early 2010s in a pair of micro-games Magic Floor and Starfight, and is number 218 on the list of iNES mappers.

The idea is that the Famicom architecture allows you to reconnect the external video controller address bus using jumpers on the cartridge connector in such a way that the 2 kilobytes of video memory built into the console, usually used for tile cards, will be used as external video RAM. If we limit ourselves to using just one tile card instead of the traditional two, this will free up 1024 bytes of video memory - enough for a set of 64 tiles loaded from ROM code. Of course, doing at least something in such conditions is a non-trivial task, but just right for fans of extreme programming and heroic overcoming of self-created difficulties.
▍ Code difficulties
Of course, the introduction of mappers not only solved the problem of memory expansion, but also brought additional difficulties to developers. Some of them are quite entertaining and not the most obvious, and are worth talking about.
First, you need to list a whole bunch of features of the Famicom architecture that you need to keep in mind when planning the architecture of the game code using a mapper:
- Mappers are almost always controlled by writing values to a ROM area. This will not change its content in any way, that’s why it is ROM, but such a recording can be easily intercepted on the cartridge board by setting the corresponding bus signals, and sent to the latch register of the mapper.
- Writing to the mapper register switches the memory bank instantly, even before moving on to the next code command. And if the code that performs the bank switching is itself in the switched window, after the completion of the mapper register write command, reading the next command will continue from the new bank.
- No console hardware knows about the existence of mappers and cannot interact with them. The presence of a mapper takes into account only the code written by the programmer.
- At the very end of the 6502 processor's address space are the so-called reset and interrupt vectors—addresses that point to the code that starts executing after the reset, as well as the code of the interrupt handlers. The processor reads this data every time a reset occurs, as well as every time an interrupt is triggered. There is no way to change these addresses.
- The Famicom sound synthesizer has what is called a DMC, a channel that plays fragments of digitized sound. It is designed in such a way that reading and playing sound is performed entirely in hardware, without the participation of the processor. The location of the samples is fixed in the device - always in the upper 16 kilobytes of the address space.
- There is no signal from the reset button at the cartridge connector. Thus, devices located on the cartridge do not have an easy way to recognize that the player has pressed the reset button and initialize themselves. You can determine a reset by changing the clock frequency period (the generator freezes during a reset), which is used by some later ASIC mappers and multi-game pirate cartridges; simple classic mappers did not provide such a possibility.
Considering all of the above, many problems and limitations arise that require careful planning of working with the mapper, as well as a well-thought-out strategy for distributing code across switchable banks: you need to plan which parts of the code may need certain data, and in what combinations.
In many mappers, exactly half of the address space allocated for ROM code, its lowest 16 kilobytes, is switchable. Thus, the bank selection code, 6502 vectors, and audio samples for the DPCM channel are always in a portion of the ROM that is never switched. On the one hand, this eliminates many problems, but on the other, space in this memory area becomes worth its weight in gold, because in this same area it is convenient to place all the code that accesses data in banks.
The second common option is to switch the entire ROM address space, all 32 kilobytes. In this case, of course, it is necessary to duplicate the 6502 vectors in all banks, and if DPCM is used, then the samples. But even this is not the main problem. After all, if you switch the bank, the next command in the switching procedure will be replaced by a completely different code. To prevent this from happening, the procedure has to be duplicated in each bank in the same place. And if the code needs to access data located in another bank - a common situation in games - it cannot do this at all. To get around this problem, some of the code is placed in RAM - it can turn on a bank of data, read it into a buffer, and return the bank with the code back. The size of RAM is extremely limited, so such code must be planned very carefully and kept to a minimum size.
Some advanced ASIC mappers can switch 8 kilobyte banks. This is an almost ideal option - you can get both fixed 16 kilobytes in the upper memory, and two windows of 8 kilobytes, into which banks with procedure codes can be connected, and at the same time banks with the data necessary for these procedures. Of course, in this case the length of a continuous procedure code or data block is limited to 8 kilobytes, but in practice this is quite enough.
If the mapper can switch the very top part of memory, in which the 6502 processor reads the start address of the code when resetting, it may not be the beginning of the program at all, but the bank that was turned on at the time of reset. Therefore, games with such mappers duplicate processor vectors in each bank, along with an initialization procedure that forces the desired bank to be installed when the game starts. The problem with interrupt handlers is solved in a similar way.
As for DPCM samples, any scheme for using a mapper would have to severely limit their size: with a fixed top window, space would be needed for other things, and a switchable bank would require duplicating samples or code in each such bank. Because of this, not all games use the DPCM channel for music and sound effects, and those that do make do with just a few very short drum sounds. This is probably one of the main reasons why the so-called Sunsoft Bass - fat-sounding bass in music made from samples that require several kilobytes of ROM - has not become widespread.
Finally, another interesting feature is the so-called “bus conflict”, that is, a bus conflict. It is typical for all simple discrete logic mappers due to their extremely simplified circuit design. Knowing this feature is quite important for modern developers of homebrew projects, since it is not emulated in most emulators (any records pass correctly), and is also not in all cases implemented on Flash cartridges.
As I already said, almost all mappers are controlled by writing to the ROM area. However, in simple mappers, in order to reduce the cost, the ROM always has a read signal active, and when such a write sets an address on the bus, the ROM faithfully outputs the contents corresponding to this address to the data bus. The processor also puts the just written value on the data bus. A situation that is unacceptable in digital circuitry arises - you cannot directly connect the outputs of logic elements, since the output levels begin to fight with each other. Which one will win depends on the specifics of the circuitry; in any case, the final value that ends up in the mapper's latch register will not be the one that was recorded by the code, the wrong bank will be selected, and the game will not work correctly.
To avoid this trouble, it is enough that the value being written and the value stored in the ROM at that address coincide. Then the struggle between different levels will simply not happen, and the correct value will be guaranteed to be written to the mapper latch. For this reason, games with discrete logic mappers contain a table of all possible values that can be written by the game into the mapper registers. In ASIC mappers, this problem is usually solved at the hardware level - when writing to the ROM area, the read signal is removed from it and its outputs go to the average state.
▍ Other platforms
It's probably time to say that mappers themselves are not an exclusive feature of the Famicom architecture. Bank-switching paging is a standard solution for memory expansion, used, for example, in 8-bit home computers that had more than 64 kilobytes of memory. Relatively unusual, but typical for cartridge systems, is the location of the mapper on the outside. A unique feature of the Famicom is the situation with the number of mappers and the variety of their capabilities. They were also used on other game consoles, but either not so widely, or were initially standardized and therefore presented in much smaller quantities.
▍ Atari 2600
The first time mappers as part of a cartridge appeared was probably on the Atari 2600. Its life cycle also turned out to be very long, from 1977 to 1992. Standardly, the system supports a maximum of 4 kilobytes of external ROM, but already at the very beginning of the 1980s, even before the Famicom entered the market, the first 8 kilobyte games appeared on it.
Subsequently, the volumes grew, and by the end of the platform’s commercial life it was 32 kilobytes (Fatal Run game, 1990), and modern amateur developments support significantly larger volumes. In total, about three dozen mappers are known for the Atari 2600. Some of them are essentially just game switchers for multi-game collections, while others are full-fledged mappers.
The platform has its own special specifics. The fact is that the cartridge connector does not provide a write signal, which means that nothing can be transferred to the hardware on the cartridge, at least for switching banks, and even more so it is impossible to place additional RAM in the cartridge. A way out of the situation, of course, was found.
To switch banks, intercept reading from a specific address is used. For example, when reading from address $1FF8, one bank is selected, and when reading from address $1FF9, another bank is selected. This, of course, requires a more complete decryption of the address bus.
To write to external RAM, the idea of dividing the address space into two ranges is used. The same area of RAM is mapped to both ranges. For example, one kilobyte of RAM is mapped to addresses $1000..$13FF and $1400..$17FF. In this case, any access to the first range is considered a read, and any access to the second range is considered a write.
▍ Sega Master System
In 1986, Sega entered into a direct battle with Nintendo for the home video game market with the release of its Sega Mark III console (later the Master System). By that time, the trend towards an increase in the volume of games had become obvious, so memory expansion was built into it from the very beginning.
The processor address space is used more efficiently: in the configuration without a mapper, 48 kilobytes of ROM are available. True, the graphics are always stored in the main ROM, and since they are 16-color, they require more space than on the Famicom. Therefore, the first games using mappers were released in 1986.
Mappers on the Master System can only expand memory for the main processor. Graphics and sound systems are not available for cartridge devices. The mapper registers have special addresses in the memory map. Almost all games, with the exception of some early Japanese releases, have a title that indicates the size of the ROM (from 8 kilobytes to 1 megabyte). Information about the ROM size is used by the BIOS to verify the ROM checksum before launching the game.
There was only one official mapper for the system, but in three versions, with support from 128 to 512 kilobytes of ROM. The first, rarest version, was made in the form of a separate microcircuit, while subsequent versions were integrated with a mask ROM to reduce the cost of cartridges. There were also two mappers from third-party developers, which were essentially simplified versions of the official mapper. Standardization made it possible to avoid a zoo of incompatible devices, and integration with masked ROM provided a certain control over the platform.
▍ NEC PC Engine
The PC Engine game console (TurboGrafx-16 in the USA), developed by Hudson Soft - the same company that previously had a significant influence on the development of the Famicom - and manufactured by NEC, entered the market in 1987. Initially, it was intended to compete with the NES and Master System, but actually faced the next, 16-bit generation consoles on the market.
The PC Engine is probably the most advanced 8-bit gaming system yet, bringing the technology of the past to perfection. Due to the use of unpackaged chips, the cartridge, called here HuCard, was reduced to the format of a credit card, which, of course, affected the possibility of both its production “outside” and the possibility of adding additional devices.

Unlike previous systems, the mapper was provided in the console itself, and, moreover, was built directly into the HuC6280 processor, an accelerated version of the 65C02 with additional devices and a 21-bit external address bus. To control the mapper, the processor provided two special instructions and eight registers. The mapper divided the address space into 8 windows of 8 kilobytes each and allowed up to 2 megabytes of ROM to be connected to them. The console also had 8 kilobytes of main and 64 kilobytes of video RAM. Thus, the need to use external mappers was completely eliminated.
An unobvious drawback of this solution was the refusal to support “battery” saves in games - it was difficult to place the battery inside the HuCard, much less change it. To support saves, it was proposed to purchase additional devices from NEC and third-party manufacturers - the first step towards the now-defunct concept of memory cards, which became the norm with the advent of the PlayStation in 1994. This decision was controversial due to additional costs and limited compatibility between devices and games. In subsequent versions of its console, NEC attempted to address this shortcoming by adding on-board memory for saves, an approach that is still relevant today.
▍ Nintendo Game Boy
Nintendo itself did some bug fixing in 1989 with its first portable gaming console, the Game Boy.
Technically, everything remained approximately at the same level as it ended on the NES: 32 kilobytes of ROM without a mapper and ASIC mappers in the cartridge to expand the ROM to 256-8192 kilobytes and add RAM for saves. As in the Master System, only the processor memory is expandable, although the signals on the cartridge connector also provided for the connection of various peripherals.
Initially, tighter control over the platform added order. Nintendo itself developed and produced only four very similar mappers, for different ROM sizes. There was also an analogue of the official mapper from Hudson Soft.
▍ Sega Genesis and SNES
Fourth-generation platforms did not particularly need mappers, since the architecture of their processors directly provided for support for relatively large amounts of memory, and video memory expansion was not provided for. But the use of mappers still happened.
The Sega Genesis is theoretically capable of addressing up to 16 megabytes of processor memory, and the necessary signals are provided on the cartridge connector for this. However, a 4 megabyte section of memory was allocated directly for the ROM code, and the rest of the space was reserved for possible future expansions, which, as we know, happened in the form of the Sega CD and Sega 32x. And although the cartridge can accommodate more than 4 megabytes of ROM without additional tricks, this amount of memory will conflict with these extensions - for normal operation they would have to be physically disconnected from the console.
The only example of a volume exceeding 4 megabytes from the period of the platform’s commercial life is the game Super Street Fighter II. It has a capacity of five megabytes (40 megabits), and to ensure conflict-free operation in any configuration, it implements the so-called Sega Mapper, developed by Sega itself. It divides the 4 megabyte address space into 8 windows of 512 kilobytes. The bottom window is always fixed, since the starting point and interrupt vectors are located in it, and in the remaining seven you can include the desired ROM fragment by writing to the corresponding 8-bit mapper registers. Thus, the theoretical maximum amount of ROM that allows you to use this mapper is 128 megabytes.

In modern history, the independent developer Water Melon turned to the use of mappers on the Sega Genesis in his games Pier Solar and the Great Architects (2010) and Paprium (2020).
Pier Solar has a capacity of 8 megabytes and uses a mapper similar to the Sega Mapper, but with control registers located at different addresses and with copy protection.

Paprium has the same capacity, but also uses very sophisticated additional hardware within the cartridge, called "Datenmeister" by the developer. It consists of an FPGA, a 32-bit microcontroller, a modern 3-volt Flash ROM and 2 megabytes of RAM. In addition to memory management, this equipment implements a sprite processing accelerator and an additional sound synthesizer.

The situation is very different on its rival console, the Super Nintendo. This platform is known for the fairly widespread use of additional, more powerful microprocessors in cartridges. Although this approach looks somewhat similar - some kind of smart chip on a board that improves games - technically they are completely different devices with different operating principles and different tasks, so calling them mappers is incorrect.
However, the SNES has its own “mapper”, and it was used everywhere. There is only one, and it’s called “The Mapper”. Despite the self-explanatory name, it does not organize page memory addressing as such; its tasks are somewhat different.

The Mapper is implemented on the 74LS139 chip or on a custom MAD-1 chip, and it is needed to configure access to the cartridge ROM according to one of two possible schemes, the so-called LoROM and HiROM, in which the memory is divided into blocks of 32 or 64 kilobytes. These schemes have their advantages and disadvantages, which are very difficult to explain on fingers, but in general this is simply the specificity of the local architecture - the 16-bit processor 65C816 has strictly 8-bit roots in its ancestor 6502, and therefore in different modes it can work with both the full amount of memory and the 16-bit address space. The Mapper also decodes addresses for connecting RAM with a battery for game saves.
▍ Conclusion
The history of mappers ended the same way as the history of many other technologies of the past - progress simply made it unclaimed. The next generation of processors no longer required the use of page addressing, and the video system of the new platforms no longer required expandability and external configuration. Famicom and NES mappers settled on fairly modest amounts of supported memory (768 kilobytes in 1993's Kirby's Adventure), and the potential for expanded graphics capabilities was also only superficially touched upon in the MMC5 mapper and a few games for it. Color Dreams' ideas to install an additional Z80 processor in the cartridge also remained unrealized.
The platform currently has a large and active community of enthusiasts. Dozens of new games and new development tools are coming out. There are also attempts to develop mapper technology - for example, UNROM 512, which has become a modern standard, or a variation on the UNROM theme that supports up to 128 megabytes of ROM (about my old project based on it there is an article on é). A cost-effective analogue of MMC5 has not yet been created, but expectations have been in the air for a long time. And perhaps new interesting chapters will be added to this story.
Discounts, results of sweepstakes and news about the RUVDS satellite - in our Telegram channel?

Why This Matters In Practice
Beyond the original publication, Mappers on Famicom, NES, Dandy: where did they come from and why are they needed (part 2/2) matters because teams need reusable decision patterns, not one-off anecdotes. Let's continue detailed conversation about “mappers”—expanded memory management devices on Famicom, NES, and Dandy game consoles. In the sec...
Operational Takeaways
- Separate core principles from context-specific details before implementation.
- Define measurable success criteria before adopting the approach.
- Validate assumptions on a small scope, then scale based on evidence.
Quick Applicability Checklist
- Can this be reproduced with your current team and constraints?
- Do you have observable signals to confirm improvement?
- What trade-off (speed, cost, complexity, risk) are you accepting?
FAQ
What is this article about in one sentence?
This article explains the core idea in practical terms and focuses on what you can apply in real work.
Who is this article for?
It is written for engineers, technical leaders, and curious readers who want a clear, implementation-focused explanation.
What should I read next?
Use the related articles below to continue with closely connected topics and concrete examples.