N64 Glide Plugin

[Dave2001]

Ok, I'm continuing my post on Emu Coding.

The status of the glide plugin:
It runs almost all 2D demos.

Thanks Azimer for the interrupt code. I had put it into ProcessRDPList instead of ProcessDList lain: . Now the games run right.

I still need information about how the N64 draws 3d objects though.

Oh, and remember, you can contact me using ICQ #24553273.

 

[Dave2001]

Ok, I'm having EXTREME difficulty finding information on display lists. Can anyone provide me with some information?

 

[Hacktarux]

Display lists are lists of commands that are used by the rsp to draw graphics. A library executed by the rsp take each command of the DList and execute a code corresponding to the command. What you have to do is to understand what is done in this code. (And also it is what will take a long long long long long time to understand).

In a first time you don't really have to understand all the rsp code, you can use header files and the different man pages that describe the ucode0. For more informations, look at the documentation files of TrueReality, you will find on it where are located the data you need in the N64 memory.

To find how each command are encoded, look at the gbi.h file. (I know it looks quite complex, the first time you will look at it, but it isn't, it's just very long).

Good luck man !

 

[Dave2001]

Ok, thanks. Now I know where to start looking. By the way, I was unable to find the TrueReality documentation files you mentioned. They weren't with any version of TrueReality that I could find.

Anyway, without them, I need to know where the codes are located in memory. I'm (in the video dll) responsible for executing them, right?

 

[Hacktarux]

It's only located on the sources release of TR.
Find the unix version at www.emuhq.com/truereality, I know these files are included with.

 

[Dave2001]

Actually, there was a broken link for the download. It's ok, though, because I got it at Zophar's Domain and it had all the documentation with it.

 

[Dave2001]

OK, as most people who wrote video plugins once were, I am somewhat confused. The documentation with TrueReality is very confusing. I have several things I need to verify:

#1. I am responsible for emulating both the RSP and RDP processors in my plugin, right?

#2. DMEM in the plugin stands for the RSP data memory, and IMEM stands for the RSP instruction memory, correct?

#3. Am I supposed to emulate the RSP in ProcessDList and the RDP in ProcessRDPList?

I also have some questions that I need to have answered:

#1. Where do I find the start of the code to be executed?

Please tell me exactly what I am responsible for doing in ProcessDList() and ProcessRDPList().

If I said something that doesn't make sense, please try to clear it up for me.

 

[Dave2001]

Ok, let's keep it simple.

Do I need to emulate the RSP?

I'm starting to understand the RSP processor, but I'm not sure if I'm supposed to emulate it in the plugin.

I'm pretty sure I am, but am I supposed to emulate the RDP?

 

[Eddy]

CAN SOMEBODY HELP THE GUY?? Cyberman i know you can help well i dont think you need to emulate the rsp in the gfx plugin, that wouldnt make sense, but i think you need to take the commands it gives you, and convert it into direct x coding and stuff. Thats where the coding comes in, im guessing all around dave.

 

[Azimer]

Ok, I'm continuing my post on Emu Coding.

The status of the glide plugin:
It runs almost all 2D demos.

Thanks Azimer for the interrupt code. I had put it into ProcessRDPList instead of ProcessDList lain: . Now the games run right.

I still need information about how the N64 draws 3d objects though.

Oh, and remember, you can contact me using ICQ #24553273.

It *IS* ProcessDList. ProcessRDPList occurs when the RSP does the graphics geometry (which is a bad thing). Make sure it isn't.

 

[Azimer]

OK, as most people who wrote video plugins once were, I am somewhat confused. The documentation with TrueReality is very confusing. I have several things I need to verify:

#1. I am responsible for emulating both the RSP and RDP processors in my plugin, right?

#2. DMEM in the plugin stands for the RSP data memory, and IMEM stands for the RSP instruction memory, correct?

#3. Am I supposed to emulate the RSP in ProcessDList and the RDP in ProcessRDPList?

I also have some questions that I need to have answered:

#1. Where do I find the start of the code to be executed?

Please tell me exactly what I am responsible for doing in ProcessDList() and ProcessRDPList().

If I said something that doesn't make sense, please try to clear it up for me.

#1. HLE Bypasses the RSP and simulates what it does. Graphics HLE also simulates a lot of what the RDP does, but must follow some rules since some of the RDP is immediately accessable.

