How do I fix the plane crashing short of the runway in the demos? For the life of me I tried all revisions of DSP firmware like dsp1.data.rom and dsp1.program.rom in retroarch system folder. Retroarch bsnes core information says I have all the necessary dsps. I am using the recent bsnes core. I am using retroarch 1.15 on Android 11 sd855+ with vulkan driver.
try getting rid of dsp1b if you have them.
Yeah I already tried that! Are they supposed to be renamed something else?
hmm, i’m having trouble getting latest bsnes and bsnes-hd-beta to land the plane, too. However, I got bsnes2014 to do it by renaming the dsp1 images to dsp1b:
I gave it a shot and the first couple of tries I crushed to the ground with bsnes (115), then I tried snes9x and mesen-s and landed correctly…then I went back to bsnes and I landed like 5 times in a row…it seems to work and I didn’t change anything 
edit: I’m on windows
I tried doing the renaming too, but no dice. Anyway I opened an issue with the libertro bsnes GitHub as a possible regression. Funny thing is that mesen-s works fine with the dsps. But I prefer bsnes because it has larger screen area on Android for games like Star Fox.
I was under the impression that the modern versions of bsnes don’t use the firmware files from the system folder at all. It uses the firmware from the rom file itself. Am I wrong?
@magichost To confirm if the files in the system folder are being used at all, create an empty file and rename it to the firmware file you’re trying to test.
Yeah, that should at least be an option if not required. However, I just tried appending dsp1.program.rom, dsp1.data.rom (and vice versa) and even tried appending the old dsp1.bin to no avail.
Here are the md5sums I tried:
8dcb216beed58c798b25df55f62218d0 <- original
76a340d41c3466ef7370b08e0b6e3952 <- program then data
5265aad28a102d7a1a03cd28fd662c40 <- data then program
bbf8e6c8d1a59479bc7df5a6e575d875 <- dsp1.binAre you sure you’re not using HLE for the DSP?
This core option defaults to ON:
You need to disable it to be able to use the firmware files from the system directory.
Well I used an md5 checksum checker app, and all of my dsp hashes matched what is required in libertro bsnes docs. So I know I have the right firmware. As far as creating an empty DSP file, the emulator would just reject it with no warning probably and run the game with less accurate built in hle DSP emulation.
yeah, i made sure to disable that. good thinking, though.
Did you check if the core option I posted above is disabled though? Your DSP files won’t be used if the option is enabled.
Yes I made sure that option was disabled.
1 Like
Then I’m out of ideas.
But I would still try the empty file. Who knows, it might at least give you the confirmation that the file is being used if it spits out an error.
Just tried a bsnes core from 2020 and it still doesn’t work. And yes I renamed the DSP files to different variations to make sure. I’m starting to think retroarch 115 somehow broke the core, and it may have something to do with the info file for bsnes being misconfigured. I also checked the config file for bsnes. Nobody responds at the libertro bsnes GitHub…so. Hope somebody can fix this problem because dsps are very important to accurate emulation.