In the DOS era there was not much MIDI-capable hardware, and it definitely was not meant to interface FM synths.
The dos games would play game-specific music formats via game- or game engine-specific driver (AIL, MIDPACK, etc). The driver would normally access OPL hardware directly, though later games could be configured to use Windows' MIDI playing facilities, which then might rely on the FM synthesis of the available cards, but that was never the intent of the MIDI.

For the in-game music format it was anything - proprietary formats, or plain MIDI files.
The MIDI files are storing MIDI commands, but drivers for OPL hardware would just interpret those commands and write appropriate values into synth registers, so MIDI music does not mean it had to be played through MIDI. It allows you to play music much better if you had MIDI hardware, but FM synths are not communicated through MIDI interface.

DOS games supporting FM either were issuing commands directly to OPL2/3 chips by using i/o ports (say, 388hex, 389hex) or by using musical notes (MIDI or not) and a music driver with a sound bank.

This driver was either a separate music engine, like Miles Sound System (DOS4GW games) or a driver like P.M.D Music Driver (Japanese games, like Rusty, Marble Cooking etc) or SOUND.COM/SBFMDRV.COM (AdLib/Soundblaster).

On Windows 3.1x, there are FM drivers which convert MIDI music to OPL2 commands, using a sound bank.
A sound bank is like a graphical font (like TrueType), but for sound chips.
It defines the individual instruments, like a piano, a harp or a guitar.
The famous Voyetra SuperSAPI driver is one of them.

Older application frameworks like Allegro do contain something similar.
They can do provide MIDI support for OPL3, EMU-8000 etc.

I have fairly limited knowledge on the subject, but here's my vague understanding of it:

Most games had midi music in vaguely proprietary formats that they would then play back on whatever device you configured. This was normally done through a handful of sound libraries that most games of the time used, which tended to support a variety of different playback devices. This is why many game's sound config menus are identical, they use the same library. If you select sound blaster (or something similar) for your music then it goes to the OPL, if you select an actual midi device (sound canvas, mt32, etc.) then it goes out to that.

It seems like most musicians at the time originally used a midi module when writing the music, but they very clearly targeted it towards playback on a sound blaster or compatible. The Tyrian sound track is a classic example where it sounds much better when played back on a sound blaster than an actual midi module. Developers at the time knew that users were very likely to have a sound blaster (and unlikely to have their own midi module), so I think they tended to adjust the music so it sounded good when played back on a soundblaster.

We're actually really lucky that developers all tended to use a handful of sound libraries because that left us with compatibility for a bunch of wildly different hardware in most games, some of which the developers never even tested or intended. It's actually pretty cool.

^commercial games&developers, yes. In the 90s, there also a large number of "bedroom programmers", though.
Not unlike it was with the countless C64, Amiga, ZX81 etc programmers in the 80s.

The game changer was the introduction of the CD-ROM, though. And access to online services like CompuServe with their various Forums.
These gave those individuals a good way of distribution.
The shareware/freeware/public domain scene of the 90s was full of DOS/Windows 3.x games programmed by one or two individuals (roughly). Some of which had run their one-man company.

Those individuals perhaps didn't all have access to electric pianos or synths, but merely a Sound Blaster or similar sound device.
So it made sense to them to directly compose music/sfx through the use of OPL commands.

midicollector wrote on 2023-09-16, 03:06:

It seems like most musicians at the time originally used a midi module when writing the music, but they very clearly targeted it towards playback on a sound blaster or compatible. The Tyrian sound track is a classic example where it sounds much better when played back on a sound blaster than an actual midi module. Developers at the time knew that users were very likely to have a sound blaster (and unlikely to have their own midi module), so I think they tended to adjust the music so it sounded good when played back on a soundblaster.

This was not always the case. As Jo22 mentioned, not everyone was using expensive professional music gear, and not exactly everyone was in the MIDI ecosystem. The example Tyrian you mentioned happens to be a track that was deliberately made in an Adlib tracker for Adlib compatible sound cards. You can also listen to the OG music release by the author himself that clearly sounds like Adlib music.

Still your point remains true, many composers used MIDI as it became the standard in studios and art schools. But the "bedroom composers" might have used whatever they had, including Adlib and sample tracker software.

vstrakh wrote on 2023-09-15, 12:47:

