THREAD issue: Dainiji_Super_Robot_Taisen_Z_Hakaihen/Saisehen #1922
Comments
Integrate atrac3+ low level decoding from oioitff media branch
|
I only said that I would test Dai2Ji Super Robot Taisen Z Saisehen in the qq group.I only find a eboot issue and marge it in 4d97916 |
|
I see .Nevermind . |
|
[Please Change the title,it is not Eboot issue,and only for this game - Dai2Ji Super Robot Taisen Z Saisehen ] |
|
Black screen seem to FBO probrem |
|
It seems to be doing this: sceUmdActivate(1, 'disc0:'); After this, it runs callbacks and nothing runs on user_main again. I think what's happening is that it's being woken up during the callbacks, and then the callback is resetting the wait state. To verify this theory, you can try (this is not a fix, this'll break a lot of things, but it may make this game get farther here even if it breaks later due to this): -[Unknown] |
|
@unknownbrackets |
|
@unknownbrackets , wondering any other thing we can try to change it to see if can help these series of games gettting further ? |
|
That implies it's not actually a callback issue after all (well, who knows?) What is the state of that thread if you pause into debug and look at -[Unknown] |
|
Wondering how to check the state of thread and look that kernelObjects ? |
|
you can select the thread, then check what's in the stack frame (the dropdown to the right, or you can use the Call Stack debug window). |
|
Alright .I selected the EmuThread and select MIPSState in the stack frame . This series of games are pretty strange .It called those UMD functions then sleep definitely and not calling other HLE functions again . |
|
@unknownbrackets , any further we can do to help debug it ? |
|
Well, the next question is where it's hanging. I would try pausing the emulator and seeing where it is in the MIPS debugger. Might have to run/pause/run/pause several times to find if there's a consistent place. If you can never get it to pause anywhere except __KernelIdle / etc., that means the thread is still dead somehow. If you can get it to pause somewhere else, it means that we may have a CPU bug, or else an earlier syscall did something wrong and the game totally lost its marbles because of it. At that point, every syscall it called up to that point is a suspect. -[Unknown] |
|
Thanks @unknownbrackets . Will follow the instruction provided to debug it .Hopefully soon we can get it bootup . |
|
I paused several times and seems to be consistent in this place shown below . |
|
Okay, if you can't get it to pause anywhere else that means the main thread is indeed dead. The question is why... You can add a NOTICE_LOG() to __KernelChangeReadyState(). This'll help see why it's not getting set ready again (presumably.) -[Unknown] |
|
I added the following line to __KernelChangeReadyState() , not too sure if it is detail enough though NOTICE_LOG(HLE,"Thread %i, SecUID %i , Ready %i , Priority %i", thread, threadID, ready, prio); We have this in debug log. (Debug mode) |
|
Hmm, I see. Okay, how about if you change this code: To: I'm not sure if it could save running, it shouldn't... -[Unknown] |
|
Running it now :) |
|
Humm seems to be stuck at the return from callback still |
|
I just tried to change it to __KernelChangeReadyState(thread, threadID, true) , it boots up ! |
|
Boths are running okay and in-game |
|
Hmm, true is definitely wrong in the general case but it should be using true in this case. I wonder what status it's saving... What about: __KernelChangeReadyState(thread, threadID, (status & THREADSTATUS_WAITSUSPEND) == 0); After all, dormant/dead threads shouldn't be running callbacks anyway... -[Unknown] |
|
Yep setting it true is wrong in general case .Let me try this one __KernelChangeReadyState(thread, threadID, (status & THREADSTATUS_WAITSUSPEND) == 0); |
|
It is okay and running . I think should be != 0 , right ? __KernelChangeReadyState(thread, threadID, (status & THREADSTATUS_WAITSUSPEND) != 0); |
|
Hmm. When I think about it, sceUmdWaitDriveStat() shouldn't even run callbacks... -[Unknown] |
|
Can we change in the following way so it can be used in general case ? __KernelChangeReadyState(thread, threadID, (status & (THREADSTATUS_READY | THREADSTATUS_WAITSUSPEND)) != 0); |
|
No, != 0 is wrong. That makes it ready if it was previously waiting or suspended (it should instead stay waiting/etc.) So I guess that means it's in a wait state, so it's back to my original theory. My initial "see if it's the problem" change must've not been enough. Let's see... the right way will be the begin callback stuff.... -[Unknown] |
|
I see . So i think the problem arised from the UMD callback . If you have anything want me to try it , let me know .Many thanks for your help to debug it . |
|
Does this fix it? -[Unknown] |
|
Just tried , not yet working . debug log here |
|
Darn. What does it log with... -[Unknown] |
|
Humm i think it didn't hit the __UmdStartCallBack & __UmdEndCallback ? |
|
That's strange. And you definitely have Inside -[Unknown] |
|
I can see __KernelRegisterWaitTypeFuncs(WAITTYPE_UMD, __UmdBeginCallback, __UmdEndCallback); in __UmdInit() void __UmdInit() } |
|
New debug log . I can see those WARN_LOG About to exec callback, wait type |
|
Oh, that is WAITTYPE_VBLANK. -[Unknown] |
|
|
|
Based on the log, the vblank is being entered AFTER it leaves the callback. So then, why isn't sceDisplay waking it up? Any interesting logging from that? -[Unknown] |
|
I just know it is raven02 hack version.. |
|
Here is the debug log , it shows Walking up 1 threads ...... |
|
Just tried to remove the line " if (--vblankWaitingThreads[i].vcountUnblock == 0) {" , it boots up okay .Not too sure if it's correct way .... I tested with other games and seems to be working fine still |
|
Can you make it log the value of Hmm. Also maybe change the VERBOSE_LOGS to NOTICE_LOGs for now to see where it's waiting exactly (at the top): #undef VERBOSE_LOG -[Unknown] |
|
Sure . Will try it out shortly (in office) |
|
Here is the debug log with |
No description provided.
The text was updated successfully, but these errors were encountered: