bsnes release 2018/01/17 opcode bug

[ghost]

Hi, I just tried your latest release: http://www.emucr.com/2018/01/bsnes-plus-git-20180117.html to test msu1 emulation. Thanks so much to not require xml anymore ;)

However there's a strange bug. I hooked in the nmi with this code:

LDA $0401 ;check busy flag
AND #$00FF
BEQ $03

It uses to emulate this code as it should:

01f08b lda $0401 [000401] A:00ff X:0008 Y:0000 S:01ef D:0000 DB:00 NvmxdIzC V:198 H:181 F:39 01f08e and #$00ff A:ff00 X:0008 Y:0000 S:01ef D:0000 DB:00 NvmxdIzC V:198 H:191 F:39

And after a while (it's in the nmi, so the code is called quite frequently, suddenly this happens:

01f08b lda $0401 [0f0401] A:0020 X:0009 Y:003c S:01e0 D:0000 DB:0f nvmxdIzc V:225 H: 88 F:39 01f08d tsb $29 [000029] A:207e X:0009 Y:003c S:01e0 D:0000 DB:0f nvmxdIzc V:225 H:102 F:39

So it reads only 2 bytes instead of the 3 bytes in the lda $0401 command. My best guess is a vblank issue? I try to make a workaround and clear the flag before executing my additional code or something.

The rom: Super Mario World 2 - Yoshi's Island, with msu1 patch applied: https://www.zeldix.net/t1606-super-mario-world-2-need-pcm#23766 snes9x 1.55 doesn't have this issue.

[devinacker]

I'll try to check this out, but fair warning: EmuCR builds are not official and have a history of sometimes being subtly broken due to sloppy builds or something, so it's possible that this doesn't actually happen when built from scratch or in any of the official release versions.

In particular, the code that controls how many bytes PC moves forward for any given instruction has not changed at all since many years before bsnes-plus even existed, so it's unlikely that this bug is recent, if it even exists at all. If possible, can you verify whether or not it also happens in the most recent official release?

[devinacker]

I'm also not going to sign up on that forum just to be able to download one attachment, so please upload it somewhere else (or send it to my email address) if you'd like me to test it.

[devinacker]

Updating for the viewers at home: I got more information via email and now it looks like this may be a CPU/GSU concurrency issue (which would happen on a real SMW2 cart and also in higan), rather than an emulation bug.

[devinacker]

update: yep, that was it. running the MSU code from RAM has no issue

[mrehkopf]

So the S-CPU is seeing something different during / just before execution (presumably of the 3-byte instruction) which makes it read a 2-byte instruction because the GSU is claiming ROM just at that point... Is there any way to make the debugger reflect/anticipate that? Either way it should become evident by (manually) observing the GSU's RON flag at that moment.

[devinacker]

Right now the SuperFX ROM class just bypasses the usual logic and always shows actual ROM if the bus is being read by the debugger, I'm not really sure if there's any good reason to keep it that way, since normally that's only meant to avoid reads/writes which have side effects. It definitely would have made the actual issue here a little more obvious.