I have a nice sounding CT2770 paired with a CS4232 based card. The Crystal handles MIDI and SB Pro if required. The FM synth chip is disabled. The CT2770 handles most PCM, FM synth, and joystick support.

So it's quite common then to pair the SB16 with other cards?
Since the CT2950 is not liked because it got the CQM, it is cheap and plentifully available on ebay and so are the YMF cards.
Pairing two sound cards without hardware conflicts and endless mixer tweaking is definitely not for a casual dos gamer but it yields the absolute best from both.
Finding a SB16 with bug-less MPU-401 and OPL3 on ebay is practically impossible.

I'm not sure how common it is, but it's the setup I use.

I would like to pair my AWE64 Value and a Yamaha Audacian 32 Plus.

Since the AWE64 has a nice clean output but doesn't have a real OPL3, I'd like to use it for digital audio and wavetable MIDI (many games that can use the AWE32 wavetable). I would like to use the Yamaha for OPL3 MIDI and external MPU401 interface to my SC-55mkII. Would be nice to have a choice of 3 different MIDI playback paths.

I haven't looked into the configuration yet (IRQ, DMA, etc), but I haven't started physically puting things together yet, either. Right now it's just a bunch of parts (need to take some time off to work on building my retro rig(s)).

If you're looking for someone to join your "paring different sound cards to fix each other flaws" club, then hello there. 😀

Some people use 3 or 4.

GuyTechie wrote:

I would like to pair my AWE64 Value and a Yamaha Audacian 32 Plus.

Since both cards are PnP I have written a small enable.bat and disable.bat so I can quickly disable the SB16 and put YMF719 at the same 220,7,1 address for games that absolutely require SBPro.
The system load with SB16 at 220,7,1 and YMF719 at 240,5,0 by default with MPU-401 and Adlib disabled on the SB16 but enabled on the YMF.

With these batch files and tweaked ini and cfg files I can seamlessly switch between cards while keeping the 220,7,1 addresses.
This is super convenient and useful for these games that freeze with anything but SBPro on A220 and don't have setup to configure, like Archon Ultra.
After I'm done with the game I run enable.bat and everything is back to normal.

* There are several nuances that have to be properly configured in the opl3sa.ini and ctpnp.cfg for this to work (I attached them).
I also "read only" autoexec.bat because oplsax changes the SET BLASTER variable after every tweak.

I'm here for help if anyone needs it. 😀

disable.bat

1@echo off
2REM :: First disable SB16::
3ren c:\sb16_dos\ctc\ctpnp.cfg ctpnp.bak
4ren c:\sb16_dos\ctc\disable.bak ctpnp.cfg
5c:\sb16_dos\ctc\ctcm.exe /t
6
7REM :: Now enable YMF719 to 220,7,1 ::
8ren c:\opl3sax\opl3sa.ini opl3sa.bak
9ren c:\opl3sax\saxonly.bak opl3sa.ini
10c:\opl3sax\setupsa.exe /s
11SET BLASTER=A220 I7 D1 T4

enable.bat

1@echo off
2REM :: First move YMF719 to 240,5,0 ::
3ren c:\opl3sax\opl3sa.ini saxonly.bak
4ren c:\opl3sax\opl3sa.bak opl3sa.ini
5c:\opl3sax\setupsa.exe /s
6
7REM :: Now enable SB16 ::
8ren c:\sb16_dos\ctc\ctpnp.cfg disable.bak
9ren c:\sb16_dos\ctc\ctpnp.bak ctpnp.cfg
10c:\sb16_dos\ctc\ctcm.exe /t
11SET BLASTER=A220 I7 D1 H5 T6

I also "read only" autoexec.bat because oplsax changes the SET BLASTER variable after every tweak.

Are you referring to how setupsa leaves an extra space in between two variables in the SET BLASTER line?
I'm still not certain if it messes things up, but it sure annoys me.

No It does not mess things up.
I default the YMF719 to 240,5,0 but want to keep the BLASTER environment variable at 220,7,1 after setupsa is loaded.
setupsa.exe will always make sure autoexec.bat is compliant with its SB settings each time you load setupsa with or without the /S (silent) parameter.
When setupsa fails to write the main autoexec.bat file it writes .ba1 and .ba2 files.

A little secret:
In the opl3sa.ini file make sure "winpath=C:\WINDOWS" is set to "winpath=C:\WINDOWS1" or anything besides your true windows folder,
setupsa.exe will not respect the SB settings in the opl3sa.ini file when run with the /S parameter if winpath is correct.
This is essential for the address to change without actually entering setupsa.

