Any insights on this? Anyone here who worked on the DOSBox OPL code and knows how these things actually work?

I've written quite a bit of OPL code over the years so I might be able to help answer some questions. There's actually quite a bit of documentation around on it now, partly due to the reverse-engineering attempts by various people. There's some maintained documentation on the ModdingWiki about the OPL chip (based on an older document but since updated) which may help explain what is going on.

I suspect your issue is related to OPL2 vs OPL3. The OPL3 is backwards compatible with OPL2, but it introduced two new things that change the sound. One is a second set of registers (almost as if there are two OPL2 chips in one) and the other is additional waveforms.

Accessing the second register set requires more effort (you typically write to a different port address for the second set) so you don't use these "by accident", however the extra waveforms can be enabled by writing to ports that are just ignored with the OPL2. This means you can have an IMF/DRO file that is in OPL2 mode, only writes to the first set of registers, but still sounds different on OPL2 vs OPL3.

Typically when initialising the chip, the code does something like writing 1 to register 5. As you can see at the link above (under "register map") this switches the chip into OPL3 mode, enabling extra waveforms in the 'waveform select' registers (0xE0). As it says under the Waveform Select heading, waveforms 4 and above are only available when the chip is in OPL3 mode.

So you can try enabling/disabling OPL3 mode using register 5, remembering that an IMF file might also adjust this register, to see if it makes things sound any different.

DROv1 files can also be troublesome to get correct instruments with. Depending on how they were captured or trimmed, they can be missing certain register writes that correctly set up the instrument sound. Certain players may set the chip up with different initial values, which the song does not change because it's missing those bytes, and so it sounds different. I think DROv2 captures are better for this because I seem to recall that they dump the current register state at the beginning of the capture, but don't quote me on that as my memory is a bit hazy there.

Hi folks,

maybe you could help me, the DRO files are driving me nuts 😉 .. it's all about simple OPL2 ..

I'm wrote an simple adlib raw data player core in 16bit asm for dos.

Instead of using dro files with the register-index table, I just dropped the index table and write the indexed registers directly to my file. I set PIT to 1000 Hz (divider value 1200) ..

I got some files, that play fine, but most don't, so it's obviously not an fundamental coders mistake 😉

When "converting" the dro captures I discovered that there are a lot of indicies with bit 7 set (>127), and not only when the playback starts, even if I playback pure OPL2 files ..
I tried to treat them with index AND 127 or to discard the values .. playback is crappy ..
The same dro files play well with IMFPLAY and I don't see differences in handling the dro files in the source compared to my code ..

All files are captured Dosbox 0.74 on debian stretch ..

I've not f****ing idea, what I'm doing wrong.

Please help 😀

Greetz

TheMechanist

.. okay, obviously discarding every value above 127 is the right solution and a divider for PIT about 1000 is better. Don't know what went wrong with my code, but now it works ..

Can you give me some of these 'difficult' DRO files?
I've added DRO support to my VGM/MIDI player a while ago, and only tested it on a few simple captures I made, but didn't find any problems.

As for the indices > 127, the MSB is used to indicate which bank of registers to use.
So if you have dual OPL2, the values > 127 are for the second chip.
And if you have OPL3, those values are for the second bank of registers.
With regular OPL2 you shouldn't encounter them.
This is whay my code does:

1			if (data[0] & 0x80)
2			{
3				chip = 1;
4				data[0] &= 0x7F;
5			}

Edit: currently my code only supports DRO 2.0 files. Perhaps this is a feature specific to version 2.0.
I will have to update my code and add support for 0.1/1.0 as well, shouldn't be too hard.

One thing I noticed here though:
http://www.shikadi.net/moddingwiki/DRO_Format

In early files, the field was a UINT8, however in most common (recent) files it is a UINT32LE with only the first byte used. Unfortunately the version number was not changed between these revisions, so the only way to correctly identify the formats is to check the three iHardwareExtra bytes. If these are all zero then they can safely be ignored (iHardwareType was a UINT32.) If any of the three bytes in iHardwareExtra are non-zero, then this is an early revision of the format and those three bytes are actually song data.

Perhaps this is related to keenmaster486's original problem? If you would miss the first few bytes of data, that may explain why some instruments sound wrong.

Some of the problem files are in the attachment on the top post - one of them is TRIUMPH.DRO. If you play this file with another player you can hear how it's supposed to sound (or play the original file with the "Note" tracker) but with my player you can hear a high-octave tone that is being played instead of one of the percussion instruments.

Also try this one:

This is one of the sample files from Adlib Tracker II. The timing is off during the first few measures - but not on the entire rest of the song! And if you let it loop back around to the beginning, the timing sounds correct the second, third, fourth time around, etc.