Mupen64Plus

[notaz]

Two things that you might want for pcsx are getting rid of the invalidate_addr/invalidate_block stubs, and expanding the cache size. The invalidate_addr calls were using a lot of memory, so I moved them into linkage_arm.s so this code isn't duplicated so many times.

Can you make a diff for invalidate_addr change? That would save me lots of time.
As for cache expansion, I haven't found evidence of need for it yet.

 

[Wally]

Well I Wally will have a Pandora tomorrow (hopefully if UPS keep their arse in line)

Got a fair idea of what games should be full speed etc.

 

[Wally]

Anyone here got advice on how to compile this one or have the latest build compiled?

 

[ari64]

Now there are some things that would benefit PCSX, but how do I cherry-pick them? I suppose you are not using version control with one-logical-change-per-diff that I'm trying to do?

Separate patches: http://bunnitude.com/ari64/patches/patches-20101026-20110128.tar.gz

It would be ideal for me if we could work on one codebase, but I guess this would be hard to achieve and I'm not sure you are interested. If we could decouple it from emulators and somehow make it more generic maybe this could be used to emulate more MIPS based systems, perhaps MAME or even PSP's Allegrex.

I'm not against the idea, but to make a more generic emulator would require at least:

- An option to reverse the endianness
- An option to disable the TLB
- An option to disable the FPU
- An option to disable the 64-bit instructions
- An option to make the register file 32 bits instead of 64 bits
- Options to set the ram size and pointer list indexes/hashes

I know you have ifdefs for some of that. Are you volunteering to maintain a generic mips emulation core?

 

[sebt3]

@Ari64 :
Are buildding this on beagle or pandora or am I missing something ?
I had a few PMs about peaps trying to build your code to update the PND. So I finally downloaded your source to find out that it's Makefile driven.
and the pre.mk set the arch from uname and force CC, CXX, CFLAGS etc. That's not realy cross-compilation friendly.

 

[ari64]

@ari64 :
Are buildding this on beagle or pandora or am I missing something ?
I had a few PMs about peaps trying to build your code to update the PND. So I finally downloaded your source to find out that it's Makefile driven.
and the pre.mk set the arch from uname and force CC, CXX, CFLAGS etc. That's not realy cross-compilation friendly.

Yes I am building it on beagle. It's fairly straightforward; just install the dependencies then type "make mupen64plus". The plugins need to be built separately.

I looked at the PND that jdbye and paulguy built, and it appears that they changed some of the pathnames (configuration files, etc) to use the mounted filesystem from the PND. I'm not sure exactly what was changed.

 

[sebt3]

Not sure it was clear, but there was no offence intended.
Here is a small patch to make the build more cross-compilation friendly :

Spoiler

--- pre.mk.orig 2011-02-07 19:10:42.000000000 -0500
+++ pre.mk      2011-02-07 19:26:30.000000000 -0500
@@ -20,6 +20,12 @@
 # * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * */
 
 # detect system architecture: i386, x86_64, or PPC/PPC64
+ifeq ("$(TARGET_SYS)","arm-angstrom-linux-gnueabi")
+  CPU = ARM
+  ARCH = 32BITS
+  OS = LINUX
+else
+  
 UNAME = $(shell uname -m)
 ifeq ("$(UNAME)","x86_64")
   CPU = X86
@@ -65,6 +71,8 @@
    $(warning OS not supported or detected, using default linux options.)
    OS = LINUX
 endif
+endif
+
 
 # test for presence of SDL
 ifeq ($(shell which sdl-config 2>/dev/null),)
@@ -151,15 +159,21 @@
 endif
 
 # set base program pointers and flags
+ifeq ($(CC),)
 CC      = gcc
+endif
+ifeq ($(CXX),)
 CXX     = g++
-LD      = g++
+endif
+LD      = $(CXX)
+ifeq ($(STRIP),)
 ifeq ($(OS),LINUX)
 STRIP  = strip -s
 endif
 ifeq ($(OS),OSX)
 STRIP  = strip -x 
 endif
