Man, really sorry. I don't recall having bugs in any of the games you guys currently list as broken.

Also, be warned: bsnes's CPU is heavily integrated with (H)DMA and other stuff that's on-die with the S-CPU.

Sort of. class CPUcore is just the raw 65816. I actually do need to add some tiny things for some special SA-1 edge cases, though.

Both class sCPU and class SA1 inherit the 65816 core, and then add their own extra hardware units.

So the game sets an HIRQ it doesn't want to ever get? That's perverse.

You're going to love some of the stuff you find in the future.

Here's a fun one ... game has the following:
-; bit $4211; bpl - //wait for IRQ acknowledgement

lda $4211 //clear IRQ acknowledgement flag

Yes, the games can break out of that loop, and many will lock up if they do not. The Snes9X team gave up on trying to support this with an opcode-based core.

There is a 6-cycle hold time for the interrupt lines. If you read them at just the right time within them, you can:
- cancel the pending interrupt, or
- read the acknowledgement bit as set twice in a row

Ah, and the fun cli stuff that shows the two-stage pipeline nature of the 65xx chips. Since IRQs are tested on the bus opcode edge, that is one stage ahead of the work cycle to clear cli. Thus an IRQ can still trigger immediately after a cli instruction has executed. But rep/sep and rti are different, because their I flag is cleared sooner within the cycle.

I believe F-1 Grand Prix and Sink or Swim do something sick like trigger HIRQs more than one time on the same line or something. You guys should play those for a bit and see how they respond in MESS.

but in MESS is 0x5555, and that's obviously fucked up ...

Sounds like it's reading from uninitialized WRAM. 0x55 is such a fun pattern, multiple titles break without it, despite the fact that SNES WRAM is DRAM-based, and is thus completely unpredictable upon power-up, with serious variations across each run.

And the YM2143 samples will eventually be converted to external load - it's on my todo list, albeit at a fairly low priority.

Be sure to externalize the S-DSP gaussian interpolation table, and the S-DSP counter lookup table, and the S-PPU light table while you're at it wink
Pro tip: $2100 INIDISP display brightness of zero isn't absolute black. If you max out your TV settings, you can still see the image. And thus, the ramp is not linear in nature, nor does it operate in the RGB colorspace.

I'm not sure the timing is as much of a problem as you guys are hoping. ZSNES doesn't even count cycles when executing the CPUs and it runs most if not all of those games cited. (It may be that eta's various attempts to enforce timing when we don't have any is ultimately harmful though).

Indeed, I'm probably doing no good here.

There's lots of very edge-case games that require the most bizarre behavior you've ever seen. Like Speedy Gonzales and Wild Guns, for instance. But you guys are hitting some really simple things.

My discussion of these extreme edge cases is probably a mere distraction with the current state of things, and you'll probably just implement them incorrectly, possibly causing more bugs. The basics really need to be addressed first.

I guess what I'm hoping for in explaining the low-level stuff is that you guys will realize the futility of an opcode-based core, and move to cycle-based before you waste too much more time fixing up a dead end ...

By understanding the lowest level stuff now, you know exactly what your core will need to be able to handle, and can skip the 4-5 core rewrites I had to go through.

Also, one thing I will say, is that the VRAM write disable isn't hurting anything. Please don't even make that an option to bypass.

Regardless of whether or not it was ever their intention, the VRAM write issue has made ZSNES the IE6 of SNES emulators. It is the "extend" element of Microsoft's strategy. Why move to another emulator if it's going to break your (already broken) fan translations?

If your timing is really that awful, then adjust the range that you block writes. For instance, instead of blocking during V=0-224, change it to only block during V=8-216. Same effect, much more forgiving timing-wise.

We need every last emulator to counter this broken behavior and push for actual standards, so that we don't end up with more ZSNES-only software, perpetuating the negative feedback loop further.