Hi superfury, I've got a SB 2.0 and a 4.77MHz PC (got it recently).
If you like, I can run this driver on the real thing and tell you if it crashes (btw, what is this driver for ?).

What is the driver for? Most games just use the card directly, but yeah some programs want to use the TSR programs so they don't have to use it directly.

My first thought is that something has gone horribly wrong as the code area it is running in (0000:03B6) is in the area reserved for interrupt vectors (0:0..0:3ff). There might be a reason for this but it is very suspicious.

Hmmm... maybe an interrupt vector is missing(the Sound Blaster IRQ5 handler) for some reason? It has something to do with timing it seems, as 3000 cycles doesn't give the bug, but 8088 speed(4.77MHz accurate timing w/ 8088 CPU clock cycles) gives the bug. Maybe the reset command (which uses 20us timeout before triggering the IRQ5)? Is that one correct(based on Dosbox)?

The driver is installed by the Creative Sound Blaster 2.0 install disks (4 disks gotten from vogonsdrivers). I think it needs it for accessing the hardware, when using the supplied programs (play.exe etc.)?

@Jo22: Yes, please test it on the actual hardware. I want to know if it's a bug in my emulator, or if it's the actual hardware timings or emulation that is at fault(if any).

I've modified the Sound Blaster code a bit: The timeout for command 0xF2 'IRQ Request' for the Sound Blaster DSP was 20ns instead of 20us(after comparing code to Dosbox's blaster.cpp ( https://sourceforge.net/p/dosbox/code-0/HEAD/ … re/sblaster.cpp )

My latest Sound Blaster code:
https://bitbucket.org/superfury/unipcemu/src/ … ter.c?at=master

It now crashes at a different point.

1Command: <HLT>
2OP: 06
3ROP: F4
4CS:0000
5IP:0005
6DS:0000
7ES:0000
8SS:86C4
9AX:DA00
10BX:3736
11CX:E005
12DX:A4CF
13SP:8AD7
14BP:0000
15SI:A6EE
16DI:0000
17F:F492
18c1p0A0zStiDo1111H
190000000000000001
20VGA@842,289(CRT:0,323)
21Display=801,446

That's what's dumped by the emulator's debugger.
OP is the first active opcode byte, ROP is the active opcode byte(the first non-prefix opcode), F is flags register. The flags described are 0/1 for unchangable values, lower case for not set, upper case for set, H means HLT state(same with the command being <HLT>).
The final big number is the binary value of the IRQ requests pending.
VGA@x1,y1(CRT:x2,y2)
Display=z1,z2 means that the VGA's raster is at x1,y1(virtual point), while it's CRT emulation is at position x2,y2. z1,z2 is the current display resolution detected by the monitor.

After enabling a special log of invalid commands sent to the DSP I notice it receives two invalid commands:
Commands 08h and 55h. Both don't exist, according to this list: http://the.earth.li/~tfm/oldpage/sb_dsp.html.

Looking at the Dosbox source code, command 08h is SB16 ASP get version, but why would the Sound Blaster 2.0 driver call that command for a Sound Blaster 2.0?

Edit: These are the current commands executed on the DSP by the program:

100:05:54:54.07168: Command: E0@ver. 0200
200:06:15:59.03984: Command: E4@ver. 0200
300:06:35:44.02528: Command: E8@ver. 0200
400:06:46:95.07696: Command: E1@ver. 0200
500:06:58:13.04464: Command: E1@ver. 0200
600:07:05:48.02112: Command: E1@ver. 0200
700:07:16:12.06016: Invalid Command: 08@ver. 0200
800:07:42:44.02208: Invalid Command: 55@ver. 0200
900:07:49:22.02720: Command: F2@ver. 0200
1000:07:59:02.08992: Command: 40@ver. 0200
1100:09:01:78.04576: Command: 24@ver. 0200

It ends with commands F2(Raise IRQ), 40(Set Time Constant) and 24(DMA ADC 8-bit). Though I don't know why it would execute a DMA ADC 8-bit command? The DMA transaction won't start until the first sample is read using Direct mode, according to TFM's DSP commands Page. However, directly after the command is executed, it gives the error? Is an IRQ supposed to be raised there?

Edit: Fixed the handling and initialization of the driver by implementing the command 0x24(Direct DMA ADC) bug, which raises an interrupt, gives the first sample through Direct ADC, then continues using normal DMA ADC.

It seems Dosbox doesn't emulate this bug, which is used in the Sound Blaster 2.0 driver? Why doesn't Dosbox emulate this bug?

Hello again, the driver seems to work fine on my PC/XT clone.
It previously came with german MS-DOS 3.2 installed and a few utilities were also left behind.
The driver loads normaly and shows a message during boot up (see picture below):

MS-DOS 6.22 was booted clean without any additional drivers, just ctsb2.sys.
Note that I had to change the card from IRQ5 to IRQ7, because my MFM controller is on IRQ5.

I tested the driver with this computer model and these cards:

- Sound Blaster 2.0 CT1350B (DSP 2.02)
- Sound Machine (DSP 2.02)
- Aztech (DSP 2.01)

The first two were accepted by the driver without any issues.
The third one didn't work. The Creative software complained "This driver only works for SB 2.0" or similar.
Without any card installed, it complained about a wrong parameter in config.sys.

I also wrote down the memory addresses from CheckIt! for you.
These were shown with the original card installed.

-- Interrupt Vector Table (IVT) --

0321:D00C INT EFh CTSOUND0

036C:C800 INT F6h CTSOUND0

0000:FFFF INT FFh CTSOUND0

- DOS DEVICES -

0B81:0000 CTSOUND0 ATTR=C800 DOS3.20 IOCTL

I hope this can somehow be useful for you.
I also attached the logs from MSD and System Information (SI)..