Nintendo’s NES: Innovation by Constraint

Reflecting on the early days at Nintendo, legendary NES composer Koji Kondo stated, “Because of the limited resources [back then] [...] we had to be very creative, and we couldn’t rely on a wide range of music [...] People [today] sometimes think, “well, we’ve got all of this.” So rather than having to create something that is really great, they [...] rely heavily on technology”[1]. The early days at Nintendo are marked by ingenuity, hard work, and great innovation; however, this was not achieved easily. Computer engineers, designers, and programmers were all required to work at the limits of available technology, leveraging their human ingenuity and artistry in the face of constraints to overcome those limits.

With cost being the number one limiting factor and memory being expensive in the early 80s, memory allocation was incredibly constrained, to the point that early games on the NES fit within roughly 49 KB (2 seconds of an mp3 file) or less [1]. In this article, we will explore how limited storage space inspired exciting innovation through three examples: hardware architecture iteration, character design in Mega Man, and music design in Super Mario Bros. 

Before exploring our first example, consider what the 1985 Nintendo Entertainment System had under its injection-molded hood. The NES Computer Processing Unit (CPU) was a Ricoh 2A03, an 8-bit CPU clone of a popular commercial processor at the time, with 1.79 MHz clock speed. The CPU’s 8-bit data bus was paired with a 16-bit address bus, meaning there were theoretically 64 KB of unique memory location that could be accessed [2]. It contained a single core, capable of performing one program task at a time. For graphic output, the NES relied on a Picture Processing Unit (PPU). When passing image data from the CPU, the PPU would control the deflection of the Cathode Ray in the back of a CRT Television, which shoots toward the back of the TV screen and “draws” the image. This handoff between computed CPU data and PPU image painting happened 60 times a second!

This image painting, player inputs, character (called sprites) management, temporary saves, and any other subroutine the CPU could be engaged in all required memory. Remember that 64 KB of addressable data? It was divided up among different chips on the motherboard for different functions. Addresses connecting the CPU to the game cartridge, for example, were limited to a max of 49 KB. This was fine for games like Super Mario Bros. (at only 40 KB) but was quickly a major limiting factor in the scope of early NES games. By the time Super Mario Bros. 3 was released, the game was 384 KB. How were game designers able to program games larger than the available addressable space on the NES? 

Figure 1: Image Courtesy of Rodrigo Copetti - A diagram demonstrating the basic concept of Nintendo's MMC1 “Mapper,” a small surface IC internal to a game cartridge which connected the allotted address wires off the CPU address bus to various banks of addresses stored on a game cartridge. This device was leveraged on Super Mario Bros 3, which had almost 400 KB of game data and the MMC3. FUN FACT: Super Mario Bros 3 running on the Nintendo Switch is now 146 times larger than its original NES cartridge.

This heavy storage addressing constraint led to the first critical innovation I want to discuss, the “Mapper.” Developed by Nintendo, the mapper allows more memory via stored mapping data on the game cartridge itself. It does so by bundling addresses into banks. Sitting between the data bus and the game cartridge storage, it takes logical addresses in, translates them with stored register data within the Mapper, and outputs physical addresses to different banks, extending the space (see Figure 1). The Mapper therefore acts like a vertical carousel storage system in a machine shop, cycling the accessible shelf of physical addresses (tools, fasteners, electrical components) using logic control (control panel), connecting the 49 KB worth of address lines with up to an order of magnitude more storage. This small IC had various iterations in 3 years (UNROM, MMC1-MMC6), all deriving their updates from heavy constraints. Referring back to Super Mario Bros 3, the addition of an MMC3 Mapper allowed game developers to create a game that was far more detailed and with greater variety than Super Mario Bros. (and access to 384 KB of storage), which was not possible otherwise [3, 4].

Figure 2: Image Courtesy of Reddit [5] - The inclusion of the MMC3 allowed Super Mario Bros. 3 to store significantly more unique sprite data than its predecessors.

With the addition of the Mapper, developers were then freed to develop bigger games, add more sprites (see Figure 2), and include more sophisticated audio, but they were still at constant odds with storage space. Mega Man, leveraging the UNROM Mapper, still took great lengths to innovate in how it saved data,  particularly in character sprite design and levels [6]. To begin, Mega Man leverages many common memory-saving techniques. For example, some sprites have mirrored designs. Ideally this means only half (or less) of a character’s 8x8 building blocks of data needs to be saved on the game cartridge. Mega Man also cleverly uses symmetry in its background tile design, which can be seen in its pattern tables (see Figure 3).

Stored on the game cartridge, pattern tables are used for all sprite art and background art. A pattern table is 4 KB, housing 256 8x8 pixel tiles, with each pixel containing 2 governing bits. Pattern tables are the essential building blocks for a level or for characters in a given part of the game. The level blocks can be combined, mirrored, color changed, as well as programmed in composite chunks that are less memory intensive to run, thus saving even more critical space [1, 2]. Where Mega Man truly shines is in its design and treatment of the robot boy himself. 

Figure 3: Image Courtesy of Andrew Schartmann’s Analyzing NES Music. Examples of a character pattern table and level pattern table.

