search

libretro / bsnes2014

Libretro fork of bsnes. As close to upstream as possible.
GNU General Public License v3.0
9 stars 17 forks source link

Some MSU-1 games not working #14

Closed andres-asm closed 8 years ago

andres-asm commented 8 years ago

Megaman X2/X3 crash after the Capcom logo

Whenever SuperRoadBlaster locks up and you can't even alt-tab or go back to the GUI, goes into what seems like an endless loop but the frame counter keeps updating (windows register the app as not responding and even then the fps counter keeps updating but input doesn't work)

andres-asm commented 8 years ago

UPDATE: superroadblaster works, had to fix the BML a bit. Worked at least, al MSU1 games broke with the input lag fix

Alcaro commented 8 years ago

what, that makes absolutely zero sense. unless @Brunnis chose a bad spot to reset the 'frame sent' flag or something, and even then, it shouldn't have anything whatsoever to the MSU.

andres-asm commented 8 years ago

This issue is older than Brunnis' fix. Some guy reported that MSU-1 games that worked are no longer working.

I was able to reproduce and a quick git bisect/build/test repeat later this came up as the first bad commit:

https://github.com/libretro/bsnes-libretro/commit/29f29c9c98824cdd1c7f0d25d428dc27df13ba02

Alcaro commented 8 years ago

That IS Brunnis' fix.

...And yes, that's a suspicious place to reset the frame sent flag. If the screen is off on scanline 0 - iirc Road Blaster does that - then HDMA isn't inited, and the flag isn't cleared either.

Better to clear it on that scanline 241 handler.

Brunnis commented 8 years ago

I agree, the frame event should obviously be reset in system.cpp when scanline 241 is reached.

I've reviewed the changes and everything looks good, except this commit (please see comment on commit): https://github.com/libretro/bsnes-libretro/commit/f8bd7b7eba15f05d040aa4a63eda80249a4647af

Also, I still haven't been able to reproduce the MSU-1 issue. I've played some Mega Man X with the MSU-1 patch and I haven't run into any issues yet.

andres-asm commented 8 years ago

At least two people have reported it crashing on Windows On Jul 10, 2016 3:27 PM, "Brunnis" notifications@github.com wrote:

I agree, the frame event should obviously be reset in system.cpp when scanline 241 is reached.

I've reviewed the changes and everything looks good, except this commit (please see comment on commit): f8bd7b7 https://github.com/libretro/bsnes-libretro/commit/f8bd7b7eba15f05d040aa4a63eda80249a4647af

Also, I still haven't been able to reproduce the MSU-1 issue. I've played some Mega Man X with the MSU-1 patch and I haven't run into any issues yet.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/libretro/bsnes-libretro/issues/14#issuecomment-231609091, or mute the thread https://github.com/notifications/unsubscribe/ABpC0ITeTENsMPRgv9n7DIxPkhj0Yv3Nks5qUVXAgaJpZM4IYkSy .

andres-asm commented 8 years ago

Ok found the issue, the problem only happens with rewind enabled which means something is going wrong with the serializer with your hack I guess.

Backtrace: 

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 12032.0x48c]
0x00000000004107fb in find_same (a=a@entry=0x11014a52, b=b@entry=0x10fcde72)
    at libretro-common/algorithms/mismatch.c:124
124           while (*a_big != *b_big)
(gdb) bt
#0  0x00000000004107fb in find_same (a=a@entry=0x11014a52,
    b=b@entry=0x10fcde72) at libretro-common/algorithms/mismatch.c:124
#1  0x000000000042e79b in state_manager_raw_compress (patch=<optimized out>,
    len=<optimized out>, dst=<optimized out>, src=<optimized out>)
    at managers/state_manager.c:188
#2  state_manager_push_do (state=0x601d320) at managers/state_manager.c:443
#3  0x000000000042f2da in state_manager_check_rewind (
    pressed=pressed@entry=false) at managers/state_manager.c:634
#4  0x000000000041066f in runloop_check_state (
    shader_dir=0x78a220 <runloop_shader_dir>, cmd=0x37ffc50) at runloop.c:696
#5  runloop_iterate (sleep_ms=sleep_ms@entry=0x37ffda0) at runloop.c:1462
#6  0x00000000004016b0 in rarch_main (argc=<optimized out>,
    argv=<optimized out>, data=0x0) at frontend/frontend.c:122
#7  0x000000000063822a in console_main ()
#8  0x00000000006382e1 in WinMain ()
#9  0x00000000004013ed in __tmainCRTStartup ()
    at C:/repo/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crtexe.c:332
#10 0x00000000004014fb in WinMainCRTStartup ()
    at C:/repo/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crtexe.c:184

Edit: disabling rewind fixes the original issue with CX4 games too, so something is definitely wrong on the serialization part

Brunnis commented 8 years ago

Thanks for testing and finding out where things go south. So, it looks like serialization was botched already before I added the "frame_event_performed" field... To be honest, I don't really know much at all about how the serialization stuff works, so I'll need to read up on it before I can attempt a fix.

Brunnis commented 8 years ago

I just confirmed that it's not the lag fix itself that causes issues with MSU-1 games. Simply adding the frame_event_performed flag to the CPU Status struct (and disabling the other parts of the lag fix code) will make the core crash with Mega Man X with MSU-1.

Turning off the lag fix just seems to hide the problem, at least to a degree (MMX2 and MMX3 crash even without the lag fix). It's probably the serialization code that needs to be fixed.

Brunnis commented 8 years ago

I believe I've found and fixed the issue. Please see pull request above.

Brunnis commented 8 years ago

Great, it's been merged. @fr500 could you test this with MM X2 and X3 with MSU-1?

Brunnis commented 8 years ago

I've performed tests on MegaMan X (MSU-1) and SMW2 (no MSU-1) in both RetroArch 1.3.4 and the latest nightly with the savestate fix from commit 13839e6. All tests were done with rewind enabled. I tested both bsnes and bsnes-mercury, but the results were exactly the same.

RetroArch 1.3.4, lag fix off

Accuracy

Balanced

Performance

RetroArch 1.3.4, lag fix on

Accuracy

Balanced

Performance

RetroArch 1.3.6 + savestate fix, lag fix off

Accuracy

Balanced

Performance

RetroArch 1.3.6 + savestate fix, lag fix on

Accuracy

Balanced

Performance

So, as expected, the crash could occur even without MSU-1 or the lag fix. Also as expected, the fix seems effective for all of the observed failure cases. This issue must have caused crashes here and there for a long time...

Given the above results, I believe this issue can be closed, but we should of course confirm that the issues originally reported with MM X2/X3 with MSU-1 have been solved as well.