Retroarch: Run-Ahead breaks system boot ROM loading for Genesis Plus GX (Sega Master System) when both options are enabled.

Created on 4 Mar 2019  路  8Comments  路  Source: libretro/RetroArch

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.

Description

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.

Expected behavior

  1. With Run-Ahead set to 1 and Run-Ahead second instance enabled, and:
  2. Genesis Plus GX core downloaded and configured to show the system boot loader, then:
  3. Boot loader screen plays correctly for the Sega Master System, then correctly transitions to the game ROM.

Actual behavior

  1. With Run-Ahead set to 1 and Run-Ahead second instance enabled, and:
  2. Genesis Plus GX core downloaded and configured to show the system boot loader, then:
  3. Boot loader screen does not display correctly (instead, jumping immediately to the game rom), but plays audio correctly, leading to a 10-15 second delay between graphics and sound.

Steps to reproduce the bug

  1. Run-Ahead Set to 1 and Run-Ahead Second Instance enabled.
  2. Genesis Plus GX core, Options, System Boot Rom enabled
  3. Load any Master System ROM.
  4. See 'Actual behavio'r above.

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.

Version/Commit

RetroArch: 1.7.6, build date 03 FEB 2019.

Environment information

OS: Windows 10 64-bit.
Compiler: Pre-compiled build for Windows 10 64-bit downloaded from the RetroArch website.

runahead core issue

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.

All 8 comments

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:

  • Byte content of savestate
  • Byte content of video frame
  • Byte content of generated audio buffer

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. :)

Was this page helpful?
0 / 5 - 0 ratings

Related issues

hyarsan picture hyarsan  路  4Comments

GoronMegaZord picture GoronMegaZord  路  3Comments

bslenul picture bslenul  路  3Comments

ghost picture ghost  路  3Comments

orbea picture orbea  路  3Comments