Figured it out! I had to write to Port 220, the SoundBlaster port. I guess they figured OPL2 apps would use Adlib's 388, but anything supporting the new-fangled OPL3 features should use the same port as the SB since this was before the Gold IIRC. Jeez, I wonder how many DOS programs mess this up. There doesn't appear to be a reliable way of testing for OPL3 vs. 2, so maybe the thing to do is to just look for the BLASTER environment variable. Bogus!

On YMF71x cards you do get full OPL3 access via $388...$38B.

louisg wrote:

I guess they figured OPL2 apps would use Adlib's 388, but anything supporting the new-fangled OPL3 features should use the same port as the SB since this was before the Gold IIRC.

No major sound card shipped with OPL3 "before the Gold", and certainly nothing from Creative. A few reviews of the time criticised Creative for being so late to the party, while others were shipping OPL3 review units and even had 4-operator stereo cards on store shelves.

Creative just arrogantly decided that they were the standard, and didn't have to follow what was already being used for OPL3 by almost everyone else. I guess it was also meant to provide an element of vendor lock-in.

It was definitely the Adlib Gold that took overly long to reach retail availability. The delay is probably exactly why they went bankrupt in 92. SB Pro 2's were out at about the same time.

Huh, I wonder if the Gold launch date varies by territory then. Or simultaneous development even though the releases weren't? I definitely remember not seeing the Gold on shelves until after I had a Pro, though that might've just been down to Adlib being less popular. I wonder what the story is. I bet we could find a definitive answer digging through old mags.

Sad that OPL3 never had the software support it deserved. That thing is an absolute beast of a synthesizer- I may even prefer it to the OPM. If they had stuck some cheap DSP fx like reverb on it, and supplied developers with some decent patches, it would've sounded just amazing.

Here's a quick preview of my musicdisk. Still working on optimization (goal is 70FPS on a 486dx2 66), and it does sound a bit better outside of DOSBox
https://youtu.be/7KTIbHxTNDU

What I heard is that the AdLib Gold was delayed because AdLib needed special chips developed by Yamaha, and Yamaha's chips kept failing validation.
The people at Creative claimed that they were very close with Yamaha because they sold so many OPL chips, and claimed that they deliberately made Yamaha delay the AdLib Gold so that the SB 16 could be out first (so apparently the Sound Blaster Pro 2 was out already as well).
https://www.pcgamer.com/author-of-sound-blast … ys-of-pc-audio/

Scali wrote:

What I heard is that the AdLib Gold was delayed because AdLib needed special chips developed by Yamaha, and Yamaha's chips kept failing validation.
The people at Creative claimed that they were very close with Yamaha because they sold so many OPL chips, and claimed that they deliberately made Yamaha delay the AdLib Gold so that the SB 16 could be out first (so apparently the Sound Blaster Pro 2 was out already as well).
https://www.pcgamer.com/author-of-sound-blast … ys-of-pc-audio/

Oh wow, that means I only saw Adlib Gold on the shelf after the company had died. That's too bad-- Creative's cards had a lot of room for improvement and kind of a meek feature set for the price. Though, I am happy that we had many years of FM jams 😀

The fact remains that Ad Lib approached Yamaha and worked with them to define what became the OPL3; it should be no surprise that they were among the first to gain access to the design. If you still need to convince yourself, go back and read old magazine articles. Computer Gaming World mentioned Creative's upcoming second-generation Sound Blaster Pro, saying that it seemed reasonable to expect that it would be compatible with the Gold, because software written for its dual-OPL2 predecessor likely wouldn't work. Early review units and developer kits seem to have been in circulation well before the bankruptcy (in some cases, even the Gold 2000 seems to have been making the rounds). Actually buying one around the time of the bankruptcy wasn't easy, but wasn't entirely impossible, either.

Media Vision had their card ready before Creative, too, if I'm not mistaken. I vividly remember reading reviews in another magazine that mentioned the superior quality of the synthesised music on the Gold and other early OPL3 cards, while complaining that Creative had yet to deliver a 4-operator stereo card for review. I wish I could remember which magazine that was.