For those who are unaware, the Mega Man gameplay loop involves starting a stage, defeating various enemies, traversing difficult terrain, and upon beating its boss, obtaining a new power-up. When equipped, this power-up ability changes Mega Man’s attack, speed, or other attribute. To the player, this is represented by a change in the color of his suit. For the six special boss abilities, Mega Man has six new costume colors. This saved space by using the same sprite for all six abilities (much like Samus equipping the missile in the original Metroid). But that was the ‘easy’ part. A close look at Mega Man reveals that he is made up of five colors. We take this for granted today, but on NES hardware, this should have been impossible! Referring back to the aforementioned sprite pattern tables, every pixel on the table is represented by 2 bits (which define the color of a pixel). This only leaves a total of 4 possibilities: 00, 01, 10, and 11. So the hardware cannot support a 5-color character. 

Figure 4: Image Courtesy of Psykhed [7] - Sure enough, he is 5 colors.

This is what makes Mega Man a prime example of constraint-driven innovation. In the development of Mega Man One, developers sought out a skilled industrial machinery systems specialist named Nobuyuki Matsushima and challenged him with the impossible [1]. His solution was an aptly named method called “sprite stacking,” which meant Matsushima had to painstakingly synchronize user input, animation, and position data of one sprite with a second nested head sprite. Therefore, the impossible 5-color character was only achieved when a skilled programmer took constraint head-on (see Figure 4).

Finally, this storage-conscious NES era was defined by yet more innovation in its soundscapes. The Super Mario Bros “Overworld Theme,” composed by Koji Kondo, is widely considered the most recognizable and ubiquitous piece of video game music in history [8]. Its original version also encapsulates the early sound aesthetic of the 5-channel NES Audio Processing Unit (APU) and has excited players for over 40 years. Andrew Schartmann, in his book Analysing NES Music - Harmony, Form, and the Art of Technological Constraint (the major inspiration for this article), puts it passionately: “‘Overworld’ is by far the longest and most formally complex of the Super Mario Bros. tracks, not least because it graces the aural stage in twenty of the game’s 32 levels. Players spend hours moving to its syncopated rhythms as they smoosh Goombas and outsmart Piranha Plants, all while clearing chasms of unfathomable depths as hearts throb steadily in their throats.

The music’s playful surface extends to its foundation by employing expectation modules that trump predictions at every turn” [1]. Analyzing the piece, Schartmann explains that it is broken into 5 modules. In his terms, modules are defined as “[The] fundamental building blocks of NES music… defined by salient changes to the musical surface and are intimately tied to the underlying hypermeter”[1]. (For us engineers, I think hypermeter is essentially the feeling of strong or weak beats invoked by a given rhythmic structure). Not surprisingly, there was little room for audio data to be stored in a game cartridge. A song lasting possibly hours of play needed to keep players engaged without tiring or irritating them through extended exposure. Therefore, Kondo had to masterfully subvert a listener's subconscious expectations. He accomplished this via the juxtaposition, manipulation, reinterpretation, and reconfiguration of those five modules, and pulling small amounts of audio data into an extended score. The most recognizable video game score of all time may not have been what it is today without the steep, labor-intensive memory constraints, and had Koji Kondo not risen to the challenge. 

In closing, it is evident that constraint is deeply connected to innovation. Even these 40-year examples reveal deep levels of complexity and clever ingenuity, which can continue to inspire us today. Whether in its hardware design, beloved characters, or captivating scores, the NES is a testament to what can be achieved when people are stretched and pushed to think outside the box. Let us remember this as we tackle our next design or engineering challenge and resolutely take on our constraints.

REFERENCES

[1] Schartmann, Andrew. Analyzing NES Music: Harmony, Form, and the Art of Technological Constraint. Intellect Books, 2025.

[2] Copetti, Rodrigo. “NES / Famicom Architecture: A Practical Analysis.” Rodrigo Copetti, updated 17 Aug. 2026, www.copetti.org/writings/consoles/nes/.

[3] “MMC1.” NESdev Wiki, www.nesdev.org/wiki/MMC1.

[4] “Super Mario Bros. 3.” NesCartDB, nescartdb.com/profile/view/4527/super-mario-bros-3.

[5]  “NES Super Mario Bros. Sprite Evolution.” Reddit, r/retrogaming, www.reddit.com/r/retrogaming/comments/1qlf8tl/nes_super_mario_bros_sprite_evolution/.

[6]“RockMan.” NesCartDB, nescartdb.com/profile/view/4282/rockman 

[7] Psykhed. “Megaman Sprite.” DeviantArt, www.deviantart.com/psykhed/art/Megaman-Sprite-174908304.

[8] “Super Mario Bros. Music and Koji Kondo.” The Wall Street Journal, www.wsj.com/tech/super-mario-bros-music-koji-kondo-a74ce7d9.

To cite this article:
Scullin, Hunter. “Nintendo’s NES: Innovation by Constraint.” The BYU Design Review, 5 Oct 2026, https://www.designreview.byu.edu/collections/nintendos-nes-innovation-by-constraint.