# oplmode -- Type of OPL emulation: auto,cms,opl2,dualopl2,opl3.
# On auto the mode is determined by sblaster type.

It is hiding itself in SoundBlaster settings (# oplmode -- Type of OPL emulation: auto,cms,opl2,dualopl2,opl3.) 😀

Mirek

I just noticed this as well when examining the config file again, so sorry for that oversight.

However, this behavior seems entirely counterintuitive. I suppose it's true that no games use both FM Synthesis and CMS/Gameblaster for music simultaneously, so in that respect it makes sense to include CMS as an alternative option to the Soundblaster's FM synthesis, but it makes no sense when relying on 'auto' mode.

Auto mode proclaims that the type of OPL emulation is determined by the card selected with "type=". However, there is no SB card that would ever be associated with CMS as OPL type, or if there is in DOSBox, it's incorrect. Soundblaster 1.0 supported both OPL/2 and CMS, but obviously OPL/2 would be favored over CMS in auto mode. From Soundblaster 1.5 to Soundblaster 2.0, CMS was optional and not included on the card by default, so OPL/2 would be the only supported option. Soundblaster Pro 1 did away with the CMS sockets entirely, as far as I'm aware, only supporting dual-OPL/2.

Therefore, if you want CMS support, you have to go into the config file and change "oplmode=" to "cms" every single time you play a game with CMS support, remembering to change it back for Adlib/OPL3 games afterwards. This sort of defeats the purpose of 'auto' mode, in my opinion.

Perhaps I'm totally alone but I favored the old method of distinguishing CMS support from OPL support, only because of the inconsistencies in its inclusion on various SB cards, and the fact that it was a separate card prior to the SB's existence. It makes more sense to treat it this way and to allow automatic support without fiddling around in the config file every time you want to use it.

dosbox works exactly as you described: if you select type=sb1 you habe both cms and opl2 😀

Actually, it's oplmode=opl2 that allows use of both CMS and OPL/2 simultaneously, presumably because OPL/2 would be associated with SB1 and SB2 and therefore support CMS as well [even though SB2 really doesn't -- you'd probably find one out of the thousands that purchased it that actually bought the additional CMS add-in chips].

However, that's still a half-assed approach. I believe the logic behind it relates to the previous versions' warning, which states that there can be conflicts by having both enabled simultaneously, so this was some way to 'circumvent' that. Who knows. Still, it makes more sense to treat CMS as a separate device from FM synthesis because it WAS a separate device! Also, it would alleviate having to change between oplmode=opl2 for CMS/OPL2 emulation and oplmode=dualopl2 or oplmode=opl3 for dual-OPL2 or OPL3, should one desire that. I guess I just don't see the 'benefit' of combining them; all it does is make things more difficult.

tbcarey wrote:

Still, it makes more sense to treat CMS as a separate device from FM synthesis because it WAS a separate device!

It actually a little more complicated than that. First there was the CMS, which was standalone, and then the SB1.0, which had the FM chips, the DAC and the CMS. Then SB1.5 and SB2.0 left out the chips but made them available to those wanted them. At that time, however, for reasons known only to Creative, they decided to complicate things by mirroring the ports 0x388 and 0x389 where the FM synthesizer worked, to 0x220 and 0x221, where the CMS chips worked. Go figure.

Let's imagine such a situation. A person has a real sb1 (or sb1,5/sb2 with cms chips) and he wants to play some game. And he has conflicts. It's just hard to believe that any game company wouldn't make their game compatible with older sound blasters. Actually most games allowes to choose sound card type in their setup. It would be strange if they used 388 for old sound blasters and 220 for new sound blasters. I think all those options will use 388. So my question is: Does anyone really know a game that makes conflicts?

canadacow wrote:

tbcarey wrote:

Still, it makes more sense to treat CMS as a separate device from FM synthesis because it WAS a separate device!

It actually a little more complicated than that. First there was the CMS, which was standalone, and then the SB1.0, which had the FM chips, the DAC and the CMS. Then SB1.5 and SB2.0 left out the chips but made them available to those wanted them.

I know that already. Didn't you read my previous post in this thread where I stated that as well? 😀

By the way, you say that the FM port [388h/389h] was mirrored to 220h/221h as well. Are you sure? I was always under the assumption that 220h was the default port for the DAC/digital sound, not for any sort of FM synthesis.

In any case, having the DAC at 220h as well as CMS really doesn't do any sort of harm, because I'm totally unaware of any games that would support Sound Blaster DAC and Gameblaster simultaneously, let alone digital sound and Gameblaster. By the time digital sound appeared in most games, Gameblaster had long been phased out.

tbcarey wrote:

In any case, having the DAC at 220h as well as CMS really doesn't do any sort of harm, because I'm totally unaware of any games that would support Sound Blaster DAC and Gameblaster simultaneously

it is using DAC and adlib simultaneously on port 220 that may make conflicts (cause cms will be set to 220 in dosbox, not adlib).

to make it more clear:
in real sb1 it was like this:
220-DAC
220-cms
388-adlib

in real sb16 it was like this:
220-DAC
220-adlib
388-adlib

in dosbox sb16 will have to look like this:
220-DAC
220-cms
388-adlib
so if the game wants to use adlib on port 220 there will be conflict in dosbox

robertmo wrote:

in real sb16 it was like this: 220-DAC 220-adlib 388-adlib […]
Show full quote

in real sb16 it was like this:
220-DAC
220-adlib
388-adlib

in dosbox sb16 will have to look like this:
220-DAC
220-cms
388-adlib
so if the game wants to use adlib on port 220 there will be conflict in dosbox

Aaah, that makes it much clearer. Thank you for the detailed explanation. I was unaware that OPL/3 was assigned 220h as well as 388h on the actual SB16 [and I'm assuming on the SBPro 1+2 as well, since neither supported CMS, which is why it's disabled for them in DOSBox]. I can understand now why that could be a potential problem, although as you say in a previous post, I don't know many games that use 220h for adlib, but I could be entirely wrong. OPL/3 games like Sam'n'max and The 7th Guest might. I'll have to download DOSBox 0.61 again and test them.

Thanks again for the info. You've sorted me out.

robertmo wrote:

tbcarey wrote:

In any case, having the DAC at 220h as well as CMS really doesn't do any sort of harm, because I'm totally unaware of any games that would support Sound Blaster DAC and Gameblaster simultaneously

it is using DAC and adlib simultaneously on port 220 that may make conflicts (cause cms will be set to 220 in dosbox, not adlib).

Actually, to play to that scenario - when would that ever cause a conflict? If there was any game that supported FM synthesis at 220h, it would have to be a game made in the post-SBPro 1 era, since you say that OPL/2 was never mirrored to 220h. From what I know and relying on various sources including the Creative website, the release of the SBPro 1 happened in 1991, while the SB16 was launched in 1992. Any game that was launched post-1991 and hypothetically supported dual-OPL/2 or OPL/3 music at 220h would probably be a game that included some sort of digital sound effects that would use the DAC [the first CD-ROM talkies I'm aware of came out in 1992, obviously making use of the DAC as well].

I guess my question is: If a game utilized both the DAC and dual-OPL/2 or OPL/3 at 220h, wouldn't a conflict arise there as well? Or is there something I'm missing that would prevent the two from interfering with each other?

If it's the case that both the DAC and the FM chips being assigned to 220h at the same time would cause a conflict, I can't see any games being released in the post-SBPro 1 era actually using 220h for FM, considering almost all of them used digital sampling for effects or voice.

If that's the case, then there's really no reason to worry about the Gameblaster using 220h for CMS at the same time as the FM chips on the SB16 or SBPro for the following two reasons:
1) CMS + DAC would never be used simultaneously. As I said before, I've never heard of a game that supports CMS + digital sound as parallel devices.
2) CMS + FM 'mirroring' 220h is not an issue, because any game that would use FM would not use 220h and risk causing a potential conflict with the DAC, which was often used in post-1991 games.

