MAME/MESS's is pretty good. 😀

I believe none of them are currently bit-perfect. Some emulators that were started in recent years try to be more bit-perfect than previously. It might take more CPU horsepower as well, but not much.

It is also a relative matter as well. For example, if you have a slow starting or decaying sound, the envelope generator may advance one step every 2048 samples for example while the sound waveform advances every sample. So when you start a sound on a real chip, you cannot really align it to one sample accuracy. So if you try to compare the output of emulator to output of real chip, it is very difficult. Or in fact, you may have to record the output of the real chip only once and generate 2048 different emulated waveforms to compare to the actual recording.

That also makes it impossible to play music from a game and record it on a real chip and try to regenerate the same music bit-accurately. Even if you know the tune plays at an interrupt rate of say 70Hz, it rarely is an integer amount of chip output samples and there might be variable latency between interrupts so the 70Hz is only an average between few samples. You also have to wait some amount of time between writes to real chip, so when playing a tune and many channels trigger a note, they won't get triggered on the same sample but during a period of few samples.

Also the emulator can be used in a way that makes the output sound bad, no matter how accurate it is when it is used properly. For example in DosBox the OPL emulator (at least used to) generate 48 samples every 1 millisecond to get a rate of 48000 (an example, may not be accurate). One game sounded pretty bad because the audio emulation generated 48 samples even when the game was still writing a bunch of registers at a time. So in a real chip only one sample would be generated wrong but DosBox generated 48 wrong samples until the next 48 samples were generated from correct register settings. Note that I am not saying DosBox emulation is bad in any way, but it just has to be used like this because it is real-time emulation from a game that is writing to emulated chip at its own rate when it wants to. It is far easier to say make a program that only plays music with emulation.

With music playing it is also difficult to for example be 100% sure how a game "converts" MIDI events to chip register writes, unless there is source code or someone has reverse-engineered how it works. Fortunately here are some music formats that only contain register writes at timed intervals so they are very easy to play.

You can also use the emulator wrong in the sense that you can force it to use non-native sampling rate you want out of the emulator. If you want smaller sampling rate out, the emulator can run faster because it can skip samples you don't need, so it makes it faster at lower sampling rates, but the feedback depends on previous samples so it won't sound the same. If you want higher sampling rate out then the emulator needs to generate samples that did not originally exist in the first place. So the best thing to do is to use native sampling rate and resample all native samples to whatever user wants to play on sound card.

If I ever have the time, I could try to write one, but what good is a pure emulator without any other surroundings like a music player? I also feel I would like to have some collaborative help as it is a big project and while it would be interesting I have very little time for hobbies nowadays. Then there is the problem how to get anyone to integrate it into other projects like DosBox or ScummVM, because what good is to make a better emulator if no one wants it as they have good enough emulations already.

Adlib Tracker II. There is no substitute (unless you have real hardware):

http://www.adlibtracker.net/

The Win32 version is based off of Mame's OPL emulator.

No OPL emulation will be able to claim it is complete unless it can reproduce the following Adlib samples contained in this blog post : http://nerdlypleasures.blogspot.com/2014/09/n … nd-part-ii.html

Great Hierophant,

I see your point, but it is not the fault of the OPL chip emulator (or its accuracy) it cannot play PCM, the problem is how it is used.

Here is a comparison:

If the emulated CPU and program it is running makes constant writes to emulated OPL chip registers, but your emulating environment generates 48 emulated samples every 1 ms from the register set, then the emulated PCM sample value does not get updated but every 1 ms.

But if you make for example a .VGM file player, as per the file format being a register dump with 44kHz timing resolution in nature, you can update chip volume register with a sample value and generate just one sample with it before making another update to chip register and generating another sample. So you can play PCM at 44kHz, with exactly the same OPL chip emulation core as above, it is just used differently.

Nice blog you have, I enjoy reading it. Brings back memories.

I've considered and am still at times considering to address this sample related problem by either generating the sound when a write is done or storing the writes + time index in a table and use that when generating the sound.
However, it is not a very simple task, but the generating the sound on a write might be doable.

I vaguely recall the adlib code already doing that, should be a simple FillUp call to the mixer handler that tries to fill the specific channel up to the current time stamp.