bsnes

bsnes copied to clipboard

I realise that hacks don't usually count but this hack runs on the real hardware on SD2SNES with no issues. In the latest bsnes and higan upon opening the hack it just presents a black screen and you only hear the sound of a coin being collected (which is the intro sound for SMWC presents screen) then nothing. The hack is found here https://www.smwcentral.net/?p=section&a=details&id=14812

If it works on the SD2SNES, I would highly suspect the issue is that you're not initializing something properly. The SD2SNES initializes a lot of things for you in order to launch the menu firmware, so it's not the same as a cold boot. If you have somebody who can burn the game onto a repro cart and that also works fine on real hardware, then that would be a different story.

Just discovered It works in higan v106 but then breaks in v107.

I can narrow it down further it works in higan v106.06 but not higan 106.18. It also works in bsnes v106r44.

Thanks. That sounds more like the SA-1 timing changes then. I've been looking into bisecting the issue, but unfortunately that version is older than the available CI builds, so I'm having to build them all individually.

Thanks qwertymodo, here are the different bsnes and higan builds that I used if that's of any help? bsnes and higan revisions.zip

Thanks, but I don't need the ones you tested. I need to go through the rest of the ones you didn't in order to narrow down exactly which commit broke things. Then we'll know more about exactly what happened.

If it helps narrow it down even further for bsnes itself, it worked in bsnes v106r44 and it doesn't in bsnes v107.

commit: c2d0ed4ca8e24c560188805a5e4d02eaddc4316e Update to v106r62 release.

byuu says:

Changelog:

  - sfc/cx4: added missing instructions [info from Overload]
  - sfc/cx4: added instruction cache emulation [info from ikari]
  - sfc/sa1: don't let CPU access SA1-only I/O registers, and vice versa
  - sfc/sa1: fixed IRQs that were broken from the recent WIP
  - sfc/sa1: significantly improved bus conflict emulation
      - all tests match hardware now, other than HDMA ROM↔ROM, which
        is 0.5 - 0.8% too fast
  - sfc/cpu: fixed a bug with DMA→CPU alignment timing
  - sfc/cpu: removed the DMA pipe; performs writes on the same cycles as
    reads [info from nocash]
  - sfc/memory: fix a crashing bug due to not clearing Memory size field
    [hex_usr]
  - bsnes/gb: use .rtc for real-time clock file extensions on the Game
    Boy [hex_usr]
  - ruby/cgl: compilation fix [Sintendo]

Now let's see if I can accept being off by ~0.65% on one of twelve SA1
timing tests for the time being and prioritize much more important
things or not.

This is the test rom he used: https://github.com/VitorVilela7/SnesSpeedTest

Looks like SA1 timing is pretty much hardware behaviour since bsnes 106r62. SD2SNES on the other hand...

Version: 1.8.0 + RedGuy SA-1 v06 -- picture by terminator2k2

It works if you put

  //(SNV) S-CPU NMI vector
  case 0x220c: { mmio.snv = (mmio.snv & 0xff00) | data; return; }
  case 0x220d: { mmio.snv = (data << 8) | (mmio.snv & 0xff); return; }

  //(SIV) S-CPU IRQ vector
  case 0x220e: { mmio.siv = (mmio.siv & 0xff00) | data; return; }
  case 0x220f: { mmio.siv = (data << 8) | (mmio.siv & 0xff); return; }

inside SA1::writeIOCPU, but that is definitely not hardware accurate. It seems like sd2snes allows writing to those registers from the SNES side? That should make real hardware crash (see: https://github.com/VitorVilela7/SA1-Pack/releases v1.25)

If I get a chance, I'll throw the SMW ROM onto one of my spare SA-1 boards and see what happens on real hardware.

Thanks for looking into this guys.

Thanks for looking into this guys.

can you also let the creator of the Mesen-S emulator know about the problem, sharknnth?

the SMW VLDC9 game also does not work on Mesen-S as well as on recent versions of bsnes while it works just fine with snes9x 1.60.

i'm waiting to see if this may get resolved in a future bsnes/higan release

I looked into this a few months ago: http://forums.nesdev.com/viewtopic.php?f=12&t=18658&start=270#p247130

byuu confirmed that the current behavior of bsnes/higan/mesen-s as far as restricting which registers can be accessed by which CPU is supposed to be correct: http://forums.nesdev.com/viewtopic.php?f=12&t=18658&start=285#p247384

So unless someone tests on a SA-1 board and determines that the romhack works on hardware, it sounds like the problem is the romhack itself.

then how come VLDC9 works perfectly in the latest version of the snes9x emulator without any problems, SourMesen?

That's not a good comparison. SNES9x isn't that accurate. That's why we have to investigate the exact behaviour on hardware.

I was curious to test this on real hardware as well. Unfortunately it's larger than the M27C322 that my SA-1 dev cart takes. I tried flashing it anyway, in truncated form, and I got a black screen. Is there any other way I can help test it?

Could the previous behavior be enabled in compatibility settings? VLDC8 is also broken.

While compatibility options to make VLDC run wouldn’t be a bad idea, future versions of Snes9x and/or SD2SNES may also break them if they’re broken on real hardware. As always, the ROMs themselves should probably be fixed for maximum compatibility.