I am not a programmer, but I was pointed here to post the bug I have. I will do my best so please bear with me.
Not sure if this counts as RetroArch bug because of Run-Ahead or as a core bug because of the specific core.
In RetroArch 1.7.6, the Genesis Plus GX core does not correctly load the Sega Master System boot loader screen before transitioning to the game ROM. If EITHER Run-Ahead in RetroArch OR the system boot ROM loader in the Genesis Plus GX core are disabled, the bug doesn't appear. However, with both options enabled, the bug appears.
As a side note, if EITHER Run-Ahead or the system boot ROM loader are disabled, then everything runs as expected, however, not with BOTH enabled.
RetroArch: 1.7.6, build date 03 FEB 2019.
OS: Windows 10 64-bit.
Compiler: Pre-compiled build for Windows 10 64-bit downloaded from the RetroArch website.
You could ask @Dwedit.
Yes, this is a known bug, but I never really bothered with it since it's only relevant if you load/save state before a specific point when running Master System BOOT ROM, which indeed becomes a problem when using run-ahead feature since it does that every frame...
From what I remember, it is related to some missing infos in Master System saved state but also the order stuff are restored back when state is loaded.
Ok, I understand this is a known bug and I assume it'll be fixed eventually. I'll simply leave the BOOT ROM option off for now, since I believe that Run-Ahead is the more desirable option in this case.
I once made an extensive save state tester.
It uses two instances of the emulator, and makes comparisons. One instance never loads state, and just saves state. The other instance will do both saving and loading state, and possible running multiple frames between loading state.
It compares these, and all must match for it to pass:
When I saw a discrepancy, I tried to see why the savestate didn't match.
When I was trying to fix savestate issues in Snes9x, I saw two different kinds of problems.
One was "minor" problems, where the CPU ends up executing the same code, but the resulting savestate still differs. This was caused by information deemed "not important enough" to be stored into the savestate, but if the savestate did not contain that information, it would cause graphics state to diverge in a minor way, and no longer matched. (Even though the generated frame image still matched exactly.)
Then, there were times where the CPU execution path would outright diverge, and I would need to use a trace log to see what caused the divergence. One time it was some "open bus" variable that wasn't stored into the savestate when it should have been.
Should now be fixed by this commit
https://github.com/ekeeke/Genesis-Plus-GX/commit/e819af455344b998669cfd4a8489d29470b77da7
I tested it by saving/loading state while Boot ROM or loaded ROM is running and it seems fine.
@summonthethunder Can you update your Genesis-Plus-GX core and confirm if its fixed or not?
Just tested it and it seems to work! I recreated the earlier steps and I can't reproduce it after a core and assets update.
Great, thanks for testing and thanks a lot for taking the time to fix it @ekeeke. Unless someone else can reproduce this again in the future I'm going to close this as fixed. :)
Most helpful comment
Yes, this is a known bug, but I never really bothered with it since it's only relevant if you load/save state before a specific point when running Master System BOOT ROM, which indeed becomes a problem when using run-ahead feature since it does that every frame...
From what I remember, it is related to some missing infos in Master System saved state but also the order stuff are restored back when state is loaded.