#2. That is correct. You may need to work with RSP microcode in the future to reverse information about certain things that don't seem sto be so apparent. (Diddy Kong Racing, Perfect Dark, Environment Mapping in Zelda, other things). This is a lot of fun... ???

#3. You are to simulate (or emulate I suppose) the RSP in ProcessDList and emulate the RDP in ProcessRDPList. You can basically ignore ProcessRDPList for HLE Audio. It's only necessary for Low Level Graphics (which zilmar's RSP dll sends to the graphics dll).

#1. Thanks to the hard work by Epsilon, we have the following information available to us which was posted on the old UltraHLE page. Check this out:

Initialisation:
If you know the following you can directly start HLE out of it.
HLE: High Level Emulation - first hacked out by Epsilon and
RealityMan.
(Authors of UltraHLE.)
The DMEM is filled from 0x04000fc0 - 0x04000fff with the following:
0x04000fc0: task
0x00000001 ... Graphics Task
0x00000002 ... Audio Task
0x04000fc4: flags?
0x00000002 ... DP wait
0x04000fc8: bootcode
0x04000fcc: bootcode length
0x04000fd0: ucode
0x04000fd4: ucode length
0x04000fd8: ucode data
0x04000fdc: ucode data length
0x04000fe0: dram stack (for matrices)
0x04000fe4: dram stack length
0x04000fe8: ?
0x04000fec: ?
0x04000ff0: display list
0x04000ff4: display list length
0x04000ff8: ?
0x04000ffc: ?

 

[Dave2001]

OK, I'm still a little confused. Do I not need to worry about the RDP yet, since it's not even calling ProcessRDPList? Isn't the RDP responsible for actually drawing the stuff?

And I'm still not sure where the code is that I'm supposed to be executing.

or is it at (as a word) display list with (as a word) display list length in imem?

 

[Hacktarux]

The display list is stored in the RDRAM, the RSP load them to the IMEM but you don't have to emulator the RSP, so you will take the display list on the RDRAM.

The library executed by the rsp analyse the top byte of each command of the DLIST, if it is greater than 0xC0 it sends it directly to the RDP, if it is less than 0xC0, it executed an appropriate code that can for example send many commands to the RDP or anything else.
In ProcessRDPList (lle emulation you only have to handle commands greater than 0xC0 since the RSP plugin must have already processed other commands).
In ProcessDList you have to execute each commands. Of course you don't need to emulate the RSP, but you have to find what the RSP code that is normally executed do and then write a C++ hle code to simulate what the RSP does.

 

[Dave2001]

By the way, Azimer, check your messages. I sent one, but I'm not sure if it's going to tell you by email.

Never mind.

 

[Dave2001]

I bring good news from the glide plugin! :colgate: By looking at the TR64 source and talking to Azimer, I finally got the display list to execute in a logical order (ex. set all the segments, set clipping, set modes). Now I'm on to the actual simulation of these instructions.

 

[Eddy]

WOW Dave good to hear, i wanted to make a plugin based on glide, but then i realized, i didnt know the first step to doing it, ill stick to my homebrew input. Its not bad, at least i got dinput working good but rumble? raw data? thats all too much for me at the moment. Good to hear you taking a stab at it.

 

[Azimer]

I'll do anything to promote new plugin development while I am in this emulation world.

 

[Dave2001]

Ok, I'm getting kinda sick of parts of my source being deleted by corruption ???. When glide freezes (switching windows, ex. illegal operation), I have to reset my computer, resulting in the loss of some of the files I'm working on. I learned after the first time to keep lots of backups, but it's still annoying to have to redo a function that you just implemented. lain2:

Is there ANY way to use glide in a window? I can't find it if there is.

 

[Eddy]

Sorry to say dave, glide had window support in its new version. But glide 4 was never released, because 3dfx went to bankruptcy. But until then, glide 3 or 2 had no window support. SORRY :-]

 

[Dave2001]

That's Ok... It's somewhat hard to program in, but I think I can do it. I just have to make backup copies every time I want to try something new that might perform an illegal operation. Also, you must switch to fullscreen mode to see anything. There is an option for that in Project64, but for some reason on my computer, it performs an illegal operation if you switch to fullscreen too fast after loading a ROM.

Hey, rewriting the uc0:vertex function helped me notice a bug that I had before anyway .