Porting Mupen64Plus to Android

[paulscode]

Ha! I found a directory I can execute from (/tmp). Next step is to test the the new dynarec version that Ari64 just posted.

 

[Cpasjuste]

paulscode, in fact i did try to port it to jni (2.2) yesterday (code from my github repo, same you are using) but while all is working fine from the executable, i get a memory problem (crash) when entering the "init memory" function, the memory is maybe corrupted when launched from jni, probably the rdram memory init.

Edit : i did try to allocate the rdram in bss, it seems to work, but then it probably crash in "init_dynarec" like before since i'm using the new ari64 version without the previous patch.

 

[paulscode]

I did try to allocate the rdram in bss, it seems to work, but then it probably crash in "init_dynarec" like before since i'm using the new ari64 version without the previous patch.

You should be able to just remove the allocation of rdram from linkage_arm.S, remove the definition of rdram at the bottom of assem_arm.h, and let memory/memory.c allocate rdram for you (by changing the #ifdef statement there to allow it). I looked through the code for the new version that Ari64 posted today, and it looks like the new BASE_ADDR / trampoline stuff is there, so that shouldn't be what's causing your crash. Maybe check to see if there is something else residing at 0x6000000, and if so, move BASE_ADDR somewhere else (in assem_arm.h)

Another question, Cpasjuste: what are you using for mupen64plus.conf in your project? Is there a default/minimum configuration file somewhere that I'm missing? In Mupen64Plus 1.99.4 there is the "--saveoptions" argument which can be used to create a configuration file, but I don't see an equivalent option in version 1.5.
--EDIT-- Nevermind, I solved this by installing version 1.5 on my PC from the repository, and grabbing the default mupen64plus.conf file from /usr/share/mupen64plus/config, and altering the names in it to match my project. Probably not the "right way", but it worked - I got the config file I needed.

 

[paulscode]

Woohoo! I got the executable working (with the new dynarec version that Ari64 posted today). Next step is to port it to JNI (Haha, I'm a stride behind you, Cpasjuste).

 

[Cpasjuste]

Good luck with that

 

[jkimber]

Good progress.
What is the video/audio/input plugins pandora porting using? Or android porting you select now?

 

[Cpasjuste]

Well, for now there's no video/audio/input plugin used at all for me, it's the easiest part

After digging with your suggestion paulscode, i'm able to pass the memory_init when launched from jni, and also pass the "new_dyna_start" function. But then i dont see the video plugin looping, nothing seems to happen then the application force close after a few seconds. I'm not sure how we should implement the stepping since the main emulator loop seems to be in the assembly code isnt it ?

 

[jkimber]

Well, for now there's no video/audio/input plugin used at all for me, it's the easiest part

After digging with your suggestion paulscode, i'm able to pass the memory_init when launched from jni, and also pass the "new_dyna_start" function. But then i dont see the video plugin looping, nothing seems to happen then the application force close after a few seconds. I'm not sure how we should implement the stepping since the main emulator loop seems to be in the assembly code isnt it ?

I suspect the potential crash at (do not know why)
new_dyanrec.c line 7626
>>>
else {
printf("Compile at bogus memory address: %x \n", (int)addr);
exit(1); >>>here
}


For video plugin, it shall be easy for you since I know you are opengl experts but I know nothing about opengl codes.

 

[Ari64]

After digging with your suggestion paulscode, i'm able to pass the memory_init when launched from jni, and also pass the "new_dyna_start" function. But then i dont see the video plugin looping, nothing seems to happen then the application force close after a few seconds. I'm not sure how we should implement the stepping since the main emulator loop seems to be in the assembly code isnt it ?

The "main emulator loop" is the code generated by the dynamic recompiler. It calls gen_interrupt periodically, which calls the audio/video plugins.

I suspect the potential crash at (do not know why)
new_dyanrec.c line 7626
>>>
else {
printf("Compile at bogus memory address: %x \n", (int)addr);
exit(1); >>>here
}

If this is happening, then find out where the bad pointer came from.

For video plugin, it shall be easy for you since I know you are opengl experts but I know nothing about opengl codes.

The Pandora port is currently using a derivative of glN64 modified to use OpenGL ES. As there seems to be a consensus that we need to get rid of glN64 due to unclear authorship and licensing, we'll need to come up with a better alternative.

 

[paulscode]

As there seems to be a consensus that we need to get rid of glN64 due to unclear authorship and licensing, we'll need to come up with a better alternative.

The obvious solution would be to track down the author -- apparently Orkin (see this page), and ask him. Obviously, finding someone based on an alias (and probably an email linked to their account) isn't the easiest thing in the world, if they don't reply to emails. I think actually all you would have to do is be able to demonstrate that one or more parts of the source code for his project was taken from another project licensed by the GPL. If that can be clearly shown, then obviously the only authority Orkin had to distribute it in the first place was under the terms of the GPL, and the GPL would still apply to your plug-in as a derivative work. I will do some research and see if I can prove that is the case.

 

[Surkow]

The obvious solution would be to track down the author -- apparently Orkin (see this page), and ask him. Obviously, finding someone based on an alias (and probably an email linked to their account) isn't the easiest thing in the world, if they don't reply to emails. I think actually all you would have to do is be able to demonstrate that one or more parts of the source code for his project was taken from another project licensed by the GPL. If that can be clearly shown, then obviously the only authority Orkin had to distribute it in the first place was under the terms of the GPL, and the GPL would still apply to your plug-in as a derivative work. I will do some research and see if I can prove that is the case.

You should look into Arachnoid. From what I can remember it's a C++ fork that is released under the GPL and allowed by Orkin. The original project page can be found here.

 

[paulscode]

You should look into Arachnoid. From what I can remember it's a C++ fork that is released under the GPL and allowed by Orkin.

I am not able to find an original release of Arachnoid with an endorsement by Orkin (doesn't mean it doesn't exist, just that I can't find proof of it). The oldest versions of Arachnoid I can find were released without any mention of Orkin in 2007, which is 4 years after the most recent official release of glN64, and more than a year since Orkin was last active. If I were to guess, someone else slapped the GPL on the project, since none of Orkin's code has any kind of licensing specified. That doesn't invalidate my original argument, though. It just means the Arachnoid project can't be used as proof that Orkin released his code under the GPL.

 

[Danny]

Hey paulscode, just a quick question..

I have been following this thread but over the last few pages I am unsure as to what your goal is now?

Are you continuing what you started, or starting a fresh from another project branch ?

 

[Surkow]

I am not able to find an original release of Arachnoid with an endorsement by Orkin (doesn't mean it doesn't exist, just that I can't find proof of it). The oldest versions of Arachnoid I can find were released without any mention of Orkin in 2007, which is 4 years after the most recent official release of glN64, and more than a year since Orkin was last active. If I were to guess, someone else slapped the GPL on the project, since none of Orkin's code has any kind of licensing specified. That doesn't invalidate my original argument, though. It just means the Arachnoid project can't be used as proof that Orkin released his code under the GPL.

That's actually correct. I was mistaken about the explicit endorsement. It's only Sourceforge showing that Arachnoid is released under the GPL.

 

[paulscode]

Are you continuing what you started, or starting a fresh from another project branch ?

Starting fresh. My idea was to start with a project where the dynamic recompiler is functioning, and Cpasjuste provided that. Then I work my way from there to my original goal of porting the dynarec to Mupen64Plus 1.99.4.

 

[Danny]

Starting fresh. My idea was to start with a project where the dynamic recompiler is functioning, and Cpasjuste provided that. Then I work my way from there to my original goal of porting the dynarec to Mupen64Plus 1.99.4.

Good choice. Having a working dynarec certainly speeds things up.

 

[Cpasjuste]

Good choice. Having a working dynarec certainly speeds things up.

I would say Ari64 provided that
By the way, i think i won't work on it anymore, it's probably a waste of time for me with my very limited assembly knowledge

 

[paulscode]

My idea was to start with a project where the dynamic recompiler is functioning, and Cpasjuste provided that.

I would say Ari64 provided that

I guess I did word that incorrectly. I meant to say "an Android project using Ari64's dynarec which does not crash on my phone". Of course everyone here gives credit to Ari64 for writing the dynarec and doing some pretty amazing "remote debugging" to get it to run on a device he doesn't even have access to.

 

[Rotkaeqpchen]

Hi Paul!

May I ask then what your plans are, regarding a approximate relase date? Or cant you even guess that at this moment?

Thanks in advance!

 

[Ari64]

I guess I did word that incorrectly. I meant to say "an Android project using Ari64's dynarec which does not crash on my phone". Of course everyone here gives credit to Ari64 for writing the dynarec and doing some pretty amazing "remote debugging" to get it to run on a device he doesn't even have access to.

It was written using a beagleboard, which is on my desk and I have easy access to. "Remote debugging" consisted of running gdb.