What's new

Porting Mupen64Plus to Android

OP
paulscode

paulscode

New member
You might want to put some logging in write_rdram to see if that's being called. It should be called a little under 300 times.
Ha! Good call. It seems to only be called twice (it writes a 0 the first time, then a 1007398912). This should help me narrow my search to the places where write_rdram is being called.
 

Ari64

New member
Aha, I see - having it outside the ifdef would result in it declared twice again.
The GNU linker will usually handle it correctly if something is declared twice - no guarantees though, so it's best to avoid it.

I should also compare to Yongzh's project some more, since he already plugged your dynarec into 1.99.4 (no reason for me to reinvent the wheel).
Also see:

http://anonscm.debian.org/gitweb/?p=collab-maint/mupen64plus-core.git;a=shortlog;h=refs/heads/ari64

It might also be worth trying to figure out why yongzh replaced every call to __clear_cache with cacheflush. There's no significant difference, AFAIK.

http://anonscm.debian.org/gitweb/?p=collab-maint/mupen64plus-core.git;a=commitdiff;h=n64oid

Ha! Good call. It seems to only be called twice (it writes a 0 the first time, then a 1007398912). This should help me narrow my search to the places where write_rdram is being called.
It's called from the dynamically generated code via a pointer in writemem[] when it accesses non-cached rdram. The code is generated by do_writestub or inline_writestub.

If there is nothing obvious wrong, a possible next step would be to uncomment the code at the bottom of store_assemble, which will call memdebug() for every memory write and produce a rather lengthy debugging log.
 
OP
paulscode

paulscode

New member
Awesome, thanks for the links - those will be very useful.

If I can't find anything obvious by doing comparisons, I'll uncomment that code to see what I get in the lengthy debug output.

It might also be worth trying to figure out why yongzh replaced every call to __clear_cache with cacheflush. There's no significant difference, AFAIK.
Ah! Another good call. A quick google search revealed this:
http://code.google.com/p/android/issues/detail?id=1803

And this as the intended solution:
http://groups.google.com/group/android-ndk/browse_thread/thread/6141782db06579b7

Thanks for noticing that - it probably would have caused me a few headaches down the road.
 

Ari64

New member
So Android is broken. The Linux documentation says that cacheflush is only guaranteed to be available on MIPS, so that isn't a good solution in general. Also you're supposed to specify ICACHE, DCACHE, or BCACHE as the third argument.

__clear_cache is a kernel call, so it's possible to write it as such:
Code:
__clear_cache:
        push    {r7, lr}
        mov     r2, #0
        mov     r7, #0x2
        add     r7, r7, #0xf0000
        svc     0x00000000
        pop     {r7, pc}
I guess you could put that in linkage_arm.S. Might need to rename it to avoid a conflict when linking.

The dynarec definitely will not work without flushing the cache.
 
Last edited:
OP
paulscode

paulscode

New member
Nice, thanks for the help. I just stuck it at the very bottom of linkage_arm.S like so:
Code:
breakpoint:
	/* Set breakpoint here for debugging */
	mov	pc, lr
	.size	breakpoint, .-breakpoint
/*  The following bug-fix implements __clear_cache (missing in Android)  */
	.align	2
	.global	__clear_cache_bugfix
	.type	__clear_cache_bugfix, %function
__clear_cache_bugfix:
	push    {r7, lr}
	mov     r2, #0
	mov     r7, #0x2
	add     r7, r7, #0xf0000
	svc     0x00000000
	pop     {r7, pc}
	.size	__clear_cache_bugfix, .-__clear_cache_bugfix
/*  End of bug-fix	*/
	.section	.note.GNU-stack,"",%progbits
And then at the top of new_dynarec.c:
Code:
// bug-fix to implement __clear_cache (missing in Android):
void __clear_cache_bugfix(char* begin, char *end);
#ifdef ANDROID
	#define __clear_cache __clear_cache_bugfix
#endif
 
OP
paulscode

paulscode

New member
a possible next step would be to uncomment the code at the bottom of store_assemble, which will call memdebug() for every memory write and produce a rather lengthy debugging log.
I did try uncommenting this block of code, but the log seems to be identical (although scanning through 668.7 MB of text I could have overlooked something). I'm thinking this might be an indication of where the problem could be. I'm looking at this more closely to see if I missed something here.
 