The dos games would play game-specific music formats via game- or game engine-specific driver (AIL, MIDPACK, etc). The driver would normally access OPL hardware directly,

Jo22 wrote on 2023-09-15, 13:12:

DOS games supporting FM either were issuing commands directly to OPL2/3 chips by using i/o ports (say, 388hex, 389hex) or by using musical notes (MIDI or not) and a music driver with a sound bank.

This driver was either a separate music engine, like Miles Sound System (DOS4GW games) or a driver like P.M.D Music Driver (Japanese games, like Rusty, Marble Cooking etc) or SOUND.COM/SBFMDRV.COM (AdLib/Soundblaster).

I suppose for commercial games a driver is usually involved, since apparently even the earliest FM option for games, adlib, came with one (SOUND.COM)?

Besides demos and indie games, were there any commercial ones that didn't use drivers, and issued commands directly to the I/O ports?

vstrakh wrote on 2023-09-15, 12:47:

though later games could be configured to use Windows' MIDI playing facilities, which then might rely on the FM synthesis of the available cards, but that was never the intent of the MIDI.

Could you go into more detail? By "could be configured", do you mean by the devs, or by the users through the games' sound setup?
Do you remember which games?

vstrakh wrote on 2023-09-15, 12:47:

For the in-game music format it was anything - proprietary formats, or plain MIDI files.
The MIDI files are storing MIDI commands, but drivers for OPL hardware would just interpret those commands and write appropriate values into synth registers, so MIDI music does not mean it had to be played through MIDI. It allows you to play music much better if you had MIDI hardware, but FM synths are not communicated through MIDI interface.

Jo22 wrote on 2023-09-15, 13:12:

On Windows 3.1x, there are FM drivers which convert MIDI music to OPL2 commands, using a sound bank.
The famous Voyetra SuperSAPI driver is one of them.

Older application frameworks like Allegro do contain something similar.

Ah, alright, so when some people say "FM through MIDI", it basically only means that the commands are simply stored in a MIDI file format, but the drivers/games would still talk to the FM synth directly, and not the MIDI protocol.

That's the understanding I had, but in a recent conversation when I made the distinction between FM and MIDI, was told "don't know what you're talking about".

Jo22 wrote on 2023-09-15, 13:12:

They can do provide MIDI support for OPL3...

Based on what's mentioned beforehand, I suppose by "MIDI support", you mean in regard to the file formats?

A FM chip is not midi capable by itself.
It is adressed by the system bus with data.
The adressing always works the same, but how a specific game used the capabilities of a fm chip depends on the programmer.
No dos game required a driver to play Adlib(FM) music/sounds.
The "Setup" was done by jumpers on the soundcard, so the fm chip is wired to a specific address, then you had to tell the game where you have put the jumpers to find the fm chip.

When midi comes into play we have a layer between fm and the inputted midi notes. A Program that translates instrument data, volume data and so on into data that a fm chip can understand.

For example the Yamaha FB01 is such a thing... It takes Midi input and with the help of fm chips inside it produces sounds.

DerBaum wrote on 2023-09-16, 11:46:

No dos game required a driver to play Adlib(FM) music/sounds.

Au contraire. A few required one. There's Spellcasting 101 that comes to mind, for example. 🙂

"The original diskette version of the game requires that the SOUND.COM TSR is loaded before starting the game to get Adlib sound.
This is not needed for the later CD release.

SOUND.COM came on a driver disk with the Adlib soundcard.
If you have a Creative SoundBlaster card, your can instead load SB-SOUND.COM which was shipped with the SoundBlaster card.
However the original Adlib SOUND.COM will work fine on SoundBlaster and other clone cards, and is often preferred for better compatibility. "

Source: https://www.pcgamingwiki.com/wiki/Spellcastin … t_All_the_Girls

Jo22 wrote on 2023-09-16, 12:21:

Au contraire. A few required one. There's Spellcasting 101 that comes to mind, for example. 🙂 […]
Show full quote

DerBaum wrote on 2023-09-16, 11:46:

No dos game required a driver to play Adlib(FM) music/sounds.

Au contraire. A few required one. There's Spellcasting 101 that comes to mind, for example. 🙂

"The original diskette version of the game requires that the SOUND.COM TSR is loaded before starting the game to get Adlib sound.
This is not needed for the later CD release.

