pseultra
pseultra copied to clipboard
pseudophpt
Add RDRAM Initialization to Bootcode
The boot code should initialize RDRAM in addition to the RCP. Some partial documentation on how to do this can be found at https://github.com/mikeryan/n64dev/blob/53c2a11f822caa1c96b9bd2eabcb125e5136b37d/docs/n64.lyx. In addition to the RDRAM interface registers at 0xA4700000, the RDRAM registers seem to be located at 0xA3F00000 for the first module and at 0xA3F08000 for the second module and the boot code may be setting the REFROW register of the second module according to the hardware revision.
ETA: an RDRAM datasheet (though for a different part) can be found at pdf.datasheetcatalog.com/datasheet/oki/MSM5718C50.pdf, and some information on the NEC part can be found at http://bitsavers.trailing-edge.com/components/nec/_dataBooks/1995_NEC_Application_Specific_Memory.pdf.
I've myself been trying to wrap my head around this and reversed C code out of the 6102's, as well as post relevant Rambus docs in Discord64#docs and some more copies of fairly useless NEC docs.
There's likely some shortcuts we may be able to take given the silly mess Nintendo made for RCP v1 support and hardcoding stuff for specific chips versus a generic path, but as of right now it's useless to try to write code without a flash cartridge in my hands, as this requires hardware testing.
I have a flash cart, so I can test whatever code may be written. I understand not wanting to rely on somebody else's hardware though, so I get that may not be good enough for you to get involved.
On Sat, Jan 18, 2020, 12:16 AM Nabile Rahmani [email protected] wrote:
I've myself been trying to wrap my head around this and reversed C code out of the 6102's, as well as post relevant Rambus docs in Discord64#docs and some more copies of fairly useless NEC docs.
There's likely some shortcuts we may be able to take given the silly mess Nintendo made for RCP v1 support and hardcoding stuff for specific chips versus a generic path, but as of right now it's useless to try to write code without a flash cartridge in my hands, as this requires hardware testing.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/pseudophpt/pseultra/issues/23?email_source=notifications&email_token=AB35VVS3CM7GI7BM5KV2FG3Q6K3EJA5CNFSM4KIRH7YKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJJTFEQ#issuecomment-575877778, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB35VVV6AGJKBDUOUCNNAJ3Q6K3EJANCNFSM4KIRH7YA .
We will definitely need testing from more people to cover both the 2x2 MB and 1x4 MB models anyways :p
Like, the code itself will be straightforward to make and getting it to work shouldn't take days, it's just that it might take quite a few tries to get the calibration right, which means backs and forths.
Essentially, all that's needed is the following:
- Set a bunch of RI/MI registers to configure the RAC.
- For each memory chip, set its registers and calibrate it until it becomes stable enough to be usable, which you'd test with writes/reads. Then you add its size as defined by the device type information embedded in a register to the total amount of memory detected.
- Write back the total amount of memory to 0x318 in RAM (or any other location of pseultra's choosing for storing the memory size).
- Initialise the CPU caches.
Nintendo's IPL3 does this additionally:
- DMA the rest of IPL3 to RAM at 0.
- Jump to 0.
But since we're not doing CRC checks we should be able to DMA the game's entry point and jump to it instead.
If you bang out an initial version of the code, I can get half a dozen people to test, pretty easily, on all sorts of hardware variants. No problem. And most of us are decent devs so we can tweak calibration values too. Agreed on what needs to be done, and that we can skip the CRC (just copy the correct value from the header to the expected registers).