What's new

Some technical questions

Jesterhead

New member
Im interested in understanding of some aspects of N64 and its emulation.
1. What exactly is meant with the famous µ-code?
Do the games change the way the N64 renders pictures?
2. What are those "D-lists" and "A-Lists" ?

If anyone knows a site with more aspects of N64 and emulating please post it too.
 

Azimer

Emulator Developer
Moderator
Jesterhead said:
Im interested in understanding of some aspects of N64 and its emulation.
1. What exactly is meant with the famous µ-code?
Do the games change the way the N64 renders pictures?
2. What are those "D-lists" and "A-Lists" ?

If anyone knows a site with more aspects of N64 and emulating please post it too.

uCode (or microcode) are small programs that are uploaded to the RSP to perform a certain task. Those uCodes can do all the 3D geometry needed for graphics (before the RDP processes the graphics), produce audio (enveloping, mixing, and resampling), MP3 decoding (Perfect Dark, Conker's Bad Fur Day), JPEG decompression (Zelda OOT), or MPEG movie playback (Resident Evil II). Each game can use different uCodes for different things or a different uCode for the same thing (such as two uCodes to render one 3D scene).

Dlists and Alists are Display Lists and Audio Lists. Display lists are microcode specific lists to process/render the 3D Geometry/Graphics needed for the scene. They are not all the same. Alists are Audio Lists are microcode specific lists to process the Audio needed for one audio frame. And Audio frame is the amount of Audio data needed to be produced for one interval (usually in Sync with Vsync) or per audio dma interruption. Most standard uCodes for audio use the previous method, while MusyX games and some modified uCodes require accurate interruptions. Obviously the former is easier to emulate with any degree of satisfactory results.

I hope I answered your questions without being too wordy.
 

olivieryuyu

New member
another small question: as i heard Musysx system is using the rest of the CPU power (that is not used for other things) to process sound if the RSP reach its limits. Is it why timings are so important in Musysx ?
 
OP
Jesterhead

Jesterhead

New member
So that means the rsp isnt completely emulated, only the way the emulator handles the data is changed when a game requests a particular µ-code?

And thanks for your answers :)
 

Azimer

Emulator Developer
Moderator
Jesterhead said:
So that means the rsp isnt completely emulated, only the way the emulator handles the data is changed when a game requests a particular µ-code?

And thanks for your answers :)

RSP is completely emulated. It just isn't flawless. It is very complicated and pretty much useless for Graphics emulation. N64 emulation would be as slow as Gamecube or PS2 emulation if we emulated the RSP for Graphics as well. Not to mention the graphics will not look very good. RSP uses fixed point, and this is not very good for graphics. However, it is far more advanced than MMX. SSE, SSE2, and 3DNow are SIMD operations for floating point processing. So you are not capable of using that for exact emulation either. It is not a pretty picture either way you look at it for graphics. I remember a demo Jabo showed me showing Mario64 with princess peach in the very beginning. Her hair was greenish. This shows me that the RSP emulation is far from perfect, or the RDP Triangle emulation is flawed. Either way, it will take one good reverse engineer to pound out the bugs on something HLE has accomplished wonderfully.
 

Top