sys_game: Implemented sys_game_get_rtc_status() & Updated sys_game_board_storage_read()

[brian218]

After looking into a number of System 357 games' decompilation, I figured out that the buffer status is supposed be set to all 0 by sys_game_get_rtc_status() if the RTC is successfully checked (required by Dark Escape 4D).

Also, with more System 357 games being discovered, I figured out that sys_game_board_storage_read() should always give buffer1 all 0, and players are responsible for setting a correct PSID in the emulator configuration on a game basis in order to play System 357 games.

[elad335]

I want to sleep, I gave you the LV2 disassembly in the past.

[brian218]

I want to sleep, I gave you the LV2 disassembly in the past.

Good night, bro!

Though it seems weird as I was unable to locate sys_game_get_rtc_status.

[clienthax]

I want to sleep, I gave you the LV2 disassembly in the past.

Good night, bro! Though it seems weird as I was unable to locate sys_game_get_rtc_status.

Some syscalls might be referred to by their number or outright missing depending on the lv2 kernel

[isJuhn]

This syscall doesn't exist in CEX kernel. Looks like it's simply copying 4 bytes unless copy_to_user has some alignment memes going on?

[brian218]

This syscall doesn't exist in CEX kernel. Looks like it's simply copying 4 bytes unless copy_to_user has some alignment memes going on?

Interesting.
Ghidra indicates the passed buffer is undefined auStack16 [16];

[elad335]

If you had counted only on ghidra that parameter would be deemed unused, ghidra is not always trustworthy.

[brian218]

If you had counted only on ghidra that parameter would be deemed unused, ghidra is not always trustworthy.

Alright, noted that.

[brian218]

Okay, I've confirmed that the buffer status of sys_game_get_rtc_status() is a pointer to a s32, and that the initial value passed by the game is -1.

[RipleyTom]

I'm really not a big fan of having a thread at 100% usage, the sleep is only 200us. If it is not rescheduled in time the system is probably already overwhelmed. So yes it will reduce latency on an overwhelmed system but it will reduce perf in all games that use usb devices for really no reason.

I personally tried Taiko and didn't notice any lag from input with that 200us sleep.

The current sleep is obviously not ideal but removing the sleep really isn't either.
Please at least put a std::this_thread::yield(); in there.

[brian218]

I'm really not a big fan of having a thread at 100% usage, the sleep is only 200us. If it is not rescheduled in time the system is probably already overwhelmed. So yes it will reduce latency on an overwhelmed system but it will reduce perf in all games that use usb devices for really no reason.

I personally tried Taiko and didn't notice any lag from input with that 200us sleep.

The current sleep is obviously not ideal but removing the sleep really isn't either. Please at least put a std::this_thread::yield(); in there.

Thank you for your suggestion.
I've added std::this_thread::yield();