Mupen64Plus

[mvickers03]

Sorry for asking a dumb question, is this the source code? I don't know how to compile this into an executable

Is there anyone one with a nifty toolchain that could possible compile it into an executable or .PND

Many thanks.. can't wait to try it.
Thanks Ari64 I love your work on this emulator.

 

[Exophase]

It now generates VFP instructions properly, which is around 5-10% faster. Also fixed issue 333.

Does this mean generating NEON instructions would be even faster? Maybe not the same sort of leap since it's only cutting a few cycles on average instead of a few dozen but could be something. Especially if there's any opportunity for auto-vectorization.

I imagine you won't do it since it's not IEEE-754, though. And also nothing for doubles.

 

[ari64]

Sorry for asking a dumb question, is this the source code? I don't know how to compile this into an executable

Install gcc and the required libraries (see first post) and then do 'make mupen64plus'.

You will need to compile gles2n64 and the input plugin seperately. I'm actually not sure which versions of these were used in the PNDs that are on apps.openpandora.org, so I can't help you there.

 

[ari64]

It now generates VFP instructions properly, which is around 5-10% faster. Also fixed issue 333.

Does this mean generating NEON instructions would be even faster? Maybe not the same sort of leap since it's only cutting a few cycles on average instead of a few dozen but could be something. Especially if there's any opportunity for auto-vectorization.

I imagine you won't do it since it's not IEEE-754, though. And also nothing for doubles.

I suspect that most of the speedup comes from eliminating the branch (mis)prediction penalty and stack overhead of calling C functions for a lot of the floating point stuff. Also the way gcc tested for NaNs was horribly inefficient. I now do it with fcmp/fmstat.

There are still C functions which are called for things like double->int64 conversions, and C functions are called for all FPU operations if you compile without hardware floating point support.

I'm not doing vectorization, and the fpu register mapping is pretty limited. Also there might be a better way of setting the rounding mode for integer conversion operations other than truncate. There's also the penalty of 10 cycles or so for transferring the flags with fmstat. There isn't that much floating point code in N64 games, so it's probably not worth putting a lot more effort into it.

The IEEE non-compliance is due to lack of handling denormals. The actual incidence of subnormal values in N64 games seems to be pretty low. The bigger problem for me was that the results from the ARM FPU are not the same as what I get from x87/SSE. When comparing debugging output I see lots of +/-1 differences, which sometimes add up to larger differences. This makes it very difficult to tell if I've got a bug in the ARM code. If I get bug reports I'll look into it.

 

[jdbye]

I'm making another attempt at compiling it, I want those savestates, but I already have 2 failed attempts at compiling it, first time taking the bollocks approach, and gles2n64 failed on EGL_Init, and second time cross compiling it and it just segfaulted, so don't expect much. I'll get it to compile somehow, but it might not actually work
Angstrom website seems to be down now too, so I can't install the required packages.

edit: libgl1 and libgl-dev won't install, and libglu-dev depends on libgl1 so it won't install either. Any idea why? It's in the repository: libgl1 1:7.2-r6.1 for armv7a (Ångström 2008.6 glibc armv7a base feed)

Edit: Removed opengl, but it segfaults after the ascii logo
Edit2: From GDB trace:

#0  0x408397ec in g_atomic_int_exchange_and_add ()
   from /usr/lib/libglib-2.0.so.0
#1  0x40766b28 in g_object_ref () from /usr/lib/libgobject-2.0.so.0
#2  0x407e3b94 in g_list_foreach () from /usr/lib/libglib-2.0.so.0
#3  0x403bdfc0 in gtk_window_set_icon_list ()
   from /usr/lib/libgtk-x11-2.0.so.0
#4  0x080cdf34 in ?? ()
Cannot access memory at address 0x0
#5  0x080cdf34 in ?? ()
Cannot access memory at address 0x0

What could be causing this?

 

[jdbye]