It wouldn't surprise me at all if Creative had orchestrated the delays that led to Ad Lib's trouble (the chip that had "test failures" was likely the MMA, another design Ad Lib had apparently requested). The last thing Creative would have wanted was to have another industry standard take hold (they were also just about the only major industry player conspicuously absent from the VBE/AI standardisation process, which speaks volumes about their motivations). Still, the Sound Blaster 16 was definitely not in stores before the Gold. Creative did manage to get the second-generation, OPL3-based Pro out the door quickly enough to prevent the Gold Sound Standard from becoming established, but the Sound Blaster 16 ASP arrived somewhat later, and was still more expensive by a good margin. It was only with the later Sound Blaster 16 Basic that the price was almost reasonable, but by then, Creative's entire line was already being put to shame, in terms of capabilities and sound quality, by the similarly-priced GUS.

louisg wrote:

Here's a quick preview of my musicdisk. Still working on optimization (goal is 70FPS on a 486dx2 66), and it does sound a bit better outside of DOSBox
https://youtu.be/7KTIbHxTNDU

Very nice!
Yea, OPL3 never really got the support it deserved. Trackers were generally aimed at the GUS and software mixing routines, not at using OPL2/OPL3 chips.
I did an invitro for the Outline party earlier this year, which also uses an OPL3 track, made in Adlibtracker II. I never paid attention to the OPL-tracker scene, so I had no idea that people were still developing trackers for these chips, and people writing music... It was quite a surprise to hear what people can do with an OPL3 these days.
I was an early adopter of the SB Pro 2, back in the day, and still have my original card, but I never heard it sound like that.
http://www.pouet.net/prod.php?which=75755

Scali wrote:

Very nice! Yea, OPL3 never really got the support it deserved. Trackers were generally aimed at the GUS and software mixing rout […]
Show full quote

Very nice!
Yea, OPL3 never really got the support it deserved. Trackers were generally aimed at the GUS and software mixing routines, not at using OPL2/OPL3 chips.
I did an invitro for the Outline party earlier this year, which also uses an OPL3 track, made in Adlibtracker II. I never paid attention to the OPL-tracker scene, so I had no idea that people were still developing trackers for these chips, and people writing music... It was quite a surprise to hear what people can do with an OPL3 these days.
I was an early adopter of the SB Pro 2, back in the day, and still have my original card, but I never heard it sound like that.
http://www.pouet.net/prod.php?which=75755

That's cool! I'm digging some of the sounds you're getting out of that thing. Yeah, back in the day, there didn't seem to be many DOS game musicians who were FM-savvy. I'm surprised when it came to FM chips that the companies didn't hire a patch designer and ship a bunch of really nice presets. It seems like the Japanese and Korean gamedev scenes had some pretty hardcore FM synth hobbyists floating around at least, and I know there were a couple great synth-heads like Stephane Picq and Moby, but in general I think there was a dearth of good patch design in DOS productions. It's not the tools IMO-- the original RADTracker was very basic but you could get fantastic sounds out of it by applying the same kinds of techniques that makes other synths shine. Western musicians weren't alone in being baffled-- I can hardly think of a Japanese OPL2-based arcade machine which sounds that great without leaning on PCM.

I keep thinking of doing an OPL3 General MIDI engine that ships with a bunch of really nice patches, maybe with features like velocity switching for maximum expressiveness. It'd be basically a MIDI mastering tool: load up a MID file, select patches, adjust levels, apply effects like echos/doubling/etc, allow the user to decimate pitch wheel messages or change other timings... I could even see an engine that compiles down to a format that's lighter weight (with all the voice allocation/note stealing baked in). I'm not sure how much interest there would be though.

louisg wrote:

That's cool! I'm digging some of the sounds you're getting out of that thing.

