The NES's CPU is a Ricoh 2A03 , which is based on the popular 8-bit MOS Technology 6502 and runs at 1.79 MHz (or 1.66 MHz in PAL systems). This is the central component that executes the code inside the game cartridge.
A bit of context
To understand the circuitry residing inside the NES' motherboard, we must first take a look at the state of the industry at the time. Interestingly, the CPU market in the late 70s and early 80s was quite diverse.
A Commodore PET, carrying a 6502 CPU.
A Tandy TRS-80, carrying a Z80 CPU.
If you were a startup aiming to build an affordable microcomputer for the western world, you had plenty of options available:
- The Intel 8080 (1974): A popular CPU featured in the MITS Altair 8800, the first 'personal' computer. It comes with a modest 8-bit data bus, a 16-bit address bus (enough to handle the necessary memory), and seven 8-bit registers. With capabilities like this, a line was drawn between the simple calculator and an actual computer.
- The Zilog Z80 (1976): Displeased with Intel's direction and lack of investment in their CPU division, former engineers of the 8080 started their own company to produce an 'unofficial' successor, enhanced with more instructions, registers, and internal components. To top it off, it was sold at a lower price and could still execute 8080 programs . The new CPU was well received by British firms Amstrad and Sinclair, as well as the Japanese Sega, among others.
- The Motorola 6800 (1974): Another 8-bit CPU designed around the same time. While a direct competitor of the 8080, the 6800 was programmed using a more sophisticated instruction set, albeit running at a slower clock speed . Nevertheless, many do-it-yourself computer kits, synthesisers, and all-in-one computers included the 6800.
Faced with similar setbacks that Intel's employees went through, engineers at Motorola grew frustrated with the company's lack of interest in capitalising on the potential of the 6800 . So, they joined a small but ambitious silicon firm, MOS, where they worked on a redesigned version of the 6800 - the MOS 6502. While incompatible with the rest, the new chip was much, much cheaper to produce , and it was only a matter of time before iconic computer makers (Commodore, Tandy, Apple, Atari, Acorn, and so forth) chose the 6502 to power their machines.
Back in Japan, Nintendo needed something inexpensive yet familiar to develop for, so they selected the 6502. Ricoh, their CPU supplier, successfully produced a 6502-compatible clone.
Core functionality
To understand how capable this console is, let's first check what the original MOS 6502 offers:
- The 6502 Instruction Set Architecture (ISA): MOS wanted to offer drastic improvements at the cost of compatibility with third-parties (especially Motorola) . Thus, the 6502 instruction set still handles 8-bit words like the 6800 and others, but its programming is not cross-compatible.
- An 8-bit data bus and a 16-bit address bus. This was the typical combination for microprocessors of that era. Basically, it allows to operate data in chunks of eight bits without running out of memory locations (at least, too quickly).
- On paper, 16-bit addresses means the 8-bit CPU will need extra cycles to process the extra size. However, thanks to MOS's new addressing modes (explained further down), these penalties were alleviated without requiring too much circuitry.
- Three general-purpose registers (
X,YandA), which may look constrained when compared to larger register files. This decision reduces costs but also means the CPU would need to move memory around more frequently. With the 6502,XandYare called 'index registers' and are used to address memory, whileAis directly connected to the ALU and dedicated to arithmetic operations.- By comparison, the Motorola 6800 has two accumulator registers and only one index register, which allows for a simpler instruction set.
- An 8-bit Arithmetic Logic Unit (ALU), which comes as no surprise for an 8-bit CPU, but it's worth pointing out that others like the Zilog Z80 came with a 4-bit ALU instead.
- An 8-bit stack pointer: This is usually beyond the scope of this analysis, but I wanted to highlight it due to its significant deviation from Motorola's design. As mentioned before, the address bus is 16-bit, so a memory-dependent component like the stack pointer should ideally match that size. However, MOS opted to halve the requirement and store the stack within a fixed memory range. Nevertheless, it was a clever cost-saving measure, as it encouraged developers to adopt efficient programming techniques to maximise the stack space.
- 13 addressing modes. Thanks to the inclusion of two index registers, programs can choose between many formats for accessing memory. Some are optimised for zero-page addressing (the first 256 bytes of memory), while others encode a lookup address to retrieve the actual address dynamically. In the end, this helped save as many memory cycles as possible, at the cost of complexity.
- By comparison, the 6800 and its single index register only offer seven addressing modes, with no equivalent for the flexible types.
As you can see, the remarkable engineering behind the 6502 allowed MOS to sell a compelling product at an extremely affordable price.
Ricoh's licensing enigma
How Ricoh managed to clone the 6502 isn't clear to this day. One would expect MOS to have licensed the chip design to Ricoh, but there are many contradictions to this:
- Both Ricoh's and MOS's variants feature the same layout, but Ricoh's contains severed buses (disabling certain functions) . I go into more detail later.
- A document explicitly stating that MOS licensed the 6502 to Ricoh is yet to be found.
- An article published in 2008 by Nikkei Trendy states that Ricoh licensed from Rockwell, an authorised chip manufacturer . However, it's debatable whether a second source was able to provide IP to a third party, much less with MOS's approval.
- It wouldn't be the first time Nintendo got away with circumventing IP rights, as Ikegami Tsushinki v. Nintendo ruled in Japan that Nintendo didn't own the code of the original Donkey Kong .
Scrapped functions
The Ricoh 2A03 omits the Binary-Coded Decimal (BCD) mode originally included in the 6502 . BCD encodes each decimal digit of a number as a separate 4-bit binary. The 6502 uses 8-bit 'words' - meaning that each word stores two decimal digits.
As an example for the curious, the decimal number 42 is represented as:
0010 1010in binary.0100 0010in BCD.
We could go on and on talking about it, but to give an outline: BCD is useful for applications that require treating each decimal place separately (for instance, a digital clock). However, it requires more storage since each 8-bit word can only encode up to the decimal number 99 - whereas traditional binary can encode up to 255.
In any case, Ricoh deliberately broke BCD mode in its chip by severing the control lines that activate it. This was presumably done to avoid paying royalties to MOS, since BCD was patented by them (and the legislation that enabled copyrighting integrated circuit layouts in the United States wasn't enacted until 1984 ).
Memory
Both Ricoh 2A03 and MOS 6502 feature an 8-bit data bus and a 16-bit address bus, which allow them to access up to 64 KB of memory. So, how did Nintendo fill that memory space?
On one side, the motherboard contains a chip providing 2 KB of Static RAM (SRAM) . Nintendo calls this area 'Work RAM' (WRAM) and can be used to store:
- Variables for handling the game state and/or to look up information.
- The 'stack', which temporarily saves register values while the CPU is executing subroutines.
- A 'buffer area' so the CPU can copy large data between two locations.
On the other side, the components of the system are memory-mapped , meaning that they are accessed using memory addresses and therefore occupy part of the CPU's address space. Consequently, the Ricoh 2A03's memory space is filled with addresses pointing to the game cartridge, WRAM, the PPU, the APU and two controllers (don't worry about each component, as they are explained throughout this article).
Segmentation Fault
Inherited from MOS' design, this console also features a special 'anomaly' called Open Bus: If an instruction tries to read from an unmapped or invalid address, the last value read is supplied instead . If this goes unhandled by the program, execution may continue in an unpredictable state.
Cartridge/game data
Just in case you don't know, NES games are distributed in the form of cartridges, and the cartridge's buses connect directly to the CPU.
Nintendo wired up the cartridge lines in a way that only 49120 Bytes (~ 49.97 KB) of cartridge data can be accessed . Now, what do I mean by 'cartridge data'? Well, any chip connected to those buses, for instance:
- A Program ROM where the game's program resides. This excludes the graphics data, as you'll later see in the 'Graphics' section. Naturally and unlike the other chips, this one is mandatory.
- RAM chips to extend WRAM.
- A battery-packed RAM chip to store saves.
The existence of different combinations stems from the fact that the CPU doesn't care about what kind of component it is reading from; it only sees memory locations. So, it is up to game studios to choose (or devise) a feasible layout to fit in their game.
PCB of Super Mario Bros .
The same PCB with important parts labelled. The meaning of the 'Lockout' chip is explained in the 'Anti-piracy' section.
For example, Nintendo's 'Super Mario Bros' used a layout they call NES-NROM-256 and consists of 32 KB of program ROM and 8 KB of 'Character ROM' for graphics (we'll see more about it in the 'Graphics' section) . NES-NROM-256 was also prepared to house up to 3 KB of extra WRAM, though the game doesn't make use of it.
Going beyond existing capabilities
One of the major limitations of 16-bit address buses (affecting 3rd and 4th-generation consoles) is their compact address space. Nowadays, 32-bit computers can address up to 4 GB of memory (and 64-bit machines lavishly enjoy up to 16 exabytes), so this is no longer a concern, but back then, the NES only had a 64 KB address space, and a significant portion was consumed by the memory-mapped hardware (something competitors avoided).
So, did this mean that game studios could only develop games that stayed within the 49.97 KB limit? Absolutely not! If history has taught us anything, it is that there's always a clever solution to a challenging problem, and this issue was tackled with a Mapper.
Simplified representation of how a mapper extends the addressing capabilities of the CPU. With the inclusion of a mapper, the CPU can access extra banks (groups of addresses) of a large Program ROM. Although the game/program has the new task of manually switching between banks whenever needed.
The same setup but without a mapper installed. While simpler and inexpensive, the CPU can only access a finite number of banks.
A mapper is an extra chip included in the cartridge that sits between the memory chips and the console's address lines. Its primary job is to extend the address space, allowing developers to fit more chips. This is achieved through bank switching: memory addresses are grouped into banks, and the mapper provides switches (controlled via memory addresses) to alternate between them. Now, the CPU still perceives the same amount of memory, so it is the game (programmed with a mapper present) in charge of operating it. Due to their cost-effectiveness, mappers were the order of the day in 80s-to-early-90s technology.
PCB of Super Mario Bros 2 . Super Mario Bros 3 also uses this layout but bundles a 256 KB Program ROM instead.
The same picture with important parts labelled. At first, I thought the extra WRAM was for storing saves, but then I realised there are no saves in this game (and there isn't a battery either). In reality, that RAM chip is used to store a decompressed level.
Back to the NES, games like 'Super Mario Bros 2' and 'Super Mario Bros 3' shipped with the 'MMC3' mapper (made by Nintendo) in their cartridges. For comparison, MMC3 provided up to 512 KB of space for the Program ROM, up to 256 KB for Character memory and up to 8 KB for extra WRAM . You can now see why 'Super Mario Bros 3' differs significantly in quality compared to the first instalment.
All in all, while this console may appear limited while examining its internal features, Nintendo made sure it could adapt as technology evolves. On the other side, while this technique helped to keep the costs of the console down, it shifted part of the burden to the game cartridge. So, game quality and cartridge costs were two concerns game studios had to balance.