Mupen64Plus

[ari64]

It's pretty natural that the inputs would be in A0-A3 or so and the return value in V0, that is afterall the ABI. An option to assume that the other registers are dead across a function call is a good enough idea. However, are you really certain NO games violate this? Did you really check all of them? N64's library is small enough that I could sort of believe this.

I tried this, and it works in some games and not others. Usually you can get away with discarding V0-V1 during a call and A0-A3 upon return. Sometimes it is also possible to discard AT and T6-T9. The speedup is about 2% when it works. This doesn't seem like a worthwhile optimization due to the minimal speed gain and high failure rate.

If one just blindly assumes those registers can be discarded without doing some smart analyses about the usage of registers, games surely happen to fail to run if they were not coded in pure C source (that si, if the emulator needs to dynarec BIOS or custom assembly code). That is the main reason I never attempted it for psx4all. That smart analyser may also be proved difficult to issue efficient code if at the end you still need store registers back when executing, says, a return instruction which is quite common in a C source.

It's nearly impossible to do that sort of analysis though. If the compiler doesn't store those registers back when compiling a return instruction, it may work in some cases, but the function could be called from a different location which does look at those registers. You'd have to consider every possible call-return pair, including cases not yet seen.

Where did our six-sided friend go? He showed up one day and then disappeared.

 

[ldesnogu]

I'd even say that *proving* such (non-)usage is the same as being able to detect all code paths statically, so it's intractable

 

[FabTheZen]

In order to let a programming-profane, is the Mupen64 Working with OpenGL acceleration or it isn't? If not, will it be possible for Mupen64 to work fluently in the near future? As some said before, this would be the killer app for the Pandora...

 

[gruso]

In order to let a programming-profane, is the Mupen64 Working with OpenGL acceleration or it isn't? If not, will it be possible for Mupen64 to work fluently in the near future? As some said before, this would be the killer app for the Pandora...

Yes, Adventus is working on the plugin (gles2n64).

 

[FabTheZen]

Yes, Adventus is working on the plugin (gles2n64).

That is the magic of Open-Source. If this became fully working (I mean BETTER than PSP and other worthless consoles ) then the Pandora will become a world-wide better-than-MS success!
I hope from the deep of my heart this project will soon realize: it would have been wonderful if the Pandora mounted a fully-working n64 emulator OOTB...
When the mupen64 is ready, I WILL buy the Pandora.

 

[Rockthesmurf]

Yes, Adventus is working on the plugin (gles2n64).

That is the magic of Open-Source. If this became fully working (I mean BETTER than PSP and other worthless consoles ) then the Pandora will become a world-wide better-than-MS success!
I hope from the deep of my heart this project will soon realize: it would have been wonderful if the Pandora mounted a fully-working n64 emulator OOTB...
When the mupen64 is ready, I WILL buy the Pandora.

Once you have brought your Pandora you could start beta testing Mupen and then post in the Beta Testing section...

Steve

 

[Cpasjuste]

Hello Ari64.

I did "port" your code and the gles plugin to the nokia n900 for fun, but i have a little problem, the emulator seems to hang without any output. I'd like to know if it's normal to use the Interpreter core on arm devices (pandora, n900 ...) ?

Here is the outpout i get from the terminal :

Nokia-N900-02-8:~/nfs/n64/Mupen64Plus-1-5-src-arm-20100212# ./mupen64plus
 __  __                         __   _  _   ____  _             
|  \/  |_   _ _ __   ___ _ __  / /_ | || | |  _ \| |_   _ ___ 
| |\/| | | | | '_ \ / _ \ '_ \| '_ \| || |_| |_) | | | | / __|  
| |  | | |_| | |_) |  __/ | | | (_) |__   _|  __/| | |_| \__ \  
|_|  |_|\__,_| .__/ \___|_| |_|\___/   |_| |_|   |_|\__,_|___/  
             |_|         http://code.google.com/p/mupen64plus/  
Version 1.5-development

Config Dir:  /root/.mupen64plus/
Install Dir: /root/nfs/n64/Mupen64Plus-1-5-src-arm-20100212/
Plugin Dir:  /root/nfs/n64/Mupen64Plus-1-5-src-arm-20100212/plugins/

Rescanning rom cache.
Rom cache up to date. 0 ROMs.
Compression: Uncompressed
Imagetype: .z64 (native)
Rom size: 8388608 bytes (or 8 Mb or 64 Megabits)
MD5: 45676429EF6B90E65B517129B700308E
80 37 12 40
ClockRate = f
Version: 1446
CRC: a03cf036 bcc1c5d2
Name: SUPER MARIO 64
Manufacturer: Nintendo
Cartridge_ID: 4d53
Country: Europe (0x50)
PC = 80241800
EEPROM type: 0
init timer!
[gles2n64]: Loading Config from /root/.mupen64plus/gles2n64.conf 
memory initialized
[gles2n64]: Width: 800 Height:480 
[gles2n64]: Depth Size: 135908704 
[gles2n64]: Color Buffer Size: 135908704 
[gles2n64]: Enable Runfast... 
[gles2n64]: Clamping max anistropy to 0x.
=============================================================
Num=1 	 usesT0=1 usesT1=0 usesCol=0 
=============================================================
                                
