RDRAM

Rambus DRAM (or RDRAM) is a type of synchronous dynamic random-access memory (SDRAM) designed by Rambus. The N64 motherboard came with either one or two chips, totaling 4 MB (4,194,304 bytes) of general purpose storage which can be accessed by the CPU. The optional Expansion Pak could increase this by an additional 4 MB and is required for some games to run.

Each byte of RDRAM actually has an extra bit, which can only be used by the RDP and VI core. This 9th bit is used to store things like anti-aliasing coverage in the color buffer. On systems other than the N64, the 9th bit would likely be used for parity checks.

= RDRAM system overview =

A typical RDRAM system is composed of 3 main elements :


 * a controller, which act as the channel master. This part reside in the RI.
 * the channel, which is a synchronous bus connecting the RDRAM devices together
 * RDRAM modules, each containing memory banks, and some registers.

TODO: insert a small diagram

The N64 system implements the "Base RDRAM" protocol, which is the earliest version of RDRAM protocol. Historical note, latter version of the protocol are "Concurrent RDRAM" and "Direct RDRAM".

= Interface Pinouts = RSL stands for Rambus Signaling Levels, a low-voltage-swing, active-low signaling technology.

Source: Rambus concurrent RDRAM datasheet

= RDRAM registers =

See RI page for details about how they are mapped into CPU address space.

TODO: detailed register description, with bit layout and arrows.

Programming caution :


 * Before reading any RDRAM register content, RDRAM current control must be calibrated
 * Also, it seems that RDRAM register reads are surrounded by MI_MODE = SET_DRAM_REG / CLR_DRAM_REG

= RDRAM addressing = Warning : In this paragraph, we describe RDRAM addressing within the RDRAM protocol. This is not to be confused with RDRAM addresses "as seen" by the CPU or RCP. See RI memory addressing paragraph for details about how the RI converts addresses between the two address spaces.

RDRAM protocol addresses RDRAM memory and registers using a 36bit address and a variety of commands :


 * many types of memory read
 * many types of memory write
 * register read
 * register write
 * broadcast register write (all connected RDRAM will write the same value to the specified register)

The higher part of the address identify an RDRAM device, the lower part is an offset within the device (in register-space for register commands, and memory space for memory commands).

The procedure of identifying which RDRAM device is addressed by a given command + address is call Id matching.

It works as follow:

Given a 36 bit address Adr[35:0], we compute a "partially bit-swapped" AdrS[35:0] such that bits [28:20] and bits [19:11] are swapped on a bit by bit bases based on the value of SwapField (from AddressSelect register). Bits [35:29] and [10:0] are left untouched. This swapping of bits provides a flexible way of remapping addresses across banks of a given device and across devices to benefit from internal row caching. This can help increase DRAM hit rate in several applications.

The upper 16 bits (or 15bits for 2x{8,9}Mbit devices) of AdrS are then compared to IdField contained in DeviceId register. If both are equal or if the operation is a broadcast register write, the RDRAM device has a Id Match.

More formally this can be written as follow :

= Current Control calibration = TODO

= Known RDRAM Console Chip Configurations =

= Known RDRAM Expansion Pak Configurations = There are 3rd party Expansion Paks that have 2 chips which are both 2.25Megabytes each. Please provide images and makers here.

= Initialization Sequence = This Initialization sequence is based on the 6102 CIC boot code

File:Cncrntug.pdf

= Expansion Pak Detection = The typical way to detect how much memory is installed is to probe it.

LibUltra provides a function called osGetMemSize which does this. The function writes different values at addresses in the uncached KSEG1 direct map, starting at 0xa0300000, and then reads the values back. It tries successively higher addresses, jumping by 1 MB each time through the loop. It returns the amount of RAM which it successfully wrote and read back, rounded up to a number of megabytes.

// C-like pseudocode... u32 osGetMemSize(void) { // Base address of RAM in kseg1. uintptr_t base_addr = 0xa0000000; uintptr_t megabyte = 1024 * 1024; // Address where we will probe. uintptr_t cur_addr = kseg1 + 3 * megabyte; while (true) { write to addr; read from addr; if (value read != value written) { break; }        cur_addr += megabyte; }    return cur_addr - base_addr; }

During boot, IPL3 will also write the amount of RAM available, in bytes, to a 32-bit value at address 0x80000318 (or 0x800003f0, for CIC 6105). On retail hardware, this should always have the value 0x400000 (no expansion pak) or 0x800000 (expansion pak). When using LibUltra, this variable can be accessed with the name osMemSize, which is defined like this:

extern u32 osMemSize;

LibDragon provides the the amount of memory installed with the get_memory_size function.

= Drawbacks and Limitations =

Opinion
"RDRAM has excellent data transfer speed for the era (bytes per second) but due to the protocol used and serial interface, memory transactions were somewhat slower (how much time it took from starting a read/write operation to finishing it). In practice, you may find that the available memory bandwidth is a limiting factor for the performance of your game. See: How fast was Rambus compared to regular EDO RAM?"

= Datasheets = Several manufacturers produced compatible "Base RDRAM" modules such as :


 * LG GM73V1892AH16L
 * NEC uPD488170L
 * OKI MSM5718B70
 * Toshiba TC59R1809VK TC59R1809HK

Reference :