+endif
 RM      = rm
 RM_F    = rm -f
 MV      = mv

I hope to be helpfull

 

[Blue Protoman]

When's the next release?

 

[ari64]

Not sure it was clear, but there was no offence intended.

huh?

Here is a small patch to make the build more cross-compilation friendly :

Hmm... The makefile is mostly the same as the original mupen64plus, which uses uname to determine the host cpu type. I don't know of a good way to do this in general when cross-compiling. OE sets TARGET_SYS, but I'm not sure that works for other build environments.

Was there anything else you needed to change besides setting the CPU/ARCH/OS?

 

[sebt3]

Was there anything else you needed to change besides setting the CPU/ARCH/OS?

I changed these line in the Makefile too, as we dont have libGL here (are you using mesa for that ?) :

OBJ_OPENGL = opengl/fake.o
LIBS = $(SDL_LIBS) #$(LIBGL_LIBS)

I built using : "export PREFIX=/mnt/utmp/mupen SHAREDIR=/mnt/utmp/mupen;make mupen64plus"

Here is fake.c :

#include "osd.h"
#include <stdlib.h>

void osd_render() {}
void TakeScreenshot(int iFrameNumber) {}
osd_message_t * osd_new_message(enum osd_corner eCorner, const char *fmt, ...) {return NULL;}
void osd_exit(void) {}
void osd_init(int width, int height) {}
osd_message_t * osd_message_valid(osd_message_t *testmsg)  {return NULL;}
void osd_update_message(osd_message_t *msg, const char *fmt, ...) {}
void osd_delete_message(osd_message_t *msg) {}
void osd_message_set_static(osd_message_t *msg) {}
void SetScreenshotDir(const char *chDir) {}
int ValidScreenshotDir(void) {return 0;}

I give that because you asked, not because I'm proud of my hacks

 

[ari64]

Was there anything else you needed to change besides setting the CPU/ARCH/OS?

I changed these line in the Makefile too, as we dont have libGL here (are you using mesa for that ?)

Yes, I built mesa from source. The maemo folks ripped out osd and screenshots also. I guess I should make it easier to compile without OpenGL.

I give that because you asked, not because I'm proud of my hacks

You said it wasn't easy to build, so I was wondering what would make it easier. If it's just libGL and cross-compiling, that's not too bad. I'm not sure there's a general solution to the cross-compiling problem though.

 

[notaz]

Now there are some things that would benefit PCSX, but how do I cherry-pick them? I suppose you are not using version control with one-logical-change-per-diff that I'm trying to do?

Separate patches: http://bunnitude.com/ari64/patches/patches-20101026-20110128.tar.gz

These look good, thanks.

It would be ideal for me if we could work on one codebase, but I guess this would be hard to achieve and I'm not sure you are interested. If we could decouple it from emulators and somehow make it more generic maybe this could be used to emulate more MIPS based systems, perhaps MAME or even PSP's Allegrex.

I'm not against the idea, but to make a more generic emulator would require at least:

- An option to reverse the endianness
- An option to disable the TLB
- An option to disable the FPU
- An option to disable the 64-bit instructions
- An option to make the register file 32 bits instead of 64 bits
- Options to set the ram size and pointer list indexes/hashes

I know you have ifdefs for some of that. Are you volunteering to maintain a generic mips emulation core?

Maybe. PCSX needs all of above options inverted (compared to Mupen64plus), so we would have them tested. Main goal for me would be to get you to do further versions based on that code, so that I have no need to rebase my work in future. Not sure how to organize such work, I do patches and you approve them, or something like that?

On the other hand you mentioned there is not too much left to do with this recompiler, or do you have some plans now? From what I can see it is missing handling of rare corner cases before it could be called more or less complete. If you will split future changes (like you did now) it will be easy to merge them for me.

 

[Wally]

Ari, any plans for OSHLE?

We use it with Daedalusx64 and it gives us a healthy speed up!!!

 

[Schnatterplatsch]

