.Z64 File Format

Introduction

A .z64, .v64 or .n64 file is a copy of the ROM in a Nintendo 64 cartridge, for playing in an emulator or running on a flash cartridge. The three extensions are one format in three byte orders; the first four bytes tell them apart. Homebrew should ship as .z64, the order the processor reads; the other two come from copiers (the Doctor V64 swapped each pair of bytes) and from tools that wrote little-endian words.

The console runs a MIPS processor, the NEC VR4300, big-endian, with a second processor, the RSP, that runs microcode for graphics and sound. This page set describes the file, the code the console starts and the hardware addresses that code uses; the instructions themselves are on the MIPS pages (the VR4300 is the MIPS III variant).

Byte orders

The explorer, like the mupen64plus emulator, tells them by the first four bytes (the extension is not used) and reads every other byte through the matching swap. A file whose first four bytes are none of the three is not a Nintendo 64 ROM, whatever its name: some other programs also use .n64 (the SGI build folders of the GLUT library are named so).

Structure

The header page describes every field. The boot code is one of a few known programs, each paired with a security chip (the CIC) in the cartridge; which one it is decides how the header’s check code is computed and what the boot address means: see boot code and check code. The addresses the code uses to talk to the hardware are on memory map and registers.

Not described

Known, not yet covered

• Reference: the 64DD disk formats and the 64DD IPL boot codes (named in the boot chip table, nothing else), the Aleck 64 arcade cartridges, the bit fields of the registers (only their names and roles are given), the RDRAM register block, the RSP’s instruction set, and the compressed formats games use (Yaz0, MIO0).
• Viewer: the explorer opens .z64, .v64 and .n64 files by their first four bytes: the header field by field, the boot code fingerprinted against the known chips (CRC-32 and word sum), the header’s check code verified under the right chip’s algorithm (all four are tried when the boot code is not in the list), the boot process, the memory map and registers, and two disassemblies with the VR4300 decoder: the boot code at $A4000040 and the program from the boot address, naming hardware registers where an address built by lui lands on one. Options: byte order, check code algorithm, load address, entry point, register names, pseudo-instructions. It does not decode the RSP’s microcode (the RSP has its own instruction set; nothing here reads it), does not expand compressed data, shows only the first 1 MiB as code, decodes every word as an instruction (no code and data separation) and does not follow jumps. The check code was verified on five real homebrew ROMs, all with the 6102 boot code; the algorithms of the 6103, 6105 and 6106 chips were checked only on built files against a second implementation of the published description. It has not been run in a browser by its author.

Links