MooglyGuy's Shoddily-Put-Together N64 WIP Page - July 2007 Entries

07/06/2007 - 187 on an Undercover COP

• Opcode to test
• Vector parameter increment values for parameters 0 through 7
• Start and end values
• Load address and load values (for vector-load opcodes)
• Store address (for vector-store opcodes)

07/05/2007 - Enlightenment

1. RCP - Reality Central Processor. MIPS chip model R4300. Clocked at approximately 94MHz, with 16kbytes of instruction cache and 8kbytes of data cache (though the listed cache sizes are questionable). Integrates standard COP0 (MMU) and COP1 (FPU) modules.


2. RDRAM - The Nintendo 64's base configuration contains 4mbytes of RDRAM located at the expected place in KUSEG, KSEG0 and KSEG1. An additional 4mbytes is mapped directly after the first 4mbytes if the user has a memory expansion pack inserted into the memory expansion slot.


3. RSP - Reality Signal Processor. Depending on how you look at it, it's either a standard MIPS chip on testosterone or a standard MIPS chip on an antiandrogen. It was designed specifically to handle display lists and audio lists. Its status is partially accessible by the RCP as COP2. The RSP has no MMU or FPU; COP0 access maps to the RDP (4)'s status and command buffer, COP1 does not exist, and COP2 maps to a custom vector instruction set designed specifically for the Nintendo 64, though it is rumored that the instruction set is the predecessor to the VICE multimedia extensions found in the Silicon Graphics O2 workstation. The RSP's vector extensions give the RSP an additional 32 vector registers; each register is 128 bits wide, made up of eight 16-bit fixed-point values that are accessible in various combinations based on bitfields present in the vector-specific instructions. The vector registers can also be accessed manually via MFC2 and MTC2 instructions. In addition, there are eight 64-bit-wide accumulator registers that are accessible only through individual vector-related instructions. To call the RSP's memory architecture bizarre would be an understatement; its instruction cache (8kbytes) and data cache (8kbytes) have been repurposed into the only memory accessible to the RSP. Furthermore, the RSP uses Harvard architecture, limiting data fetches to DMEM and instruction fetches to IMEM. Both IMEM and DMEM are mapped into the RCP's memory space; both the RCP and RSP may initiate DMA transfers to and from RDRAM, and the RCP can manually access the RSP's memory area, though manual access is subject to caching. In both this respect and the additional vector instructions, the RSP can be likened to one of the Playstation 2's VU1 or one of the Playstation 3's SPUs. I could provide more information, but this entry is already quite long, so if any further information is desired, drop me a line at my above-listed locations.


4. RDP - Reality Display Processor. This is what handles most - not all - graphical capabilities for the Nintendo 64 (more on that in a moment). It pulls 64-bit-wide command packets from either RDRAM or RSP DMEM depending on a bit in its status register. Command packets can range from a single 64-bit word (Full Sync, Sync Pipe, Set Color Image, Load TLUT, et cetera) to 22 words (Triangle with Gouraud, Texture and Z-Buffering). While it is not as fast in terms of fill rate as the Playstation 1's GPU, it makes up for it in feature richness. It supports significantly more texture formats than either the Sega Saturn (which is ostensibly not a 3D system, anyway) or the Playstation, including YUV16, Intensity (grayscale texture tinted by a specified primitive color, useful for particle effects) and Intensity with Alpha. It features a four-parameter color combiner which implements the equation (A - B) * C + D separately for both RGB and Alpha, as well as four-parameter blending with optional two-cycle mode (with the expected throughput penalty, of course); in fact, the Color Combiner is sufficiently advanced that outside of software rasterization, one needs full pixel shader support in order to fully emulate its features. The RDP's framebuffer and Z buffer are stored directly in RDRAM.


5. VI - Video Interface. It's fairly unremarkable, as it is designed to be. It handles low-level signal generation, allowing framebuffer origin, color burst, horizontal sync, vertical sync, and other signal-related parameters to be tweaked to the engineer's liking. More usefully, it is worth noting that since the framebuffer is memory-mapped instead of being in a separate CPU-inaccessible region of memory as with the Playstation 1, framebuffer effects are a cinch.


6. Cartridge Memory - This is worth noting, as the cartridge is mapped at 0xb0000000, not 0xbfc00000. In fact, a cartridge is not bootable. The Nintendo 64's Peripheral Interface contains four kbytes of embedded ROM which is initially mapped into memory, but becomes invisible after a certain (as yet unknown) number of cycles. Its job is to perform initial handshaking with the security IC on a cartridge, then subsequently perform a DMA transfer to move a specific portion of the cartridge's memory into KSEG0, at which point the RCP jumps to 0x80000400. While the RCP can access cartridge memory directly, it is much more efficient to simply perform a DMA transfer as necessary.


7. RSP Access - This is labeled simply because of the multitude of ways that the main CPU and RSP can communicate. First and foremost, the main CPU can read and write the RSP's status registers - including PC. The main status register for the RSP has eight semaphores that serve specifically as a way to communicate without having to yank a full interrupt on the main CPU. As mentioned in section (3), the RSP's IMEM and DMEM ranges are accessible from the main CPU as well, but are subject to caching. Lastly, both the main CPU and RSP can initiate a DMA transfer of IMEM, DMEM or both ranges.

06/30/2007 - Back In Black