State of the N64 emulation scene

[grinvader]

The big difference between the SNES and N64, of course, was that the individual games contained the program data to send to the RSP, and these games could write their own custom implementations. This made it more of a co-processor than a DSP, but I digress.

Hmm, I see. It provides nonspecific math assistance plus any custom functions you added to it.

So, the issue is with these builtin functions, since we can't read them from the various ROMs. How many do you think there is ?
We'd need someone like Overload to pull a DSP-1 on those...

[byuu]

So, the issue is with these builtin functions, since we can't read them from the various ROMs.

Well, an emulator would emulate the game uploading the code to the RSP/RDP, just like an SNES emu would uploading a program to the SMP. To get it working right, you "only" have to emulate the RSP/RDP like we currently emulate the S-CPU and S-SMP (as a processor), rather than like we emulate the DSP-n chips (as an I/O device).

How many do you think there is ?

No idea, probably not many, but a lot more than four.

We'd need someone like Overload to pull a DSP-1 on those...

... you want to continue with the high-level emulation? No, the individual instructions of the chip need to be figured out precisely, and emulated using pure software. No video cards, no pixel shaders, pure math. But speed is obviously a major problem here.

[grinvader]

Hmm, don't misunderstand.

Agreeing that the custom functions can be recompiled on their way through to the n64. Obvious enough. Those aren't the problematic ones.

The builtin functions... if they are all mathematical (like the DSP-1), getting the right formula is the main issue.
Once you have a bit perfect formula, you can evaluate operation speed.
After that, all that's left is exact instruction order, but as you already mentionned these lose a lot of importance on more recent systems.

I agree that using standard PC calls/shaders/stuff sn't the way. But exact instruction order isn't something I can hope on getting -ever-, since there's close to nil interest in it. I'd settle for a bit-perfect math formula and operation duration, which I'd reproduce in software entirely.
Also I don't give a landing fuck about speed, honestly.

No idea, probably not many, but a lot more than four.

Let me guess, five is right out ? ;D

Of course, if there are non-mathematical funcs in it... then it'll get horrid. And it probably is.

[mudlord]

not sure which chip is the one that is commonly emulated at a high level, the RSP or the RDP. Or if they're both emulated with HLE.

The RSP is the one that compiles the graphics microcode. The RDP does mostly graphics operations. So that should answer your question.

[Gil_Hamilton]

Programmable graphics hardware?
N64 = Jaguar!

[mudlord]

Let me guess, five is right out ? ;D

Yep, we got all Nintendo's ucode plus Factor 5's, Boss Studio's.....

[grinvader]

Let me guess, five is right out ? ;D

Yep, we got all Nintendo's ucode plus Factor 5's, Boss Studio's.....

You kinda missed the reference, but no matter.

Those microcodes are the custom ones, right ?

[mudlord]

Yup.

[grinvader]

So, any idea on how many non-custom stuff there is ?

[mudlord]

