N64 tech documentation

[Aphex123]

I thought I'd share the documentation I'd accumulated throughout my journey in low level N64 emulation. I haven't included the various source code I have (apart from mame/mess's very informative N64 emulator implementation), since most is easily available and takes up too much space to upload anyway. I originally posted an earlier version of the documents I have on a torrent site, but this is more up to date. To be honest, I haven't really made much of an effort to organise all the files in to directories, but they should be fairly self explanatory anyway.

As far as I'm aware, all of this documentation is public domain and legal. I've made an effort to not include any documents that may not be legal.

Dropbox link

If you've got any other useful info or N64 docs, please, post them. The N64 is notorious for being ill documented, but as far as I'm concerned, the truth is out there...

[WingsORC]

thank you very much

[Azimer]

A nice document base is sorely needed as well as new research to fix inaccuracies and fill holes.

[Aphex123]

A nice document base is sorely needed as well as new research to fix inaccuracies and fill holes.

Could you name any inaccuracies that you know of? I know that parts of the RSP are badly documented, but other than that, I'd say it's not too bad. Besides, MESS provides some great information detailing the inner workings of the RSP.

Perhaps we could get a list of unknown or questionable information regarding the N64 (lacking official documentation). Some things that I can think of include...

RSP
- Vector instructions
- Flag registers

N64DD?

Pretty short list, but I can't think of much else.

[smcd]

Lol I just googled up some stuff trying to find about n64 microcode, and stumbled across an apparent "official" documentation for some n64 stuff, though it says it is supposed to be under a non disclosure agreement. bleh

EDIT: actually it appears it may be the entire n64 sdk. doh. Doesn't seem like it'd be too helpful for any type of hardware-in-software implementation anyhow really, at least not at a low level

[Aphex123]

In all my efforts to find low level documentation for the RSP's microcode (vector instruction set), I haven't come up with much (apart from the abstract descriptions of the instructions). No matter though, the source code of MESS's RSP emulation provides more than enough information. The N64 SDK's, official and non official, do provide some information but it's all high level really (well, the RSP info is atleast). Even the patent on the N64 only details the high level microcode tasks which the N64 SDK implemented, but mention nothing about the actual vector instructions themselves.

I don't know why Nintendo chose to keep the RSP so closely under wraps to developers. I even spoke the RCP's engineer, Tim Van Hook (via email, go to undrian.com), and asked him what he thought about disclosure to developers. He said that he would want the authors of the hardware/software to choose whether or not they wish to release information, but ultimately, it's up to the corporations like Nintendo to decide. Obviously, they're under strict confidentiality agreements.

[zoinkity]

I was under the assumption that it was a variation of MIPS-3D, but then again it really isn't possible to know for certain without actual documentation. If it was though Nintendo could have been bound by agreement to withhold specific information concerning an emerging (and developing) technology.

Oddly, after talking to former employees at Factor 5, Rare, and a couple smaller studios that did microcodes, you hear entirely conflicting information about how much info was available, what tools were provided, and even the degree of support from big-N.

Incidenatally, obviously MESS does LLE for the RSP, but exactly how much of the RDP itself is handled?

[Aphex123]

I was under the assumption that it was a variation of MIPS-3D, but then again it really isn't possible to know for certain without actual documentation. If it was though Nintendo could have been bound by agreement to withhold specific information concerning an emerging (and developing) technology.

Oddly, after talking to former employees at Factor 5, Rare, and a couple smaller studios that did microcodes, you hear entirely conflicting information about how much info was available, what tools were provided, and even the degree of support from big-N.

Incidenatally, obviously MESS does LLE for the RSP, but exactly how much of the RDP itself is handled?

I can't say I've heard of the MIPS-3D ISA before now, but I'm sure the RSP's microcode is based around SGI's earlier work. I asked Tim Van Hook in an email but he couldn't remember what it was based on, however, he did mention the instruction sets he had personal developed and worked on. If anyone wants to know, I can always look through the emails.

Just for interest, and since this is an info thread, I'll post some general info that I (think I) know about the RSP that isn't necessarily common knowledge, although I can't guarantee complete accuracy.

General
- Scalar unit which implements most, but not all, of the r4300i's instruction set.
- Vector unit which implements the vector instruction set and load/store instructions.

Registers
- Thirty-two 32-bit general purpose registers.
- Thirty-two 128-bit vector registers which are operated on as eight 16-bit elements.
- Eight 48-bit accumulator registers, each consisting of 16-bit low, middle and high "slice".
- Four 16-bit flag registers for storing results of operations. From what I understand, the high 8 bits of flag 0 are used as zero flags, the low 8 bits are for carry flags. Flag 1 is for compare, flag 2 is "extension flags" ( I also heard the term "Anciliary clipping flags" being applied to flag 2), although I'm not sure what they mean exactly. The other flag I have no idea about. Does it even exist?

Some notes
The RSP can only directly access 4KB of DMEM, but it can also access memory mapped SP and DPC registers with the mfc0 and mtc0 instructions, which allows it to send commands directly to the RDP and to DMA back and forth between RDRAM and SP instruction and data memory.

Vector instructions use three vector operands, but one of the source vector registers can be operated on in different configurations. A field in the instruction ("el") specifies which element in the vector registers shall be used. For example, "vadd v1,v2,v3[11111111]" would add element 1 of v3 to every element of v2 and store the result in v1. There's different configurations of "el".

