Adlib (OPL2) emulation

monkeyman · Post by **monkeyman** » Mon Sep 18, 2006 12:53 am

I'm led to believe that ScummVM is using code from MAME to handle the Adlib (ie. OPL2/YM3812) emulation, but a very old version, due to the current code not being GPLed.
Is this true?
Would one of the devs be able to confirm this?
Thanks!

Post by **sev** » Mon Sep 18, 2006 7:22 am

Yes. We're using an ancient GPL'ed version. Unfortunately, Jarek refused to dual-license his code under GPL, and only option here is to use clean room rewrite. I approached dosbox folks, who use fmopl.c as well, with offer to rewrite it, but due to lack of time, the project wasn't even born.

So if somebody could open fmopl.c, and write the algo description in a free form, i.e. in, say, our Wiki, then I'd like to use that document to write new GPLed version of the emulator. And yes, hundreds of project would benefit from that.

Besides, I have source codes for several already GPLed adlib emulators, but none of them is so advanced as Jarek's of MAME, so even if I'd use that as a start. clean room implementation requires one team who will write docs, and another one, who will write the code without even peeking into original.

In fact, some GPL projects violate MAME License and use the latest fmopl.c code as is, but we won't allow that in ScummVM.

Eugene

Post by **eriktorbjorn** » Mon Sep 18, 2006 7:25 am

As I recall it, there was also some concern about the newer emulator being slower - too slow on some hardware - than the one we use. Of course, that's secondary to licensing issues.

Post by **sev** » Mon Sep 18, 2006 7:55 am

Yes, that is truly secondary, as similar hack is possible with new code too, i.e. generate wave with lesser sample rate.

Euegene

LordHoto · Post by **LordHoto** » Mon Sep 18, 2006 11:27 am

eriktorbjorn wrote:As I recall it, there was also some concern about the newer emulator being slower - too slow on some hardware - than the one we use.

I think at least that our version prefers/uses integer maths instead of floating-point math (at least I remeber reading that).

An improved version of the emulator would be nice, since in Kyrandia for example the 'elevator' in the beginning sounds wrong, while it sounds correct with the new code.

monkeyman · Post by **monkeyman** » Tue Sep 19, 2006 9:18 pm

Thanks. Does anyone know the last time Jarek was contacted about this? Apart from reverse engineering, is there a solution other than MAME going GPL?

Post by **sev** » Tue Sep 19, 2006 9:39 pm

monkeyman wrote:Thanks. Does anyone know the last time Jarek was contacted about this? Apart from reverse engineering, is there a solution other than MAME going GPL?

March 20th of this year. That was me who talked to MAMEDEV. I really doubt Jarek will change his mind, as he is against commercial usage of his code.

Apart from MAME RE you may do all work performed by Jarek, i.e. sit down with oscillograph and study the chip. So, more feasible solution would be to take one of other 2 incomplete implementations and fix them with use of Jarek's code. But again, this should be done in a clean way, i.e. 2 separate teams.

Eugene

Hexacorde · Post by **Hexacorde** » Mon Oct 06, 2008 1:12 am

Hi friends,

I did a new OPL3 emulator that I would like to share with you. I made it available at www.cozendey.com/opl3/opl3.html

There there is an applet that demonstrates it, right in the page.

I hope you enjoy, and have some fun with it.

best wishes,
hexacorde

jepael · Post by **jepael** » Mon Oct 27, 2008 8:53 am

Hexacorde wrote:Hi friends,

I did a new OPL3 emulator that I would like to share with you. I made it available at www.cozendey.com/opl3/opl3.html

There there is an applet that demonstrates it, right in the page.

I hope you enjoy, and have some fun with it.

best wishes,
hexacorde

Hi!

New to this forum, but I've been lurking around ScummVM website and using it for years now. After seeing this post I just had to come share my thoughts about OPL emulation.

I have not been exactly satisfied with the current OPL emulation in ScummVM, Bochs or DosBox - they sound a bit different than the original. I am also somewhat familiar with work done by Olli "Yehar" Niemitalo and others trying to reverse engineer how the sound is made. Heck, I even once wrote an email to Olli, being interested how to help, but it never got pass that phase. Most ideally I would like to see an OPL3 emulator (maybe OPL2 too) which is bit-accurate with original chips. Some sounds using the pseudorandom noise generator will be hard to verify, and so these sounds can have a small compromise.

I quickly read your code and have a few comments about it. Don't let me depress you with my comments, I am impressed about the work you have already done and it is a good base for future implementation of OPL emulation! I also don't have much time to help (family, thesis, work, etc), but I have access to interesting hardware and I can design and solder something, so I can help with grabbing the real OPL chip digital outputs to PC. I've built Olli's Adlib Digisnap board and it can almost directly be used to capture OPL3 data too.

I also have several sound cards with various OPL3 versions (mostly YMF262, but also these newer chips that work at 44100Hz, OPL3-SA3's are they?). All that I lack is a real Adlib card (but I am interested to buy one) and I have lost somewhere my only sound card with an OPL2 chip (SoundBlaster 1.0).

So about your code.

While Java may be a good environment to develop and debug the emulation, the emulation core should really be converted to C or C++ so it can be used in all platforms from PCs to mobile phones and PDAs. And be used in other projects like Bochs and DosBox. But let's worry this later, keep it Java for now, let's convert to C/C++ later, so we don't have two codebases to work on and keeping in sync.

Another thing is that floating point calculations take too much processing time - some devices might not even have floating point units. And the real chip also does everything with integers or fixed-point values. So we should do away without floating point stuff too.

The sampling rate should be configurable somehow. Right now you are using 49700 Hz, and hard-coding that into few places, but for example some arcade machines most likely have different sampling rates. In PC's, the OPL chips are clocked from a 14.3181818... MHz crystal (4*NTSC colourburst frequency), so the exact sampling rate - master clock divided by 288 - is a fractional 49715.909090...Hz - Rounded to 49716Hz, which is more than accurate enough.

The eighth waveform you empirically create is most likely the log-sin or exp-table itself (like Olli says) - I just don't have real output of OPL3 yet so I can't verify what algorithm the table goes through.

If it helps, I have been thinking that for everything that the chip does, there is an easy algorithm or counter or lookup table for everything. The chip does not do multiplications, it propably can only add or subtract things. However it might use the log table to simulate multiplications by adding if multiplication is required.

Other than that, you have gotten much furhter with OPL emulation than I've ever had - I wish I had more time to work on this too. I hope we can turn this into most accurate, best-sounding and free solution for ScummVM and other projects needing a OPL emulator.

c2woody · Post by **c2woody** » Sat Nov 08, 2008 9:22 pm

I have not been exactly satisfied with the current OPL emulation in ScummVM, Bochs or DosBox - they sound a bit different than the original.

If it's about dosbox please post a full report at vogons, that is including details about how to reproduce the bug.
Most people who claim the opl emulation is wrong simply fail to correctly set up the sampling rate.