Request: Comprehensive DSP1b test ROM

[Alyosha_TAS]

Hello,

I have recently been working on SNES console verifications of Tool Assisted Speedruns, but have grown frustrated with nearly everything I try desyncing on console. I'm tired of wasting all my free time on things that don't work, I don't have hundreds of hours to build up my SNES knowledge to the level where I can contribute. But, through the power of tax refunds, I can at least throw some money at the problem to hopefully provide some motivation to someone who knows the SNES.

I have opened github issues for the following problem on bsnes and Ares pages, but this seems to be a place where a lot of snes people come so I am posting here too.

The problem is in Super Mario Kart, specifically on Vanilla Lake 1. I have a TAS that plays through 25 minutes, beating Mushroom Cup and Flower Cup, and the first two course in Star Cup before desyncing on that track. I also have a much shorter TAS that only plays star cup, but also desyncs on Vanilla Lake 1, seemingly in a deterministic fashion. Curiously, another TAS that plays time trials does sync on that track.

Most desyncs I encounter are non-deterministic, which I attribute to the clock on the sound chip being imprecise, but these desyncs are not like that. Also playing through 25 minutes in the longer run is pretty good evidence that the sound chip is not to blame, so it really seems like it's a DSP1b issue, with something specific to whatever that track is doing (maybe ice physics?) or some other deterministic cause.

So, I am offering a reward for (hopefully) the resolution of this issue, through a comprehensive, publicly available test ROM that is thorough enough to either show a discrepency between hardware and emulator, or show that the problem must lie elsewhere. (What I have in mind is something similar to https://github.com/VitorVilela7/SnesSpeedTest.) My personal cart uses the DSP1b, so that is why I specified that version.

If you are interested, please PM with what price you think is commensurate with your time and talents towards working on this problem. I'll even pay some percentage up front if you can be reasonably convincing that you are seriously going to attempt it. (If you read the above and think the problem is lies elsewhere entirely, I'll pay for proof of that to, I really just want to see this fixed.)

Just to be clear up front, the max I can pay is $1000, and for that amount I would expect a dev. board (I can supply my copy of SMK), a pretty polished test ROM, and some decent documentation about what is happening on Vanilla Lake 1.

Update: reward no longer available, I'm making my own snes emulator to test.

I'll gladly provide any additional details and answer any questions.

[lidnariq]

Also playing through 25 minutes in the longer run is pretty good evidence that the sound chip is not to blame, so it really seems like it's a DSP1b issue, with something specific to whatever that track is doing (maybe ice physics?) or some other deterministic cause.

The DSP-n use the same kind of cruddy low-quality clock source (PZT ceramic resonator) as the sound chip - just at 7.6MHz instead of 24.576MHz.

This doesn't mean that it's not deterministic, but it does mean that nondeterminism can't be trivially ruled out.

[calima]

The original Super Everdrive had an option for a real DSP chip to be included. Tracking down one of those may be easier than doing a new dev cart.

The X6 version's DSP is FPGA emulation, like sd2snes's.

[none]

Mesen-S has accurate DSP Emulation (in the sense of actually emulating the firmware)

https://github.com/SourMesen/Mesen-S/bl ... NecDsp.cpp

Maybe it is possible to try and screw with the timings and see if that can reproduce the issue.

[Alyosha_TAS]

The DSP-n use the same kind of cruddy low-quality clock source (PZT ceramic resonator) as the sound chip - just at 7.6MHz instead of 24.576MHz.

This doesn't mean that it's not deterministic, but it does mean that nondeterminism can't be trivially ruled out.

If everything else gets ruled out and it's just (another) clock issue, that knowledge is just as valuable to me.

The original Super Everdrive had an option for a real DSP chip to be included. Tracking down one of those may be easier than doing a new dev cart.

The X6 version's DSP is FPGA emulation, like sd2snes's.

I try to avoid things like everdrive whenever possible in my testing and stick to original hardware. For my purposes 'dev board' can just be replacing the ROM in Super Mario Kart with a socketed EEPROM.

Mesen-S has accurate DSP Emulation (in the sense of actually emulating the firmware)

https://github.com/SourMesen/Mesen-S/bl ... NecDsp.cpp

Maybe it is possible to try and screw with the timings and see if that can reproduce the issue.

I'd really like to have something stronger then guessing, particularly about timing. (And in my experience, I'm not a particularly good guesser.)

[Alyosha_TAS]

A little more info here. Morilli made a build where I could vary the DSP1b clock speed to see how it effects the run. The Star Cup run syncs on emulator in a range of clock speed from 7 to 8.2 MHz (default is 7.6.) At 6.95 and 8.3 MHz it desyncs in the first stage due to bad item RNG. So, it seem like imprecise clock is not likely to be the issue.

[Alyosha_TAS]

It's been over 2 years since I posted this, and since there is no solution yet, I have decided to remove the reward I previously offered and instead will make my own snes emulator to sort out the details.