Open ponut64 opened 7 months ago
Hi is it possible to attach a version of your iso so that I can check in the emulator what is going so wrong with the DSP?
Thx
In fact, I will need get_time_in_frame and validation_escape code to understand the conditions of the test.
Code is here: https://github.com/ponut64/stuff ISO can be found here: https://segaxtreme.net/resources/slide-hop.178/
What's the full name of the game (including region) ? SLIDE HOP Beta RC3 (and future versions)
What's your frontend ? (standalone, libretro, ...) ? Standalone 64-bit
What's your OS ? (windows, linux, OSX, ...) ? Windows 10
What's your hardware ? (CPU, GPU, ...) ? AMD R5 5600G AMD RX 6600
What's the storage type of the game (official cd, burned cd or cd image) ? CD Image as-built (.iso)
If applicable, what's the format of your cd image ? (cue/bin, ccd/img, iso, chd, ...) .ISO
Are you using any setting different from default ? If so, precise I don't think I change anything except to ensure vertical sync and frame-limiter are enabled.
Did this game work previously ? Do you remember when ? Is it happening with other games ? Yes/no. Will explain.
If applicable, provide error messages, logs, screenshots, or whatever additional information that could help debugging this
The issue I am requested to report by @fafling is specifically about hardware validation code. In other words, I am the developer and I am looking for specific things the software (Saturn game) can do to determine whether it is operating on an emulator or on authentic hardware.
I, the developer, am therefore at liberty to prevent the game from running on an unapproved platform. As of now, Kronos is an unapproved platform for Slide Hop because Kronos does not implement a solution for the synchronization rate mis-match (59.94 vs exact 60hz). Kronos will instead skip a frame every so often to keep it mostly in sync. This causes the audio to skip, which I determine to be unacceptable and will therefore look for things to break the game for Kronos even if these specific issues are fixed but the sync issue is not.
Anyway, to the specific case, when launching the game via Kronos, this screen appears:![Capture](https://github.com/FCare/Kronos/assets/47374563/cdd5eb68-ef14-476d-a092-98797a0a43f3)
This screen (and the other emulator-check screen) is flagged here:
void hardware_validation(void) `{ load_drv(ADX_MASTER_1536); load_hmap_prog(); sdrv_vblank_rq(); update_gamespeed(); int start_time = get_time_in_frame(); run_hmap_prog(); //Dry-run the DSP to get it to flag done
}`
In other words, Kronos is specifically running the SCU-DSP too fast. The other emulators also run the SCU-DSP slightly too fast, but not as much as Kronos. Kronos in general runs all game code too fast. To some, I understand that performance being improved in an emulator is a GOOD thing. In my case I just seek a test which I can use to trip specifically Kronos and other Yabause forks. I also would like to have an emulator which was cycle-accurate but I understand that is WAY too much to ask.
The other factor is that all of the emulators do not run the M68k at the correct speed. In fact this test-case is for when the emulators run it too slowly. However, as stated, Kronos and other emulators tend to run all code (including 68K code) faster than real hardware. So I am not sure why the sound driver is initializing faster on real hardware than it is on emulators.