Page 1 of 3 123 LastLast
Results 1 to 10 of 21
  1. #1
    EmuTalk Member Aphex123's Avatar
    Join Date
    Jul 2010
    Location
    Nottingham, England
    Posts
    12
    Mentioned
    0 Post(s)

    N64 N64 tech documentation

    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...
    Last edited by Aphex123; July 17th, 2012 at 01:37.

  2. #2
    EmuTalk Member
    Join Date
    Sep 2011
    Posts
    9
    Mentioned
    0 Post(s)
    thank you very much



    • Advertising

      advertising
      EmuTalk.net
      has no influence
      on the ads that
      are displayed
        
       

  3. #3
    Emulator Developer Azimer's Avatar
    Join Date
    Nov 2001
    Location
    USA
    Posts
    872
    Mentioned
    1 Post(s)
    A nice document base is sorely needed as well as new research to fix inaccuracies and fill holes.
    -Azimer

    "I am not a teacher: only a fellow traveler of whom you asked the way.
    I pointed ahead -- ahead of myself as well as of you." (George Bernard Shaw)

  4. #4
    EmuTalk Member Aphex123's Avatar
    Join Date
    Jul 2010
    Location
    Nottingham, England
    Posts
    12
    Mentioned
    0 Post(s)
    Quote Originally Posted by Azimer View Post
    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.
    Last edited by Aphex123; May 27th, 2012 at 02:16.

  5. #5
    Moderator smcd's Avatar
    Join Date
    Jun 2004
    Posts
    2,532
    Mentioned
    0 Post(s)
    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
    Last edited by smcd; May 18th, 2012 at 00:15.

  6. #6
    EmuTalk Member Aphex123's Avatar
    Join Date
    Jul 2010
    Location
    Nottingham, England
    Posts
    12
    Mentioned
    0 Post(s)
    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.
    Last edited by Aphex123; May 18th, 2012 at 13:28.

  7. #7
    EmuTalk Member
    Join Date
    Mar 2004
    Posts
    152
    Mentioned
    1 Post(s)
    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?

  8. #8
    EmuTalk Member Aphex123's Avatar
    Join Date
    Jul 2010
    Location
    Nottingham, England
    Posts
    12
    Mentioned
    0 Post(s)
    Quote Originally Posted by zoinkity View Post
    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.
    Last edited by Aphex123; May 27th, 2012 at 09:19. Reason: more info on flag registers

  9. #9
    EmuTalk Member Aphex123's Avatar
    Join Date
    Jul 2010
    Location
    Nottingham, England
    Posts
    12
    Mentioned
    0 Post(s)
    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).
    Last edited by Aphex123; May 30th, 2012 at 03:38.

  10. #10
    EmuTalk Member
    Join Date
    Mar 2004
    Posts
    152
    Mentioned
    1 Post(s)
    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.
    Last edited by zoinkity; June 5th, 2012 at 00:01. Reason: I KAN REED

Page 1 of 3 123 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •