Having been out of the emulation scene for a few years, I recently decided to play some of my old N64 ROMs on my PC. I went with Mupen64Plus 1.99.3 for the emulator, and I was so impressed with the program that I had to dig around in the source code. I really like the modular nature of this library - it is perfectly structured to facilitate porting to new systems.

I've decided to take a crack at porting this emulator to Android, using the NDK (so I can use native c/c++ directly rather than having to translate the entire project into Java). I realize that current devices are probably not at a level to run N64 emulation smoothly yet, but by the time I finish the port, who knows?

I'll be using pelya's Android SDL port, which doesn't require the target device to be rooted (allowing for easy distribution through the Android Market and avoiding any licensing/warranty concerns that can come with rooting). My initial challenge is translating the Makefiles used by the Mupen64Plus source into NDK-speak (I'm rather new to the whole Makefile concept, so it will be a bit of an initial learning curve). I'll post my progress on this project here. Comments and suggestions are welcome. Also, if anyone else is already working on an Android port of Mupen64Plus, I'd be happy to collaborate.

How would you convert the trident shaped n64 controlle to a touch screen? Would be interesting

Make Goldeneye 64 your priority ..and mod it for wireless multiplayer haha would be siiick! goodluck

While I think most players would be using either a physical keyboard or bluetooth joystick for input (such as a Datel WII classic controller connected via the WIIMote Controller app), I do plan to add an optional virtual keypad for touchscreen-only devices like the Droid X. It will take a little rearranging to avoid having the buttons sitting where they block the action (button-arrangement suggestions are welcome, assuming I am able to get that far). My initial thought is something like this:

I originally thought that this thread was titled "Porting MUGEN 64+ to Android," which I interpreted to be MUGEN and a built-in library of 64 characters.

This is cool too, though. : D

I thought I would post a progress update, in case anyone is interested. I've got the basic project set up, utilizing Pelya's SDL port and the n64oid source code (based on Mupen64Plus 1.99.1). Current logcat output is very encouraging:

Code: Select all

