I would also like to add this very obscure fixed shooter game that requires CT-VOICE.DRV for sound effects: Galaga '94 (1994) by APSS Austria (Arnold Pichler). It is based on the real Galaga game by Namco.
There is an instruction on how to use a different CT-VOICE.DRV driver in SOUND.TXT file, which also mentions CTV16.DRV for the SB16 but that's not the case here. The one included in the game is already renamed to FX_SB.DRV and is for the SB2.0.
TextTris by Acumen Software (1992): Requires both CT-VOICE.DRV and SBFMDRV.COM when configuring the game to use Sound Blaster for music and sound effects.
Additional information can be found in SBUSERS.TXT file. It comes with SBFMDRV.COM version 1.32 and three renamed CT-VOICE drivers which are SB15.CTV, SB20.CTV and SBPRO.CTV.
Funny that the site mentions that the sound doesn't work in DOSBox but it appears that they didn't RTFM.
I've managed to produce a slightly more up-to-date table of CT-VOICE.DRV compatibility in DOSBox with various sbtype settings. My test was a simple program I cobbled together that loaded the driver and plays a VOC file if anyone's interested in it.
edit: The reason for my testing is that I had trouble getting digital sound working in Innocent Until Caught. The v1 drivers initialised but produced no sound. In the end I used sbtype=sbpro2 and the v2 drivers.
Hypothetically speaking - is there any reason why some patched ct-voice.drv that works with every sound hardware out there does not exist?
Does this driver rely on SB ADPCM decoding or some similar function?
I've managed to produce a slightly more up-to-date table of CT-VOICE.DRV compatibility in DOSBox with various sbtype settings. My test was a simple program I cobbled together that loaded the driver and plays a VOC file if anyone's interested in it.
edit: The reason for my testing is that I had trouble getting digital sound working in Innocent Until Caught. The v1 drivers initialised but produced no sound. In the end I used sbtype=sbpro2 and the v2 drivers.
Hypothetically speaking - is there any reason why some patched ct-voice.drv that works with every sound hardware out there does not exist?
I think because its hardware dependent, although the SB v.1x drivers can be used on the newer SB's as well. (I tested this DOSBox only, so this could be different on real hardware)
My test was a simple program I cobbled together that loaded the driver and plays a VOC file if anyone's interested in
im interested in, source available?
found the Sound Blaster Development Kit with headers/examples/libs of some creative drivers like ct-voice.drv and others: ftp://retronn.de/driver/Creative/Developer/DEVELOPR.SB (needs a ftp client - most web-browsers reject ftp connections)
i've disassembled the 1.13 and 2.12 CT-VOICE.DRV to see the differences between the versions
the newer versions seems to support more driver functions and has a different calling style to invoke driver functions (result return by ax or parameter)
this is the routine that gets invoked when someone far calls the driver
The attachment differences3.png is no longer available
the [bp+0Ch] overwrite in 2.12 changes data in the callers stack, so it could be that newer versions of the CT-VOICE.DRV can corrupt the game state a little (maybe too much)
if the game was developed with a older version of the driver - can someone confirm that finding?
so the stack for the function call needs to be at least
1sp+0004 unknown/unused 8 bytes 2sp+000C result offset
for example - this is a valid call to the driver if version 2.12 is used - if im not totaly wrong with my limited 16bit, stack knowledge
UPDATE: the 4.05 switched back to register ax as result, so its really needed to know the driver version before calling
and the code is all-in-all a little bit silly assembler code: for example: all variables get addressed by cs but every access to variables sets ds before to cs, instead of just accessing with cs:variable and also forcing ds segment
with the help from reddit/asm: https://www.reddit.com/r/asm/comments/vp65mu/ … rsed_dos_sound/
i've understood that the bp+0Ch actually targets the pushed ax register on stack - so the pop ax at end will contain the value comming from the called sub-function - is that typical asm code? looks a bit strange
so the 1.13 and 2.12 code is more or less doing the same and there is NO problem with corruption using newer drivers
I've managed to produce a slightly more up-to-date table of CT-VOICE.DRV compatibility in DOSBox with various sbtype settings.
i've updated your matrix with my findings - the pre 2.x versions didn't check for the exact hardware - thats why the 1.x working for all combinations
some of the drivers identical, some got only minor differences like some bytes (base-adress etc.)
The attachment matrix.png is no longer available
nearly code identical, only base-address different and another port-adress, only 2 bytes different
anyone know how to actually "load" a CT-VOICE.DRV before starting a game?
If a game requires CT-VOICE.DRV it will load it itself.
so i need to change the CT-VOICE.DRV file in the game installation if i want to use a different driver version?
or is the CT-VOICE.DRV file usually reachable through PATH?
are there games that include the driver directly in code - because technical there is no need to have a free floating CT-VOICE.DRV file around - could be part of the game executable
anyone know how to actually "load" a CT-VOICE.DRV before starting a game?
If a game requires CT-VOICE.DRV it will load it itself.
so i need to change the CT-VOICE.DRV file in the game installation if i want to use a different driver version?
Yes.
or is the CT-VOICE.DRV file usually reachable through PATH?
Installing the Sound Blaster drivers normally will add the SOUND environment variable which is a directory path that contains the DRV subfolder and said subfolder has the CT-VOICE.DRV file. However, not all the games will check that environment variable.
I assume you want to switch between versions, for testing purposes:
Change the path eg: SET SOUND=C:\DOS\CT-VOICE\2.12, but some games do not use or respect the SOUND path.
Overwrite CT-VOICE.DRV with the version you want to test, which always works.
Write a loader to intercept the CT-VOICE.DRV path and redirect it (which is a lot of work to get 100%)
are there games that do not load a single file but got the driver integrated (could be also part of other game resources, there is no need for a single file load as long as the driver code is segment aligned)