Super Mario World - 9th Annual Level Design Collaboration (SA-1) Hack about bsnes HOT 19 OPEN

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.

from bsnes.

commit: c2d0ed4
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.

from bsnes.

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

from bsnes.

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

from bsnes.

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.

from bsnes.

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

from bsnes.

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

from bsnes.

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.

from bsnes.

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

from bsnes.

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.

from bsnes.

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

from bsnes.

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)

from bsnes.

Thanks for looking into this guys.

from bsnes.

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

from bsnes.

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.

from bsnes.

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

from bsnes.

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?

from bsnes.

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

from bsnes.

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.

from bsnes.