I've tried enabling verbose logs but still unable to find any network-related syscalls between the join request and the player has left detection, other than sceNetAdhocPdpSend and sceNetAdhocPdpRecv which is part of the internal AdhocMatching communication instead of what the game calls explicitly.

I saw the game is using sceKernelGetSystemTimeWide in several place in the loop, but not sure how it calculate and compare the syscall value with stored value (as i don't quite understand MIPS instruction)

But none of my brakpoints at getsystemtime used in the loop got hit (unless i missed some)

I found the condition that will never goes to that sceNetAdhocMatchingCancelTargetWithOpt which allows me to take as much of time as i wanted to accept the player (when tampered/forced to branch)

But, when i tried to put memory write breakpoint on the value being compared with zero while branching, apparently not triggering at all, even from the moment i choose multiplayer menu (was hoping to see an attempt to initialize the value at beginning, but nothing triggered).

The value itself being decreased by 1 if it was not zero (in a large loop), and goes to sceNetAdhocMatchingCancelTargetWithOpt when zero, so it should probably supposed to start at positive value, but apparently stays at zero since beginning without anyone writing to it, thus leading to the sceNetAdhocMatchingCancelTargetWithOpt immediately.

Similarly, the value loaded and being compared/calculated (not sure what they did to both values) with the output from sceKernelGetSystemTimeWide also remains zero instead of an [assumed to be] initial timestamp. - Then again, since the breakpoints at sceKernelGetSystemTimeWide never got triggered, the memory probably not initialized yet (probably not part of the joining/accepting procedure).

Edit: i found another condition where it compare a value in memory ( a counter?) with slti a0,a0,0x51 where the value increased by 1 on each loop, and when i tried to change the constant 0x51 with a higher value (ie. 0x5100), the memory value seems to be increasing rapidly (around 33 per second), thus the original 0x51 will certainly reached way too soon (thus leading to sceNetAdhocMatchingCancelTargetWithOpt)

Unfortunately, tampering the constant value will make the game stuck unable to start properly after accepting the player.

May be these counters (the one being decrease and another one being increased over time) are counting the number of frames instead of using timestamp as timeouts?

Hmm.. apparently the timing feels pretty much the same when i tested this game on JPCSP LLE, it's just that my laptop couldn't get 60 FPS and struggles between 40~46 FPS where the error message appeared within 3 seconds (or more), while on PPSSPP (with 60 FPS) the error message appeared in less than 2 seconds.

I guess this game really did have a short timeout to accept the joining player, while most games allowed us to accept/reject within at least 3 seconds.

The only difference with JPCSP LLE (i couldn't get JPCSP HLE to work with this game) is that both players is showing the same error message, while on PPSSPP one of the player apparently unable to detect that the other player (that have the error message shown) has terminate AdhocMatching.

Also, the count down timer going twice faster issue seems to be more of a general issue, as it also happened on the non-AdHoc multiplayer (which didn't use any networking code at all, basically single player where a single PSP being shared by multiple players in turns)

PS: I couldn't start multiplayer game properly after joining using JPCSP (LLE) multiple instances, so unable to see the difference.