Well, credit where credit's due, I didn't make the music, Diode Milliampere did.
I just wrote the code.
Speaking of FM, a few years earlier I did a small thing with OPL2 music, made with EdLib tracker, music by No-XS:
http://www.pouet.net/prod.php?which=62165

louisg wrote:

It's not the tools IMO-- the original RADTracker was very basic but you could get fantastic sounds out of it by applying the same kinds of techniques that makes other synths shine.

I think it was the tools though.
RADTracker didn't come out until 1995, and EdLib is from 1994. By that time, the era of FM was basically over. We were in the era of fast 486 machines and early Pentiums, which could easily do software mixing of 16 or more channels at 16-bit 44.1 kHz. Aside from that, CD-ROM became the standard.

There should have been a decent AdLib tracker in the late 80s, then it may have been different.

louisg wrote:

I keep thinking of doing an OPL3 General MIDI engine that ships with a bunch of really nice patches, maybe with features like velocity switching for maximum expressiveness. It'd be basically a MIDI mastering tool: load up a MID file, select patches, adjust levels, apply effects like echos/doubling/etc, allow the user to decimate pitch wheel messages or change other timings... I could even see an engine that compiles down to a format that's lighter weight (with all the voice allocation/note stealing baked in). I'm not sure how much interest there would be though.

I think that may be where OPL2 and OPL3 went wrong in the first place: most games just used standard MIDI music, with default instruments.
Most developers either didn't have the time or the knowledge to tweak their music specifically for OPL2 and OPL3.
I think trackers are better than MIDI for the simple reason that the pattern approach is easy to sync to the display refresh rate, which has many advantages for slow systems (you always know exactly where and when your music data is processed).

Scali wrote:

I think it was the tools though.
RADTracker didn't come out until 1995, and EdLib is from 1994. By that time, the era of FM was basically over. We were in the era of fast 486 machines and early Pentiums, which could easily do software mixing of 16 or more channels at 16-bit 44.1 kHz. Aside from that, CD-ROM became the standard.

RAD 1 was very basic though; it's just easy to use. It didn't do macros, it didn't do vibrato, and the instrument definitions were literally just whatever the OPL registers were. It had about 8 commands, and pitch slide up/down and volume change were three of them already. My understanding too is a lot of those really kick ass FM tracks for Genesis were done in a very basic language like MML.

I think that may be where OPL2 and OPL3 went wrong in the first place: most games just used standard MIDI music, with default instruments.
Most developers either didn't have the time or the knowledge to tweak their music specifically for OPL2 and OPL3.
I think trackers are better than MIDI for the simple reason that the pattern approach is easy to sync to the display refresh rate, which has many advantages for slow systems (you always know exactly where and when your music data is processed).

I do tend to think trackers are best for squeezing every last drop out of a chip, but a lot of DOS stuff didn't even scratch the surface. Default instruments like you mentioned are probably the biggest culprit. Honestly, patch design gets you 90% of the way there. If I have strong composition and strong patches, I don't need to even put down a single command for it to sound good-- I can just put the notes down and voila. One reason I want to do a GM engine for OPL3 is to prove my point once and for all that it's possible to make an FM engine that you can throw GM tracks into and have it sound nice.

