That is normally the case for period adventure games. The game itself is not as speed sensitive, it's the sound drivers that either run a timer calibration or have a response timeout and it hits the end of the counter too fast on faster processors.

You have to look around to see if someone has made a speed patch for each game you want to play. There's no way to universally avoid the issue on unpatched games without slowing down how fast the CPU performs the commands in the timer loop (which is done by slowing down the CPU).

Would it be possible to build a TSR that responds in place of the device itself? Or is it not just initialization but the entire time the device is being used?

Shagittarius wrote on 2026-01-27, 00:40:

Would it be possible to build a TSR that responds in place of the device itself? Or is it not just initialization but the entire time the device is being used?

It wouldn't help for device detection issues, the sound drivers are shipped with and customised for each game (or game engine version) and the issue which causes the sound device not detected error happens before any card or TSR can respond since it's coded into the game's sound driver directly.

There is also a buffer overflow issue on rev.0 MT-32 modules specifically due to sysex commands being sent too fast on newer systems, SoftMPU can delay sysex messages to help avoid that. PicoGUS also has that option.

Bummer, but thanks for the info.

I can confirm that Sierra games (KQVI) also have this issue.