Can we possibly have a new release for JPCSP that caters to Kingdom Hearts Birth By Sleep, and overrides the errors? That would be nice, if it were possible. Whenever I (and many other people also) get to Deep Space with Terra, after the cutscene there is supposed to be a huge battle, but the game freezes. I would attach the log, except it won't let me because the file is too large, so I am resorting to Media Fire. I am also going to give you the link to a video that I made that shows exactly what happens and what I do. Note: The game runs more slowly that normal because of the screen capture I was doing.
If this error could be overrun in a future build or something, that would be greatly appreciated, by many people, myself included.
Another note about the video, I didn't have the media engine or SonicStage enabled. In the video, it showed the cutscene, but if I skip the cutscene, the same thing happens. If I use CWCheat to skip to that event without the cutscene, it freezes in the same way and shows the same message. If I boss warp past that point, then it freezes after I defeat the boss.
Will it be fixed in newer revisions ? nothing has changed to fix this problem in the last ~50 revs. I know that the network and the fullscreen/resizing fuctions are indev but devs could solve this problem :/ I think this problem is in the complier source file, i've searched on the jpcsp google code.
Sorry for the delay on this issue, but this one was quite hard to figure out.
Anyway, I've finally traced this bug by disassembling the compiler's instructions at the problematic execution time:
So, that's the trace output that results when the game attempts to interpret this portion of code here:
Code:
08B8CCA8:[27BDFFF0]: addiu $sp, $sp, -16
08B8CCAC:[AFBF0000]: sw $ra, 0($sp)
08B8CCB0:[0E26044A]: jal 0x08981128
08B8CCB4:[00000000]: nop
08B8CCB8:[3C0508B9]: lui $a1, 0x08B9 <=> li $a1, 0x08B90000
08B8CCBC:[2444FFFF]: addiu $a0, $v0, -1
08B8CCC0:[ACA2CDA8]: sw $v0, -12888($a1)
08B8CCC4:[2C85000F]: sltiu $a1, $a0, 15
08B8CCC8:[10A00013]: beq $a1, $zr, 0x08B8CD18
08B8CCCC:[00000000]: nop
08B8CCD0:[00042080]: sll $a0, $a0, 0x0002
08B8CCD4:[3C0108B9]: lui $at, 0x08B9 <=> li $at, 0x08B90000
08B8CCD8:[00240821]: addu $at, $at, $a0
08B8CCDC:[8C21CD68]: lw $at, -12952($at)
08B8CCE0:[00200008]: jr $at
08B8CCE4:[00000000]: nop
08B8CCE8:[0E260447]: jal 0x0898111C
08B8CCEC:[3404000A]: ori $a0, $zr, 10 <=> li $a0, 10
08B8CCF0:[8FBF0000]: lw $ra, 0($sp)
08B8CCF4:[03E00008]: jr $ra
08B8CCF8:[27BD0010]: addiu $sp, $sp, 16
08B8CCFC:[0E260447]: jal 0x0898111C
08B8CD00:[3404000B]: ori $a0, $zr, 11 <=> li $a0, 11
08B8CD04:[8FBF0000]: lw $ra, 0($sp)
08B8CD08:[03E00008]: jr $ra
08B8CD0C:[27BD0010]: addiu $sp, $sp, 16
08B8CD10:[0E260447]: jal 0x0898111C
08B8CD14:[3404000C]: ori $a0, $zr, 12 <=> li $a0, 12
08B8CD18:[8FBF0000]: lw $ra, 0($sp)
08B8CD1C:[03E00008]: jr $ra
08B8CD20:[27BD0010]: addiu $sp, $sp, 16
08B8CD24:[03E00008]: jr $ra
I've narrowed this down to that particular instruction "08B8CCE0:[00200008]: jr $at". Apparently, at runtime, the register $at contains 08B8CD10.
This causes the execution of "jr $at" to jump to the 0x08B8CD10 address, which in turn contains the instruction "08B8CD10:[0E260447]: jal 0x0898111C".
Now, this should make the compiler jump to the address 0x0898111C, but for some reason it's immediately jumping (not even compiling the delay slot) into 0x08A57578, which contains this:
(05-29-2011, 07:01 PM)Hykem Wrote: Weird, huh? Either the game forgot to load something at that address, or something is quite wrong with our compilation sequence (most likely ).
Could you enable "debugCodeBlockCalls = true" in RuntimeContext.java, line 68 and post a log file including compiler and runtime logs at DEBUG level? This way, I can see what the compiler generated and which call sequences are executed.
(05-29-2011, 07:01 PM)Hykem Wrote: Weird, huh? Either the game forgot to load something at that address, or something is quite wrong with our compilation sequence (most likely ).
Could you enable "debugCodeBlockCalls = true" in RuntimeContext.java, line 68 and post a log file including compiler and runtime logs at DEBUG level? This way, I can see what the compiler generated and which call sequences are executed.
Thanks!
Sure.
To save space, I've tried to make the log as specific as possible. Here is a DEBUG level Compiler and Runtime log file recording the activity of the thread "user_main" alone, shortly after loading the KEYBLADE_RIDE.ELF.
As you can see, for some reason, there seems to be some sort of conflict with the runtime call instructions and the respective compiled jump (the one with the $at register).
(05-29-2011, 08:45 PM)Hykem Wrote: Sure.
To save space, I've tried to make the log as specific as possible. Here is a DEBUG level Compiler and Runtime log file recording the activity of the thread "user_main" alone, shortly after loading the KEYBLADE_RIDE.ELF.
As you can see, for some reason, there seems to be some sort of conflict with the runtime call instructions and the respective compiled jump (the one with the $at register).
The only information I could find in the log was that the address 0x8B8CD10 was compiled as a "nop" some time before:
Code:
Replacing CodeBlock at 0x08B8CD10 by Native Code 'nop'
Which means that at that time, the code at 0x8B8CD10 was
Code:
0x8B8CD10 jr $ra
0x8B8CD14 nop
It seems that this code has been replaced with another sequence but it looks like the compiler is still using the old compiled code.
Normally the compiled code is invalidated (RuntimeContext.invalidateAll) when unloading a module (sceKernelUnloadModule)... Does this game call a different method to unload the module located at 0x8B8CD10?
Could you set a memory write breakpoint at 0x8B8CD10-0x8B8CD17 to find out who is overwriting the memory?
05-30-2011, 02:47 PM (This post was last modified: 05-30-2011, 03:19 PM by Hykem.)
(05-30-2011, 07:25 AM)gid15 Wrote:
(05-29-2011, 08:45 PM)Hykem Wrote: Sure.
To save space, I've tried to make the log as specific as possible. Here is a DEBUG level Compiler and Runtime log file recording the activity of the thread "user_main" alone, shortly after loading the KEYBLADE_RIDE.ELF.
As you can see, for some reason, there seems to be some sort of conflict with the runtime call instructions and the respective compiled jump (the one with the $at register).
The only information I could find in the log was that the address 0x8B8CD10 was compiled as a "nop" some time before:
Code:
Replacing CodeBlock at 0x08B8CD10 by Native Code 'nop'
Which means that at that time, the code at 0x8B8CD10 was
Code:
0x8B8CD10 jr $ra
0x8B8CD14 nop
It seems that this code has been replaced with another sequence but it looks like the compiler is still using the old compiled code.
Normally the compiled code is invalidated (RuntimeContext.invalidateAll) when unloading a module (sceKernelUnloadModule)... Does this game call a different method to unload the module located at 0x8B8CD10?
Could you set a memory write breakpoint at 0x8B8CD10-0x8B8CD17 to find out who is overwriting the memory?
Uh oh, found the problem...
This game is using sceKernelIcacheInvalidateRange to invalidate the memory area where the ELF file will be read into.
Then, when the next ELF file is read, no module loading is processed, the contents are just overwritten and the range is recompiled *facepalm*.
Going to implement this right away and also improve a bit our trace debug for some of these cache functions (missing params in some of them).
EDIT:
Finally, this is with chessplayerjames' save file, after the bug. Commiting the fix right now.
).