But you are absolutely right that syncing to a slower timer is a big advantage. 480PPQ is way too much of a burden. But that's why I was getting into decimating the messages, quantizing everything to a lower clock. You could even go down to refresh I bet if you don't go too nuts with the wheel (even something like Doom's MIDI engine supported wheel messages to some extent). The absolute lightest thing to do though is to implement GM's monophonic mode CC and put the vibrato on a delay. That gives you most of everything you can do with a lead-- you can even do those neck-slide pitch effects by overlapping notes at that point (especially if you implement your glides not as constant-time but as constant-rate).

You still generally do wind up with multiple timers for anything but PAL and trackers, just because everything in the tracker scene got standardized around 50hz and everything else is 60 or 70, and it's also how varied BPMs are produced (if the engine decides to implement it). I wonder why we didn't see more DOS scene trackers based on 60 or 70..? Could there be something more pleasing about 50hz-based BPMs, or is it just what we got used to? I definitely have some pro-50hz arguments hehe

louisg wrote:

My understanding too is a lot of those really kick ass FM tracks for Genesis were done in a very basic language like MML.

I think the best FM music came from people who developed their own tools. This is true for Dune and Tyrian at least.

louisg wrote:

One reason I want to do a GM engine for OPL3 is to prove my point once and for all that it's possible to make an FM engine that you can throw GM tracks into and have it sound nice.

True, FM has pretty advanced parameters for its instruments, so you don't need a lot of manual effects added to each played note to get a rich sound.
I think the best approach might be to use an approach similar to the UltraMid player for the GUS: they allow a configuration file for each MIDI file you play, to load custom patches. For OPL3 that would also allow you to fine-tune the instruments for each MIDI file, which would probably sound very nice.

louisg wrote:

But you are absolutely right that syncing to a slower timer is a big advantage. 480PPQ is way too much of a burden. But that's why I was getting into decimating the messages, quantizing everything to a lower clock. You could even go down to refresh I bet if you don't go too nuts with the wheel (even something like Doom's MIDI engine supported wheel messages to some extent). The absolute lightest thing to do though is to implement GM's monophonic mode CC and put the vibrato on a delay. That gives you most of everything you can do with a lead-- you can even do those neck-slide pitch effects by overlapping notes at that point (especially if you implement your glides not as constant-time but as constant-rate).

Yes, I did some experiments with a quantizing MIDI player. At refresh-rate levels (50-70 Hz), you are limited in the tempos you can support. Most tracker-based music is also limited in the BPM they use.
Aside from just quantizing the MIDI events, you should perform interpolation for controllers and such. But the result will never be that great for regular MIDI files, only for files that happen to be a good fit for the limited set of BPM that you can accurately quantize at your refresh-rate.

louisg wrote:

You still generally do wind up with multiple timers for anything but PAL and trackers, just because everything in the tracker scene got standardized around 50hz and everything else is 60 or 70, and it's also how varied BPMs are produced (if the engine decides to implement it). I wonder why we didn't see more DOS scene trackers based on 60 or 70..? Could there be something more pleasing about 50hz-based BPMs, or is it just what we got used to? I definitely have some pro-50hz arguments hehe

Well, I think 50 Hz was carried over from the Amiga, where the MOD format originated. It was developed by the European scene, so everything was PAL-oriented.
The first PC trackers started as clones of Amiga trackers, and wanted to be compatible with Amiga MODs, so 50 Hz was a requirement.
Not to mention that they used software mixing, so they wouldn't necessarily have to run on a timer. They could run on the DMA interrupt of the sound card, at whatever buffer size you want to choose.
Mind you, by the time this stuff became popular, frame-related timing was not an issue on PCs anyway. Most stuff was just 'bruteforce' double-buffered rendering, and syncing to the screen was not useful anyway.

This discussion leads to a few interesting questions:

Tiido wrote:

On YMF71x cards you do get full OPL3 access via $388...$38B.

Do these chips not also mirror the OPL3 at 220H as part of their SB Pro compatibility, or is it only available at the 388H base address?

Similarly, do Creative's cards restrict what you can do at 388H to OPL2-level access, or is it unrestricted OPL3 access, but only to the first two of the four addresses? If it's the latter, that could easily throw off some detection routines.

Still, it should be possible to write a detection routine capable of deciding if OPL3 access should go to 220H or 388H in a reasonable amount of code. It makes me wonder how many games gave bad sound with Creative cards because they simply assumed they could access all OPL3 features at 388H once a trivial detection routine passed.

louisg wrote:

One reason I want to do a GM engine for OPL3 is to prove my point once and for all that it's possible to make an FM engine that you can throw GM tracks into and have it sound nice.

It seems like you'd quickly run out of voices before you could do most GM compositions justice. The General MIDI standard calls for a minimum of 24 voices; OPL3 provides 20 at best. If you resort to any sort of layering and/or 4-operator modes for one or more instruments, you're even farther behind. Of course, you could also support multiple cards, or design your own multi-OPL3 device, if you think it's worth the trouble.

640K!enough wrote:

Similarly, do Creative's cards restrict what you can do at 388H to OPL2-level access, or is it unrestricted OPL3 access, but only to the first two of the four addresses? If it's the latter, that could easily throw off some detection routines.

I think in theory it's 'unrestricted', but the thing is that OPL3 acts more or less like two OPL2 chips, with two register sets, where the second register set allows you to enable OPL3-specific features.
At least on early OPL3-based SB cards, like the CT1600, the second set of registers is not mapped in the 388h-range.
So you can only switch it to OPL3-mode via the 220h range (or whatever base address you chose).
But I assume that there is nothing 'fancy' going on, so writing to 388h/389h is probably exactly the same as writing to 220h/221h. The same registers are just mirrored at both addresses. In which case, once you switched the chip to OPL3 mode, you should be able to use the first register set in OPL3 mode at address 388h.

640K!enough wrote:

It makes me wonder how many games gave bad sound with Creative cards because they simply assumed they could access all OPL3 features at 388H once a trivial detection routine passed.

I think the SB cards (and register-compatible clones) were so overwhelmingly popular that the chances of SB cards not working by accident is close to 0.
The only game I know of that doesn't work in OPL3 mode is Dune, but that's deliberate, as they were targeting the AdLib Gold specifically (and they also use the special extra effects that other OPL3 cards don't have anyway, so it really is an AdLib Gold soundtrack, not an OPL3 soundtrack, if you know what I mean).
I would also think that most games detect Sound Blasters via the DSP, not via the OPL chip, because it is far more reliable.

Scali wrote:

Well, I think 50 Hz was carried over from the Amiga, where the MOD format originated. It was developed by the European scene, so […]
Show full quote

Well, I think 50 Hz was carried over from the Amiga, where the MOD format originated. It was developed by the European scene, so everything was PAL-oriented.
The first PC trackers started as clones of Amiga trackers, and wanted to be compatible with Amiga MODs, so 50 Hz was a requirement.
Not to mention that they used software mixing, so they wouldn't necessarily have to run on a timer. They could run on the DMA interrupt of the sound card, at whatever buffer size you want to choose.
Mind you, by the time this stuff became popular, frame-related timing was not an issue on PCs anyway. Most stuff was just 'bruteforce' double-buffered rendering, and syncing to the screen was not useful anyway.

Yeah, I forgot that you're dealing with a sample stream on the SB, so you'd be doing sample-counting for the timers.

50hz has some neat musical perks vs. 60hz: The common 120BPM fits nicely into it: 6 ticks per 16th note gives you perfect 32nd notes in that tempo. There's something pleasing about the tempos derived from that tick rate, but maybe that's just conditioning.

Hmm, I think syncing to the screen is rather nice if it can be managed. You can really see judder in a 2d game that's panning at a 1:1 framerate if you drop a frame, and it makes tearing really visible too. With the 3d games that DOS gamers like myself liked to play, it was less of a big deal (the movement tended to be more 'into the screen', and they often maxed out at half framerate, which they often didn't reach on the systems I played them on), but I got really spoiled by all those arcade games that opt for the rare slowdown rather than using a frame-independent timer. Really beautiful stuff, IMO. Completely silky movement, and by the time you got to all those arcade cabs that could pull it off at high res, that was really a treat.

Actually, speaking of timers, I didn't find a way of timing frames that I was totally happy with other than vsync. A lot of people recommended setting the PIT to the same as the refresh, but what guarantee would you have that it'd be locked with the refresh and wouldn't drift at all? What about the phase of the timer (if it's not in phase with the display timer, your measurements will be off depending on when you check)? I'm guessing the right way to do it might be to use the PIT as a high-res timer and do expensive scaling for all the movements..?

Scali wrote:

It seems like you'd quickly run out of voices before you could do most GM compositions justice. The General MIDI standard calls for a minimum of 24 voices; OPL3 provides 20 at best. If you resort to any sort of layering and/or 4-operator modes for one or more instruments, you're even farther behind. Of course, you could also support multiple cards, or design your own multi-OPL3 device, if you think it's worth the trouble.

I'm thinking that a good voice allocation/stealing algorithm can go a long ways. It could be my experiment will fall flat on its face (or I'll have to supplement the nice rich 4-op sounds with lightweight 2-operator ones), but I've got high hopes I can make it work! One reason you can get so much mileage out of trackers is that the human is doing all the voice allocation, but... I think I can automate a lot of what I do.