12-04 14:14:27.830: INFO/System.out(2130): libSDL: setting envvar LANGUAGE to 'en_US'
12-04 14:14:27.830: INFO/System.out(2130): libSDL: accelerometer start required: false
12-04 14:14:27.830: INFO/libSDL(2130): Calling SDL_main("mupen64plus --corelib /data/data/paulscode.android.mupen64plus/lib/libcore.so --rsp /data/data/paulscode.android.mupen64plus/lib/librsp-hle.so --audio /data/data/paulscode.android.mupen64plus/lib/libaudio-sdl.so roms/mario.n64")
12-04 14:14:27.830: INFO/libSDL(2130): param 0 = "mupen64plus"
12-04 14:14:27.830: INFO/libSDL(2130): param 1 = "--corelib"
12-04 14:14:27.830: INFO/libSDL(2130): param 2 = "/data/data/paulscode.android.mupen64plus/lib/libcore.so"
12-04 14:14:27.830: INFO/libSDL(2130): param 3 = "--rsp"
12-04 14:14:27.830: INFO/libSDL(2130): param 4 = "/data/data/paulscode.android.mupen64plus/lib/librsp-hle.so"
12-04 14:14:27.830: INFO/libSDL(2130): param 5 = "--audio"
12-04 14:14:27.830: INFO/libSDL(2130): param 6 = "/data/data/paulscode.android.mupen64plus/lib/libaudio-sdl.so"
12-04 14:14:27.830: INFO/libSDL(2130): param 7 = "roms/mario.n64"
12-04 14:14:27.830: VERBOSE/front-end(2130):  __  __                         __   _  _   ____  _             
12-04 14:14:27.830: VERBOSE/front-end(2130): |  \/  |_   _ _ __   ___ _ __  / /_ | || | |  _ \| |_   _ ___
12-04 14:14:27.830: VERBOSE/front-end(2130): | |\/| | | | | '_ \ / _ \ '_ \| '_ \| || |_| |_) | | | | / __| 
12-04 14:14:27.830: VERBOSE/front-end(2130): | |  | | |_| | |_) |  __/ | | | (_) |__   _|  __/| | |_| \__ \ 
12-04 14:14:27.830: VERBOSE/front-end(2130): |_|  |_|\__,_| .__/ \___|_| |_|\___/   |_| |_|   |_|\__,_|___/ 
12-04 14:14:27.830: VERBOSE/front-end(2130):              |_|         http://code.google.com/p/mupen64plus/ 
12-04 14:14:27.830: VERBOSE/front-end(2130): Mupen64Plus Console User-Interface Version 1.99.1
12-04 14:14:27.830: VERBOSE/front-end(2130): Parsing arg 1: --corelib
12-04 14:14:27.830: VERBOSE/front-end(2130): Parsing arg 3: --rsp
12-04 14:14:27.830: VERBOSE/front-end(2130): Parsing arg 4: /data/data/paulscode.android.mupen64plus/lib/librsp-hle.so
12-04 14:14:27.830: VERBOSE/front-end(2130): Parsing arg 5: --audio
12-04 14:14:27.830: VERBOSE/front-end(2130): Parsing arg 6: /data/data/paulscode.android.mupen64plus/lib/libaudio-sdl.so
12-04 14:14:27.830: VERBOSE/front-end(2130): Parsing arg 7: roms/mario.n64
12-04 14:14:27.861: VERBOSE/front-end(2130): Core Warning: Couldn't open configuration file '/mnt/sdcard/app-data/paulscode.android.mupen64plus/./mupen64plus.cfg'.  Using defaults.
12-04 14:14:29.416: VERBOSE/front-end(2130): Core: Goodname: Super Mario 64 (U) [!]
12-04 14:14:29.416: VERBOSE/front-end(2130): Core: Name: SUPER MARIO 64
12-04 14:14:29.416: VERBOSE/front-end(2130): Core: MD5: 20B854B239203BAF6C961B850A4A51A2
12-04 14:14:29.416: VERBOSE/front-end(2130): Core: CRC: 635a2bff 8b022326
12-04 14:14:29.416: VERBOSE/front-end(2130): Core: Imagetype: .v64 (byteswapped)
12-04 14:14:29.416: VERBOSE/front-end(2130): Core: Rom size: 8388608 bytes (or 8 Mb or 64 Megabits)
12-04 14:14:29.416: VERBOSE/front-end(2130): Core: Version: 1444
12-04 14:14:29.416: VERBOSE/front-end(2130): Core: Manufacturer: Nintendo
12-04 14:14:29.416: VERBOSE/front-end(2130): Core: Country: USA
12-04 14:14:29.432: VERBOSE/front-end(2130): Core Warning: No video plugin attached.  There will be no video output.
12-04 14:14:29.432: VERBOSE/front-end(2130): Core Warning: No input plugin attached.  You won't be able to control the game.
12-04 14:14:29.713: VERBOSE/front-end(2130): Audio: Initializing SDL audio subsystem...
12-04 14:14:29.713: INFO/libSDL(2130): ANDROIDAUD_OpenAudio(): app requested audio bytespersample 2 freq 44100 channels 2 samples 4096
12-04 14:14:29.760: INFO/libSDL(2130): ANDROIDAUD_OpenAudio(): app opened audio bytespersample 2 freq 44100 channels 2 bufsize 16384
12-04 14:14:30.119: VERBOSE/front-end(2130): Core: Starting R4300 emulator: Cached Interpreter
12-04 14:14:31.314: INFO/libSDL(2130): ANDROIDAUD_OpenAudio(): app requested audio bytespersample 2 freq 44100 channels 2 samples 4096
12-04 14:14:31.322: INFO/libSDL(2130): ANDROIDAUD_OpenAudio(): app opened audio bytespersample 2 freq 44100 channels 2 bufsize 16384


