Why don't you start by checking the other opl emu types in dosbox rather than comparing against (known broken) mame-rips?

Ah, right, I should have written this:

Apologizes in case someone is disappointed. For DOSBox v0.74, it doesn't matter which value is set for oplemu, be it default, compat or fast.

You do hear it on real hardware with the YMF-262 chip, if this is of any help.

Thanks for checking this out on a real system.

I shall send my thanks as well.

While one can use PCem (or another emulator) in order to have a hint of something (like a missing tone), actual hardware is what should better be used for reference. (Or as ones would say: Should be used 😀)

Sometimes when I play Keen 4-6 on DOSBox, there are some ''extra'' sounds that I can't remember to be heard back in the day on Win95. A strange sound is heard sometimes when I drop out of a ledge or pole and when squashing a Skypest in Keen4, the squash sound effect is messed up at random times.
Does this have anything to do with the thing mentioned in this thread? I use rate 49716.

Hey MadMonk,

To begin with, at least according to a few attempts, looks like the falling sounds can be corrected by setting oplemu=compat. The skypest squashing sounds are still "random", though.

In more details:

Well, I don't know if the report is relevant to the Keen 5 fuse issue, but there's still the possibility, so I've written the following.

With oplemu=default and oplemu=fast, I can hear the "extra" falling and skypest squashing sound effects. While I seem to recognize which sounds are "original" (e.g. ones I heard on real hardware before) and which are "extra", only someone with real hardware can validate these.

Furthermore, with oplemu=compat, I can still hear the "extra" skypest squashing sounds.

Regarding these, here are a few relevant tests I've done on Keen 4, using DOSBox with: rate=49716, oplrate=49716, sbtype=sb16, oplmode=auto, and oplemu=default or oplemu=fast. The given tests 4-5 results are also reproduced with oplemu=compat.
1) Make sure that the in-game environment is empty. We don't want various sound effects (like mad mushroom jump) to interfere. You're soon to read why.
2) Falling test 1: Drop off the bottom of a pole. You're expected to hear a silent (and "correct") falling sound.
3) Falling test 2: Walk towards a cliff and fall down. In most of the attempts (although not all), you're going to hear a louder ("incorrect") falling sound.
4) Skypest test 1: Stand near a skypest resting on a floor, although not directly nearby. Activate Keen's pogo. Now, while mid-air, prepare to land on the skypest. As you hit it, you should hear a silent ("correct") squashing sound.
5) Skypest test 2: Stand right near a skypest resting on a floor. As you activate the pogo, the skypest should get squashed immediately. Furthermore, a louder ("incorrect") sound is to be heard.

Conclusion (more of a guess): There appear to be some issues when one sound effect is halted in the middle, so another one can be played.
In falling test 2, it'd be a (very silent) walking sound halted in favour of the falling sound. In skypest test 2, it'd be the pogo sound halted for the squashing sound.

On a side note: While less relevant to us, tests 4-5 can be repeated with the same results on PCme, but not on QEMU (where the squashing sound is quite wrong). Furthermore, on both PCme and QEMU, the falling sound appears to be "correct" permanently. Thus, the PCme way is similar to the DOSBox behavior with oplemu=compat.

As before, test results on real hardware are more than welcome.

Is oplemu=compat recommened for all games for original quality? I'm glad I got rid of that annoying wrong falling sound.