louisg wrote:

Actually, speaking of timers, I didn't find a way of timing frames that I was totally happy with other than vsync. A lot of people recommended setting the PIT to the same as the refresh, but what guarantee would you have that it'd be locked with the refresh and wouldn't drift at all?

That only works on early CGA systems. It explains why IBM ran the CPU at 4.77 MHz: the entire motherboard runs on NTSC timing. The oscillator on the motherboard also provides a 14.32 MHz NTSC clock to the ISA bus. The CGA card does not have its own clock.

On later systems (EGA/VGA), the video chip runs async from the ISA bus, and the PIT.
The way I did it in 1991 Donut is to set up a timer interrupt at a frequency just short of the actual refresh rate. This means the interrupt will fire just before the vsync. In the interrupt handler, I poll for vsync, and then reset the timer interrupt, so it is resynchronized.
I also added a simple counter to the timer interrupt, so you have a framecount to synchronize movement to.

Scali wrote:

That only works on early CGA systems. It explains why IBM ran the CPU at 4.77 MHz: the entire motherboard runs on NTSC timing. T […]
Show full quote

louisg wrote:

Actually, speaking of timers, I didn't find a way of timing frames that I was totally happy with other than vsync. A lot of people recommended setting the PIT to the same as the refresh, but what guarantee would you have that it'd be locked with the refresh and wouldn't drift at all?