SOUND.COM came on a driver disk with the Adlib soundcard.
If you have a Creative SoundBlaster card, your can instead load SB-SOUND.COM which was shipped with the SoundBlaster card.
However the original Adlib SOUND.COM will work fine on SoundBlaster and other clone cards, and is often preferred for better compatibility. "

Source: https://www.pcgamingwiki.com/wiki/Spellcastin … t_All_the_Girls

Of course there are exceptions to the norm.
To keep it simple and not cause more confusion i explained in the most simple way.

I have a lot of soundcards that need to be initialized first before even the fm part makes any sound... but that information is completely irrelevant... so i dint mention drivers and so on...

DerBaum wrote on 2023-09-16, 14:36:

Of course there are exceptions to the norm. To keep it simple and not cause more confusion i explained in the most simple way. […]
Show full quote

Jo22 wrote on 2023-09-16, 12:21:

Au contraire. A few required one. There's Spellcasting 101 that comes to mind, for example. 🙂 […]
Show full quote

DerBaum wrote on 2023-09-16, 11:46:

No dos game required a driver to play Adlib(FM) music/sounds.

Au contraire. A few required one. There's Spellcasting 101 that comes to mind, for example. 🙂

"The original diskette version of the game requires that the SOUND.COM TSR is loaded before starting the game to get Adlib sound.
This is not needed for the later CD release.

SOUND.COM came on a driver disk with the Adlib soundcard.
If you have a Creative SoundBlaster card, your can instead load SB-SOUND.COM which was shipped with the SoundBlaster card.
However the original Adlib SOUND.COM will work fine on SoundBlaster and other clone cards, and is often preferred for better compatibility. "

Source: https://www.pcgamingwiki.com/wiki/Spellcastin … t_All_the_Girls

Of course there are exceptions to the norm.
To keep it simple and not cause more confusion i explained in the most simple way.

I have a lot of soundcards that need to be initialized first before even the fm part makes any sound... but that information is completely irrelevant... so i dint mention drivers and so on...

No problem, I didn't knew it either until a few years ago. 😅
My Pro Audio Spectrum 16 didn't ship with any Sound Blaster/AdLib utility, either. 🤷‍♂️

I assume that by ~1994, the old sound.com driver from the 80s was nolonger of much relevance.
Despite the fact that the sound.com was meant as an official sound library/interface for the AdLib card.

Even the AdLib Jukebox used it, originally. In later versions, the need for sound.com was dropped.

The dilemma here is that games made by Legend (Spellcasting 101, Gateway with MPU-401 UART support) do use the official, correct way of doing things.

Akin to, for example, use DOS/BIOS calls vs accessing Hardware directly.
Or like, for example, determining the video frame buffer location in memory first,
rather than simply assuming the default location that is common (A000h on VGA, B800h on CGA) etc.

So what these few, highly professionally made games do is in harmony with the official programmimg guidelines.

That's the dilemma here, I think.
There are about a dozen games that work "correctly" vs a hundreds of thousand doing it the "wrong" way.

It's like a handful of sane people among a legion of insane people.
But because the majority is being thought of as being right, these dozen people are being seen as irregulars, as the crazy ones.
Because, the crazy people think they're sane, of course. It's all a matter of perspective, I guess.

Anyway, I didn't mean to criticize you in any way.
My apologies if it did sound that way.
The situation with FM music has quite some diversity, I think. 🤷‍♂️
There are many roads that lead to Rome, so to say.

Personally, I recommend reading the book "The Sound Blaster book" or "Programming the Sound Blaster Card".
There's also the "Sound Blaster Developer Kit" available somewhere online.

__
That being said, Sound Blaster and AdLib aren't exactly same when it comes to FM programming.

The Sound Blasters have a separate set of FM i/o port addreses at 220h/221h (OPL2; OPL3 has extra i/o ports for left/right).
Of course, they also listen to the old AdLib ports at 388h/389h.
So well written FM games prefer the old ones, in order to be compatible with AdLib and its clones.

The Sound Blaster ports are handy if multiple sound cards are installed, so their FM part can be individually addressed.

The problem is, that some games do use different ways to get their.
Some do use math to get to the i/o ports they think is right.
Like 220+168=388h (220h is SB default i/o port, 388h AdLib default i/o port).