I remember pointing out on vogons some time ago that there was a problem with setupsa on systems with windows installed. I noticed the behaviour of setupsa not respecting the opl3sa.inf file, but I couldn't quite pin down what was causing it or how to resolve it. Good work!

I'd like to try your pairing, but I will likely try it with an AWE64G instead.

Anonymous Coward wrote:

I'd like to try your pairing, but I will likely try it with an AWE64G instead.

Should work exactly the same.

James-F;
Are you aware that there are multiple FM addresses? The usual 388h and the Sound Blaster base address+offset (220h).
See this topic (page 8 ) for example. I never really solved this complication, and therefore consider a SBPro or SB16 interface/card to always include its own original FM. The MPU Midi interface does not have this problem at all, and can generally be replaced by another interface/card without any problem.

Anonymous Coward wrote:

I remember pointing out on vogons some time ago that there was a problem with setupsa on systems with windows installed. I noticed the behaviour of setupsa not respecting the opl3sa.inf file...

That topic is here: The Yamaha OPL YMF718-S chipset.

gerwin wrote:

James-F;
Are you aware that there are multiple FM addresses? The usual 388h and the Sound Blaster base address+offset (220h).

Yep I am aware of that.
From what I've tested some games that require 220 for FM usually will point it to address 388 by default.
Others will let me choose address in their setup which I point to 240 where the YMF719 and its OPL3 live.
Doom for example will address to 388 even if 220 and Sound blaster is selected as the Music device, it might even send FM signals both to 220 and 388 at the same time.

The list of games that will not let me choose the music device from their setup, or not automatically address to 388 is practically non existent.
MK2 and Lost Vikings fall under the category, but that's why I created the batch files to instantly switch the YMF719 as the primary sound card at 220,7,1.
Easy as pie.

Actually I think the use of A220+offset is very rare.
388-220=168, so to reach address 388 for FM the games adds 168 to the base 220 address, very inconvenient.

James-F wrote:

Actually I think the use of A220+offset is very rare.

Wasn't 'Gods' from the Bitmap Brothers another one? I don't remember exactly why I did not like this issue much.

James-F wrote:

388-220=168, so to reach address 388 for FM the games adds 168 to the base 220 address, very inconvenient.

These games don't send FM data to 220+168=388h and 389h at all, they send it directly to 220h+221h. It is a different set of I/O ports to the same FM chip. It is in the Sound Blaster I/O port specification. Seemingly Creative Labs did not want to rely on a port specified by Adlib.
There is one port address for each channel (left/right). In case of mono/OPL2 only the first port is used: 389h and 221h are then left unused.

gerwin wrote:

Wasn't 'Gods' from the Bitmap Brothers another one?

No, the recording on the first post is done with both sound cards and the FM music is on port 388 from the YMF719.

gerwin wrote:

Seemingly Creative Labs did not want to rely on a port specified by Adlib.

I assume some games fall under that special category.
But a bigger problem is some games alter the mixer and mute the Line-In so even if port 388 plays on the YMF, there will be no sound at the output.

gerwin wrote:

Wasn't 'Gods' from the Bitmap Brothers another one? I don't remember exactly why I did not like this issue much. […]
Show full quote

James-F wrote:

Actually I think the use of A220+offset is very rare.

Wasn't 'Gods' from the Bitmap Brothers another one? I don't remember exactly why I did not like this issue much.

James-F wrote:

388-220=168, so to reach address 388 for FM the games adds 168 to the base 220 address, very inconvenient.

These games don't send FM data to 220+168=388h and 389h at all, they send it directly to 220h+221h. It is a different set of I/O ports to the same FM chip. It is in the Sound Blaster I/O port specification. Seemingly Creative Labs did not want to rely on a port specified by Adlib.
There is one port address for each channel (left/right). In case of mono/OPL2 only the first port is used: 389h and 221h are then left unused.

No, that is not correct at all.

Adlib:
One OPL2 chip, two IO ports, register index port at 388h and register data port at 389h.