That only works on early CGA systems. It explains why IBM ran the CPU at 4.77 MHz: the entire motherboard runs on NTSC timing. The oscillator on the motherboard also provides a 14.32 MHz NTSC clock to the ISA bus. The CGA card does not have its own clock.

On later systems (EGA/VGA), the video chip runs async from the ISA bus, and the PIT.
The way I did it in 1991 Donut is to set up a timer interrupt at a frequency just short of the actual refresh rate. This means the interrupt will fire just before the vsync. In the interrupt handler, I poll for vsync, and then reset the timer interrupt, so it is resynchronized.
I also added a simple counter to the timer interrupt, so you have a framecount to synchronize movement to.

That sounds like it'd work pretty well, giving you the entire retrace period to do all your graphics, and I like how it's still scaling up movement by an integer (or running logic more). I just polled for vsync in my project and allowed the user to sync to the music engine's timer instead if their machine can't pull it off. "PAL mode" hehe

Ahhh, the days when everything was sync'd to one clock. Yup, that sure did put a little dent in the processor speeds.

louisg wrote:

That sounds like it'd work pretty well, giving you the entire retrace period to do all your graphics, and I like how it's still scaling up movement by an integer (or running logic more). I just polled for vsync in my project and allowed the user to sync to the music engine's timer instead if their machine can't pull it off. "PAL mode" hehe

Yea, that approach worked acceptably even on an 8088 at 4.77 MHz. You waste a small amount of processing time polling for vsync, but it's acceptable.
The best feature of this approach in 1991 Donut in my opinion is that I also ran the scroller from this routine. So the scroller always ran at full framerate, perfectly smooth, even if the donut was running at a lower framerate. This gave the same effect as early Amiga demos, such as Phenomena's Animotion, which inspired me: https://youtu.be/WJGraZ44EqA