Porting Mupen64Plus to Android

paulscode · Jan 20, 2011

Debug messages are a bit of a problem, because unfortunately there is no "printf" function in Android (it compiles, but is equivalent to using "nullf"). I thought I had this covered by putting the following at the top of new_dynarec.c (this should also cover any messages generated in assem_arm.c, since that is #include'ed in new_dynarec.c):

Code:

#include <android/log.h>
#define printf(...) __android_log_print(ANDROID_LOG_VERBOSE, "new_dynarec", __VA_ARGS__)
#define assem_debug(...) __android_log_print(ANDROID_LOG_DEBUG, "assem_debug", __VA_ARGS__)
#define inv_debug(...) __android_log_print(ANDROID_LOG_DEBUG, "inv_debug", __VA_ARGS__)

This seems to cover most of the debug messages, but apparently not all of them. I'll look at this more closely. Are there any other functions besides printf(), assem_debug(), and inv_debug() being used to print messages? Could any of the missing messages be generated in other files besides new_dynarec.c and assem_arm.c? If so, I'll have to #define printf in a few other places as well, probably.

paulscode · Jan 21, 2011

I've looked at new_dynarec.c and assem_arm.c more closely, but I really don't see any other ways that messages are being generated. It seems to me that regardless of what itype is, something should print out since there is a "default:" in that switch statement. This must mean that "disassemble_inst(int i)" is not being called for every "i", right? But looking at the code, I do not see how that can be, since "i" is iterated in a for loop like such: "for(i=0;i<slen;i++)" ?! Am I interpreting the code incorrectly? Is there some way that sections of instructions could be skipped or done out of order? If the latter is the case, is it possible that the crash occurs before the instructions are printed (i.e. does it print the instructions after using them or before?)

In any case, I'm going to add in more log messages to try and pinpoint more accurately where the crash is happening.

Ari64 · Jan 21, 2011

Try using fprintf and logging to a file.

paulscode · Jan 21, 2011

BTW, I should also point out a couple of changes I made to your code which I don't think would affect the behavior, but knowing me I probably better check. They are a result of the fact that the NDK has no clue what to do with the following (because of the whole missing printf issue):

Code:

if((void*)assem_debug==(void*)printf)

To fix this problem, I made the following changes:

Code:

#define ASSEM_DEBUG 1
#define INV_DEBUG 1

void nullf() {}
#if defined( ASSEM_DEBUG )
    #define assem_debug(...) __android_log_print(ANDROID_LOG_DEBUG, "assem_debug", __VA_ARGS__)
#else
    #define assem_debug nullf
#endif
#if defined( INV_DEBUG )
    #define inv_debug(...) __android_log_print(ANDROID_LOG_DEBUG, "inv_debug", __VA_ARGS__)
#else
    #define inv_debug nullf
#endif

Code:

//  if((void*)assem_debug==(void*)printf)
#if defined( ASSEM_DEBUG )
  for(i=0;i<slen;i++)
  {
...
  }
#endif

Code:

//    if((void*)assem_debug==(void*)printf) disassemble_inst(i);
#if defined( ASSEM_DEBUG )
    disassemble_inst(i);
#endif

Ari64 · Jan 21, 2011

paulscode said:
Code:

if((void*)assem_debug==(void*)printf)

That was just a way to call disassemble_inst() when debugging is enabled. Of course, it doesn't work if you're not using printf. What you did is fine.

paulscode · Jan 21, 2011

Ari64 said:
Try using fprintf and logging to a file.

Yep, that did the trick (so I guess that stupid "__android_log_print" function just drops messages sometimes... seriously?! It's bad enough that there isn't a printf function! ) I had a little trouble getting this to work, since the program is crashing before I can fclose the file (thus resulting in an empty file). I fixed this by opening the file in append mode, and then closing it after each fprintf.

I should be able to write a function that does an fopen + fprintf + fclose, and use that in a macro for printf(), assem_debug(), and inv_debug(). I'll post the results tomorrow after I have time to do that. Thanks for the help!

paulscode · Jan 21, 2011

Actually, that was a lot faster to put together than I thought it would be (I remembered about vfprintf, which greatly simplifies things).

I've uploaded the output HERE.

And here is the rest is in the normal logcat output which shows the crash messages:

Code:

01-20 23:15:20.177: INFO/System.out(3302): libSDL: setting envvar LANGUAGE to 'en_US'
01-20 23:15:20.177: INFO/System.out(3302): libSDL: accelerometer start required: false
01-20 23:15:20.177: INFO/libSDL(3302): Calling SDL_main("mupen64plus roms/mario.n64")
01-20 23:15:20.177: INFO/libSDL(3302): param 0 = "mupen64plus"
01-20 23:15:20.177: INFO/libSDL(3302): param 1 = "roms/mario.n64"
01-20 23:15:20.177: VERBOSE/front_end(3302):  __  __                         __   _  _   ____  _             
01-20 23:15:20.177: VERBOSE/front_end(3302): |  \/  |_   _ _ __   ___ _ __  / /_ | || | |  _ \| |_   _ ___ 
01-20 23:15:20.177: VERBOSE/front_end(3302): | |\/| | | | | '_ \ / _ \ '_ \| '_ \| || |_| |_) | | | | / __|  
01-20 23:15:20.177: VERBOSE/front_end(3302): | |  | | |_| | |_) |  __/ | | | (_) |__   _|  __/| | |_| \__ \  
01-20 23:15:20.177: VERBOSE/front_end(3302): |_|  |_|\__,_| .__/ \___|_| |_|\___/   |_| |_|   |_|\__,_|___/  
01-20 23:15:20.177: VERBOSE/front_end(3302):              |_|         http://code.google.com/p/mupen64plus/  
01-20 23:15:20.177: VERBOSE/front_end(3302): Mupen64Plus Console User-Interface Version 1.99.4
01-20 23:15:20.177: VERBOSE/core_interface(3302): UI-console: attached to core library 'Mupen64Plus Core' version 1.99.4
01-20 23:15:20.177: VERBOSE/core_interface(3302):             Includes support for Dynamic Recompiler.
01-20 23:15:20.395: VERBOSE/front_end(3302): Core: Goodname: Super Mario 64 (U) [!]
01-20 23:15:20.395: VERBOSE/front_end(3302): Core: Name: SUPER MARIO 64
01-20 23:15:20.395: VERBOSE/front_end(3302): Core: MD5: 20B854B239203BAF6C961B850A4A51A2
01-20 23:15:20.395: VERBOSE/front_end(3302): Core: CRC: 635a2bff 8b022326
01-20 23:15:20.395: VERBOSE/front_end(3302): Core: Imagetype: .v64 (byteswapped)
01-20 23:15:20.395: VERBOSE/front_end(3302): Core: Rom size: 8388608 bytes (or 8 Mb or 64 Megabits)
01-20 23:15:20.395: VERBOSE/front_end(3302): Core: Version: 1444
01-20 23:15:20.395: VERBOSE/front_end(3302): Core: Manufacturer: Nintendo
01-20 23:15:20.395: VERBOSE/front_end(3302): Core: Country: USA
01-20 23:15:20.403: VERBOSE/cheat(3302): UI-Console: Cheat codes disabled.
01-20 23:15:20.403: VERBOSE/front-end(3302): UI-console: using Video plugin: <dummy>
01-20 23:15:20.403: VERBOSE/front-end(3302): UI-console: using Audio plugin: 'Mupen64Plus SDL Audio Plugin' v1.99.4
01-20 23:15:20.403: VERBOSE/front-end(3302): UI-console: using Input plugin: <dummy>
01-20 23:15:20.403: VERBOSE/front-end(3302): UI-console: using RSP plugin: 'Hacktarux/Azimer High-Level Emulation RSP Plugin' v1.99.4
01-20 23:15:20.403: VERBOSE/core(3302): Running plugin_check()
01-20 23:15:20.403: VERBOSE/front_end(3302): Core Warning: No video plugin attached.  There will be no video output.
01-20 23:15:20.403: VERBOSE/front_end(3302): Core Warning: No input plugin attached.  You won't be able to control the game.
01-20 23:15:20.403: VERBOSE/core(3302): Running main_run()
01-20 23:15:20.403: VERBOSE/core(3302): inside main_run
01-20 23:15:20.403: VERBOSE/core(3302): inside init_memory
01-20 23:15:20.520: VERBOSE/front_end(3302): Audio: Initializing SDL audio subsystem...
01-20 23:15:20.520: INFO/libSDL(3302): ANDROIDAUD_OpenAudio(): app requested audio bytespersample 2 freq 44100 channels 2 samples 2048
01-20 23:15:20.528: DEBUG/AudioHardwareMot(1157): Output bufSize from kernel = 8192
01-20 23:15:20.536: INFO/libSDL(3302): ANDROIDAUD_OpenAudio(): app opened audio bytespersample 2 freq 44100 channels 2 bufsize 8192
01-20 23:15:20.536: VERBOSE/core(3302): Calling r4300 CPU core and running the game
01-20 23:15:20.552: VERBOSE/core(3302): RUNNING r4300_execute!!!
01-20 23:15:20.552: VERBOSE/front_end(3302): Core: Starting R4300 emulator: Dynamic Recompiler
01-20 23:15:20.575: DEBUG/AudioHardwareMot(1157): AudioStreamOut::wake: disabling SRC
01-20 23:15:20.583: DEBUG/AudioHardwareMot(1157): Output 0x123e0 exiting standby
01-20 23:15:21.575: INFO/DEBUG(1149): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
01-20 23:15:21.575: INFO/DEBUG(1149): Build fingerprint: 
    'verizon/shadow_vzw/cdma_shadow/shadow:2.2.1/VZW/23.340:user/ota-rel-keys,release-keys'