uniform sampler2D uTex0;                                   
uniform sampler2D uTex1;                                   
uniform lowp vec4 uEnvColor;                               
uniform lowp vec4 uPrimColor;                              
uniform lowp vec4 uFogColor;                               
uniform highp float uAlphaRef;                             
uniform lowp float uPrimLODFrac;                           
                                                           
varying highp float vFactor;                               
varying lowp vec4 vShadeColor;                             
varying highp vec2 vTexCoord0;                             
varying highp vec2 vTexCoord1;                             
                                                           
void main()                                                
{                                                          
lowp vec4 lFragColor;                                      
lowp vec4 lTex0 = texture2D(uTex0, vTexCoord0); 
lFragColor.rgb = (vec3(0.0) - vec3(0.0)) * vec3(0.0) + lTex0.rgb; 
lFragColor.a = (0.0 - 0.0) * 0.0 + lTex0.a; 
gl_FragColor = lFragColor; 
} 

=============================================================
=============================================================
Num=2 	 usesT0=0 usesT1=0 usesCol=1 
=============================================================
                                
uniform sampler2D uTex0;                                   
uniform sampler2D uTex1;                                   
uniform lowp vec4 uEnvColor;                               
uniform lowp vec4 uPrimColor;                              
uniform lowp vec4 uFogColor;                               
uniform highp float uAlphaRef;                             
uniform lowp float uPrimLODFrac;                           
                                                           
varying highp float vFactor;                               
varying lowp vec4 vShadeColor;                             
varying highp vec2 vTexCoord0;                             
varying highp vec2 vTexCoord1;                             
                                                           
void main()                                                
{                                                          
lowp vec4 lFragColor;                                      
lFragColor.rgb = (vec3(0.0) - vec3(0.0)) * vec3(0.0) + vShadeColor.rgb; 
lFragColor.a = (0.0 - 0.0) * 0.0 + 1.0; 
gl_FragColor = lFragColor; 
} 

=============================================================
Starting r4300 emulator
R4300 Core mode: Interpreter

It seems to hang after "R4300 Core mode: Interpreter", no matter what i do.
Maybe i'm missing something ?

 

[Cpasjuste]

It work better with dynamic recompiler

 

[Pickle]

It work better with dynamic recompiler

Im just throwing this out there (and i might be totally off base), but i know this was true for the iphone. There was a restriction on running binary code (from the stack?), basically it wouldnt let the process run the dynamic recompiled code. But there was a work around to allow for the code to run.
Is it possible nokia does the same thing

 

[Cpasjuste]

In fact i'm saying that it work with the dynamic recompiler, not the interpreter.

 

[Pickle]

In fact i'm saying that it work with the dynamic recompiler, not the interpreter.

Doh ;-)

 

[ari64]

It seems to hang after "R4300 Core mode: Interpreter", no matter what i do.
Maybe i'm missing something ?

If you want to use the interpreter, you'll have to undefine NEW_DYNAREC in cop1_*.c to get rid of some hacks that I put in to speed up floating point. I should improve that code, but I never seriously thought anyone would try to run the interpreter.

 

[kingoddball]

Hey Ari:

Looks like your Mupen64Plus release has made it over to N900 (maybe you already know?).

N64 for N900 thread

 

[Cpasjuste]

Well, proper link is : http://talk.maemo.org/showthread.php?t=47043

 

[kingoddball]

..

 

[kingoddball]

@ Cpasjuste & Ari64: Will this work with similar specs/speeds on N900 as it is on Pandora/BB? It's huge news that your hard work is being ported everywhere Ari. I hope you get all the credit you deserve!!

 

[Cpasjuste]

By the way Ari64, is it normal that the "assem_arm.c" file isn't compiled/used for me, or do i miss something ?

 

[ldesnogu]

By the way Ari64, is it normal that the "assem_arm.c" file isn't compiled/used for me, or do i miss something ?

You missed something

$ grep -Ir assem_arm .
./r4300/new_dynarec/assem_arm.c: *   Mupen64plus - assem_arm.c                                             *
./r4300/new_dynarec/new_dynarec.c:#include "assem_arm.h"
./r4300/new_dynarec/new_dynarec.c:#include "assem_arm.c"

EDIT: this was my 1000th post, at least it was somewhat technical :unsure:

 

[Cpasjuste]

w00t, i see !

Happy 1000 post

 

[Mithrildor]

No progress anymore?