Super Robot Taisen Gaiden - Masou Kishin - The Lord of Elemental crashes Snes9x

[ImSpecial]

Super Robot Taisen Gaiden - Masou Kishin - The Lord of Elemental (Japan)
Snes9x 1.55 (OV's test build 05-24-2018)
Windows 10 64-bit

During the intro sequence before the first mission the emulator just locks up.

Not sure what else to add. :/

[OV2]

Seems to no longer be an issue in the latest git.

[ImSpecial]

Just grabbed the latest off of EmuCR and it still happens.

https://i.imgur.com/VBqj6j8.png

And with a clean Snes9x.ini

https://i.imgur.com/pTGGYtI.png

[OV2]

You can try the most recent automatic appveyor build: https://ci.appveyor.com/project/snes9x/snes9x

I'll make a new testbuild soon.

[ImSpecial]

Yeah same thing unfortunately.

https://i.imgur.com/2PbaEAx.png

EDIT: Also verified the rom, it seems good.

Super Robot Taisen Gaiden - Masou Kishin - The Lord of Elemental (J).smc
EBADC924
680EE04AF6792C3891947B43B98EED46
3FA8B1EDEB9A42916A1B59634D7EEAC0A5B26966

[bearoso]

I'm using the same rom image and it works. On GTK+ port, at least.

[ImSpecial]

For what its worth, I wasn't able to get it to crash with higan_v106-windows
EDIT: and seems to works fine with v1.55, so a regression somewhere, sometime happened...

[OV2]

I can't even get it to crash with the emucr build. How are you triggering it? Are you just pressing A until you get there? Do you let it idle somewhere?

[bearoso]

I'm not even getting a crash with the new translation patch.

[bearoso]

I notice in his screenshots that the whole program is unresponsive. Maybe something to do with syncing spinlocking again?

@ImSpecial: Try turning off sound syncing and/or the automatic input rate box and see if it still locks up.

[ImSpecial]

I should say that it happens "sometimes". I have gotten past this part before, but the crash seems to happen very regularly, it might be turbo related? Like, as I'm testing and reproducing this over and over again, I just hold down the turbo key to get to this part. I can make a Save state right before, and sometimes get past it, sometimes it locks, it's like a 50/50.

All I can say is maybe try several times.

[ImSpecial]

I've tried with both sound syncing on/off and made no difference, not sure what " automatic input rate " is...

[bearoso]

No cheats enabled, either?

[ImSpecial]

Nope, happens with a clean snes.conf file too, also I'm not alone so it's nice knowing I'm not crazy here.

[bearoso]

Ok, I reproduced it on windows using a release build, but couldn't on a debug build. That's not good, because it might be the optimizer screwing with things.

[ghost]

Just tried it on Snes9x 1.55-171 Dev Build May 30 2018 appveyor no crash

Hmm no crash on release 1.55 either.

Using WIndows in OPEN GL and D3D

[bearoso]

I've already reproduced the crash numerous times. It's temperamental and dependent on compiler. I'm trying to track it down.

[ghost]

i see that you have im saying these two builds dont so maybe that helps i dunno :)

[bearoso]

I've tried that build, too. It still crashes. It's random: if you can run through it 5 times or more with no crashes, then it's probably ok.

[bearoso]

Tracked it down to 3553650, the Speedy Gonzales commit. For some bizarre reason, this coupled with enabling optimization causes the crash. Only on Visual Studio. With gcc and clang on Linux it's fine.

[OV2]

I've tried the latest git about 20 times and only got the crash once, so I guess it's somehow timing related?

[bearoso]

I was guessing more like uninitialized memory being used. But I don't know why that commit would cause it.

[bearoso]

But the uninitialized memory thing does fit with the debug/release discrepancy.

[bearoso]

Should be fixed now. No idea why the VS optimization broke it. I moved the openbus set to the last register Speedy writes during HDMA, 212D, since we know that because Speedy does it that the hardware does it, too. It's very likely that having all PPU writes go through OpenBus was wrong, so this is a better fix.

[ImSpecial]

Using the latest appveyor build, I gave the intro probably a good 10 run-throughs and was not able to get it to lockup once, so I'm thinking you got this bug fixed.

[bearoso]

One can only hope so. :-)

[OV2]

I think I've found the root issue in S9xGetWord:
return (OpenBus | (S9xGetByte(a.xPBPC) << 8));

Bitwise or does not specify an evaluation order, and MSVC will reorder it to this:

00000001400612CE  mov         ecx,dword ptr [a]  
00000001400612D2  call        S9xGetByte (0140060BE0h)  
00000001400612D7  movzx       ecx,al  
00000001400612DA  movzx       eax,byte ptr [OpenBus (01405AEED3h)]  
00000001400612E1  shl         ecx,8  
00000001400612E4  or          ax,cx  

This causes problems when OpenBus changes during S9xGetByte, in this instance when HDMA triggers and S9xSetPPU runs. Looks like this:

$00:91C3 7C E1 9F    JMP ($9FE1,x)[$00:9FB0] A:001E X:001E Y:0000 D:0000 DB:01 S:0374 P:envmxdizc HC:1068 VC:163 FC:56   V .    HT:10 VT:223 C:81850
*** HDMA Transfer HC:1108, Channel:60
--- HDMA PPU 2132 -> 80
--- HDMA PPU 2132 -> 40
--- HDMA PPU 2132 -> 20
$00:9F20 1F 00 49 1F ORA $1F4900,x[$1F:491E] A:001E X:001E Y:0000 D:0000 DB:01 S:0374 P:envmxdizc HC:1166 VC:163 FC:56   V .    HT:10 VT:223 C:81850
$00:9F24 00 1A       BRK #$1A                A:1F1F X:001E Y:0000 D:0000 DB:01 S:0374 P:envmxdizc HC:1210 VC:163 FC:56   V .    HT:10 VT:223 C:81850
*** BRK
$00:E875 78          SEI                     A:1F1F X:001E Y:0000 D:0000 DB:01 S:0370 P:envmxdIzc HC:1274 VC:163 FC:56   V .    HT:10 VT:223 C:81850
$00:E876 DB          STP                     A:1F1F X:001E Y:0000 D:0000 DB:01 S:0370 P:envmxdIzc HC:1288 VC:163 FC:56   V .    HT:10 VT:223 C:81850

(address discrepancy between the disassembly of JMP and the next command)

The lockup is then because it runs into an STP command, in which case we no longer leave the main loop unless we're in DEBUGGER mode. Should we maybe add DEBUG_MODE_FLAG as a break condition even in regular mode?

[bearoso]

Should we maybe add DEBUG_MODE_FLAG as a break condition even in regular mode?

Probably. I don't imagine a state where we never return from S9xMainLoop is ever a good idea.