Mupen64Plus

[ari64]

There's been some people asking about merging code from this project to mupen64plus v2.0, so I wanted to clarify the status of things.

There are currently two separate source packages which are based on mupen64plus v1.5:

The first is the new dynamic recompiler, which I wrote. The source code to this is available at http://bunnitude.com/ari64/mupen64plus-arm-20100402.tar.gz

The second is the gles2n64 plugin, which was made by Adventus based on glN64. This is available at http://code.google.com/p/gles2n64


Merging the dynamic recompiler: This generates ARMv5, ARMv7, x86, and x86-64. The compatibility is about 90-95% at present. There are some known issues with the floating point code and in the TLB emulation. These will need to be fixed before this can be used as the default CPU core in mupen64plus.

Merging gles2n64: This is an OpenGL ES 2.0 plugin based on glN64. Due to the unclear status of some code in glN64, this really shouldn't go into mainline in its present state. At some point I'd like to investigate how feasible it would be to merge Adventus's changes with the current Arachnoid plugin.

Finally there is the input plugin by JayFoxRox. I'm not sure whether it's necessary to maintain this as a separate plugin, or whether we can use one of the standard input plugins on the Pandora.

 

[Pickle]

Finally there is the input plugin by JayFoxRox. I'm not sure whether it's necessary to maintain this as a separate plugin, or whether we can use one of the standard input plugins on the Pandora.

We should be able to use the blight plugin with some modifications since its just SDL based. Not sure why the one i built wouldnt register in game yet though.

 

[Adventus]

Merging gles2n64: This is an OpenGL ES 2.0 plugin based on glN64. Due to the unclear status of some code in glN64, this really shouldn't go into mainline in its present state. At some point I'd like to investigate how feasible it would be to merge Adventus's changes with the current Arachnoid plugin.

I actually thought of this when i ported gln64.... but i looked at the source and noticed it was C++ which turned me off. The original gln64 looked easier to modify.

http://code.google.com/p/ppsp-input/

Not sure if that is enough, I'd like to give someone else the project ownership tho.
I just suck with management and all the legal crap.

Any volunteers?

I suck equally with the legal stuff, but maybe i should have svn submission permissions at least. I quickly hacked in key mappings / configuration yesterday. Currently you can:

• map the N64 analog to either the Left/right analogs or the DPAD. You can specify a velocity when you map to the DPAD, so each time its registered it adds that value to the analog x/y axis.
• map the N64 digital buttons to either the pandora buttons, keyboard or an analog axis. When you map to analog you specify a threshold, so if the analog is pushed pass the threshold it registers a button press.
• you can define your own left/right analog calibration curve. ie out = v[0]*in + v[1]*in*in + v[2]*in*in*in..... this way you can make the nubs less sensitive in the lower values and more sensitive in the upper.

Is there anything else i should add?

We should be able to use the blight plugin with some modifications since its just SDL based. Not sure why the one i built wouldnt register in game yet though.

Maybe its to do with the mupen64plus's window losing focus as my plugin starts.

 

[God Ginrai]

Merging gles2n64: This is an OpenGL ES 2.0 plugin based on glN64. Due to the unclear status of some code in glN64, this really shouldn't go into mainline in its present state. At some point I'd like to investigate how feasible it would be to merge Adventus's changes with the current Arachnoid plugin.

I actually thought of this when i ported gln64.... but i looked at the source and noticed it was C++ which turned me off. The original gln64 looked easier to modify.

http://code.google.com/p/ppsp-input/

Not sure if that is enough, I'd like to give someone else the project ownership tho.
I just suck with management and all the legal crap.

Any volunteers?

I suck equally with the legal stuff, but maybe i should have svn submission permissions at least. I quickly hacked in key mappings / configuration yesterday. Currently you can:

• map the N64 analog to either the Left/right analogs or the DPAD. You can specify a velocity when you map to the DPAD, so each time its registered it adds that value to the analog x/y axis.
• map the N64 digital buttons to either the pandora buttons, keyboard or an analog axis. When you map to analog you specify a threshold, so if the analog is pushed pass the threshold it registers a button press.
• you can define your own left/right analog calibration curve. ie out = v[0]*in + v[1]*in*in + v[2]*in*in*in..... this way you can make the nubs less sensitive in the lower values and more sensitive in the upper.

Is there anything else i should add?

We should be able to use the blight plugin with some modifications since its just SDL based. Not sure why the one i built wouldnt register in game yet though.

Maybe its to do with the mupen64plus's window losing focus as my plugin starts.

That configuration sounds nice. How do you do it? Through a GUI, or using config files? o_ô

-God Ginrai

 

[Adventus]

That configuration sounds nice. How do you do it? Through a GUI, or using config files? o_ô

I'm just using text files for now, i generally prefer them to GUI's anyway. Writing something in GTK / QT takes twice as long and can be done at a later date.

 

[God Ginrai]

That configuration sounds nice. How do you do it? Through a GUI, or using config files? o_ô

I'm just using text files for now, i generally prefer them to GUI's anyway. Writing something in GTK / QT takes twice as long and can be done at a later date.

I'm not complaining. I'm just glad about the level of configuration you've added. ^_^ Although, later, GUIs for the configuration would probably be a good idea. Especially for tweaking the nubs and setting up USB controllers.

-God Ginrai

 

[JayFoxRox]

Adventus: I made you a committer some days ago already, feel free to add anything etc.

I feel that updating ppsp-input is like beating a dead horse.


