At its core, the Nintendo Entertainment System (NES) was powered by a custom variation of the 6502 microprocessor, but what truly set it apart was how its components worked together. Unlike other consoles at the time, the NES pushed a different modular design approach. Its hardware components were relatively simple, but its architecture allowed cartridges to become an extension of the system, handling tasks that other consoles hardwired into their motherboards.

This flexibility gave developers room to release some of the best games of the era, and ensured the NES would remain relevant in the gaming market for nearly a decade. Even now, 40 years later, someone got .NET running on the original hardware.

Let’s break down how the NES architecture was designed, examine its core components, and explore how everything worked together to deliver its iconic gaming experience.

Inside the NES: Three groups, one system

How the cartridge expanded the console’s capabilities

The NES architecture can be divided into three key groups: CPU-related components, PPU-related components, and cartridge-specific components. Together, these groups handled logic, visuals, and game-specific enhancements, communicating via a well-coordinated bus system. By offloading certain capabilities to the cartridge, Nintendo kept the console affordable while empowering developers to push the hardware further with each new game and increase the longevity of the system.

• The CPU-related group consisted of the central processing unit (CPU), audio processing unit (APU), and a 2KB static RAM (WRAM) chip. These elements worked together to execute the game’s logic, process sound, and manage temporary data.
• The PPU-related group was dedicated to rendering visuals. It included the picture processing unit (PPU) and its associated video RAM (VRAM), which managed everything from character sprites to background tiles.
• The cartridge group included the program ROM (PRG-ROM) and character memory (CHR-ROM or CHR-RAM), and many also featured additional components like mappers (MMC) or even their own on-cartridge 8KB VRAM chip to handle more complex games.

While many consoles of the era utilized cartridges primarily as storage mediums, the NES distinguished itself by leveraging the cartridge slot to interface directly with both the CPU and PPU groups. This design allowed for the inclusion of custom hardware, like the MMCs and expanded VRAM, within the cartridges themselves. The integration of the cartridge slot with the PPU and CPU allowed cartridges to modify key aspects of graphics, sound, and memory directly, giving developers greater flexibility to extend the system’s capabilities. This is why we saw a steady progression of better quality games throughout the NES lifespan.

The modular building blocks of the NES

A closer look at its core components

CPU-related components: The brain of the NES

At the heart of the NES was its CPU, a custom Ricoh chip (RP2A03 for NTSC and RP2A07 for PAL regions) based on the MOS Technology 6502 processor used in the Apple II. Unlike the standard 6502, the NES version lacked support for binary-coded decimal (BCD) operations, useful in applications like calculators or business software but largely irrelevant in games. BCD mode was patented by MOS Technology and, by disabling the BCD circuitry, Nintendo and Ricoh could avoid licensing fees that they would otherwise have had to pay to MOS Technology.

What made the NES CPU unique was that it wasn’t just a processor—it also housed the audio processing unit (APU). This co-processor generated sound using five channels: two pulse channels for melodies, one triangle channel for bass, a noise channel for percussion, and a DMC channel for playing sampled audio. The APU gave the NES its signature 8-bit sound, and why circuit bending the NES is so fun.

The 2KB of work RAM (WRAM) labeled BR6216C-10LL was used to store mutable data—information that could be changed or modified after being created. While limited, clever programming allowed developers to make the most of the low capacity. For example, rather than keeping entire maps in memory, games like The Legend of Zelda used algorithms to dynamically generate map data on the fly.

In simple terms, the CPU was the NES’s “brain,” running the game code, processing inputs, and telling the other components what to do. The APU side of the CPU controlled sound, and the WRAM served as a workspace for keeping track of everything happening in the game.

PPU-related components: The visuals of the NES

The NES’s graphics were handled by the Picture Processing Unit (PPU), a custom Ricoh chip labeled RP2C02H-O. While the CPU executed the game’s logic, the PPU focused solely on rendering visuals to the screen. It was designed to draw two distinct layers: background tiles and sprites, which were essentially movable objects like characters, enemies, or projectiles.

Unlike modern GPUs, the PPU wasn’t directly programmable. Instead, the CPU manipulated it through memory-mapped I/O registers, which acted as a bridge between the two components. These registers let the CPU tell the PPU what tiles to draw, where to place them, and how to color them. For instance, when Mario jumps in Super Mario Bros., the CPU updates the PPU registers to move Mario’s sprite vertically while redrawing the appropriate background tiles as he moves.

Supporting the PPU was 2KB of VRAM (video RAM), the same type of SRAM used for WRAM. This VRAM stored name tables (which mapped out where tiles appeared on the screen), attribute tables (which handled color assignments for groups of tiles), and palettes (the specific colors each tile could use). These tables allowed developers to create complex visuals despite the NES’s limited hardware.

