Z64 support in svn branch

[DarkJezter]

Just posting to announce that the z64 rsp/gfx plugins are now compiling and running with mupen64plus.
Check out the original plugin at Z64 - a LLE graphics plugin



This is currently only in svn, and has been included in the trunk

In addition to the existing dependancies, this plugin needs glew and ftgl

With those installed on your system, type the following:

./configure
make all

Make sure you select both the z64-rsp and z64gl plugins for the rsp and gfx plugins respectively. Note that configure should list RSP under Plugins when run.

Right now it appears to work on both 64-bit and 32-bit builds, and as of right now, sound is working too

[DarkJezter]

Thanks to olejl on irc, I have some more info on using the branch.

On ubuntu the following packages were needed:
libglui-dev libglui2c2 libftgl-dev libftgl2

As well, there is a new config file called z64gl.conf that will need to be copied to your "~/.mupen64plus" folder.

This is a work in progress, so please post any comments, questions or backtraces you may have

[DarkJezter]

Just a bump for the topic as z64 support is now in the trunk

The version in the trunk has relaxed the dependancies from 5 extra down to 2.

The debugging tools may still need some extra libraries (glui for one) but for most people just looking to give the plugin a try this should suffice.

Please not that this plugin is NOT in the 1.5 release

[wahrhaft]

It's always good to see more plugins. I was trying this out with Zelda: MM, though, and got the following error:

RSP: unknown opcode 560 (1372) (1BB76ABA) at 00D2AA20

I can reliably reproduce this problem by entering West Clock Town for the first time.

Also, are there any good ways to speed this plugin up? I noticed the multi-threading options in the z64gl.conf, but they didn't appear to do anything. I also saw rsp_recomp.cpp/h files... is a dynarec in the works?

[wahrhaft]

Unless I'm having a massive brain fart here, something screwy is going on. This is the code that printed my error message:

fatalerror("RSP: unknown opcode %02X (%d) (%08X) at %08X\n", op >> 26, op >> 26, op, rsp.ppc);

Two things to note here, even without any code context:
1. The first and second numbers are supposed to be the same, just one is in hex. 560 in hex is 1376, not 1372.
2. The first 2 numbers are supposed to be the 3rd shifted right by 26. It's not even close. Actually, the 3rd number is different every time I run it, but the other numbers are the same.

How does this happen?

[wahrhaft]

I still don't know why I got such goofy numbers, but I was able to use the built-in disassembler to figure out what the problem really was. Turns out the BLTZAL operation was missing. I was able to add it in by adapting the BGEZAL operation like so:

case 0x10:      /* BLTZAL */    LINK(31); if ((INT32)(RSVAL) < 0) JUMP_REL(SIMM16); break;

Which should be around line 2644 in rsp.cpp, or just find the BGEZAL case and put it above that.

[DarkJezter]

fatalerror("RSP: unknown opcode %02X (%d) (%08X) at %08X\n", op >> 26, op >> 26, op, rsp.ppc);

How does this happen?

I'm aware of the issue, fatalerror does not handle varargs properly. So the printf only gets the first arg if that... it's one of many bugs to be fixed in the plugin

Oh, thanks for adding the opcode, I'll see about applying it to trunk in the next couple days