Retrocomputing Stack Exchange is a question and answer site for vintage-computer hobbyists interested in restoring, preserving, and using the classic computer and gaming systems of yesteryear. It only takes a minute to sign up.
Sign up to join this community
By "AdLib sound card" I mean AdLib Music Synthesizer Card released in 1987.
Wikipedia says that AdLib uses frequency modulation synthesis to produce sound, but does it use MIDI communication protocol or some another way?
It's entirely possible that the FM synthesis uses MIDI under the hood to control the FM synthesis chip. The other option would be a specific driver control library which would be linked into the software.
-- From the question on the sound.stackexchange.com
As documented by Jeffrey S. Lee, the AdLib simply provides raw programmatic access to its OPL2:
The sound card is programmed by sending data to its internal registers via its two I/O ports: ...
The sound card possesses an array of two hundred forty-four registers; to write to a particular register, send the register number (01-F5) to the address port, and the desired value to the data port.
After writing to the register port, you must wait twelve cycles before sending the data; after writing the data, eighty-four cycles must elapse before any other sound card operation may be performed.
So, no MIDI, no other high-level format. The card produces nine channels of sound, each of which is the product of two sine-derived functions; you can instead configure it as six of those channels plus five percussion channels.
It supports automatic application of ADSR but otherwise it is a simple modal device. Set the current instrument set, their frequencies and volume envelopes, then they'll play continuously until you tell the card otherwise.
So, unlike MIDI or other formats like it, there's no inherent sequencing or timing of notes — the card has no autonomy in proceeding through music. It just makes the noises you've currently assigned to it.
(and as to implementation of that expensive-sounding audio generation, see this reverse engineering; summary: it's all log tables)
As another answer has said, the OPL2/3 chip on the AdLib is driven by directly writing the registers that control the pitch, volume, and tone of each channel. But how does a game (or other music player) know what values to send when? There are a few different approaches.
Raw data. The IMF format used by Apogee and early Id titles is a typical example of this. The file is a sequence of instructions, where every instruction consists of which register to write, what value to write, and how long to wait before processing the next instruction. This is easy to integrate into a game engine, and uses pretty much the minimal possible amount of CPU on playback. The DRO format used by DOSBox's OPL capture is a slightly more advanced version of this concept that produces smaller file sizes, and there's at least one game in existence that stores its music files on disk as DRO (I know because I wrote the music playback code for it).
Raw data with separate instrument definitions. A simple way to save space (and simplify composer tools) is to define an instrument by directly dumping the OPL register values needed to create a given sound, and store the instruments separately from the note data. Then on playback you need commands to set the instrument for a given channel (which loads a bunch of registers from the instrument data), play a note at a given pitch and volume (loads the pitch, volume, and keyon registers), and stop a note (clears the keyon register). The ROL format used by AdLib themselves is an example of this method.
MIDI. If you have instrument definitions for each of the 127 General MIDI instruments (you could get these from AdLib, or someone else, or make your own), then you can play MIDI files by parsing the MIDI events and doing a little bit of conversion between the value ranges used by MIDI and the value ranges used by AdLib. The Windows 3 - 9x MIDI Mapper driver did this, as did several standalone DOS MIDI players and DOS games.
CMF (Creative Music Format) was a very popular format for AdLib music, which is almost MIDI, except that the headers are different (it isn't recognized as a MIDI file), and each file contains its own set of instrument definitions (like option #2) instead of using a standardized set of General MIDI patches. Program numbers in the MIDI data correspond to the built-in instruments rather than GM instruments. The "SBFMDRV" music driver provided by Creative Labs supports playback of CMF, and a number of games make use of it.
Anything else. Since the programming interface to the OPL chip is so simple and low-level, other things are possible that I don't have time to write about. Procedurally generated music, using AdLib for sound effects rather than music by tweaking the register values in real time, AdLib S3M modules, etc., etc.