Ari64

New member
I did try uncommenting this block of code, but the log seems to be identical (although scanning through 668.7 MB of text I could have overlooked something). I'm thinking this might be an indication of where the problem could be. I'm looking at this more closely to see if I missed something here.

So I take it there was no improvement after fixing the clear cache issue?

With that code uncommented, it will call memdebug(). You'll have to add some logging there. Generally I log the cycle count and a checksum of RAM, then add other things depending on what I'm looking for. It can output a lot of stuff, so usually I'll limit the logging based on the cycle count.

I'm not quite sure what it is that's going wrong here, other than some writes to memory are not happening. So basically, you'd want to compare with a log from known-good version, and see where they differ.
 

Ari64

New member
BTW there is no cacheflush function in the standard Linux libraries on ARM, so it looks like Google added this to the Android libraries. If you try to call cacheflush on a standard Linux distro, you'll get a linker error when compiling.

The syscall will work as long as the Linux kernel isn't broken. (The bug report that you linked indicates the toolchain is broken, not the kernel, so this should work.)
 
OP
paulscode

paulscode

New member
Interesting. I'll try plugging your function into Yongzh's code to test and make sure it works on Android.

My next plan is to upgrade his core to the current dynarec version, so its a closer match to use for comparing the log output to help track down what's wrong with my code.
 
OP
paulscode

paulscode

New member
Getting closer.. the core is functioning properly, and executing the first instructions of the ROM now. Gets to where it initializes the video plug-in before it crashes. From the output, it appears that I need to fix a setenv call somewhere for gles2n64 to work. I'm working on tracking that down now.

