#130894 - Lordus - Sat Jun 09, 2007 1:59 am
I am currently working on an emulator and a bug that i cant figure out is driving me nuts for some time now.
If anyone would have any advice or an idea of what could be causing it, i would really appreciate it.
It started like this:
I first wrote my cpu core in C, then wrote an assembler core and had them running in parallel to fix all assembler opcodes. When everything was working like expected, i completely cut off the C core and it was still fine.
Just when i removed the source files of the C core the bug appeared.
Most games are still running perfectly on the emu, just some get a massive slowdown (~6 seconds for 1 frame), or behavior that looks like an opcode is not doing what it is supposed to.
This is reproducable and happens with the same games (on emulators and real hardware).
While trying to find the reason, i found out that random changes, that could not directly have something to do with it make the bug dissapear.
Like adding a printf somewhere that definately never gets called. Adding another line of code somewhere might make it appear again though.
I guess it has something to do with how things are arranged in memory, but i cant really figure it out. I am sure though, that it has something to do with the assembler core.
I know that this info is a bit vague, so here is how i am basically doing things:
If anyone sees a possible problem there, please let me know. Thanks for taking your time.
If anyone would have any advice or an idea of what could be causing it, i would really appreciate it.
It started like this:
I first wrote my cpu core in C, then wrote an assembler core and had them running in parallel to fix all assembler opcodes. When everything was working like expected, i completely cut off the C core and it was still fine.
Just when i removed the source files of the C core the bug appeared.
Most games are still running perfectly on the emu, just some get a massive slowdown (~6 seconds for 1 frame), or behavior that looks like an opcode is not doing what it is supposed to.
This is reproducable and happens with the same games (on emulators and real hardware).
While trying to find the reason, i found out that random changes, that could not directly have something to do with it make the bug dissapear.
Like adding a printf somewhere that definately never gets called. Adding another line of code somewhere might make it appear again though.
I guess it has something to do with how things are arranged in memory, but i cant really figure it out. I am sure though, that it has something to do with the assembler core.
I know that this info is a bit vague, so here is how i am basically doing things:
| Code: |
|
__attribute__((section(".dtcm"))) static CPU _cpu; // Main emulation loop: for(scanline=0; scanline<n_visible_scanlines; scanline++){ // some code executeCPU( &_cpu, cycles ); // some code } // executeCPU - Arm Assembler .arm .align 4 .global executeCPU executeCPU: stmfd sp!, {r4-r11,lr} mov CPU, r0 mov cycles, r1 // some code @ fetch Opcode ldrh OPCODE, [EMULATEDPC], #2 @ jump to Opcode handler ldr pc, [OPTABLE, OPCODE, asl #2] EXECEND: // some code ldmfd sp!, {r4-r11, pc} @ exit function // Example Opcode MOVE_B: // some code that gets address into r0 and operand into r1 bl WBYTE subs cycles, cycles, #8 ldrgth OPCODE, [EMULATEDPC], #2 ldrgt pc, [OPTABLE, OPCODE, asl #2] b EXECEND // Example write handler WBYTE: // check if write is to emulated ram and r2, r0, #0x00F00000 cmp r2, #0x00E00000 ldrlt pc, [CPU, #O_WBYTE] // call C writeByte-Handler @ *** RAM WRITE *** ldr r2, [CPU, #O_RAMREG] // get direct pointer to emulated ram eor r0, r0, #1 mov r0, r0, lsl #16 strb r1, [r2, r0, lsr #16] bx lr |
If anyone sees a possible problem there, please let me know. Thanks for taking your time.