Nice, thanks for figuring this out, think the kit is available on the net along with a
few demos that didn't work.

STMIK (mental.exe) still doesn't work though. They perform a reset (1/0)
and want the 0x22e status read to settle to 0x7f after a while (some 0x300
reads from that port).

yes, but that 0x7f value will be returned naturally if the sb.dst.out.used index is zero.
I made a patch for the SX demo specifically, which pretends that it happened like that. I haven't looked yet at patching DOSBox.

yes, but that 0x7f value will be returned naturally if the sb.dst.out.used index is zero.

Well the reset performs the transition from 1 to 0, and the 0-reset adds
the 0xaa to the buffer so it fills again the buffer.

ah, that's a tricky problem, then.
Perhaps we can append a call to DSP_ReadData() so that the 0xaa can be read even though the buffer is "empty", because of the static data?

Sure you can do that, but that might break a hellalot other stuff.
I don't know what the kit is expecting, maybe there should be a delay
before the ack is put into the buffer.

the kit resets the card, then it reads (DSP_READ_STATUS) until either bit 7 is cleared or the loop expires. Bad things happen if the loop expires. However, if bit 7 is cleared, then it reads (DSP_READ_DATA) and expects to see 0aah.
I would expect that a reset would empty the buffer, and that nothing would break if that happened, but there is a lot of bad software out there...

I would expect that a reset would empty the buffer

No it doesn't, it responds with the ack.
The usual sb detection procedure (as described in pcgpe) is to have a 1-0
transition of the resets, then wait until data is available (bit7 set) and then
check if the returned data is the ack.

then perhaps Sami got it backwards, because STMIK waits until bit 7 is clear, then checks if the returned data is the ack. The only way to achieve that in DOSBox right now would be to empty the buffer by calling DSP_ReadData().

The only way to achieve that in DOSBox right now would be to empty the buffer by calling DSP_ReadData().

When would you do that to pertain compatibility with "correct" detection methods?

I'd have to see someone doing that first. Other methods that I have seen did not rely on bit 7 being set at all, they just reset and read and check for 0xaa.
If you have an example, then I can think about it.

http://www.bluemg.de/prg/pcgpe/sound/soundblaster/sbdsp.html
This is the standard procedure and definitely works.

they just reset and read and check for 0xaa.

But that would mean that the 0xaa is already available even though that
byte has not yet been enqueued. Maybe the 1-part of the reset procedure
triggers something like that.

okay, but there is no mention of what happens during the delay. What happens if you keep waiting? Or don't wait long enough? Perhaps it's just a pulse? STMIK reads the port up to 1000 times waiting for the bit to clear. Since that code did work on real hardware, it makes me think that the bit goes from set to clear to set again, and it's during the clear moment that STMIK decides that everything is okay.
Too many questions, and no real hardware here to find out.

My observations on this:

Aztech Soundblaster Pro clone:

mental.exe works with this card.

When the RESET bit is set, the 'data availible for read' flag is immediately cleared, the data itself stays the same as it was set to by the previous command. 100 microseconds later the 'data availible for read' flag is set and 0xAA can be read. This conforms to the soundblaster documentation.

At this point it makes no difference if the RESET bit is cleared or not.

Other clones: (82c929, CS4236)

mental.exe does not work.

When the RESET bit is set, the 'data availible for read' flag is immediately cleared, the data itself stays the same. Nothing else happens as long as the RESET bit is set.

Now, when we clear the RESET bit the 'data availible for read' flag is set immediately and 0xAA can be read from the data register.

It would be nice to know how original soundblasters (all mayor types) behave, if somebody who owns such volunteers I could make the test program availible.

the data itself stays the same as it was set to by the previous command

Their detection only works because some previous command finished with ack then...

Thanks for the information 😀

At least in mental.exe they poll the 'data availible for read' flag and not the data itself.

Hm? There should be a cmp al,0xaa or so right after they detect that
no data is available, not?

Ah, so they actually need the second little secret I thought was not important.

This is what they do in DOSBox:

SB write reg 226 val 1
SB write reg 226 val 0
SB read port 22e val ff
SB read port 22e val ff
SB read port 22e val ff
SB read port 22e val ff
....

You say they are waiting for 0xAA here?

From 0x22e you usually check only bit7 which indicates that something can be read from port 0x22a and then do so.

This other little secret is that reading from 0x22e returns the content of 0x22a with bit7 replaced with the 'data availible' flag.

0xAA | 0x80 = 0xAA.

it reads 0x22e until the value is 0x7f (ie no data available), then it reads from 0x22a to check for the 0xaa. So real hardware does pulse the bit. DOSBox would need a timer of some kind to emulate that properly. It's probably easier to just patch the individual apps instead.