01-20 23:15:21.575: INFO/DEBUG(1149): pid: 3302, tid: 3311  >>> paulscode.android.mupen64plus <<<
01-20 23:15:21.575: INFO/DEBUG(1149): signal 11 (SIGSEGV), fault addr a4001fd4
01-20 23:15:21.575: INFO/DEBUG(1149):  r0 ffffffff  r1 00000000  r2 ffffffff  r3 00000000
01-20 23:15:21.575: INFO/DEBUG(1149):  r4 840a97e8  r5 a4001fd8  r6 00000b9c  r7 00000002
01-20 23:15:21.575: INFO/DEBUG(1149):  r8 00000000  r9 843baad0  10 ffffec86  fp 853bb000
01-20 23:15:21.575: INFO/DEBUG(1149):  ip 00001388  sp 47bb2a58  lr ffffec76  pc 843bb150  cpsr 40000010
01-20 23:15:21.575: INFO/DEBUG(1149):  d0  6472656767756265  d1  10000003ade80036
01-20 23:15:21.575: INFO/DEBUG(1149):  d2  035bd0243c1b0134  d3  0000000017400030
01-20 23:15:21.575: INFO/DEBUG(1149):  d4  0288a0203c080010  d5  ad88000024082000
01-20 23:15:21.575: INFO/DEBUG(1149):  d6  8dfa00008de90024  d7  ad88000024081000
01-20 23:15:21.575: INFO/DEBUG(1149):  d8  0000000000000000  d9  43e0000000000000
01-20 23:15:21.575: INFO/DEBUG(1149):  d10 41dfffffffc00000  d11 c3e0000000000000
01-20 23:15:21.575: INFO/DEBUG(1149):  d12 0000000000000000  d13 0000000000000000
01-20 23:15:21.575: INFO/DEBUG(1149):  d14 0000000000000000  d15 0000000000000000
01-20 23:15:21.575: INFO/DEBUG(1149):  d16 0000000700002000  d17 4059c00000000000
01-20 23:15:21.575: INFO/DEBUG(1149):  d18 0100010001000100  d19 0100010001000100
01-20 23:15:21.575: INFO/DEBUG(1149):  d20 003f003f003f003f  d21 003f003f003f003f
01-20 23:15:21.575: INFO/DEBUG(1149):  d22 0002000600030007  d23 0002000600030007
01-20 23:15:21.575: INFO/DEBUG(1149):  d24 0101010101010101  d25 0000000000000000
01-20 23:15:21.575: INFO/DEBUG(1149):  d26 0000000000000000  d27 0000000000000000
01-20 23:15:21.575: INFO/DEBUG(1149):  d28 0000000000000000  d29 0000000000000000
01-20 23:15:21.575: INFO/DEBUG(1149):  d30 001b001b001b001b  d31 001b001b001b001b
01-20 23:15:21.575: INFO/DEBUG(1149):  scr 60000012
01-20 23:15:21.622: INFO/DEBUG(1149):          #00  pc 843bb150  
01-20 23:15:21.622: INFO/DEBUG(1149):          #01  lr ffffec76  <unknown>
01-20 23:15:21.622: INFO/DEBUG(1149): code around pc:
01-20 23:15:21.622: INFO/DEBUG(1149): 843bb130 e59b5168 e59b3118 e2455018 e3a02f6b 
01-20 23:15:21.622: INFO/DEBUG(1149): 843bb140 e0822625 e79b2102 e3120000 1a0001d6 
01-20 23:15:21.622: INFO/DEBUG(1149): 843bb150 e7853102 e59b4120 e2850004 e3a02f6b 
01-20 23:15:21.622: INFO/DEBUG(1149): 843bb160 e0822620 e79b2102 e3120000 1a0001df 
01-20 23:15:21.622: INFO/DEBUG(1149): 843bb170 e7804102 e59b0128 e2851008 e3a02f6b 
01-20 23:15:21.622: INFO/DEBUG(1149): code around lr:
01-20 23:15:21.622: INFO/DEBUG(1149): ffffec54 ffffffff ffffffff ffffffff ffffffff 
01-20 23:15:21.622: INFO/DEBUG(1149): ffffec64 ffffffff ffffffff ffffffff ffffffff 
01-20 23:15:21.622: INFO/DEBUG(1149): ffffec74 ffffffff ffffffff ffffffff ffffffff 
01-20 23:15:21.622: INFO/DEBUG(1149): ffffec84 ffffffff ffffffff ffffffff ffffffff 
01-20 23:15:21.622: INFO/DEBUG(1149): ffffec94 ffffffff ffffffff ffffffff ffffffff 
01-20 23:15:21.622: INFO/DEBUG(1149): stack:
01-20 23:15:21.622: INFO/DEBUG(1149):     47bb2a18  853bb324  
01-20 23:15:21.622: INFO/DEBUG(1149):     47bb2a1c  00000002  
01-20 23:15:21.622: INFO/DEBUG(1149):     47bb2a20  00000000  
01-20 23:15:21.622: INFO/DEBUG(1149):     47bb2a24  843baad0  
01-20 23:15:21.622: INFO/DEBUG(1149):     47bb2a28  00000002  
01-20 23:15:21.622: INFO/DEBUG(1149):     47bb2a2c  8403d730  /data/data/paulscode.android.mupen64plus/lib/libcore.so
01-20 23:15:21.622: INFO/DEBUG(1149):     47bb2a30  de7d2323  
01-20 23:15:21.622: INFO/DEBUG(1149):     47bb2a34  840a97e8  /data/data/paulscode.android.mupen64plus/lib/libcore.so
01-20 23:15:21.622: INFO/DEBUG(1149):     47bb2a38  000008d0  
01-20 23:15:21.622: INFO/DEBUG(1149):     47bb2a3c  00000b9c  
01-20 23:15:21.622: INFO/DEBUG(1149):     47bb2a40  00000002  
01-20 23:15:21.622: INFO/DEBUG(1149):     47bb2a44  00000000  
01-20 23:15:21.622: INFO/DEBUG(1149):     47bb2a48  843baad0  
01-20 23:15:21.622: INFO/DEBUG(1149):     47bb2a4c  00000002  
01-20 23:15:21.622: INFO/DEBUG(1149):     47bb2a50  df002777  
01-20 23:15:21.622: INFO/DEBUG(1149):     47bb2a54  e3a070ad  
01-20 23:15:21.622: INFO/DEBUG(1149): #00 47bb2a58  869bf304  
01-20 23:15:21.622: INFO/DEBUG(1149):     47bb2a5c  853bb054  
01-20 23:15:21.622: INFO/DEBUG(1149):     47bb2a60  8593cb18  
01-20 23:15:21.622: INFO/DEBUG(1149):     47bb2a64  840a97e8  /data/data/paulscode.android.mupen64plus/lib/libcore.so
01-20 23:15:21.622: INFO/DEBUG(1149):     47bb2a68  ffff35b0  
01-20 23:15:21.622: INFO/DEBUG(1149):     47bb2a6c  00000001  
01-20 23:15:21.622: INFO/DEBUG(1149):     47bb2a70  00000000  
01-20 23:15:21.622: INFO/DEBUG(1149):     47bb2a74  840ad4a8  
01-20 23:15:21.622: INFO/DEBUG(1149):     47bb2a78  81b0ddfc  /data/data/paulscode.android.mupen64plus/lib/libapplication.so
01-20 23:15:21.630: INFO/DEBUG(1149):     47bb2a7c  000044dc  
01-20 23:15:21.630: INFO/DEBUG(1149):     47bb2a80  00000001  
01-20 23:15:21.630: INFO/DEBUG(1149):     47bb2a84  8401c018  /data/data/paulscode.android.mupen64plus/lib/libcore.so
01-20 23:15:21.630: INFO/DEBUG(1149):     47bb2a88  840a97e8  /data/data/paulscode.android.mupen64plus/lib/libcore.so
01-20 23:15:21.630: INFO/DEBUG(1149):     47bb2a8c  00000184  
01-20 23:15:21.630: INFO/DEBUG(1149):     47bb2a90  8409cd98  /data/data/paulscode.android.mupen64plus/lib/libcore.so
01-20 23:15:21.630: INFO/DEBUG(1149):     47bb2a94  00000000  
01-20 23:15:21.630: INFO/DEBUG(1149):     47bb2a98  00000004  
01-20 23:15:21.630: INFO/DEBUG(1149):     47bb2a9c  8401af60  /data/data/paulscode.android.mupen64plus/lib/libcore.so
01-20 23:15:21.895: INFO/BootReceiver(1259): Copying /data/tombstones/tombstone_09 to DropBox (SYSTEM_TOMBSTONE)
01-20 23:15:21.958: DEBUG/Zygote(1156): Process 3302 terminated by signal (11)
01-20 23:15:22.028: DEBUG/dalvikvm(1259): GC_FOR_MALLOC freed 1289 objects / 313640 bytes in 111ms
01-20 23:15:22.028: INFO/dalvikvm-heap(1259): Grow heap (frag case) to 10.920MB for 87150-byte allocation
01-20 23:15:22.122: DEBUG/dalvikvm(1259): GC_FOR_MALLOC freed 92 objects / 3840 bytes in 94ms
01-20 23:15:22.122: INFO/WindowManager(1259): WIN DEATH: Window{45cb1bc0 
    paulscode.android.mupen64plus/paulscode.android.mupen64plus.MainActivity paused=false}
