Just to rule it out, though: could you try configuring your sound card to use base I/O address 220 and play Mystic Towers with that? It's unlikely that this would be the cause, but 220 is so universally considered the safe default, that I don't think it's ever a good idea to deviate from that.

If you get sound, then the address is not the problem. The sound stopping after a while might indicate an IRQ issue, but 10 seconds seems way too long for that. The only advice I can give is to make sure that the BLASTER environment variable is set up correctly, since that's what the game uses when initializing the sound blaster (-compatible) card. There should be a SET BLASTER=... line in your AUTOEXEC.BAT.

If the SET BLASTER=... line is missing, the game defaults to address 220, IRQ 7 and DMA 1. The game will also use the default value if the corresponding entry is missing in the BLASTER string. The game shows the sound blaster settings at startup, so it should be easy to check if those are the correct values for your system. At least that's how it is in version 1.11 of Mystic Towers.

It's NOT missing, it's there, and yes the games shows the settings correctly, like I said in my first post. Otherwise, the sound would not have been played at all. Strangely enough.

digger, I'll try that and get back to you - I was hoping not to open the case for the nth time but oh well.

Yep, setting the base I/O address to 220 will definitely help. Further analysis showed that even though the code parses the BLASTER string and sets the base address variables accordingly, there are still a couple of instances in the code that are hard-coded for base address 220 and prevent the playback routines from working correctly with any other I/O address.

jefklak wrote on 2020-09-28, 13:58:

digger, I'll try that and get back to you - I was hoping not to open the case for the nth time but oh well.

Don't close the case until you know it's all working correctly 😉

Also, it's odd that the SB16 is on I/O 240-- what's on 220 that you couldn't choose that instead? And are you sure nothing else (like a NIC, perhaps) on 240?

K1n9_Duk3 wrote on 2020-09-28, 20:31:

Yep, setting the base I/O address to 220 will definitely help. Further analysis showed that even though the code parses the BLASTER string and sets the base address variables accordingly, there are still a couple of instances in the code that are hard-coded for base address 220 and prevent the playback routines from working correctly with any other I/O address.

... And VOGONS saves the day - again. Thanks! I closed a jumper and yup, that's it. WTF. Why would the music play for like 10 seconds and then go to a hardcoded value? Just WTF...
Thanks again!

jefklak wrote on 2020-09-29, 15:57:

K1n9_Duk3 wrote on 2020-09-28, 20:31:

Yep, setting the base I/O address to 220 will definitely help. Further analysis showed that even though the code parses the BLASTER string and sets the base address variables accordingly, there are still a couple of instances in the code that are hard-coded for base address 220 and prevent the playback routines from working correctly with any other I/O address.

... And VOGONS saves the day - again. Thanks! I closed a jumper and yup, that's it. WTF. Why would the music play for like 10 seconds and then go to a hardcoded value? Just WTF...
Thanks again!

Since most people configured their Sound Blasters and clones at the recommended I/O base address 220h anyway, I guess some developers and testers didn't test alternative configurations with their games as extensively, causing such erroneously hard-coded parts to slip through quality control.

All the more reason to always stick to the recommended configurations.

Anyway, glad it helped, man! 😃 Enjoy your game.