New release of Mupen? Great, seems FZeroX is running faster now, but as it ran great before too, I am not really sure. :lol: Big thanks to everyone involved.
I'd also like to cast a vote for Adventus getting a Pandora from the Dev fund. Come on, didn't even Zod get one (or is my memory fooling me here?)?


Once again, thanks. You make the pandora awsome, guys

 

[ari64]

On the other hand you mentioned there is not too much left to do with this recompiler, or do you have some plans now? From what I can see it is missing handling of rare corner cases before it could be called more or less complete. If you will split future changes (like you did now) it will be easy to merge them for me.

One goal is to merge with 1.99.4. Mostly that depends on improving x86-64 support and the graphics plugins.

There are a few minor things to fix in the dynamic recompiler. There's the r31 in the delay slot issue, and I noticed that I missed a case where MFC1 can write r0. I don't have a good way to test a lot of these rare corner cases.

Ari, any plans for OSHLE?

We use it with Daedalusx64 and it gives us a healthy speed up!!!

The only game that I know would significantly benefit from OS HLE is Conker's Bad Fur Day. This game uses a demand-paged executable, and much of the overhead associated with the frequent pagefaults could be avoided by high-level emulation of the OS. Since we don't have a renderer that can emulate the microcode of this game, I haven't really looked into it.

Is there any particular bit of HLE that resulted in a significant speedup in DaedalusX64?

New release of Mupen? Great, seems FZeroX is running faster now, but as it ran great before too, I am not really sure. :lol: Big thanks to everyone involved.
I'd also like to cast a vote for Adventus getting a Pandora from the Dev fund. Come on, didn't even Zod get one (or is my memory fooling me here?)?

The biggest change in the latest version was to increase the cache size so that large games don't thrash the cache and cause frequent recompilation. There were also some minor improvements in the TLB handling. I'm surprised you saw much improvement in F-Zero X as its code size is relatively small and it doesn't use virtual memory.

The problem with devs not having Pandoras is that they haven't finished filling all the orders that were placed in 2008.

 

[Schnatterplatsch]

Not much, but sound was running a bit smother, I imagine. My pandora was broken for 2 monthes though, so I cannot really compare it. Maybe I clocked higher this time. However, FZero is much fun here

 

[jonjandran]

What is the version for this build? Last one was R13BF.

I just need to know for the compatibility list.

Thanks

 

[Wally]

The only game that I know would significantly benefit from OS HLE is Conker's Bad Fur Day. This game uses a demand-paged executable, and much of the overhead associated with the frequent pagefaults could be avoided by high-level emulation of the OS. Since we don't have a renderer that can emulate the microcode of this game, I haven't really looked into it.

Is there any particular bit of HLE that resulted in a significant speedup in DaedalusX64?

Its an Round Robin improvement on the PSP. Salvy tells me that the CPU patches are the ones that give significant results.

Games older than Conker benefit from the HLE patches mostly i.e (Rugrats, Mario & Aerogauge for example), Conker uses custom stuff and Salvy doubts it will benefit from HLE.. Out of the 90 OS Funcs that Daedalus uses, Conker of all games uses approx 11.

While games like doom without hle run at ~ 8fps, with hle about ~30fps.


Feel free to look and poke around the DaedalusX64 Source for any references (maybe you should port this to your ARM Dynarec instead? )

 

[javispedro]

I guess you already know that, but the recently released n64oid (not the same that is on Google Code) uses both code from Ari64's recompiler release 20110128, and Adventus' gles2n64 plugin rev. 22. I was able to find function genjmp from the former and __indexmap_getnew from the latter.

Of course, he's charging $6 for it and the source is nowhere to be found...

 

[Schnatterplatsch]

Oh, this sucks so much. Zodttd, this one, chinese companies taking gpl-emu-code without credits and all. Any known way to contact this yongzh to ask him for the code? If he doesn't hand it out, he commits crime, doesn't he?!?

What it leads to: Exophase said, that if he does a new gbaemu, he'll not make it OS, notaz said that if he had done a completly new PSXemu he'd not OS it...