It was originally written because I didn't expect to be this close to actual N64 emulation on the Pandora.
- I heard that you and Pickle were having problems getting your graphics plugin to work and when I looked at it and got it to load the first time (with that one-liner fix) it ran great already.
However, since Pickle had no way to control it (and since I used a beagleboard I didn't have an option neither) I decided to write a plugin based on my Pandora-PSP sources and just slammed it all together because the Pandora was missing a default joystick-input device to work with other plugins.
Because of that I decided to work on my pandora-input-drivers to re-create the pandora-event devices on the beagleboard so I could test the N64 emulator and my newly created plugin too.
Once that was working I wanted to have a real joystick device so we could use the existing plugins and I worked on the second part of my pandora-input-drivers to create a joystick device from the input-events.

Since that is working since a long long time already, I don't even know why ppsp-input was even included and why the pandora kernel still has the *imo* stupid event system.
In the end all I can say is that ppsp-input was written in a few hours, with an extremly dirty source as base - the input driver solution is way cleaner.

You can find the pandora-input-drivers, version 2 (re-written the main source file and dropped the event emulation) here: http://scratchpad.jannikvogel.de/projects/pid2/

Since that creates a standard joystick device you should be able to use most N64 input plugin. But you should note that the driver has to be running in the background and you must most likely be a super-user to start it because it access the uinput device.

Also note that I never tested the driver myself as I don't have a Pandora yet. [Thanks again to aTc and Pawprints for testing]

 

[Adventus]

Yeah I know where your coming from. I like ppsp_input purely because it works and i understand it, meaning i can make changes with minimal effort. If someone gets blight input, etc to work I'll definitely include it with the emulator. However at the moment i don't especially want to be that someone.

 

[JayFoxRox]

I definitly had another input plugin working on my beagleboard. Not sure if it was blight though. I'm getting a Pandora soon and I'll look into it.

 

[ari64]

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


Changes since 20100402:


Fix pagefault-on-execute

Properly set Context register on pagefault

Fix constant propagation in delay slots

Tolerate delay slot abuse with JR instruction

Fix DMTC1 instruction

Fix TLBWR instruction

Fix DSRLV/DSRAV instructions

Fix SDR instruction

 

[jonlad1]

Hey thanks Ari!

Is there any speed/compatibility increases with this release? (Not at home so cant test : )

 

[ari64]

Hey thanks Ari!

Is there any speed/compatibility increases with this release? (Not at home so cant test : )

The speedup from fixing the constant propagation is less than 1%. I fixed all the crashes I could find, but people will probably find more : )

BTW I wrote some documentaton on the dymanic recompiler here.

 

[God Ginrai]

Hey thanks Ari!

Is there any speed/compatibility increases with this release? (Not at home so cant test : )

The speedup from fixing the constant propagation is less than 1%. I fixed all the crashes I could find, but people will probably find more : )

BTW I wrote some documentaton on the dymanic recompiler here.

What games did you fix? I can give you a list of ones that didn't work for me if that would help you in searching for bugs. (Specifically, Bomberman 64 crashes immediately, Bomberman 64: Second Attack crashes right before getting to the Start Screen, and Mario Tennis crashes immediately)

-God Ginrai

 

[ari64]

What games did you fix? I can give you a list of ones that didn't work for me if that would help you in searching for bugs. (Specifically, Bomberman 64 crashes immediately, Bomberman 64: Second Attack crashes right before getting to the Start Screen, and Mario Tennis crashes immediately)

Mario Tennis is fixed (it was the SDR instruction). I didn't test bomberman.

 

[God Ginrai]

What games did you fix? I can give you a list of ones that didn't work for me if that would help you in searching for bugs. (Specifically, Bomberman 64 crashes immediately, Bomberman 64: Second Attack crashes right before getting to the Start Screen, and Mario Tennis crashes immediately)

Mario Tennis is fixed (it was the SDR instruction). I didn't test bomberman.

I'm glad to hear about Mario Tennis, and I would be grateful if you could test Bomberman for me.

-God Ginrai

 

[Exophase]

BTW I wrote some documentaton on the dymanic recompiler here.

Good read Ari, thanks.

 

[javispedro]

From reading http://hcs64.com/files/n64-hw.dox (and warning that all I know from the N64 comes from having just read it),

what would happen if I were to reduce the (emulated) delay between a write to the Audio Interface LEN register and the deassertion of BUSY / FIFO_FULL in the AI STATUS register (thus firing the AI interrupt)?

Ideally, if it were truly streaming audio, the game would just fetch and write audio data more often (at the cost of less rendering throughput, etc.).
From a quick test though, it seems that games will wait for a minimum delay between audio data writes even if the interrupt is fired right the next cycle after a write. This delay is ~ the same delay one would experience on a real N64 at the configured sample rate. Thus, nothing happens: same average number of audio bytes written per second => choppy audio.

So I guess games don't care at all about FIFO_FULL, or did I do something wrong?

 

[ari64]

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


Changes since 20100627:


Fixed register allocation where a branch jumps into a delay slot of another branch

Fixed TLB/COP0 register corruption

Fixed self-modifying code detection during block deallocation

Some fixes for cases where a branch and delay slot cross a virtual memory page

Made SMC comparison based on virtual address only, not physical address

Avoid loading/storing registers inside loops if possible

 

[Figa]

Thank you very much your work is awesome. Any speed or compatibility improvements in this release?

 

[DaveC]

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


Changes since 20100627:

Cool thanks for the continued work on this.