Going with Pelya's SDL port has really paid off -- mupen64plus' sdl audio plugin successfully connects to the audio device, meaning I've advanced beyond n64oid's original capability (if anyone wants to continue n64oid development using Pelya's SDL, let me know and I can help you set up the project).

Now that I have the makefiles and globals set up the way I want them, I'm ready to trash n64oid. My next step will be to port the current Mupen64Plus 1.99.4 sources and Ari64's ARM dynarec.

I am absolutely following this project, and look forward to your posts. Though, I must say that I am in some doubt that this will run smoothly/playable on some of the android devices. Anyways, keep up the great work!

aspic wrote:I must say that I am in some doubt that this will run smoothly/playable

As am I, but who knows - maybe the next generation devices will be coming out about the time I finish the port..

Update: I finished moving to the current 1.99.4 sources, and have begun porting the ARM dynarec. Logcat output from the latest successful build and execution, for those interested in that sort of thing:

Code: Select all

12-05 11:05:10.740: INFO/System.out(2256): libSDL: setting envvar LANGUAGE to 'en_US'
12-05 11:05:10.740: INFO/System.out(2256): libSDL: accelerometer start required: false
12-05 11:05:10.740: INFO/libSDL(2256): Calling SDL_main("mupen64plus roms/mario.n64")
12-05 11:05:10.740: INFO/libSDL(2256): param 0 = "mupen64plus"
12-05 11:05:10.740: INFO/libSDL(2256): param 1 = "roms/mario.n64"
12-05 11:05:10.740: VERBOSE/front-end(2256):  __  __                         __   _  _   ____  _             
12-05 11:05:10.740: VERBOSE/front-end(2256): |  \/  |_   _ _ __   ___ _ __  / /_ | || | |  _ \| |_   _ ___
12-05 11:05:10.740: VERBOSE/front-end(2256): | |\/| | | | | '_ \ / _ \ '_ \| '_ \| || |_| |_) | | | | / __| 
12-05 11:05:10.740: VERBOSE/front-end(2256): | |  | | |_| | |_) |  __/ | | | (_) |__   _|  __/| | |_| \__ \ 
12-05 11:05:10.740: VERBOSE/front-end(2256): |_|  |_|\__,_| .__/ \___|_| |_|\___/   |_| |_|   |_|\__,_|___/ 
12-05 11:05:10.740: VERBOSE/front-end(2256):              |_|         http://code.google.com/p/mupen64plus/ 
12-05 11:05:10.740: VERBOSE/front-end(2256): Mupen64Plus Console User-Interface Version 1.99.4
12-05 11:05:12.544: VERBOSE/front-end(2256): Core: Goodname: Super Mario 64 (U) [!]
12-05 11:05:12.544: VERBOSE/front-end(2256): Core: Name: SUPER MARIO 64
12-05 11:05:12.544: VERBOSE/front-end(2256): Core: MD5: 20B854B239203BAF6C961B850A4A51A2
12-05 11:05:12.544: VERBOSE/front-end(2256): Core: CRC: 635a2bff 8b022326
12-05 11:05:12.544: VERBOSE/front-end(2256): Core: Imagetype: .v64 (byteswapped)
12-05 11:05:12.544: VERBOSE/front-end(2256): Core: Rom size: 8388608 bytes (or 8 Mb or 64 Megabits)
12-05 11:05:12.544: VERBOSE/front-end(2256): Core: Version: 1444
12-05 11:05:12.544: VERBOSE/front-end(2256): Core: Manufacturer: Nintendo
12-05 11:05:12.544: VERBOSE/front-end(2256): Core: Country: USA
12-05 11:05:12.560: VERBOSE/front-end(2256): UI-console: using Video plugin: <dummy>
12-05 11:05:12.560: VERBOSE/front-end(2256): UI-console: using Audio plugin: 'Mupen64Plus SDL Audio Plugin' v1.99.4
12-05 11:05:12.560: VERBOSE/front-end(2256): UI-console: using Input plugin: <dummy>
12-05 11:05:12.560: VERBOSE/front-end(2256): UI-console: using RSP plugin: 'Hacktarux/Azimer High-Level Emulation RSP Plugin' v1.99.4
12-05 11:05:12.560: VERBOSE/front-end(2256): Core Warning: No video plugin attached.  There will be no video output.
12-05 11:05:12.560: VERBOSE/front-end(2256): Core Warning: No input plugin attached.  You won't be able to control the game.
12-05 11:05:12.795: VERBOSE/front-end(2256): Audio: Initializing SDL audio subsystem...
12-05 11:05:12.795: INFO/libSDL(2256): ANDROIDAUD_OpenAudio(): app requested audio bytespersample 2 freq 44100 channels 2 samples 2048
12-05 11:05:12.835: DEBUG/AudioHardwareMot(1160): Output bufSize from kernel = 8192
12-05 11:05:12.841: INFO/libSDL(2256): ANDROIDAUD_OpenAudio(): app opened audio bytespersample 2 freq 44100 channels 2 bufsize 8192
12-05 11:05:13.216: VERBOSE/front-end(2256): Core: Starting R4300 emulator: Cached Interpreter
12-05 11:05:14.272: INFO/libSDL(2256): ANDROIDAUD_OpenAudio(): app requested audio bytespersample 2 freq 44100 channels 2 samples 2048
12-05 11:05:14.279: INFO/libSDL(2256): ANDROIDAUD_OpenAudio(): app opened audio bytespersample 2 freq 44100 channels 2 bufsize 8192

