VOGONS

Common searches


First post, by keenmaster486

User metadata
Rank l33t
Rank
l33t

As part of the code for the latest iteration of my DOS game engine, I'm working on a DRO/IMF player for OPL3 in pure DOS, written in FreeBasic. It plays IMF type 0 and 1 files, and DRO v0.1 files (yes, I'm lazy. Don't shoot me.)

I've made significant progress since my first feeble attempts in QuickBasic, mostly due to kvee, writer of IMFPLAY. I stole some initialization code from bisqwit, because his code works 95% of the time and mine works 70% of the time.

My player now plays most files perfectly, some even better than AdPlay and/or IMFPLAY - certain DRO files cause AdPlay or IMFPLAY to royally screw up where my player does just fine. Yes, I know IMFPLAY doesn't use OPL3.

But there are still a few files (always DRO files) which inexplicably have certain instruments which simply sound wrong. I can't quite figure it out; usually it's just one instrument which will either sound completely wrong (with the correct frequencies, though) or will sound just enough wrong to know that it's not how it's supposed to sound.

Could it be a problem with the initialization code? I didn't write it, bisqwit did in one of his OPL3 projects. I don't even know what it's doing - I have searched high and low for information on how to properly initialize the OPL3 chip, to no avail. No information seems to be floating around on it.

Can anyone help me out?

Here's the player, with the source code, a few sample DRO files, and AdPlay and IMFPLAY thrown in so it can be seen how they handle the sample files as well:

Filename
droplay.zip
File size
533.65 KiB
Downloads
164 downloads
File license
Fair use/fair dealing exception

World's foremost 486 enjoyer.

Reply 1 of 6, by keenmaster486

User metadata
Rank l33t
Rank
l33t

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

World's foremost 486 enjoyer.

Reply 2 of 6, by Malvineous

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 3 of 6, by TheMechanist

User metadata
Rank Newbie
Rank
Newbie

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

Unchained demo group
swap42

Reply 4 of 6, by TheMechanist

User metadata
Rank Newbie
Rank
Newbie

.. 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 ..

Unchained demo group
swap42

Reply 5 of 6, by Scali

User metadata
Rank l33t
Rank
l33t

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:

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

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.

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 6 of 6, by keenmaster486

User metadata
Rank l33t
Rank
l33t

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:

Filename
NO72.DRO.zip
File size
8.76 KiB
Downloads
56 downloads
File license
Fair use/fair dealing exception

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.

World's foremost 486 enjoyer.