MESS emulates the RDP on the low level too and implements a software renderer. If you want info on the RDP, the N64's patent is a good source of information which lists all the RDP commands and their respective formatting and usage (note that both patent US6331856 and US6239810 are essentially the same, but the former gives more detailed RDP info). On another note, The RDP is quite interesting and unusual really. Unlike most graphics chips (even back then), it doesn't specify vertex data (e.g. coordinates, colour, texture coordinates etc) for rendering primitives. It instead uses edge and slope values to be used directly by the edge walking hardware and RGBAZ steppers. If anyone wants to know more, I'll be happy to explain as best I can. The RDP is a fascinating and quite unique piece of hardware I think.

edit: in fact, i'll post some info on the RDP too.

As I mentioned, RDP commands, more specifically the triangle commands, specify data as edge and (inverse) slope values. If you look at "Sheet 74 of 96" in the pdf file "n64_patent_6239810", you can see how the commands are formatted (as well as a helpful little diagram).

To render the triangles, the edge walking hardware has to walk down each edge. Here's the procedure which the edge walking hardware goes through to define the spans (edges) of the triangle (note that mooglyguy posted a similar list but in my opinion, it was slightly inaccurate).

IF is right major triangle (dir = 1)
1. load xright with xm
2. load xleft with xh
3. load xright_inc with dxmdy
4. load xleft_inc with dxhdy
5. load j with yh
6. if j is less than ym then, increment j by 1, increment xleft by xleft_inc, increment xright by xright_inc, render span (at vertical line j) from xleft to xright. repeat step 6 until j >= ym.
7. load xright with xl
8. load xright_inc with dxldy
9. load xleft_inc with dxhdy
10. load j with ym
11. if j is less than yl then, increment j by 1, increment xleft by xleft_inc, increment xright by xright_inc, render span (at vertical line j) from xleft to xright. repeat step 11 until j >= yl.
ELSE
1. load xright with xh
2. load xleft with xm
3. load xright_inc with dxhdy
4. load xleft_inc with dxmdy
5. load j with yh
6. if j is less than ym then, increment j by 1, increment xleft by xleft_inc, increment xright by xright_inc, render span (at vertical line j) from xleft to xright. repeat step 6 until j >= ym.
7. load xleft with xl
8. load xright_inc with dxhdy
9. load xleft_inc with dxldy
10. load j with ym
11. if j is less than yl then, increment j by 1, increment xleft by xleft_inc, increment xright by xright_inc, render span (at vertical line j) from xleft to xright. repeat step 11 until j >= yl.

That's pretty much how the edge walking hardware operates. During the rendering of the each line, the stepping hardware interpolates the shade values, texture coordinates and Z buffer values in a similar way.

Of course, this is all very low level information that most N64 programmers wouldn't need to know. As far as I'm aware, the libraries would convert vertex information (provided by the programmers) to edge/slope format for the RDP to process. The conversion between vertex values and edge coefficients is fairly straight forward, but if somebody wants to know, i'll be happy to detail what i know of it.

[Aphex123]

Here's a little bit of info about how the N64 boots up. It's quite widely known, but oh well, it can't hurt.

Upon power on/reset, the N64 begins executing the IPL (initial program load) boot ROM at physical address 0x1fc00000 (kseg 1 address 0xbfc00000). The boot code pretty much just initialises the hardware, does a few checks and copies the cartridge boot code (cart offset 0x40-0x1000) to 0xa4000040 (RSP DMEM) and jumps to it. (After this, the cartridge boot code is in control, so it can vary, but the following is typically what will occur). At this point, a portion of the main program code (starting cart offset 0x1000) is DMA'd to the 4 byte address specified at cart offset 0x8 (in the cart header). This address is usually referred to as the "Boot address offset" or "Program Counter". This address is where the actual program will begin. Think of it as the "main" function of the program. However, before this happens, a CRC check is done on the cartridge boot code. This is usually done somewhere around RDRAM address 0x80000100 - 0x80000200. The results are compared to the two CRC values in the cart ROM's header. If they don't match, the N64 will just hang in an infinite loop (using the BGEZAL instruction), otherwise, execution will continue.

Note that most emulators choose to not boot from the real PIF ROM and instead begin execution at 0xa4000040 (after copying the cart boot code to there). Of course, they set up all the registers to the values that the PIF ROM would put them in, first.

Also, another quick note. The cartridge ROM is mapped at physical address 0x10000000 (kseg 1 address 0xb0000000).

[zoinkity]

Incidentally, there's six different CRC checks within the 64DD's IPL. That thing's a real pain.
ret = (A3 == 0xE1F9D977)
ret &=(T2 == 0xDA29C069)
ret &=(T3 == 0xBC587021)
ret &=(S0 == 0x33E17503)
ret &=(A2 == 0x96310A49)
ret &=(T4 == 0x08E5FB8C)

[edit]
Just noticed you pointed out that PIF ROM executes between that jump to rdram and sets some static values.

Incidentally, Nemu64's solution was to ignore all BGEZALs. Ran into a problem with custom code that used that particular op. Throw a breakpoint on it sometime after invalidating the CRC. It will walk right past it.

Incidentally, you wouldn't have a list of all the static values that are set by the hardware? Very few are set by hardware, but among them the video mode/region value.

For reference:
05000000 is 64DD device registers
06000000 is 64DD IPL
08000000 is the typical address for FLASHram/SRAM

Incidentally, GameShark/Pro Action Replays have a unique setup. It's apparently some 16bit memory system that uses an exploit for 32bit access. The upper halfwords are readable from 1EE00000 and the lower halfwords from 1EF00000. There are points where these are read and intermeshed via software.