While this *IS* an awesome project, I think the unique (read: ridiculous) design of the N64's controller will make it extremely difficult to incorporate that on-screen controller in such a way so that games will flow naturally.

Just think about something like Ocarina of time side-jump lunges or starfox 64 barrel-roll loops. As far as exhibition goes, I think this is great stuff. I just don't know how much fun I could have at the end of the day using it on a touchscreen device.

Anyhow, hope you prove me wrong. Best of luck!

I agree with that analysis, too. I think anyone serious about playing on a touchscreen only device will probably be using a wireless controller of some type anyway. I personally use the Datel Retro wireless controller connected via the Wiimote Controller app when playing any emulator on my Droid X. The Zimote is pretty good too, but has fewer buttons (better for simple controllers like the NES or in conjunction with a touchscreen controller for the less-used bettons)

So, I have some good news, some bad news, and some really bad news.

The good news is I finished adding in the ARM dynarec to version 1.99.4 (just the c code, and it is yet untested).

The bad news is that the NDK will not compile assembly. The compiler throws a stack of "bad instruction" errors. After some research into the issue, it seems that I need a program called the "Keil RealView Microcontroller Development Kit". Apparently, one must compile the assembly in this program into a library that the NDK can link with.

The really bad news is this program costs around $2,500. If I were a rich man, no problem, but unfortunately I am not. I'm looking into the possibility of any other program that can perform the same function for less cash (preferably free). Another option would be to find someone who owns the software and can compile the assembly for me (I'll be asking around on various forums).

In the mean time, unfortunately, this project is at a standstill.

Perhaps use Kickstarter as a potential funding source for the project?

Another potential option would be to get in direct contact with the software company and explain your project. Perhaps they will provide a development copy free-of-charge if you promise to plug their product in the credits. It's worth a shot.

Best of luck on finding someone and knocking this project out of the park.

After a bit more research, I've discovered that the NDK can compile some assembly, and thankfully it looks like it can handle this particular .s file. I've only gotten it to work from the command line, but at least that means a separate shared library is a fall-back option (and it won't cost me the two and a half grand). I'm sure there has got to be a way for this thing to compile in the project as well (output from the builder shows that it is using the same executable I used from the command line, just more involved options/parameters). I really think I just need to get the compiler options right in my Android.mk file. I'll keep tinkering around with this.

For reference, here are the commands for building it into a shared library from the terminal (pretty straight-forward gcc stuff):

Code: Select all

/home/paul/bin/android-ndk-r4b/build/prebuilt/linux-x86/arm-eabi-4.4.0/bin/arm-eabi-gcc -fpic -c linkage_arm.s -o linkage_arm.o

/home/paul/bin/android-ndk-r4b/build/prebuilt/linux-x86/arm-eabi-4.4.0/bin/arm-eabi-gcc -shared -Wl,-soname,liblinkage_arm.so.1 -nostdlib -o liblinkage_arm.so linkage_arm.o

This is looking really promising. : )
Very cool that the project wasn't killed by a $2.5k hurdle.

Wow, so I found the problem. For some reason the builder decides to give the output from the first command an extension of ".s" instead of ".o". This then confuses the builder when it executes the second command (apparently it sees that ".s" extension and expects a text file with assembly commands, which is why it spits out a hundred "bad instruction" errors).

What a stupid bug! Although it is so simple, I honestly have no clue how to get around it short of compiling from the command line -- I have no clue how to debug the Eclipse plug-in so it names the output (name).o instead of (name).s. I'll probably have to build the entire core from the command line, and just plug the resulting library into my project, rather than having it built inside the project along with the other libraries. The other way would be to compile linkage_arm.s separately, but this would require a different memory mapping than it is using now, and I'd really rather not tinker with Ari64's complicated assembly code..

I figured out an acceptable workaround. I've created two mirror projects, one with the new dynarec as part of the core, the other with the cached interpreter. I run the builder for the first project and wait for the errors. Then I select copy the last build command onto the clipboard, and pull up a terminal. I rename that output file to linkage_arm.o, paste the command, change the word linkage_arm.s to linkage_arm.o, and run it. This creates the good core library. Then I load up the second project and build it completely. I swap out the old core library with the good one, and can then deploy the .apk to the phone or emulator. This method is a pain in the butt, but at least I am back on track.

I now have some debugging to do, because the program crashes when it tries to start the dynamic recompiler, but right now I am just thrilled that I finally got the thing out of Eclipse onto the phone.