well the error you are getting in DOSBox basicly means that zero code was executed.
So there is a jump or an irq going wrong. The library could have removed the irq handler before the irq came. You might want to try setting the irq of the soundblaster irq of dosbox to 5.

But this is offcourse pure speculation. I would have to take a look to see what is wrong with it.

I tested it with IRQ5 inside DOSBox. Didn't work either.

OK, good to know what the error message means. It might be a timing issue then. We developed the Demo for a 286 PC. Or could it be a library relocation issue with the third party library?

Interrupt coming before interrupt handler set?

Memories of good old days are getting stronger 😀

I remember now that STMIK worked so that you had to "poll" the library with regular intervals. If I remember correctly we did use clock interrupts for polling the device and STMIK used DMA interrupts to feed the samples (calculated in polling phase) to SB.

Maybe the order of interrupts have changed somehow, and STMIK library is sensitive for that.

Is there some ways of twaking the SB DMA handling or interrupt handling in general? Can it be, that way dosbox handles SB sound is somehow "too fast" compared to the year 1993?

An other guess that comes to my mind, is that the jump to STMIK library somehow does not succeed. Have there been changes in .exe structure between DOS versions? I think I was using Dos 6.01 or something by then... (I think jumping to the libary code may be the problem, since even if I disable sound (from the demo) Dosbox crashes at the place, we try to jump to library code (just to set some IRQ values, but not starting the sound).

Well, these are just my random guesses, and they might be completely irrelevant. All suggestions however welcome on how to proceed from here.

Thanks,

Vesa

Unsure it related, Mental Surgery:
http://www.pouet.net/prod.php?which=1280
With SB selected, this scroller freezes soon after DSP reset command.

Don't know if it's sound related at all. The sb dsp reset is just the last
visible message.

If you're handy with a debugger, at 8b4:10f there are three successive
calls to one function, just the registers are set up differently. The first
call succeeds, but during the second one it overwrites code, which it
executes later (still in that call though).
Could be that this code is part of that library, does some lengthy memory
translation/decryption/whatever.

Debugged the demo Srecko mentioned a bit, and there were some similarities
so i tried to look up what sound module they use, and as vsuontam
already stated they (both) use the STMIK scream tracker mod player.

With a bit more fiddling i could get it to work, actually they can't detect
the soundblaster and do some assumptions later which corrupt the code.
They don't do that much in their sb detection, but require data to be
available/not available depending on executed instructions and stuff
like that.