I found a better workaround for that compiler bug. It seems that if I rename the file linkage_arm.S, gcc can still compile it, and the plug-in will call the output linkage_arm.o like it is supposed to, instead of linkage_arm.s like it was before.

Also, it turns out that I will have to make some changes to Ari64's code, because it assumes the program to be statically linked (which isn't possible with an .apk). The changes are fairly minor, though, so it shouldn't be too much trouble to get working. I basically added 16MB to the .bss section rather than mapping memory directly. Due to a limitation of the ARM architecture, I have to make sure everything in linkage_arm.s, fpu.c, tlb.c, cop0.c, BASE_ADDR through BASE_ADDR+16777216, and the .text section are within 32MB of each other. Looking at the current memory mapping, it looks like I have met these requirements.

The ap is still crashing, but at least now I can debug it a bit more easily without having to worry about that compiler bug anymore.

I thought I would post a progress update. I have hit a brick wall on the dynamic recompiler. I'm starting to believe that I'm looking in the wrong place for the source of the problem. Part of it may be the fact that I am trying to port the dynarec from Ari64's Pandora port of Mupen64Plus (which is based on version 1.5) to the current version 1.99.4. I've noticed that every other port of Mupen64Plus to ARM devices are all based on version 1.5 (Ari64's Pandora port, zodttd's n64iphone port, Cpasjuste's droid64 port, and several other completed or in development ports). The only project based on 1.99.x that I know of is scottgl's n64oid port, and he stopped development before adding the dynamic recompiler.

All this leads me to believe that I am not the only one who is having problems getting the ARM dynarec to work on more recent versions of Mupen64Plus. For that reason, I think I will change my strategy here. I'll port version 1.5 plus the dynarec to Android first (to solve any dynarec/Android issues first). If zodttd gets his project out before then, I'll start with his code (which I'm guessing is also based on version 1.5) Once I get the dynarec working on Android, I can then focus on trying to port the project to version 1.99.4. I think breaking the problem up into two parts should help me isolate trouble spots.

For those who have been asking when I'll be ready to release a beta version, this is just another example of why placing a time-line on this type of project is really impossible. A couple days ago I felt I was nearly finished with the dynamic recompiler, and now I'm basically starting from scratch again. Zodttd will almost certainly release his project first, unless he also runs into a problem. But I think ultimately, my port will be superior to his. There have been a number of optimizations and bug fixes for Mupen64Plus since version 1.5. Additionally, the new Mupen64Plus API will allow the user to download and link with core and video plug-ins that I've specifically optimized for their phone models' hardware. This is something which can't be done for with the statically linked version 1.5. Zodttd would have to either release multiple versions of his emulator on the market, or release a non-optimized version in order to support a wider variety of phone models.

Sure, I have a couple of examples that I can think of right away. For example, the Dynamic Recompiler itself has several optimizations that can be applied if the target CPU and memory mapping are known. The generic settings that would work on most devices use ARM version 5 with the RDRAM memory at an unknown location, and trampolines between the dynarec target memory and BASE_ADR in case they are not within 32MB of each other. However, I could compile a super-optimized version that assumes that the target device has ARM version 7a, that there is nothing loaded at the native RDRAM memory location, and that the dynarec target and BASE_ADR are within 32MB of each other. This version would run nearly twice as fast, but would not be compatible on every device. And there could be any combination of these optimizations (from the results of beta-testing it could be determined which is the best pick for which phone model). Likewise, for the video plug-in, if we know a user has Android 2.3 on their device, a much more efficient OpenGL plug-in could be used. I could even provide a menu option in the front-end itself to allow the user to download different versions of the plug-ins or specify paths to custom plug-ins. This would really give the user the flexibility to try out what works best on their particular phone.

Woohoo! I have the dynamic recompiler working on my phone! Project is based on Mupen64Plus 1.5, and it is a total hack-job. I compiled it as a basic executable with statically linked libraries, pushed to the phone into /tmp directory, and run via the "terminal emulator", but the dynarec runs smoothly and the process does not crash.

My next step is to port this to a JNI project which can be deployed as an .apk package.

The available GLES video plug-ins weren't quite plug-and-play, so I've decided to leave video out for now. The glide64 plug-in wouldn't compile, and the gles2n64 plug-in shuts down stating that a functionality is missing. I'll work on debugging these as well as the audio plug-in next. In the mean time, here are links to the test APKs. Note that test C is the only one that works on my phone; tests A and B may work on other devices, but are mainly for gathering debug information to help me with development:

--Links Removed--

NOTE: All of these first three tests require a device with ARM7a and minimum Android version 2.2. Sorry to the folks with older devices. I'll be posting more compatible tests hopefully later this week. Also note that there is no video plug-in and the audio plug-in is broken, so "working" means the app doesn't crash.

NOTE 2: These apps do not have a "shutdown" functionality built into them yet, so if they work on your device, you'll have to either force close the app or reboot your device to shut the dynarec down. Please be sure to do this after running each test.

The test aps will automatically download the Mupen64Plus configs and data files, as well as a rom the first time you run one of them. If your device doesn't have an internet connection, or if you have a data limit, you can manually install this data BEFORE running any of the tests. Simply unzip the following file and place all the contents onto your device's SD card under/app-data/paulscode.android.mupen64plus/App Data ZIP (not necessary if your device has internet access)

Testers, please note that you must uninstall each test app before installing another one. Debug files will be generated on your device's SD card under app-data/paulscode.android.mupen64plus/DEBUG_test*.txt. Please also provide logcat output in addition to the DEBUG_test*.txt files. You can use the free app "aLogcat" from the Android Market to get the logcat output. Just run aLogcat, press the menu button and choose "Clear". Then run one of the test APKs above, return to aLogcat, and choose "Save" from the menu. Be sure to clear the logcat output between tests. You can email me the logcat output and debug files to paul@paulscode.com. Be sure to include your device model, Android version, and whether or not your device is rooted in the email. Also describe any odd behavior you might have experienced when running the test.

And here is the sourcode for the above test apps. I haven't had time to streamline the project yet, so I apologize for all the extra garbage included.

--Links Removed--

Last edited by paulscode on Mon Sep 05, 2011 2:04 am, edited 1 time in total.

Here is the next test app, which utilizes the latest version of Ari64's dynarec:

--Link Removed--

And the sourcecode:

--Link Removed--

As with the earlier tests, this one requires a device with ARM7a and minimum Android version 2.2. There will be one more upcoming test in this series, which will be compiled for ARM5 and minimum Android version 1.6. I haven't decided if I'll work on it next, or if I'll debug the audio and video plug-ins first.

Last edited by paulscode on Mon Sep 05, 2011 2:05 am, edited 1 time in total.

Hello all, here is the last test app in my core test series. This one is compiled for ARM5 and should be compatible back to Android 1.6. This is the same core as in Test D, plus a couple changes in the jni/core/Android.mk file:

As with the previous tests, I'm measuring "success" as the app enters into a black screen and does not crash. Be sure to either restart your device after running the test, or force-close the app, or it will continue running in the background slowing down your device.

I haven't posted the full project source for this one yet, because I fully expect I'll need to fix a few initial bugs in the Java code, XML manifest, or project settings. It runs fine on my phone, but I don't have an older device myself, and my netbook is too slow to emulate an AVD to test it on (an emulator running within an emulator - now theres a fun thought). I'm mainly interested in getting ahold of some logcat outputs from older devices which do not have SDCards. This should help me identify where any problems are located.

Last edited by paulscode on Mon Sep 05, 2011 2:06 am, edited 1 time in total.

I reached a sort of milestone today.. I finally heard Mario's greeting, which besides proving beyond any doubt that the core is really working, is very satisfying after nearly eight months. The audio quality and rate are good. All the main components are not finished yet - there are crashes being caused by the input plug-in (I shouldn't have been surprised since I only just ported the thing to SDL 1.3 yesterday), and there is also a separate problem with the video plug-in (I'll look into this next after I fix the input plug-in). But I'm slowly getting there..

YES!!! I see Mario! The rendered screen is only like 1.5 inches wide and down in the bottom-left of the screen (simple layout issue, most likely), but I have video finally! I am seriously jumping in my chair right now.

Solved the resolution problem. It was using the default resolution, which is extremely tiny on a high-res screen. It wasn't quite as simple as changing the default resolution, though, because there is no way of knowing ahead of time what the end user's screen resolution is going to be. Easy solution was to simply make a call to resize once the resolution is known after SDL is initialized.

Anyway, I have to get ready for another long shift at work, so here is the test APK and full source code, as promised:

--Links removed--

IMPORTANT: Before you start, please delete the app-data from my previous test apps if you ran those in the past! Several things have changed in there since the last round of tests, so I have no idea how the app will behave if you aren't using the current version of the app data. It will still be located on your device, even if you uninstalled the apps themselves. It will be located on your sdcard at[path to sdcard]/app-data/paulscode.android.mupen64plus (on my phone this is /mnt/sdcard/app-data/paulscode.android.mupen64plus). Simply delete the entire paulscode.android.mupen64plus folder before you run the above test the first time.

The above APK is packaged with two versions of the app, one optimized for ARM7a, and one compatible back to ARM5. However, since I don't have an ARM5 device to test on, I have no idea if the settings are correct to deploy the correct version on pre-ARM7a devices. So if it won't install, let me know, and I'll compile a separate ARM5 test apk.

As with the last round of tests, the above app will automatically download the data it needs the first time you run it. If your device doesn't have an internet connection, or if you have a data limit, you can manually install this data BEFORE running any of the tests. Simply unzip the following file and place all the contents onto your device's SD card under[path to sdcard]/app-data/paulscode.android.mupen64plus/App Data ZIP (not necessary if your device has internet access)

I didn't include an x86 version in this round of tests. I want to fix some of the other bugs first before I open a new can of worms. ;D The next round of tests will include x86 (sorry, folks who have to wait)

The main things I'm looking for in this round of tests are:1) Results on a variety of devices, to see how consistently it behaves.2) Results on devices with ARM5 or ARM6 processors3) Results from Android versions prior to 2.3 (should be compatible back to Android 1.6 in theory, but untested)4) In the case that the app doesn't crash like it does on my phone, tests of the input plug-in (requires manual editing of the file app-data/paulscode.android.mupen64plus/data/InputAutoCfg.ini to configure the buttons)5) In the case that the app has new problems that I haven't experienced on my own phone (immediate crash, error messages, black-screen even after force-closing and restarting the app, no-sound, strange phone behaviors, etc), then please send me your logcat output (using the free app "aLogcat" from the Android market), and also send me the file app-data/paulscode.android.mupen64plus/data/DEBUG_PluginTestA_memoryMaps.txt). (I don't need these from everyone else, just the folks who are experiencing different problems that I don't know about yet).

If you are compiling from source code, to work around the "RAM full of zeros" bug, run "ndk-build" for mupen64plus-SDL1.3, and then again for mupen64plus-core-ARCHs. Then do four copy/pastes (overwriting the existing files):Copy mupen64plus-core-ARCHs/libs/armeabi/libcore.so and paste it into: mupen64plus-SDL1.3/libs/armeabi/ and mupen64plus-SDL1.3/obj/local/armeabi/Copy mupen64plus-core-ARCHs/libs/armeabi-v7a/libcore.so and paste it into: mupen64plus-SDL1.3/libs/armeabi-v7a/ and mupen64plus-SDL1.3/obj/local/armeabi-v7a/If any of you Android developers out there can figure out how to solve the problem without this silly work around, please let me know (it's got to be a simple settings-related bug in the make files, because the source code itself is identical in both projects)

Last edited by paulscode on Tue Sep 13, 2011 2:49 pm, edited 1 time in total.