To save resources, the NES had only enough VRAM to support two screens worth of name tables, which is why games like Metroid used “mirroring” to recycle parts of the display when scrolling horizontally or vertically. Developers could control this mirroring using memory-mapped registers, ensuring smooth gameplay even with limited hardware.

In simple terms, the PPU group functioned similarly to the CPU group but was dedicated entirely to graphics. While the CPU processed the game's logic, the PPU handled everything visual—drawing backgrounds, characters, and animations on-screen using data stored in VRAM.

Cartridge-related components: Extending the NES’s capabilities

While the PPU and CPU formed the core of the NES, the cartridges added the magic that made each game unique. The cartridge wasn’t just a storage device—it was an extension of the console, interfacing directly with both the CPU and PPU through a 72-pin connector.

Every cartridge contained a Program ROM (PRG-ROM) chip, which stored the game’s code, and a Character ROM (CHR-ROM) or CHR-RAM, which stored tile data for graphics. For games with CHR-ROM, the graphics were preloaded into the cartridge, while games with CHR-RAM allowed the CPU to modify graphics dynamically during gameplay.

Some cartridges included additional general-purpose RAM (up to 8KB) to expand the NES’s memory and store save data. These cartridges often included a CR2032 battery soldered to the PCB, used to preserve saved progress even when the console was turned off—a feature used in games like The Legend of Zelda.

One of the NES’s most innovative features was the ability to include Memory Management Controllers (MMC) in cartridges.

One of the NES’s most innovative features was the ability to include Memory Management Controllers (MMC) in cartridges. These chips allowed developers to exceed the console’s 64KB addressable memory limit by enabling bank switching. By swapping chunks of memory in and out of the CPU’s accessible range, developers could include larger and more complex games on a single cartridge. MMCs also introduced features like smooth scrolling and expanded palettes.

Some advanced cartridges even came with their own on-board VRAM, allowing them to handle graphical data independently of the console’s built-in VRAM. For example, games like Kirby’s Adventure used these enhancements to push the boundaries of what the NES could display.

Put simply, the cartridge was more than a storage medium—it was actually an integral part of the NES’s architecture. By embedding additional hardware directly into the cartridge, developers could break free from the console’s limitations and push the boundaries of what could be done at the time.

How everything communicates: The NES bus system

The NES’s components worked together through a well-coordinated system of data buses and address buses. The CPU was always connected to these buses, changing the flow of data between WRAM, PPU, APU, and game cartridge.

• The data bus: This 8-bit parallel bus carried the actual information, like game instructions or graphics data, between components.
• The address bus: This 16-bit bus identified where specific data was stored, whether in WRAM, VRAM, or the cartridge.

Each component had a chip-select signal, controlled by a discrete logic chip labeled 74LS139, which ensured only the correct component responded when data was being accessed. For instance, when the CPU needed to update Mario’s position, the address bus pinpointed the exact memory location in WRAM, while the data bus sent the new coordinates.

To keep things efficient, the NES used memory-mapped I/O, which divided the CPU’s 64KB memory into regions assigned to specific components. This setup allowed the CPU to interact with all the hardware seamlessly, treating the PPU, APU, and cartridge as if they were just additional memory locations.

In simple terms, the NES’s communication system worked like a network of messengers, each responsible for carrying specific information between components. The CPU acted as the central coordinator, ensuring that game logic, graphics, and sound data all reached the right place at the right time.

A modular masterpiece of gaming history

Reverse engineering the past

The NES’s hardware design was unique for its time, and it certainly paid off. By offloading some of the console's hardware to the cartridge, Nintendo created a system that was both cost-effective and endlessly adaptable. That’s what kept it relevant for nearly a decade and allowed developers to push the limits of what was possible in game design.

Today, we can take these machines apart, analyze every trace on the board, and fully understand how they worked. That level of accessibility is part of what makes retro computing so appealing—you can follow every connection, see how everything fits together, and even recreate the hardware yourself with projects like OpenTendo.

Why doesn’t it feel this simple anymore?

Unfortunately, with modern computing, that kind of deep, hands-on understanding feels almost out of reach. With processors housing billions of transistors and software relying on layers of abstraction, the idea of fully deconstructing a modern system the way we do with the NES seems impossible. For many of us, the most powerful computer we own is likely in our pocket. Will anyone, decades from now, be reverse-engineering today’s technology in the same way? Or has the era of truly knowing how something works, down to the last circuit, passed us by?

Either way, there’s something satisfying about digging into hardware, whether it’s analyzing the architecture of a classic console or working on your own projects today. If you’ve read this far, chances are you share the same curiosity that inspired so many to experiment with the NES back in the day. So maybe this is your sign to finally start that Arduino project, build your own desktop computer, or turn that old laptop into a NAS. After all, the best way to understand a system is to get your hands on it.