Giters

crazii / SBEMU

legacy sound blaster emulation for DOS

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

SBEMU is not setting the T parameter in the BLASTER environment variable

volkertb opened this issue · comments

commented

The BLASTER environment variable also has a T ("type") parameter, which is used to specify which revision or type of Sound Blaster is installed. SBEMU doesn't appear to currently include that parameter when it sets the BLASTER variable. The value for T should be set as follows, depending on what Sound Blaster variant is being emulated:


T specifies the type of the soundcard: 


  1 : Soundblaster 1.0/1.5/MicroChannel   22kHz,  8bit, mono

  2 : Soundblaster Pro 1.0  (dual-OPL2)   44kHz,  8bit, mono or 22KHz, 8bit, stereo

  3 : Soundblaster 2.0/2.0 CD/2.5         44kHz,  8bit, mono

  4 : Soundblaster Pro 2.0  (OPL3)        44kHz,  8bit, stereo

  5 : Soundblaster Pro 2.0 Microchannel   44kHz,  8bit, stereo

  6 : Soundblaster 16/32/AWE32/AWE64      44kHz, 16bit, stereo

Source: https://www.vogons.org/viewtopic.php?p=83949#p83949

So it seems that SBEMU should add T4 when Sound Blaster Pro emulation is enabled, and T6 when Sound Blaster 16 emulation is enabled.

commented

I remember there was compatibility problem when set T for those other that SB16, so only SB16 set T parameter.

commented

That seems weird. Didn't the original installation media that came with the Sound Blaster Pro cards configure the BLASTER variable with the proper T option? If so, wouldn't Sound Blaster Pro owners back in the day have faced such compatibility problems too?

commented

I probably didn't make it clear.
It's not that the T causing problem, but it is not used to avoid some "emulation"/compatibility problems, apparently SBEMU is not the real SBPro hardware, neither does it achieve precise emulation, and is far from that. There're also games that don't work properly in DOSBox with T set. Any tiny differences may cause problems, even the timing, and the setups of some games have an option of "SB Clone" for a reason. if the type is set, some games may use type specific init/detection sequence that might not work.

I think it is be OK to set T now since time has passed when the issue was created, could be tested in next release. There're some DSP command not supported, after they're done, hopefully there might be fewer problems.

commented

Let's keep this issue open for a few more days, and after that we can set it and do more tests.

commented

Ah, so if I understand correctly: the compatibility with the original Sound Blaster Pro would have to be really good enough before we can safely add the T4 parameter to the BLASTER variable, since it would result in some games using very strict I/O detection routines instead of the more forgiving "SB clone" ones. Did I get that right?

The reason why I think we should strive for good Sound Blaster Pro compatibility though, is because there are a lot of games that came out before the Sound Blaster 16 was released, and therefore output stereo sound only on a Sound Blaster Pro. Or at least, I would assume they do, since why else would you be able to explicitly select the Sound Blaster Pro as a sound card in the installation and/or setup programs of those games?

The "SB clone" option that some games offer is a "lowest common denominator" mode, which would result in mono sound (and possibly downsampling, in the case of games that came with higher quality digitized sound assets).

By the way, does SBEMU support both the Sound Blaster Pro 1.0 (with dual OPL2 chips) and the Sound Blaster Pro 2.0 (with a single OPL3 chip)? The former would need the T2 option in the BLASTER environment variable, the latter T4.