April 6th, 2012, 09:11
Now with 30% more words!
What's the lifecycle of the RDP & RSP?
I am working on a proof-of-concept N64 emulator for an exotic, speed-constrained platform. A direct port from an open-source emulator is not an option because I cannot compile from C or C++. (That's really all the details I'm willing to give for now–sorry!)
Since this is just a proof-of-concept, I don't expect to run a lot of games. Just a few demo ROMs would be fine for me, and my most ambitious goal would be Super Mario 64.
So far I've gone through a good deal of documentation (including anarko's n64ops) and the CPU seems under control. It's not the first emulator I'm working on either and I have good assembly knowledge, so I know what to expect. (Besides, MIPS is a surprisingly pleasant architecture to emulate, since instructions have so little side-effects.)
My biggest issues are the RSP & RDP. My understanding is that those are responsible for most of the audio and graphical work, and they can be programmed with microcode. However, since official documentation and support were so poor and so sparse, most Nintendo 64 games ended up using just a few different microcode libraries.
I know from the documentation that both coprocessors can be loaded with instructions, and I have also figured out that by making a checksum of the loaded instructions, it's possible to guess what operation the game is trying to perform, and it's possible to achieve the right effect without actually executing the exact same code. (I believe this is what is called high-level emulation, and it'll be enough for my purposes.)
It's also my understanding that while the main CPU is constantly running, the RSP and RDP aren't: data is loaded in their address space, they are activated and they do their dirty work, then they are suspended again, waiting for another workload.
I don't know, however, how those processors get started. I am not informed enough to make the clear distinction between what goes in a graphical plugin and what goes into core code in an emulator either, so it's harder to look up in the source code.
I read on a site (I'm sorry, the board software won't let me link to it because I'm a new user) that clearing a bunch of flags is enough to get the RSP going, and I can probably assume that the RDP starts in a similar fashion, but that's hardly enough to emulate the behavior.
So, can someone point me in the right direction? What's the "lifecycle" of a use of the RSP and RDP, how does it start and how does it end? I feel that if I knew better what I should be looking for, I would be able to poke around in open source emulators to figure out the rest.
The CPU writes to the relevant IO registers to enable them, and off they go. The RSP is essentially started by clearing the "halt" bit in the SP status register (0x04040010), although there are other bits which cause it to operate in different fashions (breakpoint mode). The RDP will start processing a display list upon a write to the dpc end reg (0x04100004).
The RSP is stopped by setting the halt bit in the sp status register. The RDP will halt when it has reached the end of the display list.
Your explanation of high level emulation seems right on, and I would say that, in your case, going the route of high level emulation is the best idea, since low level emulation of the N64 is very tricky and largely unnecessary for most purposes.
Check out my post N64 tech documentation if you want some documentation on the N64. It covers pretty much everything you would want to know. Especially, check out the patents which are very good sources on the RDP in particular. For low level RSP data, check out mame. If you're focusing on high level emulation, this may not be useful, but it can't hurt to check it out.
Good look with your emulator. Anything else, feel free to ask and I will try my best.
Last edited by Aphex123; July 17th, 2012 at 02:34.