01-20 23:15:22.130: INFO/WindowManager(1259): WIN DEATH: Window{45ba9f58 SurfaceView paused=false}
01-20 23:15:22.145: INFO/ActivityManager(1259): Process paulscode.android.mupen64plus (pid 3302) has died.

I hope to have some time to look at all this tomorrow to see if I can identify the problem.

Oh, and for anyone interested, I used the following to set up my macros:

Code:

#define ASSEM_DEBUG 1
#define INV_DEBUG 1

void log_to_file( char* format, ... )
{
    va_list args;
    va_start( args, format );
    FILE *file = fopen( "/sdcard/data/mp64plog.txt", "a" );
    vfprintf( file, format, args );
    va_end( args );
    fclose( file );
}
void nullf() {}

#if defined( ASSEM_DEBUG )
    //#define assem_debug(...) __android_log_print(ANDROID_LOG_DEBUG, "assem_debug", __VA_ARGS__)
    #define assem_debug(...) log_to_file(__VA_ARGS__)
#else
    #define assem_debug nullf
#endif
#if defined( INV_DEBUG )
    //#define inv_debug(...) __android_log_print(ANDROID_LOG_DEBUG, "inv_debug", __VA_ARGS__)
    #define inv_debug(...) log_to_file(__VA_ARGS__)