By this logic, there's no reason to ever worry about CMS being enabled at 220h. However, with my flawed logic, something is probably amiss. Please let me know 😀

tbcarey wrote:

robertmo wrote:

tbcarey wrote:

.
By this logic, there's no reason to ever worry about CMS being enabled at 220h. However, with my flawed logic, something is probably amiss. Please let me know 😀

This is about the only thing your correct on, unfortunately. The DAC didn't really use 0x220, it used ranges 0x224 to 0x22f. The DAC is really on different ports than the CMS or Adlib. (In earlier posts, whenever you see 0x220, they are actually referring to being in the range of 0x220-0x22f. That's why you'll often see it written as 0x2?0 or something like that.) Then its either the CMS or Adlib at 0x220 and 0x221. When the OPL3 came out, they went to the port range 0x222 and 0x223. Any program that uses the OPL3 Adlib will use 0x220-0x223. The 0x388-0x389 range is for OPL2 synthesis only.

Technically the Sound Blaster 1.0 could have the CMS, OPL2 Adlib and the DAC all playing simultaneously if they were so inclined. (Never saw any software that did this though. It didn't stop their AD department from claiming a total of 24 ports!) When the Creative chose to mirror the Adlib into the CMS's range, that possible trio-combination ceased to exist.

Thanks for clearing that up. That was the explanation I was looking for from the beginning.

Just some interesting trivia about sound hardware:

For a while, there was a competition among sound hardware companies in comparision of "ports" or channels of audio.

The Adlib had 11 or 9 channels (of FM synthesis = average quality)
The Game Blaster had 12 channels (of square wave synthesis = poor quality)
The GUS had 32 digital channels (of variable quality depending on memory and use)
The MT-32 had 32 channels (of LA synthesis = best synthesis quality)
And the Sound Blaster was claimed to have 24 ports (12 CMS + 11 Adlib + 1 DAC)

Then all of this channel counting became moot when two things happened. 1) Computers had the processing power to mix as many channels as they needed using the digital channel. 2) Music was driven by CD audio.

