As a little side note, something odd happens when I try to execute the Sound Blaster Pro's DIAGNOSE.EXE.

When it starts up, nothing weird happens. I can run the FM synth tests without any problems.

The issue starts when I try to perform the DSP tests. I see it executing a Speaker command, then it flat out crashes the CPU, causing a reboot of the emulated system.
Anyone knows if it does something special with the hardware or CPU that might cause this? Is it 286+ code or just 8086 code that's running?

superfury wrote on 2025-08-10, 16:34:

The issue starts when I try to perform the DSP tests. I see it executing a Speaker command, then it flat out crashes the CPU, causing a reboot of the emulated system.
Anyone knows if it does something special with the hardware or CPU that might cause this? Is it 286+ code or just 8086 code that's running?

It seems you encountered the "the original Creative Labs Soundblaster is a copy protection dongle that unlocks the Creative Labs Soundblaster driver", and you failed to emulate the dongle portion of the soundblaster well enough. The original Creative Labs voice driver has a jump table for the different services it can provide, like "initialize", "shutdown" or "play voice file". The jump table entry for "play voice file" is obfuscated. The "initialize" function sets up the DMA controller to write to the jump table entry for "play voice file" and send two E2 commands to the sound card to deobfuscate the two bytes. See for example the dosbox-x source code for a concise example on how the E2 command can be implemented.

So basically, the card receives an E2h command, followed by a byte of data using PIO, after which it will use a single cycle 1-byte DMA transfer to write the resulting byte to memory?

How will the card know to stop to assert the DREQ line? Only by a reset being executed?
Or does the DSP simply transfer 1 byte only, then lower the DREQ line and complete the command?

Edit: My bad. Not DIAGNOSE.EXE but TEST-SBP.EXE.

superfury wrote on 2025-08-10, 20:33:

So basically, the card receives an E2h command, followed by a byte of data using PIO, after which it will use a single cycle 1-byte DMA transfer to write the resulting byte to memory?

exactly.

superfury wrote on 2025-08-10, 20:33:

How will the card know to stop to assert the DREQ line? Only by a reset being executed?

The E2 command instructs the card to send a single byte via DMA, so it will de-assert DREQ as soon as it sees DACK. I didn't check back with the Snark Barker schematics, but I am confident that DREQ is always deasserted by hardware as soon as a single byte is transferred. If the 8051 would put a new byte into the output buffer, DREQ would be asserted again. As the E2 command only puts a single byte into the output buffer, only one byte per E2 command is transferred. This doesn't mean the DMA controller needs to be set for a count of 1. Actually, the Creative Labs driver sets the DMA controller for a count of 2, so the DMA controller will process the responses of the sound card to both E2 commands by writing the response byte to two consecutive memory locations, that happen to be the jump-table slots the voice driver is going to use soon.

Does it raise an IRQ when the transfer completes? If not, how will the driver know it's completed the transfer? Or does it know through the write status register instead?
Edit: Managed to figure it out. Basically a 1-byte DMA transfer, but not raising any IRQ on completion.
And simply execute the DMA transfer normally otherwise, except keep the command busy (bit 7 of the write status register) until the DMA transfer finishes transferring the byte. Then simply terminate both DMA transfer command and PIO executing command (my emulator's latest commits uses a seperate state for both, allowing DMA commands to run while executing different commands on the I/O interface (keeping track of both)). Basically DMA commands run on the DMA command interface and PIO on the PIO interface (affecting DMA commands appropriately as the commands are supposed to do).

Edit: The software runs again with these changes. Although somehow it looks like I'm getting a mono output instead of proper stereo on Sound Blaster Pro II?
Edit: It looks like the software uses the normal 14h DMA DAC command to play back stereo samples, but my implementation requires the documented 90/91/98/99 commands for the bit to become effective? What happens on real hardware?
Edit: Fixing DMA DAC/ADC to not require high-speed mode when using stereo properly makes it render a stereo sample as heard on Youtube recordings (from right to left, 3 times).
Edit: Oddly, on https://www.youtube.com/watch?v=Qfo87tUdVCI , I hear the audio going from left to right instead?
Edit: My implementation starts each DMA DAC/DAC command with the left sample first (after receiving the DMA DAC command for example), then the right sample, then keeps flipping between the two channels. Is that correct behaviour?

superfury wrote on 2025-08-10, 22:00:

My implementation starts each DMA DAC/DAC command with the left sample first (after receiving the DMA DAC command for example), then the right sample, then keeps flipping between the two channels. Is that correct behaviour?

I did not re-read this old thread, but I am confident you will most likely find all information about SB Pro stereo PCM playback in it. I remember it as being a very thorough thread: SBPro1 CT1330A, lets solve the Reversed Stereo myth!

mkarcher wrote on 2025-08-11, 06:37:

superfury wrote on 2025-08-10, 22:00:

My implementation starts each DMA DAC/DAC command with the left sample first (after receiving the DMA DAC command for example), then the right sample, then keeps flipping between the two channels. Is that correct behaviour?

I did not re-read this old thread, but I am confident you will most likely find all information about SB Pro stereo PCM playback in it. I remember it as being a very thorough thread: SBPro1 CT1330A, lets solve the Reversed Stereo myth!

Could it be that the issue mainly comes from the mixer itself? The main chip always sends out mono samples (no matter if "high speed" mode commands are used or not, proven by TEST-SBP.EXE). The mixer chip somehow messes up the first sample, probably happening on the first command after the bit is toggled on? Thus it starts on the right channel instead of the left channel, which is why the first zeroed sample (sent using command 14h like the next command sent, which isn't high speed mode documented, same 14h command) must be sent to fix it? Writing said mixer register not changing the bit keeps the left/right flip status intact?
Edit: Having implemented the first sample after setting the DSP's stereo bit from 0 to 1 (reset state machine for samples rendered) to come from the right side for the first sample, the audio now properly pans from left to right on the Digitized Sound test on the Sound Blaster Pro Test Program (DSP version 3.01 on the Sound Blaster Pro II).

Tried Duke3D. It seems to render in stereo, I think. Although the startup menu (is there any?) is a static gameplay image, it looks like?

The radioactive logo during startup was rendering correctly I think?

The bottom part of the interface looks fine. The top part looks like in front of a grey wall only, zoomed in perhaps?

Audio sounds fine though.

Running install1/2.exe keeps asking for the drive after the CD-ROM drive not being ready, they aren't mounted? I have C(HDD), D(HDD), E/F(CD-ROM). It keeps asking for drive G. With only one HDD/partition, it asks for drive F instead.