Rushing Beat plays fine here without any mul/div timing.

The only thing the mul/div timers do is allow you to return incorrect mul/div results if the registers are read too early. The calculation runs in parallel with the SNES, so the S-CPU timing isn't really affected by this.

The only way a game can 'not work' by not emulating these calculation delays is if they ask for a value to be multiplied or divided, and only work when the result of that operation is incorrect. Do think about how absurd that would be for a moment.

Now even in the unlikely event that a game out there did rely on this, it would be expecting at least the 'correct' wrong result, and not whatever you guys return in that instance (0x00? The original value? Both are wrong.)

If it fixed the game in MESS, it was because of some other error being avoided by it.

Don't get me wrong, I am not making excuses for not supporting this properly. It sucks, and it's a gaping problem in our emulators if we want to claim they are accurate. It's just a really tough problem, and faking this delay isn't going to do any good; except maybe to alert ROM hackers / translators / demo coders that this delay exists when their code gets the wrong results. ( and subsequently result in RHDN posts that our emulators are inaccurate because ZSNES runs their broken code fine :P )

I need someone who can run tests on real hardware and is willing to bang out a metric ton of code and test results to analyze. I can't find the motivation right now to do that myself.