There are rarely notable differences and fast is significantly faster (if that's relevant for your system depends of course). compat is not perfect either.

Hi again,

While I know almost nothing about any OPL chip, there are chances the main cause of the lack of tone in the sound effect has been found.
Per the AdLib manual, a few microseconds of wait should follow a write to the OPL's register port, before a write to the data port is done. This is done by reading the register port 6 times. A (relatively) longer delay should further be added after the write to the data port, accomplished by reading the register port 35 times.

Keen 4-6 and Wolf3D/SOD are no exceptions, being games following this pattern. See, for instance, alOut from the Wolf3D source code: https://github.com/id-Software/wolf3d/blob/ma … C/ID_SD.C#L1264

Now, it is apparently the case that none of the OPL emulators in DOSBox is "notified" of these port reads, so it's just like the reads never occur. By hacking in a call generating (very) few samples (possibly less than 1 per port read) and a bit of more code modifications, the fuse explosion sound can have the missing tone (somewhat) restored.

And so, I'm attaching a super-hackish patch that is an attempt to handle that. This may break thread safety in any way I'm not aware of. It is assumed that in the DOSBox settings, rate=49716 and oplrate=49716. Furthermore it is assumed that oplemu=default (or fast). A few "magic values" are involved in the patch, which may have to be modified for oplemu=compat and more.

Furthermore, the exact frequency of the missing tone from the sound effect seems to vary, and it may be unheard at all from time to time, even with the patch applied.

I'm not quite sure I correctly understand the logic behind this patch. As I understand it, you assume that reading from the YM3812 has an effect on its sound generators. I see no reason why that should be the case.

There appear to be some issues when one sound effect is halted in the middle, so another one can be played.

It's a common annoyance with Yamaha FM chips that the "attack" period does not start quietly, but at whatever volume level the operator just happens to be. So if a is note turned off and on again because the player cuts it off for a difference piece, not only is the release period skipped (which would be expected), but part of the attack period as well.

This is particularly a problem with id Software because several of their FM instruments contain nonsensical values for the attack and release phases. For example, the "snare" instrument used in Wolf3D's WARMARCH.IMF has a nonsensical Release value of 0 (almost infinity) and an Attack value of 5 (short build-up) in the modulator. As a result, the first "snare" note sounds more like a steel drum than a snare, as the modulator starts off quietly. However, because the modulator has a Release value of (almost) infinity, its output always stays at full amplitude once it has reached it. (You don't hear this because the carrier quiets down quickly, since it's a percussion instrument after all). For the next note, since the OPL does not start a new note's attack phase at silence but at its previous value (as mentioned), the slow build-up attack in the modulator is effectively skipped, which is why every "snare" note after the first actually does sound like a "snare". Early bad OPL2 emulators (such as the one used to produce this file) did not emulate this behavior, hence, all snares sound like the first, because every note incorrectly starts off with the modulator at zero amplitude. Both of DosBox' OPL cores emulate this behavior more-or-less properly, "compat" better than "fast"/"default", but none do so 100% correctly.

NewRisingSun wrote:

I'm not quite sure I correctly understand the logic behind this patch. As I understand it, you assume that reading from the YM3812 has an effect on its sound generators. I see no reason why that should be the case.

I think it's mainly about the timing. Basically, on a lot of vintage setups with actual working OPL2 chips (or compatible), a single read of the OPL's register port should take a bit of time, as described in my preceding post. I think that in vanilla DOSBox, this time period is not handled in any of the OPL emulators at all, or at least not directly.

With the patch, any of the OPL emulators should generate a few samples during a port read, being a rough attempt to simulate that delay in terms of OPL emulation. This can naively lead to more samples generated than necessary, hence OPL_CallBack is modified to generate only what's left.

NewRisingSun wrote:

There appear to be some issues when one sound effect is halted in the middle, so another one can be played.

It's a common annoyance with Yamaha FM chips that the "attack" period does not start quietly, but at whatever volume level the operator just happens to be. So if a is note turned off and on again because the player cuts it off for a difference piece, not only is the release period skipped (which would be expected), but part of the attack period as well.

This is particularly a problem with id Software because several of their FM instruments contain nonsensical values for the attack and release phases. For example, the "snare" instrument used in Wolf3D's WARMARCH.IMF has a nonsensical Release value of 0 (almost infinity) and an Attack value of 5 (short build-up) in the modulator. As a result, the first "snare" note sounds more like a steel drum than a snare, as the modulator starts off quietly. However, because the modulator has a Release value of (almost) infinity, its output always stays at full amplitude once it has reached it. (You don't hear this because the carrier quiets down quickly, since it's a percussion instrument after all). For the next note, since the OPL does not start a new note's attack phase at silence but at its previous value (as mentioned), the slow build-up attack in the modulator is effectively skipped, which is why every "snare" note after the first actually does sound like a "snare". Early bad OPL2 emulators (such as the one used to produce this file) did not emulate this behavior, hence, all snares sound like the first, because every note incorrectly starts off with the modulator at zero amplitude. Both of DosBox' OPL cores emulate this behavior more-or-less properly, "compat" better than "fast"/"default", but none do so 100% correctly.

Thanks for telling that, it is surely informative! And yeah, more strange OPL glitches can be found; For instance, in Keen 4-6, musical tracks tend to interfere with the sound effects in some way.

I think it's mainly about the timing.

If that were the cause, running the game at a low cycle setting should also give you the desired result, but it doesn't. Which is why I'm still wondering how exactly your patch affects sound generation.

NewRisingSun wrote:

I think it's mainly about the timing.

If that were the cause, running the game at a low cycle setting should also give you the desired result, but it doesn't. Which is why I'm still wondering how exactly your patch affects sound generation.

While I don't know much about the timing when it comes to DOSBox as a whole, some statistics can be constructed at the least. This leads us to a different patch attached to this post. It doesn't aim to correct any sound effect. All it does is add logging messages in adlib.cpp:
- One message per call to Module::PortRead (doesn't involve any OPL emulator without applying another patch).
- One message per call to OPL_CallBack (asks one of the supported OPL emulators to generate samples).

It's not the best way to do the logging, and it results in very large log files after a short time of investigation (less than one minute). But there's still enough that one can learn.
Basically, with cycles=10000 (fast) or cycles=500 (slow), I've gathered some info while running keen5e.exe v1.4 (loading a saved game and then playing back the fuse explosion sound, but no music).
Independently of the value for "cycles", I have spotted many groups of calls to PortRead, with no call to OPL_CallBack in between. What's common for each such group, is that the total amount of calls to PortRead is divisible by 41; Usually there's a total of 41 or 82 such calls.

But 41, or 35+6, is the exact number of port reads that should be done while writing some value to an OPL register, per the AdLib manual (and is also done in alOut from Wolf3D as shown above).

So it truly looks like, more often than not, the OPL emulator is not involved at all while a value is written to the OPL register, at least in terms of timing for the generation of samples.

But 41, or 35+6, is the exact number of port reads that should be done while writing some value to an OPL register, per the AdLib manual (and is also done in alOut from Wolf3D as shown above)

According to Yamaha's data sheets, the OPL2 needs 12 cycles of the 3+51/88 MHz master clock to process a register address write, and 84 cycles of the 3+51/88 MHz master clock to process a register data write. The OPL3 on the other hand only needs 32 cycles each of its 14+7/22 MHz master clock to process both a register address and a register data write, which is equivalent in duration to 8 cycles of the YM3812's 3+51/88 MHz master clock.

A little time for an update: The cause of the difference in the Keen 5 sound originally described here may also have an effect on a couple of sounds from the "Catacomb Adventure Series" games, at the least. This may be expected, as along with the earlier Catacomb 3-D (The Descent), these games actually share a lot of code with Keen 4-6 (also Keen Dreams, having an earlier revision of the code).

If anybody wants to test, The Catacomb Abyss was made available as shareware (you probably want v1.13): http://www.classicdosgames.com/game/The_Catacomb_Abyss.html

In contrary to the case of Keen 5, though, I cannot confirm any "proper" way to hear the sounds, since I don't recall myself originally trying any of these games with vintage DOS hardware. Hence, it's still better to test with real hardware if possible, although I suspect this applies.

OK, the exact in-game issue is this. There is a sound effect that should be played back when one attempts to open a locked door (the very first map you visit already has such doors). However, as of vanilla DOSBox this effect isn't always properly played back. Similarly, if you go through a teleporter a sound isn't always played back (to quickly see this you can skip to map no. 13 with the F10+W debug keys).

On the other hand, the sound effects are properly played back in any of these setups:
- A patched DOSBox, using one of the diffs posted beforehand.
- PCem: I used v0.9 for Linux this time. The DOSBox' OPL emulator may be used here, but otherwise the effects are properly played back. And yeah, you can also hear the fuse explosion from Keen 5 with the "missing tone", although its frequency may differ from the original from time to time.
- Hmm... ok, there's also this port of the "lost" episode of Keen Dreams and the 3D Catacomb games. The relevant code chunk is the replacement of alOut given here (linking to a specific revision in case something gets changed later): https://github.com/NY00123/refkeen/blob/87463 … io_timer.c#L273

A different approach, though similar to your idea in some respects:

1 void Module::PortWrite( Bitu port, Bitu val, Bitu iolen ) {
2     //Keep track of last write time
3     lastUsed = PIC_Ticks;
4     //Maybe only enable with a keyon?
5     if ( !mixerChan->enabled ) {
6         mixerChan->Enable(true);
7     }
8     if ( port&1 ) {
9         switch ( mode ) {
10         case MODE_OPL2:
11         case MODE_OPL3:
12             if ( !chip[0].Write( reg.normal, val ) ) {
13                 handler->WriteReg( reg.normal, val );
14                 CacheWrite( reg.normal, val );
15             }
16+            //Force a bit of sound generation at KeyOn
17+            if ((reg.normal >= 0xb0 && reg.normal <= 0xb8) && (val & 0x20))
18+                handler->Generate(mixerChan, 1);
19             break;

It still seems hack-ish, but something better would probably require potentially complicated changes to when and/or how often the mixer calls the CallBack...

Hi there,

I've tried your patch today and I think it's working in Keen 5 and The Catacomb Abyss! This covers both oplemu=default and oplemu=compat (always using rate=49716 and oplrate=49716).

The rate of the missing tone in Keen 5 may also be a bit more consistent when comparing oplemu=default and oplemu=compat, once your patch is applied (with the patch of tone the tone has a lower pitch using oplemu=compat).

There was at least one time I didn't hear it in Keen 5, but then again I realize it may still be a hack, and there are chances this can also happen with vintage hardware.

Could this method of forcing the generation of sample bytes at port writes be used to support sample playback on OPL and Tandy PSG? 😉