Here are the relevant parts of the latest logcat output, for anyone interested in that sort of thing:
Code:
07-27 18:06:34.546: VERBOSE/SDL(7228): pixel format unknown -1
07-27 18:06:34.554: INFO/ActivityManager(1259): Displayed activity paulscode.android.mupen64plus/.SDLActivity: 956 ms (total 956 ms)
07-27 18:06:34.593: INFO/SDL(7228): SDL_Android_Init()
07-27 18:06:34.593: VERBOSE/front_end(7228): Attempting to change directory to /mnt/sdcard/app-data/paulscode.android.mupen64plus/
07-27 18:06:34.608: VERBOSE/front_end(7228):  __  __                         __   _  _   ____  _             
07-27 18:06:34.608: VERBOSE/front_end(7228): |  \/  |_   _ _ __   ___ _ __  / /_ | || | |  _ \| |_   _ ___ 
07-27 18:06:34.608: VERBOSE/front_end(7228): | |\/| | | | | '_ \ / _ \ '_ \| '_ \| || |_| |_) | | | | / __|  
07-27 18:06:34.608: VERBOSE/front_end(7228): | |  | | |_| | |_) |  __/ | | | (_) |__   _|  __/| | |_| \__ \  
07-27 18:06:34.608: VERBOSE/front_end(7228): |_|  |_|\__,_| .__/ \___|_| |_|\___/   |_| |_|   |_|\__,_|___/  
07-27 18:06:34.608: VERBOSE/front_end(7228):              |_|         http://code.google.com/p/mupen64plus/  
07-27 18:06:34.608: VERBOSE/front_end(7228): Mupen64Plus Console User-Interface Version 1.99.4
07-27 18:06:34.608: VERBOSE/core_interface(7228): UI-console: attached to core library 'Mupen64Plus Core' version 1.99.4
07-27 18:06:34.608: VERBOSE/core_interface(7228):             Includes support for Dynamic Recompiler.
07-27 18:06:34.608: VERBOSE/core(7228): The current working directory is /mnt/sdcard/app-data/paulscode.android.mupen64plus
07-27 18:06:34.608: VERBOSE/core(7228):     envpath was null or length < 1
07-27 18:06:37.030: VERBOSE/front_end(7228): Core: Goodname: Super Mario 64 (U) [!]
07-27 18:06:37.030: VERBOSE/front_end(7228): Core: Name: SUPER MARIO 64
07-27 18:06:37.030: VERBOSE/front_end(7228): Core: MD5: 20B854B239203BAF6C961B850A4A51A2
07-27 18:06:37.030: VERBOSE/front_end(7228): Core: CRC: ff2b5a63 2623028b
07-27 18:06:37.030: VERBOSE/front_end(7228): Core: Imagetype: .v64 (byteswapped)
07-27 18:06:37.030: VERBOSE/front_end(7228): Core: Rom size: 8388608 bytes (or 8 Mb or 64 Megabits)
07-27 18:06:37.030: VERBOSE/front_end(7228): Core: Version: 44140000
07-27 18:06:37.030: VERBOSE/front_end(7228): Core: Manufacturer: 4e000000
07-27 18:06:37.030: VERBOSE/front_end(7228): Core: Country: USA
07-27 18:06:37.038: VERBOSE/cheat(7228): UI-Console: Cheat codes disabled.
07-27 18:06:37.038: VERBOSE/front-end(7228): UI-console: using Video plugin: 'gles2n64' v0.0.5
07-27 18:06:37.038: VERBOSE/front-end(7228): UI-console: using Audio plugin: 'Mupen64Plus SDL Audio Plugin' v1.99.4
07-27 18:06:37.046: VERBOSE/front_end(7228): Input: No auto-configuration found for device 'Android accelerometer'
07-27 18:06:37.046: VERBOSE/front_end(7228): Input: N64 Controller #1: Forcing default keyboard configuration
07-27 18:06:37.046: VERBOSE/front_end(7228): Input: Using auto-configuration for device 'Keyboard'
07-27 18:06:37.046: VERBOSE/front-end(7228): UI-console: using Input plugin: 'Mupen64Plus SDL Input Plugin' v1.99.4
07-27 18:06:37.046: VERBOSE/front-end(7228): UI-console: using RSP plugin: 'Hacktarux/Azimer High-Level Emulation RSP Plugin' v1.99.4
07-27 18:06:37.046: DEBUG/gles2n64(7228): [gles2n64]: Loading Config from data/gles2n64.conf 
07-27 18:06:37.054: DEBUG/gles2n64(7228): Rom is NTSC
07-27 18:06:37.054: DEBUG/gles2n64(7228): [gles2N64]: Searching data/gles2n64rom.conf Database for "SUPER MARIO 64" ROM
07-27 18:06:37.054: VERBOSE/front_end(7228): Input: N64 Controller #1: Using keyboard/mouse
07-27 18:06:37.054: VERBOSE/front_end(7228): Input: 1 controller(s) found, 1 plugged in and usable in the emulator
07-27 18:06:37.054: VERBOSE/front_end(7228): Input: Mupen64Plus SDL Input Plugin version 1.99.4 initialized.
07-27 18:06:37.054: VERBOSE/frontend(7228): Running plugin_check()
07-27 18:06:37.054: VERBOSE/frontend(7228): Running main_run()
07-27 18:06:37.054: VERBOSE/core(7228):   Inside main_run
07-27 18:06:37.327: VERBOSE/front_end(7228): Audio: Initializing SDL audio subsystem...
07-27 18:06:37.327: VERBOSE/SDL(7228): SDL audio: opening device
07-27 18:06:37.327: VERBOSE/SDL(7228): SDL audio: wanted stereo 16-bit 44.1kHz, 2048 frames buffer
07-27 18:06:37.343: DEBUG/AudioHardwareMot(1157): Output bufSize from kernel = 8192
07-27 18:06:37.343: VERBOSE/SDL(7228): SDL audio: got stereo 16-bit 44.1kHz, 4096 frames buffer
07-27 18:06:37.350: VERBOSE/core(7228):     Calling r4300 CPU core and running the game
07-27 18:06:37.390: DEBUG/AudioHardwareMot(1157): AudioStreamOut::wake: disabling SRC
07-27 18:06:37.398: DEBUG/AudioHardwareMot(1157): Output 0x123e0 exiting standby
07-27 18:06:37.468: VERBOSE/core(7228): RUNNING r4300_execute!!!
07-27 18:06:37.468: VERBOSE/front_end(7228): Core: Starting R4300 emulator: Dynamic Recompiler
07-27 18:06:37.608: VERBOSE/ANDROID(7228):     Yes, ANDROID was defined (just checking)
07-27 18:06:37.811: VERBOSE/commented_message(7228): notcompiledCount=1
07-27 18:06:37.835: VERBOSE/commented_message(7228): notcompiledCount=2
..
07-27 18:06:38.686: VERBOSE/commented_message(7228): notcompiledCount=87
07-27 18:06:38.686: VERBOSE/commented_message(7228): notcompiledCount=88
07-27 18:06:38.749: VERBOSE/SDL(7228): SDL audio: opening device
07-27 18:06:38.749: VERBOSE/SDL(7228): SDL audio: wanted stereo 16-bit 44.1kHz, 2048 frames buffer
07-27 18:06:38.757: VERBOSE/SDL(7228): SDL audio: got stereo 16-bit 44.1kHz, 4096 frames buffer
07-27 18:06:38.757: VERBOSE/commented_message(7228): notcompiledCount=89
07-27 18:06:38.765: VERBOSE/commented_message(7228): notcompiledCount=90
...
07-27 18:06:38.975: VERBOSE/commented_message(7228): notcompiledCount=124
07-27 18:06:38.975: VERBOSE/commented_message(7228): notcompiledCount=125
07-27 18:06:38.975: DEBUG/AudioHardwareMot(1157): AudioStreamOutMot::setParameters() fm_attenuate=0;fm_mute=0
07-27 18:06:38.975: VERBOSE/commented_message(7228): notcompiledCount=126
07-27 18:06:38.975: VERBOSE/commented_message(7228): notcompiledCount=127
...
07-27 18:06:39.421: VERBOSE/commented_message(7228): notcompiledCount=170
07-27 18:06:39.429: VERBOSE/commented_message(7228): notcompiledCount=171
07-27 18:06:39.452: VERBOSE/core(7228):     envpath was null or length < 1
07-27 18:06:39.460: VERBOSE/core(7228):     envpath was null or length < 1
...
07-27 18:06:40.054: VERBOSE/core(7228):     envpath was null or length < 1
07-27 18:06:40.054: VERBOSE/core(7228):     envpath was null or length < 1
07-27 18:06:40.054: VERBOSE/commented_message(7228): notcompiledCount=172
07-27 18:06:40.061: VERBOSE/commented_message(7228): notcompiledCount=173
...
07-27 18:06:40.311: VERBOSE/commented_message(7228): notcompiledCount=211
07-27 18:06:40.311: VERBOSE/commented_message(7228): notcompiledCount=212
07-27 18:06:40.319: DEBUG/gles2n64(7228): UCODE CRC=0xffffffff
07-27 18:06:40.319: VERBOSE/commented_message(7228): notcompiledCount=213
07-27 18:06:40.327: VERBOSE/commented_message(7228): notcompiledCount=214
07-27 18:06:40.327: VERBOSE/commented_message(7228): notcompiledCount=215
07-27 18:06:40.335: VERBOSE/commented_message(7228): notcompiledCount=216
07-27 18:06:40.335: VERBOSE/commented_message(7228): notcompiledCount=217
07-27 18:06:40.343: INFO/DEBUG(6198): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
07-27 18:06:40.343: INFO/DEBUG(6198): Build fingerprint: 'verizon/shadow_vzw/cdma_shadow/shadow:2.2.1/VZW/23.340:user/ota-rel-keys,release-keys'
07-27 18:06:40.343: INFO/DEBUG(6198): pid: 7228, tid: 7236  >>> paulscode.android.mupen64plus <<<
07-27 18:06:40.343: INFO/DEBUG(6198): signal 11 (SIGSEGV), fault addr c107b056
07-27 18:06:40.343: INFO/DEBUG(6198):  r0 8107af72  r1 47e359e4  r2 c107af72  r3 7a3cb9e0
07-27 18:06:40.350: INFO/DEBUG(6198):  r4 8107af72  r5 000000f0  r6 00000000  r7 ffffffff
07-27 18:06:40.350: INFO/DEBUG(6198):  r8 81205c10  r9 00000000  10 fff98efa  fp 8a409000
07-27 18:06:40.350: INFO/DEBUG(6198):  ip 81205c60  sp 47e358f0  lr 81201697  pc 8120149c  cpsr 80000070
07-27 18:06:40.350: INFO/DEBUG(6198):  d0  643a64696f72646e  d1  6472656767756265
07-27 18:06:40.350: INFO/DEBUG(6198):  d2  8fbf001400000000  d3  03e0000827bd0000
07-27 18:06:40.350: INFO/DEBUG(6198):  d4  0c0c8b088f040040  d5  0c09f9488f050044
07-27 18:06:40.350: INFO/DEBUG(6198):  d6  3c08803324040002  d7  241900048d08d570
07-27 18:06:40.350: INFO/DEBUG(6198):  d8  00000000080b03f7  d9  0000000000000000
07-27 18:06:40.350: INFO/DEBUG(6198):  d10 0000000000000000  d11 0000000000000000
07-27 18:06:40.350: INFO/DEBUG(6198):  d12 0000000000000000  d13 0000000000000000
07-27 18:06:40.350: INFO/DEBUG(6198):  d14 0000000000000000  d15 0000000000000000
07-27 18:06:40.350: INFO/DEBUG(6198):  d16 002bd03045934e20  d17 7e37e43c8800759c
07-27 18:06:40.350: INFO/DEBUG(6198):  d18 0000000000000000  d19 0000000000000000
07-27 18:06:40.350: INFO/DEBUG(6198):  d20 3ff0000000000000  d21 8000000000000000
07-27 18:06:40.350: INFO/DEBUG(6198):  d22 0000000000000000  d23 ff00030003000300
07-27 18:06:40.350: INFO/DEBUG(6198):  d24 ff00030003000300  d25 ff00030003000300
07-27 18:06:40.350: INFO/DEBUG(6198):  d26 0100010001000100  d27 0100010001000100
07-27 18:06:40.350: INFO/DEBUG(6198):  d28 0100010001000100  d29 3ff0000000000000
07-27 18:06:40.350: INFO/DEBUG(6198):  d30 0000000000000000  d31 3ff0000000000000
07-27 18:06:40.350: INFO/DEBUG(6198):  scr 60000012
07-27 18:06:40.514: INFO/DEBUG(6198):          #00  pc 0000149c  /data/data/paulscode.android.mupen64plus/lib/libinput-sdl.so
07-27 18:06:40.514: INFO/DEBUG(6198):          #01  pc 00001692  /data/data/paulscode.android.mupen64plus/lib/libinput-sdl.so
07-27 18:06:40.522: INFO/DEBUG(6198):          #02  pc 000335b4  /data/data/paulscode.android.mupen64plus/lib/libcore.so
07-27 18:06:40.522: INFO/DEBUG(6198):          #03  pc 00034978  /data/data/paulscode.android.mupen64plus/lib/libcore.so
07-27 18:06:40.522: INFO/DEBUG(6198):          #04  pc 00021d88  /data/data/paulscode.android.mupen64plus/lib/libcore.so
07-27 18:06:40.522: INFO/DEBUG(6198):          #05  pc 00031804  /data/data/paulscode.android.mupen64plus/lib/libcore.so
07-27 18:06:40.522: INFO/DEBUG(6198): code around pc:
07-27 18:06:40.530: INFO/DEBUG(6198): 8120147c 185b447b 4770731a 000048ac 4ff0e92d 
07-27 18:06:40.530: INFO/DEBUG(6198): 8120148c 4280f100 f8dfb089 4604816c 44f89204 
07-27 18:06:40.530: INFO/DEBUG(6198): 8120149c 30e4f892 bf0c2b00 23282350 f2409303 
07-27 18:06:40.530: INFO/DEBUG(6198): 812014ac f2c403e5 5cc30300 9b03b113 93033b14 
07-27 18:06:40.530: INFO/DEBUG(6198): 812014bc 9144f8df 4e512700 f8584a51 447e5009 
07-27 18:06:40.530: INFO/DEBUG(6198): code around lr:
07-27 18:06:40.530: INFO/DEBUG(6198): 81201674 f8df4606 447c04a8 f8dfb09f 582354a4 
07-27 18:06:40.530: INFO/DEBUG(6198): 81201684 20009008 681b910a f7ff931d f7ffee00 
07-27 18:06:40.530: INFO/DEBUG(6198): 81201694 f8dffef9 44780490 f7ff300c f7fffef3 
07-27 18:06:40.538: INFO/DEBUG(6198): 812016a4 00b1ee80 eb015967 91040a06 17caeb07 
07-27 18:06:40.538: INFO/DEBUG(6198): 812016b4 f8d79707 2b003260 808af2c0 2468f8df 
07-27 18:06:40.538: INFO/DEBUG(6198): stack:
07-27 18:06:40.538: INFO/DEBUG(6198):     47e358b0  80330000  /system/lib/libicudata.so
07-27 18:06:40.538: INFO/DEBUG(6198):     47e358b4  ffffffff  
07-27 18:06:40.538: INFO/DEBUG(6198):     47e358b8  00000004  
07-27 18:06:40.546: INFO/DEBUG(6198):     47e358bc  00000000  
07-27 18:06:40.546: INFO/DEBUG(6198):     47e358c0  80330000  /system/lib/libicudata.so
07-27 18:06:40.546: INFO/DEBUG(6198):     47e358c4  ffffffff  
07-27 18:06:40.546: INFO/DEBUG(6198):     47e358c8  afd4376c  /system/lib/libc.so
07-27 18:06:40.546: INFO/DEBUG(6198):     47e358cc  0000001b  
07-27 18:06:40.546: INFO/DEBUG(6198):     47e358d0  00000002  
07-27 18:06:40.546: INFO/DEBUG(6198):     47e358d4  00000000  
07-27 18:06:40.546: INFO/DEBUG(6198):     47e358d8  00000002  
07-27 18:06:40.546: INFO/DEBUG(6198):     47e358dc  00000001  
07-27 18:06:40.546: INFO/DEBUG(6198):     47e358e0  80330000  /system/lib/libicudata.so
07-27 18:06:40.546: INFO/DEBUG(6198):     47e358e4  ffffffff  
07-27 18:06:40.546: INFO/DEBUG(6198):     47e358e8  df002777  
07-27 18:06:40.554: INFO/DEBUG(6198):     47e358ec  e3a070ad  
07-27 18:06:40.554: INFO/DEBUG(6198): #00 47e358f0  02a832d0  
07-27 18:06:40.554: INFO/DEBUG(6198):     47e358f4  ffffffff  
07-27 18:06:40.554: INFO/DEBUG(6198):     47e358f8  1fffffff  
07-27 18:06:40.554: INFO/DEBUG(6198):     47e358fc  ff24ffff  
07-27 18:06:40.554: INFO/DEBUG(6198):     47e35900  c107af72  
07-27 18:06:40.554: INFO/DEBUG(6198):     47e35904  7a3cb9e0  
07-27 18:06:40.554: INFO/DEBUG(6198):     47e35908  88498788  
07-27 18:06:40.554: INFO/DEBUG(6198):     47e3590c  80246abc  /system/lib/libicudata.so
07-27 18:06:40.554: INFO/DEBUG(6198):     47e35910  80202dc8  /system/lib/libicudata.so
07-27 18:06:40.554: INFO/DEBUG(6198):     47e35914  81205c10  /data/data/paulscode.android.mupen64plus/lib/libinput-sdl.so
07-27 18:06:40.561: INFO/DEBUG(6198):     47e35918  000000f0  
07-27 18:06:40.561: INFO/DEBUG(6198):     47e3591c  00000000  
07-27 18:06:40.561: INFO/DEBUG(6198):     47e35920  ffffffff  
07-27 18:06:40.561: INFO/DEBUG(6198):     47e35924  884a481c  
07-27 18:06:40.561: INFO/DEBUG(6198):     47e35928  00000000  
07-27 18:06:40.561: INFO/DEBUG(6198):     47e3592c  fff98efa  
07-27 18:06:40.561: INFO/DEBUG(6198):     47e35930  8a409000  
07-27 18:06:40.561: INFO/DEBUG(6198):     47e35934  81201697  /data/data/paulscode.android.mupen64plus/lib/libinput-sdl.so
07-27 18:06:40.561: INFO/DEBUG(6198): #01 47e35938  a2000103  
07-27 18:06:40.561: INFO/DEBUG(6198):     47e3593c  00000000  
07-27 18:06:40.561: INFO/DEBUG(6198):     47e35940  a2000103  
07-27 18:06:40.561: INFO/DEBUG(6198):     47e35944  00000000  
07-27 18:06:40.561: INFO/DEBUG(6198):     47e35948  0000048f  
07-27 18:06:40.561: INFO/DEBUG(6198):     47e3594c  00000000  
07-27 18:06:40.561: INFO/DEBUG(6198):     47e35950  0000048f  
07-27 18:06:40.561: INFO/DEBUG(6198):     47e35954  00000000  
07-27 18:06:40.561: INFO/DEBUG(6198):     47e35958  000000d8  
07-27 18:06:40.561: INFO/DEBUG(6198):     47e3595c  00000000  
07-27 18:06:40.561: INFO/DEBUG(6198):     47e35960  47e359e4  
07-27 18:06:40.561: INFO/DEBUG(6198):     47e35964  00000000  
07-27 18:06:40.561: INFO/DEBUG(6198):     47e35968  00000000  
07-27 18:06:40.561: INFO/DEBUG(6198):     47e3596c  00000000  
07-27 18:06:40.561: INFO/DEBUG(6198):     47e35970  80330000  /system/lib/libicudata.so
07-27 18:06:40.561: INFO/DEBUG(6198):     47e35974  ffffffff  
07-27 18:06:40.561: INFO/DEBUG(6198):     47e35978  00000004  
07-27 18:06:40.561: INFO/DEBUG(6198):     47e3597c  00000000  
07-27 18:06:40.561: INFO/DEBUG(6198):     47e35980  00000000  
07-27 18:06:40.561: INFO/DEBUG(6198):     47e35984  afd102d0  /system/lib/libc.so
07-27 18:06:40.561: INFO/DEBUG(6198):     47e35988  afd4376c  /system/lib/libc.so
07-27 18:06:40.561: INFO/DEBUG(6198):     47e3598c  afd437a0  /system/lib/libc.so
07-27 18:06:40.561: INFO/DEBUG(6198):     47e35990  002bcdd8  [heap]
07-27 18:06:40.561: INFO/DEBUG(6198):     47e35994  ffffffff  
07-27 18:06:40.561: INFO/DEBUG(6198):     47e35998  00000000  
07-27 18:06:40.577: INFO/DEBUG(6198):     47e3599c  afd102d0  /system/lib/libc.so
07-27 18:06:40.577: INFO/DEBUG(6198):     47e359a0  afd4376c  /system/lib/libc.so
07-27 18:06:40.577: INFO/DEBUG(6198):     47e359a4  00000004  
07-27 18:06:40.577: INFO/DEBUG(6198):     47e359a8  00000001  
07-27 18:06:40.577: INFO/DEBUG(6198):     47e359ac  7a3cb9e0  
07-27 18:06:40.577: INFO/DEBUG(6198):     47e359b0  00000000  
07-27 18:06:40.577: INFO/DEBUG(6198):     47e359b4  880f6a4c  /data/data/paulscode.android.mupen64plus/lib/libcore.so
07-27 18:06:40.577: INFO/DEBUG(6198):     47e359b8  8be0d328  
07-27 18:06:40.577: INFO/DEBUG(6198):     47e359bc  80367050  /system/lib/libicudata.so
07-27 18:06:40.577: INFO/DEBUG(6198):     47e359c0  ffffffff  
07-27 18:06:40.577: INFO/DEBUG(6198):     47e359c4  884a481c  
07-27 18:06:40.577: INFO/DEBUG(6198):     47e359c8  00000000  
07-27 18:06:40.577: INFO/DEBUG(6198):     47e359cc  fff98efa  
07-27 18:06:40.577: INFO/DEBUG(6198):     47e359d0  8a409000  
07-27 18:06:40.577: INFO/DEBUG(6198):     47e359d4  880335b8  /data/data/paulscode.android.mupen64plus/lib/libcore.so
07-27 18:06:40.874: INFO/BootReceiver(1259): Copying /data/tombstones/tombstone_04 to DropBox (SYSTEM_TOMBSTONE)
07-27 18:06:40.905: DEBUG/Zygote(1156): Process 7228 terminated by signal (11)
07-27 18:06:41.015: DEBUG/dalvikvm(1259): GC_FOR_MALLOC freed 13877 objects / 1051520 bytes in 136ms
07-27 18:06:41.015: INFO/ActivityManager(1259): Process paulscode.android.mupen64plus (pid 7228) has died.