Well there was a time where "hardware wavetable" with MIDI was the preferred music combination, "software wavetable" implementation wasn't in that many games... even now, games tend to use precompressed streaming audio in mp3 or ogg or some other format.

Darkfalz wrote:

"software wavetable" implementation wasn't in that many games...

Yeah, the only major examples of games with software wavetable I can think of are some of the early 90's Epic games and Star Control 2.

canadacow wrote:

The MT-32 had 32 channels (of LA synthesis = best synthesis quality)

Wow... I write the emulator for it myself and still get a historical fact horribly wrong. The MT-32 did not have 32 channels. It had 9 channels (8 melody, 1 percussion) but each of those 9 channels could have different notes of the instrument playing, up to 32 independent sounds, depending on the sound configuration.

Origin had a few games that utilized one of the major wavetables on the scene. The games that I have that has the ability to use a wavetable soundcard for it purposes was Crusader: No Regret w/ Patches, Crusader: No Remose, and also Westwood's Legend of Kyrandia 3: Malcom's Revenge. The wavetable in question was the Ensoniq Soundscape Wavetable 😀.

canadacow wrote:

Darkfalz wrote:

"software wavetable" implementation wasn't in that many games...

Yeah, the only major examples of games with software wavetable I can think of are some of the early 90's Epic games and Star Control 2.

"Software wavetable" is such an ugly name for it, considering that it had very little in common with "Hardware wavetable", which is MIDI-based. I suppose it's an adequate term, but most people would refer to it as a 'tracked module' or some variant thereof ['track', 'module', 'mod' (although that's a poor nickname for it, considering it only refers to one of the many sub-categories of formats)]. Actually, I ran the IRC network that the main channel for trackers resided on -- #trax on SceneNet.

At any rate, you're right, I can't think of many games that had utilized tracked music on the PC other than the Epic games, like One Must Fall (music by C.C. Catch) and Jazz Jackrabbit and so forth. I suppose the chief reason was that advanced tracked formats such as .IT [IT] by Jeff Lim and .XM [FT2] by Triton were fairly complicated and not extremely well-documented. The four channel, primitive effects, 8-bit, small sample size limits of .MODs [that were really based upon Amiga Paula sound chip limitations] were quickly reached as better MIDI hardware became cheaper and more readily available.

Still, there are some real benefits to advance format tracked music over General MIDI, but with games coming on multiple cds nowadays and digital compression so effective, there's really no point I suppose.