#else
    #define inv_debug nullf
#endif

//#define printf(...) __android_log_print(ANDROID_LOG_VERBOSE, "new_dynarec", __VA_ARGS__)
#define printf(...) log_to_file(__VA_ARGS__)

Ari64 · Jan 21, 2011

paulscode said:
I had a little trouble getting this to work, since the program is crashing before I can fclose the file (thus resulting in an empty file). I fixed this by opening the file in append mode, and then closing it after each fprintf.

Try using fflush instead.

paulscode said:
I've uploaded the output HERE.

Okay, so the crash occurs at 0x843bb150, which is

Code:

str r3, [r5, r2, lsl #2]

where r5=a4001fd8 and r2=ffffffff

According to the log, the code that should be at that location is

Code:

  a4000064: SW r19,r29+0
<->
mov r2,#428
add r2,r2,r5 lsr #12
ldr r2,fp,r2 lsl #2
tst r2,$1073741824
bne 0
str r3,r5,r2 lsl #2

If that was accurate then there would be no crash since the branch would be taken and the str would never be reached.

So, what's actually there?

Code:

01-20 23:15:21.622: INFO/DEBUG(1149):          #00  pc 843bb150  
01-20 23:15:21.622: INFO/DEBUG(1149):          #01  lr ffffec76  <unknown>
01-20 23:15:21.622: INFO/DEBUG(1149): code around pc:
01-20 23:15:21.622: INFO/DEBUG(1149): 843bb130 e59b5168 e59b3118 e2455018 e3a02f6b 
01-20 23:15:21.622: INFO/DEBUG(1149): 843bb140 e0822625 e79b2102 e3120000 1a0001d6 
01-20 23:15:21.622: INFO/DEBUG(1149): 843bb150 e7853102 e59b4120 e2850004 e3a02f6b 
01-20 23:15:21.622: INFO/DEBUG(1149): 843bb160 e0822620 e79b2102 e3120000 1a0001df 
01-20 23:15:21.622: INFO/DEBUG(1149): 843bb170 e7804102 e59b0128 e2851008 e3a02f6b

which disassembles to:

Code:

0x843bb148: tst r2, #0
0x843bb14c: bne 0x843bb8ac
0x843bb150: str r3, [r5, r2, lsl #2]

paulscode · Jan 21, 2011

Wow. :ermm: That went completely over my head.

I better start by figuring out how to follow your deductions, or I won't have a prayer trying to figure out what needs to be changed in the code. If you don't mind repeating something that is probably elementary, I'd like to step through the process to figure out how to get from A to B.

Ari64 said:
Okay, so the crash occurs at 0x843bb150

Ok, I see that address in a line of the logcat. What are the signs I should recognize that indicate this is where the crash occurred?

Code:

01-20 23:15:21.622: INFO/DEBUG(1149):          #00  pc 843bb150

Ari64 said:
0x843bb150 which is

Code:

str r3, [r5, r2, lsl #2]

How do you translate the address into this type of list/set thingamajig (is there a relevant tutorial on line somewhere that you know about?)

Ari64 said:
According to the log, the code that should be at that location is

Code:

a4000064: SW r19,r29+0 <-> mov r2,#428 add r2,r2,r5 lsr #12 ldr r2,fp,r2 lsl #2 tst r2,$1073741824 bne 0 str r3,r5,r2 lsl #2

Great, I can find this by searching for that list.

Ari64 said:
If that was accurate then there would be no crash since the branch would be taken and the str would never be reached.

I assume "branch" is something like GOTO in Basic. I'm guessing "tst r2,$1073741824 ... bne 0" translates to something like "If r2 does not equal $1073741824 then branch to 0", correct? And you know that r2 does not equal this value because of the mov, add, and ldr lines above it.

Ari64 said:

So, what's actually there?

Code:

01-20 23:15:21.622: INFO/DEBUG(1149):          #00  pc 843bb150  
01-20 23:15:21.622: INFO/DEBUG(1149):          #01  lr ffffec76  <unknown>
01-20 23:15:21.622: INFO/DEBUG(1149): code around pc:
01-20 23:15:21.622: INFO/DEBUG(1149): 843bb130 e59b5168 e59b3118 e2455018 e3a02f6b 
01-20 23:15:21.622: INFO/DEBUG(1149): 843bb140 e0822625 e79b2102 e3120000 1a0001d6 
01-20 23:15:21.622: INFO/DEBUG(1149): 843bb150 e7853102 e59b4120 e2850004 e3a02f6b 
01-20 23:15:21.622: INFO/DEBUG(1149): 843bb160 e0822620 e79b2102 e3120000 1a0001df 
01-20 23:15:21.622: INFO/DEBUG(1149): 843bb170 e7804102 e59b0128 e2851008 e3a02f6b

which disassembles to:

Code:

0x843bb148: tst r2, #0
0x843bb14c: bne 0x843bb8ac
0x843bb150: str r3, [r5, r2, lsl #2]

What is the process for disassembling the information to get this? Also, how in God's name could the instructions be so different (how did it get from "tst r2,$1073741824 ... bne 0" to "tst r2, #0 ... bne 0x843bb8ac"), or are these the type of differences I should expect to see? Any tips for taking that information and actually relating it to a particular section in the source code, or additional messages I could have the ap print to shed more light on the problem?

Ari64 · Jan 21, 2011

paulscode said:
Wow. :ermm: That went completely over my head.

If you're going to try to port dynamic recompilers, it would help if you learned something about assembly code. Really.

paulscode said:
Ok, I see that address in a line of the logcat. What are the signs I should recognize that indicate this is where the crash occurred?

Code:

01-20 23:15:21.622: INFO/DEBUG(1149): #00 pc 843bb150

pc = program counter. ie the instruction pointer.

paulscode said:
I assume "branch" is something like GOTO in Basic.

Yes

paulscode said:
I'm guessing "tst r2,$1073741824 ... bne 0" translates to something like "If r2 does not equal $1073741824 then branch to 0", correct?

If (r2&0x40000000) goto ...

paulscode said:
And you know that r2 does not equal this value because of the mov, add, and ldr lines above it.

I know what r2 equals because the contents of all the registers are in the crash report.

paulscode said:
What is the process for disassembling the information to get this?

Use a disassembler, eg gdb.

paulscode said:
Also, how in God's name could the instructions be so different (how did it get from "tst r2,$1073741824 ... bne 0" to "tst r2, #0 ... bne 0x843bb8ac"), or are these the type of differences I should expect to see?

That's exactly what you need to debug. Figure out how the value at 0x843bb148 got corrupted.

paulscode · Jan 22, 2011

Ari64 said:
If you're going to try to port dynamic recompilers, it would help if you learned something about assembly code. Really.

Haha, good point. I suppose that will be the next step (unless anyone happens to know of an existing port of your dynarec which uses RDRAM at some other location than the native 0x80000000, that I can look at for comparison). Either way, do you recommend any particular on line tutorials or books for a beginner like me?

--EDIT--
I just took a quick look at Zodttd's n64iphone source code, and it appears to be using a different RDRAM location as well, based on this line in memory.c (I'm assuming __APPLE__ is defined here since it is for the iPhone):

Code:

#if defined(__x86_64__) || defined(NO_ASM) || (!defined(__i386__)&&!defined(__arm__)) || (defined(__APPLE__) && defined(__arm__))
unsigned int rdram[0x800000/4] __attribute__((aligned(16)));
#endif

I think I'll do a little comparing to see if there are any obvious changes that I could apply to my project. I can see quite a few differences already in new_dynarec.c (for example, there is no using_tlb variable)

Ari64 · Jan 22, 2011

paulscode said:
Haha, good point. I suppose that will be the next step (unless anyone happens to know of an existing port of your dynarec which uses RDRAM at some other location than the native 0x80000000, that I can look at for comparison).

Try this: http://pastebin.com/7r1xCy6c

Of course that will only fix the ram location, and not whatever else is wrong with your code, which is crashing long before it ever tries to access the ram at 0x80000000.

paulscode said:
Either way, do you recommend any particular on line tutorials or books for a beginner like me?

Surely a google search for "arm instruction set" would find helpful things.

paulscode said:
I think I'll do a little comparing to see if there are any obvious changes that I could apply to my project. I can see quite a few differences already in new_dynarec.c (for example, there is no using_tlb variable)

That depends on whether or not you would consider an N64 emulator with no TLB emulation useful.

paulscode · Jan 22, 2011

Ari64 said:
Try this: http://pastebin.com/7r1xCy6c

Of course that will only fix the ram location, and not whatever else is wrong with your code, which is crashing long before it ever tries to access the ram at 0x80000000.

Surely a google search for "arm instruction set" would find helpful things.

Thanks I'll give that a shot. I guess I've been going off the assumption that the problem was related to accessing the ram, since I'm no good at interpreting the output. I will start looking elsewhere for problems then (perhaps the issue is in one of the things I applied from your project to version 1.99.4.) It might be smarter for me to start with version 1.5 come to think of it, just to verify that I can get your dynarec to work on Android, rather than trying to port two things at the same time.

Of course I can google, but I meant are there any sites or books that you personally have found to be really educational?

Ari64 · Jan 22, 2011

paulscode said:
Of course I can google, but I meant are there any sites or books that you personally have found to be really educational?

Just read the ARM reference manuals, it explains the instruction encoding and everything.

paulscode · Jan 22, 2011

--EDIT-- Removed my previous post. I'm going to just work with version 1.5 first, so I can hopefully rule out some of the potential human error from porting the dynarec not only from Pandora to Android but also from Mupen64Plus 1.5 to 1.99.4 at the same time. Once I get that going, then I'll try and port it to 1.99.4.

paulscode · Jan 23, 2011

Cpasjuste said:
Ps : my work (not complete) is available here : https://github.com/Cpasjuste/droid64

Cpasjuste, what process are you using to compile the executable and run it on your device? Sorry if that's a dumb question, I'm still new to Android development.

Cpasjuste · Jan 24, 2011

paulscode said:
Cpasjuste, what process are you using to compile the executable and run it on your device? Sorry if that's a dumb question, I'm still new to Android development.

First, this is a crappy work i did

You should just have to build it : "ndk-build" then transfer the resulting executable file to your device "adb push lib/armv7-a/mupen64plus /data/droid64" then run it from there (console application for now).

All is statically linked (plugins too), and it will search for configuration files etc in the "/data/droid64" folder (take a look at my crappy "main/main.c" file). The dynarec should work then, you'll see it looping ! So next you'll have to port this to an android jni project, i did work a little on this, first by using the new android 2.3 native build system (no jni anymore, just need to take a look at the native-activity sample from the latest sdk) but i too have a memory problem when launching it from a native activity, i guess the jni crap is loading in another chunk of memory or i don't know ... but there's probably not a lot of work to do to get it working.

paulscode · Jan 25, 2011

Cpasjuste, when I run "ndk-build" for your project, it starts building fine for a while, but then it stops with the following message:

Code:

make: *** No rule to make target `/home/paul/workspace/Cpasjuste-droid64/obj/local/armeabi-v7a/libsdl.a', 
    needed by `/home/paul/workspace/Cpasjuste-droid64/obj/local/armeabi-v7a/mupen64plus'.  Stop.

Any thoughts what I might be doing wrong?

Cpasjuste · Jan 25, 2011

Ha yes ... i used a fixed path in the "droid64/jni/Application.mk" file, change :

-> NDK_MODULE_PATH := /home/cpasjuste/dev/android/droid64/jni/
to
-> NDK_MODULE_PATH := /path/to/droid64/jni/

paulscode · Jan 25, 2011

Doh! Silly me, I should have known to check the paths. Thanks.

Porting Mupen64Plus to Android

New member

New member

New member

New member

New member

New member

New member

New member

New member

New member

New member

New member

New member

New member

New member

New member

New member

New member

New member

New member