|
The RDRAM chips are connected to the RCP via a bus called RAMBUS. This bus allows to connect multiple chips to a controller; the controller can then talk to each chip and configure it to reply to a certain range of addresses (that is, "map it" into a memory map).
The RDRAM initialization is performed by [[IPL3]], a piece of the Nintendo 64 secure boot code (there are a few variants to its contents but the differences are not related to RAM management). IPL3 does the RDRAM chip initialization using a process called "current calibration", and then map them into the (phyisical) address space, by giving to each chip its own address. TheNintendo's codeIPL3 incan IPL3correctly ishandle readyup to handle 14 2-MiB andchips 2(it also has buggy support for 1 MiB chips, butwhich itprobably doeswere currentlynever mapreleased onlyby enoughRambus, chipsso untilthe 8code MiBwas isnever reachedtested).
For a long time, it was then believed that changing IPL3 would be enough to allow more chips to be mapped, assuming somebody built an expansion pak card with more chips in it. ThisInstead, islate madework difficulton because[Libdragon's IPL3open contentssource areIPL3](https://github.com/DragonMinded/libdragon/tree/preview/boot) verifiedbrought throughmore areverse hashengineering andof arethe partRI ofchip, thewhich secureeventually bootproven chain,that soRI even*internally* ifruns thea hashstate canmachine nowthat betracks bruteforcedRDRAM withbank GPUsstatus, (and only has beenenough done aroom fewfor times8 as1-MiB proofbanks (each 2-MiB chip is logically made of concepts2 1-MiB bank),. nobodyMore hasdetails stillcan writtenbe andfound releasedin anthe open[RI sourcebank IPL3status boottracking]([[RDRAM codeInterface#Bank toStatus Tracking]]) tinkerwiki withsection.
On top of this, Rasky (who authored Libdragon's IPL3) also got the chance to test a custom made expansion pak with 8 MiB of RAM in it, designed by LambBraink. This pak uses donor chips from official expansion paks, and is correctly recognized by Nintendo IPL3, though just as a 4 MiB pak. Anyway, by hacking Libdragon's open source IPL3, it can be seen that the extra banks were indeed present on the bus, but it turned out to be inaccessible after bus mapping. This is further proof that RI is not actually able to handle more than 8 MiB of RAM.
This notwithstanding, Mazamars312 has done investigations while implementing his N64-on-FPGA system, and has reported that, even if the chips are mapped to more than 8 MiB, it seems like the RCP chip itself (specifically, the RI subsystem which is in charge of converting VR4300 memory accesses to RAMBUS packets) is physically limited to managing requests in the first 8 MiB range. That is, even if the VR4300 generates accesses beyond 8 MiB, the RI refuses to generate the corresponding RAMBUS packets to talk to the chips that have been mapped there. In other words, the 8 MiB limit seems hardcoded in the RCP chip. If there is a way to unlock this limit via RI hardware registers, it is not known at this time.
The tests Mazamars312 conducted are currently not reproducible with open source source and tools. Libdragon is planning to eventually release an open source IPL3, at which point it would be easier for others to experiment with the RDRAM initialization sequence.
=== Is it true that the RSP has hardware MPEG-1 acceleration? Is it used by full motion videos in Resident Evil 2? ===
|