I addition to the obvious problem near the end around the time when the video plug-in starts up, you'll also notice a couple of other potential problem spots in there, which I'll highlight quickly. These will most likely be the next few bugs I'll have to work out before the app will be functional:

Code:
07-27 18:06:34.546: VERBOSE/SDL(7228): pixel format unknown -1
This could potentially be the initial indication that there was going to be a problem with the video. I'll have to look into this more closely.

Code:
07-27 18:06:33.843: ERROR/dalvikvm(7228): could not disable core file generation for pid 7228, errno=1
I have no idea what this means (I'll have to do some googling). It doesn't seem to prevent the app from continuing, but until I know what it means, I can't say for sure that it won't cause problems down the road.

Code:
07-27 18:06:34.608: VERBOSE/core(7228):     envpath was null or length < 1
This is the one that prints out right before the ROM is loaded. Not sure which setenv is missing, so I'll have to track it down to make sure it isn't something important.

Code:
07-27 18:06:37.327: VERBOSE/front_end(7228): Audio: Initializing SDL audio subsystem...
07-27 18:06:37.327: VERBOSE/SDL(7228): SDL audio: opening device
07-27 18:06:37.327: VERBOSE/SDL(7228): SDL audio: wanted stereo 16-bit 44.1kHz, 2048 frames buffer
07-27 18:06:37.343: DEBUG/AudioHardwareMot(1157): Output bufSize from kernel = 8192
07-27 18:06:37.343: VERBOSE/SDL(7228): SDL audio: got stereo 16-bit 44.1kHz, 4096 frames buffer
...
07-27 18:06:38.749: VERBOSE/SDL(7228): SDL audio: opening device
07-27 18:06:38.749: VERBOSE/SDL(7228): SDL audio: wanted stereo 16-bit 44.1kHz, 2048 frames buffer
07-27 18:06:38.757: VERBOSE/SDL(7228): SDL audio: got stereo 16-bit 44.1kHz, 4096 frames buffer
With the frames the wrong size, this could result in the audio being the wrong pitch. Also, I'm not sure why it is opening the audio device twice. This doesn't seem to prevent the app from continuing, but it might be a potential problem down the road.
 
OP
paulscode

paulscode

New member
"It's a-me, Mario!"

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, so my earlier worries about the pitch were unfounded. All the main components are not finished yet - the crash from my last post was actually caused by the input plug-in (I shouldn't have been surprised since I 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..
 
OP
paulscode

paulscode

New member
I've made a little more progress toward solving the video plug-in problem. I had the idea of looking at Lachlan's gles2n64 port, which, unlike Yongzh's, still uses SDL. Unfortunately, the code from this port is not just plug-and-play into an Android project, because it makes use of EGL. Native EGL was not available on Android versions prior to 2.3, and I'd rather not limit my project to only devices running Android 2.3 and later. At least this points me in the right direction. Now I just have to figure out how to do the equivalent without using EGL (or by interfacing with it from Java through some JNI magic)...
 
OP
paulscode

paulscode

New member
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.
 
OP
paulscode

paulscode

New member
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:

Plug-in Test A (source code)

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 processors
3) 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).

