Two bits of related news; the 4.0 release of GlideN64, the most-compatible High-Level-Emulation graphics plugin for N64 emulators: but more interestingly, this story about the struggle to reverse-engineer the GPU microcode used in Indiana Jones and the Infernal Machine and Star Wars Episode I: Battle for Naboo that have eluded developers for decades.
When consumer chips were pretty consistently fixed-function, the N64 (like SGI hardware and other high-end 3D hardware) had graphics chips that were much more generic RISC processors. Owing to being an extended MIPS R4000 design, the N64 even had hardware T&L 3 years before the release of the NVidia GeForce, the first consumer card with support.
Well wasn’t N64 designed in cooperation with SGI?
BTW, Matrox and Rendition Verite cards before GeForce were also, perhaps, potentially capable of some programmability…
From https://en.wikipedia.org/wiki/Matrox_G400#Performance
http://web.archive.org/web/20021122193755/http://grafi.ii.pw.edu.pl/gbm/matrox/tlspec.html
http://web.archive.org/web/20030207162604/http://grafi.ii.pw.edu.pl/gbm/matrox/ (15.12 and 16.12)
The thing to understand about the N64 is that it isn’t magic, that’s just a lot of hype by SGI. The N64 chipset consists of three main parts: the main cpu, a second cpu to handle sounds and video control (the RSP), and a fairly standard GPU (the RDP). About the only differences between the RDP and other GPUs of the time: it used a funny edge-walking algorithm for rasterizing polys, and it had a pretty tiny texture cache (holds one 32×32 32-bit texture). The RSP is an R4000 MIPs processor with the multiply, divide, and branch likely opcodes removed, and a simple SIMD unit added to help process audio, geometry, and lighting. No, the RDP doesn’t handle that. The RSP controls a DMA channel to help move data needed for by the RDP, like textures, and to fetch samples to process into the audio output. The N64 hardware merely has a stereo audio out port that has a DMA channel to fetch the stereo samples. The RSP does all mixing and decompression, leaving the result in RDRAM for the DMA to fetch.
The “microcode” is nothing of the sort – it’s actually a library of MIPS assembly code to parse and execute a stream of byte code like some compilers generate. The byte code is formatted to be similar to the command buffer format the RDP uses to help minimize the work the RSP has to do. Many of the commands are simply passed on by the RSP directly to the RDP, with maybe a little work like doing matrix operations on the coords to drawing commands. Reverse engineering the microcode is mainly disassembling the RSP MIPS code and figuring out how the RSP is handling various commands from the byte code. The article covers that part of the process rather well. It helps that the custom microcode for the games in question are mostly a modification to an existing microcode library.