He and I both know the guy who programmed that audio driver. The author considers it an ongoing source of lulz that even bsnes sometimes glitches that audio but it's always perfect on real h/w.
I certainly wouldn't be proud of writing such flaky software, but to each their own
People tend to think that if something works on one real SNES, that it will work on every real SNES. Not true, those crystal clocks tend to vary per unit, if ever so slightly. I can almost guarantee you that even if it's only on 0.1% of SNES units, that some have problems with these types of games.
Anyway, I'm not aware of any audio glitches in this game. But I do know that we desperately need someone to clock the S-CPU crystal with an oscilloscope. We know that the S-SMP is rated at 24,576,000hz, but really runs at around 24,606,720hz. The S-CPU is rated at 21,477,272hz, but if it actually is off by such a large amount as well, it could very well be the cause of issues in Clayfighters.
If someone can reproduce Clayfighters sound issues, they can try modifying cpu.ntscClockRate in bsnes.cfg. I'm almost certain they could get sound perfected if they find the right value.
Depending on how it fails, some games seem to want the SPC700's RAM to be initialized on power-up.
Common SNES emulator practice is to flood-fill RAM with bit 5 of the address (but this doesn't fix Panic Bomber World. Already tried it). I believe Overload (of DSP-* fame) discovered that pattern.
I've heard this a lot, and since bsnes started, I've always filled APURAM with 0x00 on power-on. Never had any problems, not even with Bomberman games.
The only game I know that has issues with APURAM initialization is SD Gundam G-NEXT, an SA-1 game. It has some sort of issue if you don't clear certain parts of it on reset. I haven't looked into it much.
(something about Captain Commando (J) crashing in bsnes)
I can't reproduce that, it runs fine here. Any more details?
byuu, how much of a testing battery for things like interrupts and DMA do you still have?
I have a few test ROMs that combine a few dozen tests each.
But seriously, you don't want them right now. You will need extremely precise timing for them to work. They will fail if you're off by even a single master clock cycle.
You'll need bus-level (not cycle-level) accuracy, DRAM refresh, (H)DMA/CPU sync, the differences between CPU revisions 1 and 2, every opcode tested to ensure the cycle timing and ordering are correct, full MDR support, etc etc etc perfected before you try them.
At this time, no other emulator can even pass my seek_frame function, which when called, returns with the PPU counters at *exactly* V=0,HC=0 (H=HC/4, by the way. $213c reports the current *dot*, but there are four cycles per dot.)
You guys really need to drop the current CPU approach and go full-on at 21MHz. Be prepared that proper DMA sync timing requires executing the next cycle of the current position, which can be in the middle of two opcodes, and you need to be able to sync up all other processors while a DMA that can be up to ten frames long runs.
I never managed to pull that off flawlessly with state machines, so hopefully you guys are more skilled with those than I am.
I would love it if you guys could catch up, and especially if you guys could start performing your own hardware tests. I desperately need someone else who's really interested in SNES emulation to help motivate-and-work-with me, so we can start making real progress once again
Things have stalled badly since anomie left ...