Known issues on my phone (Motorola Droid X, Android 2.3.3, rooted):
1) Layout switching problem after the data downloader finishes on the first run. Results in video disappearing, app restarting, and black-screen. Work-around: force-close the app and restart it (not until after the data is finished downloading though!)
2) Polygon sort-order problem (3D splash is missing pieces, Mario's face looks jumbly, Bowser's arms show through his body).
3) Scene transitions are choppy (audio cuts out, frame-rate stalls momentarily).
4) Crash after Bowser breaths fire (app usually restarts once then force-closes; sometimes enters restart loop, requiring manual force-close; sometimes freezes the phone, requiring battery to be removed, sometimes reboots the phone)

Feel free to post results here, PM me, or email (whichever works). Thanks in advance!

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 Android developers who happen to be reading this 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)
 
OP
paulscode

paulscode

New member
Anyone who was having a problem with the app immediately crashing, please give the latest build a try:

Test APK (source code)

I'm pretty sure that will fix the immediate crash problem, but if it still doesn't work, then please send me your logcat output.
 
OP
paulscode

paulscode

New member
Today's Update:
- Mapped common Android buttons to recognizable SDL scancodes
- SDL scancodes printing to logcat when keys are pressed (for input config)
- Shutting app down smoothly when user presses "Home" to leave

Test APK (source code)
 

Top