The origins of the Nintendo 64's main processor trace back to the MIPS R4000, MIPS' new avant-garde CPU. Released in 1991, the R4000's most apparent novelty was the inclusion of 64-bit capabilities, which resulted from widening the buses, registers and computation units to manipulate 64-bit values with efficiency. Developers, on the other hand, accessed these capabilities through the new MIPS III instruction set. All in all, the R4000 enabled new applications to manipulate larger chunks of data without consuming extra cycles.
For their next-generation console, Nintendo looked into bringing industrial hardware into the home. Unlike Sony, who owned an array of in-house components and only needed a MIPS second-source, Nintendo formed a direct partnership with the owners of MIPS (and numerous graphics workstations) to co-design their entire ecosystem. That company was Silicon Graphics Incorporated (SGI).
Back at SGI's headquarters, the R4000 was an expensive product (priced at around $400 ), which made it unfeasible for a video game console. Still, Nintendo didn't want to give up on their state-of-the-art ambitions, so they opted for a low-end variant called R4300i, which NEC was able to second-source.
The MIPS R4300i CPU (1994).
In the end, Nintendo and SGI settled on the NEC VR4300 clocked at 93.75 MHz . This is a binary-compatible version of the MIPS R4300i that features :
- Two modes of operation:
- 32-bit mode: Traditional mode in which the CPU behaves as a MIPS II-compatible processor. There's nothing special about this mode except that all new functions are locked out.
- 64-bit mode: 'Native' mode where all 64-bit extensions are available. It's also binary-compatible with 32-bit applications.
- 32 general-purpose registers: These are 32 bits wide in 32-bit mode, and 64 bits wide in 64-bit mode.
- The MIPS III Instruction Set Architecture (ISA): A RISC instruction set that builds on MIPS II. It introduces new opcodes for computing 64-bit words (called 'doublewords'). Finally, instructions are always 32-bit long, regardless of mode.
- It's worth mentioning that, starting with MIPS II, load delay slots became optional. Instead, the hardware can automatically interlock/stall the pipeline to prevent data hazards. This is an interesting contradiction to MIPS' initials!
- Weirdly, branch delay slots still persist, but there are new branch instructions that can discard the delay slot. Although these were removed in later revisions of the instruction set .
- An internal 64-bit bus connected to an external 32-bit data bus: While doublewords operations don't degrade performance when operated internally, moving 64-bit data across the system incurs extra cycles.
- This is one of the cutbacks of the R4300i variant (the R4000 features a full 64-bit data bus).
- 32-bit address bus: Capable of addressing up to 4 GB of physical memory.
- Five-stage pipeline: Up to five instructions can be allocated for execution (a detailed explanation can be found in a previous article).
- 24 KB of L1 cache: Partitioned into 16 KB for instructions and 8 KB for data.
The package also includes an internal Floating-Point Unit (FPU). The VR4300 designates it as a co-processor (CP1), however, the unit is fitted adjacent to the Arithmetic Logic Unit (ALU) and accessed solely via the ALU pipeline, meaning there's no co-processing per se. On the other side, the FPU still houses a dedicated register file and speeds up operations involving 64-bit and 32-bit floating-point numbers. Finally, this unit adheres to the IEEE 754 standard.
Simplified memory access
The way RAM is assembled follows the Unified Memory Architecture (UMA), wherein all available RAM is centralised in one place only, and any component requiring RAM access draws from this shared location. The unit arbitrating its access is, in this case, the graphics chip.
The reason for choosing this design comes down to manufacturing costs. At the same time, if not managed properly, it also increases access contention.
No DMA controller?
As a consequence of the unified memory architecture, the CPU no longer has direct access to RAM. Thus, the graphics chip provides the required Direct Memory Access (DMA) functionality as well.
Memory design
Apart from the UMA, the structure of RAM is a little bit complicated, so I'll try to keep it simple. Here it goes...
The system physically contains 4.5 MB of RAM; however, it's connected using a 9-bit data bus, where the 9th bit is reserved for the GPU (I explain more in the 'Graphics' section). As a consequence, every component except the GPU will only find up to 4 MB.
Memory layout of this system. I assume the CPU-RCP bus speed matches either the RCP's clock speed or the CPU's.
The type of RAM fitted to the board is called Rambus DRAM (RDRAM) . This was just another design that competed with 'Synchronous DRAM' (SDRAM) to become the next standard. RDRAM is connected using a fast serial architecture (where memory modules are chained in sequence), while SDRAM employs a slower parallel connection (wiring all modules directly to the memory controller). Each came with its own advantages and disadvantages, both technical and commercial. Nevertheless, it's worth pointing out that although SDRAM ultimately triumphed, RDRAM continued to appear in later console generations, each introducing a new revision of the protocol.
Finally, the Nintendo 64 implemented the Base RDRAM variant - the very first revision of the protocol.
Latency and speed
While RDRAM installations required less wiring and enjoyed greater clock speeds than SDRAM, access latency increased proportionally with the number of banks installed . In the case of the Nintendo 64, the delay between initiating a memory transaction to finding the value in cache was significant - around 640 ns . Engineers tried to offset this by applying a high clock speed of 250 MHz (approximately 2.6 times faster than the CPU) to the memory banks. This way, Nintendo claimed that RDRAM could deliver high-speed data transfers of up to 500 MB/sec when reading or writing consecutive data .
As a side note, Nintendo chose NEC's uPD488170L memory banks for the N64's motherboard . These chips implement a technology known as 'Rambus Signaling Logic' - an umbrella term used to promote many advancements, one of which doubles the transfer rate . This may explain why some sources cite the 'effective' memory rate as 500 MHz.
Leaving room for improvement
Interestingly, the amount of available RAM on this console can be expanded by installing the Expansion Pak accessory - a peculiar box that adds another 4.5 MB. While this accessory remained optional for some games (and the majority didn't make use of it), certain titles such as Donkey Kong 64 and The Legend of Zelda: Majora's Mask were designed with the expansion as a requirement, and would display an error screen if it was not present.
The Expansion Pak , an optional accessory sold separately (sometimes bundled with the game that required it).
The Jumper Pak . In the absence of the Expansion Pak, this must be present to terminate the RDRAM bus.
Due to its end-to-end design, RDRAM must be properly terminated; otherwise, signals would bounce back and forth along the bus (a common phenomenon known as reflection). Rambus mitigated this by requiring PC users to install memory modules in pairs and to fill all unused slots with 'Continuity RIMM' (CRIMM) modules, which acted as terminators. For this console, however, Nintendo shipped a terminator called Jumper Pak, which came fitted in place of the Expansion Pak. The Jumper Pak housed only enough capacitors and resistors to match the bus's impedance , thereby reducing reflection. It also served to close the loop in the serial chain .
Now, you may ask, what would happen if you switched on the console without any Pak installed? Well, the onboard memory chips won't be functional, so the boot sequence will fail and nothing will come out of the video signal.
Memory management
The VR4300 includes another coprocessor known as the System Control Coprocessor (CP0), which is composed of a Memory Management Unit (MMU) and a Translation Lookaside Buffer (TLB). The MMU governs how memory is organised and cached.
Although the CPU is capable of addressing up to 4 GB worth of memory, the Nintendo 64 contains far less, even after considering memory-mapped I/O. For that reason, the MMU provides efficient uses for addressing limited memory, including a virtual memory map in which physical memory is mirrored multiple times. Consequently, memory locations are treated as virtual addresses (as opposed to 'physical addresses'). Furthermore, this layout is enhanced by the TLB, which enables developers to define custom memory maps in some mirrors without adding (significant) performance penalties.
At first glance, all of this may seem redundant. However, each mirror (called segment) is connected to distinct circuitry (e.g. L1 cache, physical RAM, or TLB-mapped regions), allowing developers to optimise usage by selecting the most appropriate segment depending on the needs .
Some segments were designed to distinguish between 'kernel' and 'user' locations for security purposes. Nevertheless, the N64 always operates in 'kernel' mode, making the 'non-TLB kernel cached' segment (called 'KSEG0') the most commonly used for games.
Finally, the MMU can also work in 64-bit mode, where memory addresses are 40 bits long. This extends the virtual address space to approximately 1 TB worth of addresses... but I don't think the Nintendo 64 will ever take advantage of this!