I bring you... a new build!
Compiled from Ari64's latest sources, PND'd up, and using the same pxml and run script as the old PND.
http://www.fragmentedforce.com/pandora/mupen64plus-new.pnd
Credits to paulguy for compiling it, and to me for PNDing it up and providing him with my edited source (OpenGL removed and makefile slightly altered)
I also included a freebie - cheats for almost every game, including the subscreen delay fix for Zelda OoT so it doesn't delay for several seconds every time you press start
Notaz audio is included.
(My post in the other topic: http://www.gp32x.de/board/index.php?/topic/53683-mupen64plus/page__view__findpost__p__920214)

 

[ari64]

I bring you... a new build!
Compiled from Ari64's latest sources, PND'd up, and using the same pxml and run script as the old PND.
http://www.fragmentedforce.com/pandora/mupen64plus-new.pnd
Credits to paulguy for compiling it, and to me for PNDing it up and providing him with my edited source (OpenGL removed and makefile slightly altered)

So it works for paulguy... did you figure out what was wrong with your build?

I also included a freebie - cheats for almost every game, including the subscreen delay fix for Zelda OoT so it doesn't delay for several seconds every time you press start

How did you fix that? I've noticed that problem with OoT and never knew what caused it.

 

[jdbye]

I bring you... a new build!
Compiled from Ari64's latest sources, PND'd up, and using the same pxml and run script as the old PND.
http://www.fragmentedforce.com/pandora/mupen64plus-new.pnd
Credits to paulguy for compiling it, and to me for PNDing it up and providing him with my edited source (OpenGL removed and makefile slightly altered)

So it works for paulguy... did you figure out what was wrong with your build?

No idea, and my Pandora decided to get a blue tint when I was trying to figure it out. He cross compiled it with DJWillis' toolchain, so that might've been the difference.

I also included a freebie - cheats for almost every game, including the subscreen delay fix for Zelda OoT so it doesn't delay for several seconds every time you press start

How did you fix that? I've noticed that problem with OoT and never knew what caused it.

It's a known issue in Project64 (and I guess other emulators too), eventually they added the patch to the ROM database so you no longer needed the cheat, but the cheats.cfg file I included was just something I found online, probably converted from Project64
Edit: For the record, PPSP Input and gles2n64 didn't need to be recompiled (the new PND is still using the old PPSP Input plugin, the recompiled one complained about a missing reference to 'config' or something like that)

 

[Yamara]

Tried out Hydro Thunder at 500mhz using the PND provided, no defaults changed. I was pleasantly surprised that, though it was a bit lagging, it was still smoothish, and fast enough to actually play a bit of the first Easy level. However, it crashed quick, after maybe 4 seconds in on the first jump in the race. Also, no sound. Thought the input might be useful.

I should check out some games that are more likely to work well, and try them at a more reasonable CPU speed. This is just what I had at hand. Really awesome work so far. Thanks for the time and effort put into it.

 

[Surkow]

[...]
It's a known issue in Project64 (and I guess other emulators too), eventually they added the patch to the ROM database so you no longer needed the cheat, but the cheats.cfg file I included was just something I found online, probably converted from Project64

Where did you find the cheats.cfg file? Mupen64Plus has an official copy of the Project64 cheats database. I guess you guys are still working with an older code base?

 

[jdbye]

[...]
It's a known issue in Project64 (and I guess other emulators too), eventually they added the patch to the ROM database so you no longer needed the cheat, but the cheats.cfg file I included was just something I found online, probably converted from Project64

Where did you find the cheats.cfg file? Mupen64Plus has an official copy of the Project64 cheats database. I guess you guys are still working with an older code base?

Found it on google a while ago when I was looking for one for the subscreen delay fix. I don't know what code base Ari64 is using, but I didn't see a cheats.cfg file included with the source.

 

[ari64]

Tried out Hydro Thunder at 500mhz using the PND provided, no defaults changed. I was pleasantly surprised that, though it was a bit lagging, it was still smoothish, and fast enough to actually play a bit of the first Easy level. However, it crashed quick, after maybe 4 seconds in on the first jump in the race. Also, no sound. Thought the input might be useful.

Has Hydro Thunder ever worked reliably in any version of mupen?

#define CLOCK_DIVIDER 1

seems to make it work better, at the risk of making the emulator run slowly.

 

[ari64]

I don't know what code base Ari64 is using, but I didn't see a cheats.cfg file included with the source.

The config files were exactly the same as in mupen64plus v1.5.

 

[jonlad1]

I've got a one nubber and I've read that there is a plugin that allows the dpad to be used as the left analogue stick.

I've tried the Blight plugin (which IIRC is the plugin required) but then no button works, start button, A/B/X/Y and dpad doesnt work.

I'm using the latest release.

Can anyone shed any light on this please?

 

[ari64]

http://bunnitude.com/ari64/mupen64plus-arm-20101026.tar.gz


Changes since 20100929:

- Fixed i-cache invalidation bug (random crashes)

- Fixed register writeback when splitting code blocks to accommodate changes in vitrual memory mapping

 

[paulscode]

Ari64, what versions of ARM is your dynamic recompiler likely to work on (i.e. only the ARMv7-A Cortex-A8, or has been tried on other versions as well)?

--EDIT-- I just saw in your wiki article that the dynarec generates ARMv5 and ARMv7.

 

[ari64]

http://bunnitude.com/ari64/mupen64plus-arm-20110128.tar.gz


Changes since 20101026:

- Fixed JALR instruction where link register is other than r31

- Fixed branch offsets that were mistakenly cast to unsigned ints

- Fixed address generation for SWL/SWR/SDL/SDR instructions

- Corrected xor with zero (treat as move or nop)

- Corrected some errors when hoisting loads out of loops

- Ignore loads to r0 except for pagefaults and I/O

- Ignore MFC0 instructions which write to r0

- Eliminate some unnecessary calls to invalidate_block

- Reduce epilogue stubs that call invalidate_block (4% reduction in memory usage)

- Cache pointer to TLB memory map, when a free register is available (1% speed improvement)

- Avoid calling __clear_cache too frequently, with some Linux kernels it is very slow

- Use trampolines for jumps >32MB

- Increase maximum cache size to 32MB on ARM

- Allow mapping rdram at locations other than 0x80000000

- Make SSE usage optional on x86

 

[gruso]

User chat moved to the beta testing thread: http://www.gp32x.de/board/index.php?/topic/53683-mupen64plus

 

[notaz]

http://bunnitude.com/ari64/mupen64plus-arm-20110128.tar.gz

Changes since 20101026:

 assem_arm.c      |  633 +++++++++++++++++++++--------
 assem_arm.h      |    7 
 assem_x64.c      |  300 +++++++-------
 assem_x64.h      |    1 
 assem_x86.c      |  302 +++++++-------
 assem_x86.h      |    1 
 linkage_arm.s    |  131 +++++-
 linkage_x86.s    |   74 +++
 linkage_x86_64.s |   88 ++++
 new_dynarec.c    | 1177 +++++++++++++++++++++++++++++++++++--------------------
 10 files changed, 1845 insertions(+), 869 deletions(-)

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?

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 was hoping to do non-destructive changes on top of your code in ifdef blocks that could be re-applied when you release new versions but I failed at that. Shame it's so hard to make use of your improvements now.

 

[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?

The problem is that I have seperate local trees for x86 and ARM, and I merged them together to make this release. So unfortunately the history is not in the order that you would want to apply to git. I can try to split out patches if there is something specific you're interested in.

Many of these patches are things you already have. 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.

The other thing is that I expanded the cache to 32MB. It was 16MB before, and it would begin evicting things when it was 75% full (12MB), A lot of N64 games were hitting this limit and thrashing excessively. Increasing the size got rid of a lot of the lag in some games. PSX games tend to be smaller so maybe this isn't as much of a problem.