SB 1.X and SB 2 (not Pro):
One OPL2 chip, two IO ports, mapped at two areas, at 388h/389h for Adlib compatibility and 2x8h/2x9h in the SB area. CMS chips, if installed, are at addressess 2x0h/2x1h/2x2h/2x3h in the SB area, for GameBlaster compatibility (except that detection of GameBlaster won't work, have to detect SB DSP presence and version instead).

SB Pro (1): Two OPL2 chips, one for left speaker and one for right speaker. Adlib, SB1 and SB2 compatibility maps ports so that Adlib ports 388h/389h and SB FM ports 2x8h/2x9h actually writes to both chips to get same music from both speakers. Otherwise 2x0h/2x1h accesses the two ports of the left OPL2 chip and 2x2h/2x3h accesses the two ports of the right OPL2 FM chip.

SB Pro (2) and SB16: Single OPL3 chip, takes four IO ports. It powers up into mode where first two OPL3 ports are compatible with single OPL2 and the second two ports are only used for enabling and using the OPL3 mode. Therefore, it has Adlib, SB1 and SB2 compatibility again because ports 388h/389h and 2x8h/2x9h map to first two ports of OPL3 chip. Otherwise the four OPL3 ports are mapped to 2x0h/2x1h/2x2h/2x3h, but it is not SB Pro1 (dual OPL2) compatible in any way, because 2x0h/2x1h access the same OPL3 ports as 388h/389h and 2x8h/2x9h, and 2x2h/2x3h are the extension ports.

So a short summary:

-Games supporting only Adlib use only OPL2 at 388h/389h.

-Games that can detect and support SB 1 or SB 2 could use single SB driver for digital and OPL2 FM so it might just use 2x8h/2x9h for FM, but if a game has separate drivers anyway for music and digital, it might just use the already existing Adlib music driver so it uses ports 388h/389h.

-Games that can detect and support SB Pro (1) for music could use a separate music driver for dual OPL2 stereo FM, so this driver must use ports 2x0h/2x1h/2x2h/2x3h as two OPL2 chips. But it might still use 2x8h/2x9h for writing identical data to both chips simultaneously, and/or 388h/389h for detecting presence of any OPL chip and its type. And detecting second OPL2 at 2x2h/2x3h.

-Games that can detect and support SB Pro (2) or SB16 for music, could use a separate music driver for OPL3 4-op stereo FM, so this driver must use 2x0h/2x1h/2x2h/2x3h as single OPL3 chip. Again 2x8h/2x9h or 388h/389h could be used for detecting any OPL chip and type, but trying to detect OPL chip on 2x2h/2x3h will fail.

-Forcing to use dual OPL2 music driver on OPL3 card will sound wrong

-Forcing to use OPL3 music driver on dual OPL2 card will sound wrong

Jepael wrote:

No, that is not correct at all.

Yeah OK, I had an oversimplified situation left in my memory. Tried to illustrate the point that it is not just port 388h for FM. Thanks for explaining proper ( I will just trust you on that ).

Jepael wrote:

No, that is not correct at all.
...

Thanks for clarifying.
I went through the Sound Blaster I/O Address Maps section (page 115) in the Hardware Programming Guide (attached) and everything is much clearer.

A nice way to test all these port options is the Warcraft 2 Setup utility which lets you select anything anywhere (this is not an overstatement).
It even has a "Generic OPL3" option which addresses to port 388/9 38A/B like Adlib Gold I assume.

Going back to the thread topic, most older games (SB2.0 and down) will send FM data to ports Base+8 and 388 at the same time,
numerous are the games that only send FM to Base (SBPro and up) without having a setup utility to choose an address or driver from, the gap is very small between the two.
In fact this is easily tested with the CT2950 fully disabled while the YMF719 still active with the 388 port.
If FM sounds still play with the SB16 disabled and Sound Blaster 220 setting in the game setup, the game sends to 388 automatically which the YMF719 still receives, like Doom.

This kind of behavior I rely on to get the YMF719 OPL3 pumping along with the SB16 CT2950.
PS. I have bought a SB16 CT2230 to test.
PPS. and a CT2890 to test.

EDIT:
I hope the CT2890 is full PnP and well behaved because I hope to be able to switch between it and the YMF719 with the batch files or disable it without restarting or pulling it out.
The CT2230 is not fully PnP so it will not be easily messed with, it permanently occupies an I/O address by a jumper on board.

@Jepael
To confirm the theory that all FM data that goes into I/O Base+8 routed automatically to 388 I need you expertise.
Can you write a tiny program that sends a FM tone to Base+8 to test this, similar to the opl440.com we already have?

EDIT:
Warcraft 2 setup.exe with the old SB choice confirms that 220+8 will not automatically send to 388, do we need further confirmation?
Can I assume most older games send both to Base+8 and 388 as a safety measure, or just to 388?

If you're using the YMF card for MIDI and FM, why not just use it for digital sounds too? From all accounts the SB support is pretty good.