But by that logic, using the alternate SB i/o port of 240h would lead those games to believe the FM port is at 408h (and 409h), which isn't exactly true (it's 240h/241h).

Jo22 wrote on 2023-09-16, 20:48:

That being said, Sound Blaster and AdLib aren't exactly same when it comes to FM programming. […]
Show full quote

That being said, Sound Blaster and AdLib aren't exactly same when it comes to FM programming.

The Sound Blasters have a separate set of FM i/o port addreses at 220h/221h (OPL2; OPL3 has extra i/o ports for left/right).
Of course, they also listen to the old AdLib ports at 388h/389h.
So well written FM games prefer the old ones, in order to be compatible with AdLib and its clones.

Er, other than the port, it's pretty much the same, unless you are specifically programming to the OPL3. Let's get a few things straight:

Adlib: 1 OPL2 @ 388h/389h;
Adlib Gold: 1 OPL3 @ 388h/389h (OPL2 mode) or 388/389/38A/38B (OPL3 mode);

Sound Blaster: 1 OPL2 @388/389h AND base port + 8/9h (example 228/229 if BP @220h or 248/249h if BP @240h); in these cards 220h-223h is reserved for left and right SAA 1099.
Sound Blaster Pro: 2 OPL2, left OPL2 addressed @388/389h AND base port + 8/9h(OPL2 mode). Left OPL2 @220/221 and Right OPL2 @222/223h (Dual OPL2 mode);
Sound Blaster Pro2: 1 OPL3 @ 388h/389h AND base port + 8/9h (OPL2 mode) or base port + 0/1/2/3h (OPL3 mode);

ATI Stereo FX: Exactly the same as Sound Blaster;

Thunderboard: Same as Sound Blaster, minus CMS;
Pro Audio Spectrum : 2 OPL2. Left OPL2@ 388h/389h (OPL2 mode) AND Right OPL2 @38A/38Bh (Dual OPl2 mode) (managed by MVSOUND.SYS);
PAS Plus/PAS 16: 1 OPL3 @ 388h/389h (OPL2 mode) or 388/389/38A/38B (OPL3 mode) natively; When in SB compatibility OPL3 only works in Base Port + 8/9h (OPL2 mode);

Jo22 wrote on 2023-09-16, 20:48:

The problem is, that some games do use different ways to get their. Some do use math to get to the i/o ports they think is righ […]
Show full quote

The problem is, that some games do use different ways to get their.
Some do use math to get to the i/o ports they think is right.
Like 220+168=388h (220h is SB default i/o port, 388h AdLib default i/o port).

But by that logic, using the alternate SB i/o port of 240h would lead those games to believe the FM port is at 408h (and 409h), which isn't exactly true (it's 240h/241h).

Can you give me an example of a game that works like this?? Usually the math is added with Base Port +8/9h, it never adds up to the Adlib Port @388h. Base Port is figured out either by the BLASTER environment variable or via a setup configuration file. I never seen OPL2 source code routines doing math like this.

Hm, you're right it seems. My bad, SB FM is listening for center/mono at base address +8/9h (and the old AdLib ports), as you also pointed out.
For some reason I had mistaken the address of the left FM channel (SB Pro etc) for mono sound.
I suppose that was because left audio often is used for mono output/as a primary output, too. In general, I mean. Not specific to soundcards.
That's the only explanation that comes to mind. 🤷‍♂️
Thanks for clarification, also.

Edit: The weird FM math.. Well, I remember reading about it a few times online, but can't think of a real world example here.
I never used that math myself, either, also. I was fine with the AdLib ports.

Jo22 wrote on 2023-09-20, 04:57:

Edit: The weird FM math..

I always thought the "math" is for the scale of the tones.
Because the FM operator does not behave like a analog circuit you cant simply scale the tones linear, so you have to calculate them.

But this is just theory that i have read somwhere, and i dont know if its like that or if i remember it wrong.

Some years ago i wanted to utilise fm chips out of old yamaha keyboards in self made synthesizers. But im not a programmer. I have learned a lot how to control the chips but i simply cant write proper code.

I always thought the "math" is for the scale of the tones.

Hi there, good point. I was referring to "calculation" of the offset for the FM chip.
The BLASTER variable merely holds information for the base address of the SB specific part and optionally, MPU-401 and EMU8000.
It roughly looks like this: BLASTER=A220 I7 D1 H5 P330 E620 T6
The FM port address is not explicitly mentioned and must be determined separately.