At the moment for graphics, there is around 4-10 graphics ucodes (can't recall off the top of my head) that Nintendo developed, and which are documented. The others are ones 3rd parties developed, such as Rare, Factor 5, Boss Studios and some others. Of course, the Rare ones are fully reverse-engineered. Lemmy did some work on Rogue Squadron, but the main stumbling block it seems, is how to emulate Factor 5's landscape engine which uses heightmaps.

[grinvader]

At the moment for graphics, there is around 4-10 graphics ucodes (can't recall off the top of my head) that Nintendo developed, and which are documented. The others are ones 3rd parties developed, such as Rare, Factor 5, Boss Studios and some others. Of course, the Rare ones are fully reverse-engineered. Lemmy did some work on Rogue Squadron, but the main stumbling block it seems, is how to emulate Factor 5's landscape engine which uses heightmaps.

Wait, aren't these custom ? I asked about the non-custom ones, the ones that are built-in, the ones we cannot read from ROMs.
The ones that would actually be hard to deal with.

[mudlord]

the ones that are built-in, the ones we cannot read from ROMs.

Sorry, there is none. Everything graphics wise is done via programmable ucode.


Unless you are talking about the RDP commands, which are another thing entirely. Currently, MAME has a driver implementation of all these in LLE form. And so currently, the various video plugins and MAME/MESS has only information on these stuff. When there seriously needs to be more research into things like coverage, etc.

Here's what MAME has got so far....

Code: Select all

static void (*const rdp_command_table[64])(UINT32 w1, UINT32 w2) =
{
	/* 0x00 */
	rdp_noop,			rdp_invalid,			rdp_invalid,			rdp_invalid,
	rdp_invalid,		rdp_invalid,			rdp_invalid,			rdp_invalid,
	rdp_tri_noshade,	rdp_tri_noshade_z,		rdp_tri_tex,			rdp_tri_tex_z,
	rdp_tri_shade,		rdp_tri_shade_z,		rdp_tri_texshade,		rdp_tri_texshade_z,
	/* 0x10 */
	rdp_invalid,		rdp_invalid,			rdp_invalid,			rdp_invalid,
	rdp_invalid,		rdp_invalid,			rdp_invalid,			rdp_invalid,
	rdp_invalid,		rdp_invalid,			rdp_invalid,			rdp_invalid,
	rdp_invalid,		rdp_invalid,			rdp_invalid,			rdp_invalid,
	/* 0x20 */
	rdp_invalid,		rdp_invalid,			rdp_invalid,			rdp_invalid,
	rdp_tex_rect,		rdp_tex_rect_flip,		rdp_sync_load,			rdp_sync_pipe,
	rdp_sync_tile,		rdp_sync_full,			rdp_set_key_gb,			rdp_set_key_r,
	rdp_set_convert,	rdp_set_scissor,		rdp_set_prim_depth,		rdp_set_other_modes,
	/* 0x30 */
	rdp_load_tlut,		rdp_invalid,			rdp_set_tile_size,		rdp_load_block,
	rdp_load_tile,		rdp_set_tile,			rdp_fill_rect,			rdp_set_fill_color,
	rdp_set_fog_color,	rdp_set_blend_color,	rdp_set_prim_color,		rdp_set_env_color,
	rdp_set_combine,	rdp_set_texture_image,	rdp_set_mask_image,		rdp_set_color_image
};

However, if you want to learn more about the N64, Dextrose.com has some development info on the N64.

[grinvader]

No built-in RSP microcode ? This is excellent news. Fantastic even.

[mudlord]

Yuh, the games themselves are compiled against the RSP ucode they use. As I explained, Nintendo ships some common ucodes with thier SDK, but 3rd parties can make thier own ucode at will. Same goes for audio. Though, the only 3rd party sound systems I know of are MusyX and Boss Studio's audio ucode (Top Gear Rally and co) .

[grinvader]

Time for me to dive in and see what gives.
Wish me luck doods.

[Agozer]

Remember that it's a-ok to come back with your proverbial tail between your legs.

[declan]

ZSNES is written in x86 assembly for speed and timing right???

Could an N64 emu improved by being witten in x86 machine code

Not that it is really feasable to do so. Not to mention, porting it would be REALLY hard, harder than ZSNES

[Agozer]

ZSNES is written in x86 assembly for speed and timing right???

Not anymore. many part have been rewritten in C, and the bitchiest parts have stayed in ASM, although the recent overhauls done by pagefault would suggest that ASM is fading fast, if not already gone.

ASM was de facto in the past because _Demo_ and zsknight needed all the speed they could possibly squuze out of the code in order to make the emulator run on then-486s.

[mudlord]

Could an N64 emu improved by being witten in x86 machine code

Dunno..I'd love to see a person try. 1964 has quite a fast dynarec, and its just in C, so personally, I am extremely interested

[Nach]

It does make me wonder, though. If we were to successfully dump those DSP program ROMs one day, and a low-level implementation caused a massive speed hit, would all of us emulate it, or stick with our high-level emulation, simply because our simulation is good enough for full compatibility already?

I doubt we'd get a *MASSIVE* speed hit, if the DSP was emulated well. From the docs I read on it, it isn't a very complicated chip. I imagine the speed hit would be in the S-DD1 neighborhood, just a bit higher.

Remember that this guy works as pass through on copiers, it's not very strict in the timing department. Timing matters yes, but not enough that we can't cheat with it.

I'm all for killing the simulation we have and switching to the real thing, even with a bit of a speed hit. The only one I wouldn't mind much if it wasn't emulated was the DSP-2, because that thing is just ridiculous. Heck, I bet a serious ROM hacker who knows his stuff and the DSP-2 well can remove of the DSP-2 requirements from DM in a long weekend. I would still prefer to have emulation though.

And our simulation simply isn't good enough. Some DSP-1 games have slight graphical glitches because results are ready just a moment too soon. DSP-3 crashes, and Overload once told me timing plays quite a role in this one. And DSP-4, while it seems good, in some situations, something is definitely wrong with what we have.

[I.S.T.]

I see you've come out of your hibernation, Nach.

[Nach]

I see you've come out of your hibernation, Nach.

And I come with much new software.

Excellent to get away from everything for a while, and just code till you drop.

[I.S.T.]

I see you've come out of your hibernation, Nach.

And I come with much new software.

Excellent to get away from everything for a while, and just code till you drop.

I'm sure Deathlike2 will be putting the chains back on you for good this time. You've proven you can't be trusted.

[mudlord]

I was wondering when you'll be back Nach....

[Deathlike2]

I see you've come out of your hibernation, Nach.

And I come with much new software.

Excellent to get away from everything for a while, and just code till you drop.

I'm sure Deathlike2 will be putting the chains back on you for good this time. You've proven you can't be trusted.

He's the brains of the operation. Without him, I'm lost.