Similar to the PS1 and Saturn, N64 games are written for bare metal. However, there are no BIOS routines available to simplify hardware operations. As a substitute, games embed a small operating system that provides a fair amount of abstraction to efficiently manage the CPU, GPU, and I/O.
This is not the conventional desktop OS that we may imagine at first, it's just a microkernel with the smallest possible footprint that offers the following functionality :
- Multithreading using message passing.
- Scheduling and preemption.
- Simplified register and I/O access.
All in all, these functions are critical for coordinating audio, video, and game logic tasks - all of which need to work concurrently - in an efficient manner.
The kernel is automatically embedded when using Nintendo's libraries. Additionally, if programmers decide not to include part of the library set, the corresponding portion of the kernel is stripped to avoid wasting cartridge space.
Boot process
Unlike previous cartridge-based systems, the Nintendo 64 follows a sophisticated boot process to prepare all of its hardware before the actual game runs. This process begins as soon as the user powers on the console and is very similar to its CD-based contemporaries bundling a BIOS or IPL.
These routines are also referred to as Initial Program Loader (IPL) and work as follows :
- The user turns on the console.
- The PIF-NUS (a separate chip on the motherboard) subdues the main CPU with an infinite reset until it validates the Checking Integrated Circuit (CIC) chip found in the game cartridge.
- The PIF-NUS and the CIC chip are explained further in the I/O and anti-piracy sections, respectively.
- If the verification process finishes successfully, the CPU starts execution at
0xBFC00000. This address points to an internal ROM within PIF-NUS, specifically the first boot stage called IPL1. - IPL1 initialises part of the hardware (CPU registers, the parallel interface, and the RCP), then copies the next stage (IPL2) from the internal ROM to the RSP's memory for faster execution. It then redirects execution there.
- IPL2 copies the first four bytes of the game ROM into the RSP's memory. This is used to adjust the ROM bus timings. Afterwards, it copies another 4 KB of the ROM header and sends a checksum of it to the PIF-NUS, which verifies the checksum using the cartridge's CIC chip. If the verification fails, the PIF-NUS interrupts the CPU indefinitely. Otherwise, the CPU continues execution on those 4 KB, which contain the next boot stage, called IPL3.
- IPL3 initialises RDRAM, the CPU cache, and the Expansion Pak (if present). Afterwards, it copies 1 MB of game ROM into RDRAM, computes its checksum, and compares it against a precomputed value stored in the ROM header. Finally, the CPU jumps to the game code in RDRAM.
As IPL3 resides within the game cartridge, not every game includes the same code. Additionally, the IPL3 checksum stored in the CIC is hardcoded . Thus, the CIC chip and IPL3 variants found in the cartridge are bound together and cannot be swapped with different models.