Anyway, these are merely details.
What I meant to say was that games written with Sound Blaster in mind usually have two options for accessing FM chip (the OPL2).
Unless they allow the user to manually configure the FM base address, of course. Via config file, sound setup menu etc.

a) use AdLib's base address (FM default: 388h/389h, probably the result of 380h+8h/380h+9h; other base addresses selectable)
b) use Sound Blaster's base address (FM default: 228h/229h, result of 220h+8h/220+9h; other base addresses selectable)

(Other addresses may also be valid if the sound card in question has incomplete address decoding;
and some i/0 addresses may also repeat in memory due to the memory layout of the PC bus. Aliases may exist.)

The AdLib port usually is fine in most cases, since it's not Sound Blaster specific. It's not "proprietary" to Creative products.
Sound cards that aren't Sound Blaster compatible, but support FM, do usually listen to the AdLib port.

Dual OPL2/OPL3 and stereo is not so well standardized, there are differences between Sound Blasters and Pro Audio Spectrums, for example.
The summary of carlostex gives a very good idea about the details (kudos!, btw).

Edit: Wording fixed. Still not completely error-free, I'm afraid.

Jo22 wrote on 2023-09-20, 13:10:

a) use AdLib's base address (FM default: 388h/389h, probably the result of 380h+8h/380h+9h; other base addresses selectable)

AdLib port, 388h, is pretty much always fixed in games unless the game allows you to tell that for a specific card. I’ve disassembled various games for the CMS and Tandy patching projects and no game ever started with 380h and then had 8 added to a register or a variable.

It’s EXTREMELY common to find in games, on the AdLib routines to find a MOV DX, 388h, into opcodes that translates into BA 88 03. Usually then instead of doing a BA 89 03 if you need, you just do a INC DX which is 1 vs 3 bytes.

The Base Port + 8/9 is a Creative Labs thing and that’s it. That’s because CL decided to duplicate the AdLib port on BP + 8/9 and that’s it. You can check a Sound Blaster manual and confirm the address map.

For instance if you change the Base port on an AdLib Gold, from 388h to let’s say 398h, it means that the OPL3 on the AdLib Gold won’t play anymore unless a game allows you to change the default AdLib(OPL2) for that card or you’ll have to patch the game.

Jo22 wrote on 2023-09-20, 13:10:

b) use Sound Blaster's base address (FM default: 228h/229h, result of 220h+8h/220+9h; other base addresses selectable)

For Sound Blaster, yes.

carlostex wrote on 2023-09-20, 20:34:

AdLib port, 388h, is pretty much always fixed in games unless the game allows you to tell that for a specific card.
I’ve disassembled various games for the CMS and Tandy patching projects and no game ever started with 380h and then had 8 added to a register or a variable.
[..]

I see. I shouldn't have mentioned that.. I somehow knew this would end up in an argument. *sigh*
Okay, the reason I mentioned that is the recent activity in another thread.
There, the reason for the original AdLib's i/o jumper block was being discussed.

If I hadn't mentioned that other port addresses are technically available,
someone would surely have been complaining here about that, as well.
So I felt the need to make a comment about that, at least. 🤷‍♂️

Edit: Thanks for clarification, though.
If something is wrong, then it's wrong and should be addressed, of course. 👍

Jo22 wrote on 2023-09-20, 21:14:

I see. I shouldn't have mentioned that.. I somehow knew this would end up in an argument. *sigh* Okay, the reason I mentioned th […]
Show full quote

I see. I shouldn't have mentioned that.. I somehow knew this would end up in an argument. *sigh*
Okay, the reason I mentioned that is the recent activity in another thread.
There, the reason for the original AdLib's i/o jumper block was being discussed.

If I hadn't mentioned that other port addresses are technically available,
someone would surely have been complaining here about that, as well.
So I felt the need to make a comment about that, at least. 🤷‍♂️

Edit: Thanks for clarification, though.
If something is wrong, then it's wrong and should be addressed, of course. 👍

Exactly this was just for clarification, nothing else. About that thread, I never commented on it because it felt rather silly. Robin has been here long enough to understand how the AdLib works, but whatever. Things are what they are.