nesdev.com

Hello. I'm working on an OPL2 + Atmega based MIDI synth, and having trouble keeping up with incoming MIDI while sending commands to the OPL2, which requires delays between writing address and data values. In the simple case it works fine but with lots of incoming note and CC messages, the serial rx buffer overflows. I have a few things I'd like to try (faster mcu and/or asm optimizations, timer/interrupt routines). Alternatively can anyone suggest other sound generator ICs that operate faster? Thank you.

I seem to remember Yamaha FM chips can take about one write per sample because of how they operate (round robin, I've read), and they run at about 52 kHz (in the case of the YM2612 in the Sega Genesis). A simplistic PSG, such as SN76489 or AY-3-8910, shouldn't have near the same delay as a Yamaha FM chip. A wavetable chip, such as the Konami SCC or Namco 163, might be quick to respond as well.

MIDI can push no more than a thousand events per second. (It runs at 31250 bps, with stop and start bits between bytes, and most messages are 3 bytes including the status byte.) How many writes does it take to set up one note?

MIDI (31250 8n1 asynchronous 5ma current loop) or USB-MIDI?

The amount of time you have to wait between writes to the OPL2 is 26µs, so I'm really surprised you're having problems keeping up.

The OPL2 features 2-op FM with 5 registers per operator and 3 per channel, so 13 writes total to start a new note using a new instrument.

I doubt the OPL2 is really the bottleneck here, but if it is, the OPL3 has significantly reduced wait times and is effectively backwards-compatible (it lacks the WS enable and CSW registers, and uses a slightly different algorithm, but can otherwise act as a drop-in replacement from a software standpoint and the differences are inaudible in all but the most contrived cases).

One note-on is 4 registers (2x operator levels, frequency lo bits, frequency hi bits) which comes to 8x SPI transfers (estimating ~40 micros) + 4x OPL2 delays (~120 micros) = ~160 micros. So a four note chord is already ~640 micros of processing, not counting the rest of the program. 31250 baud is a max of 1 message per 320 micros. So with a fast tempo, chords, and modulating 3 or 4 CCs, it makes sense to me that the 64 byte (~20 MIDI message) serial rx buffer will overflow sometimes.

I will look at the OPL3. Thanks for the tip, Rahsennor. And/or I may try an ARM Cortex instead of AVR. Faster clock and DMA should help. Thanks all.

A friend of mine had a similar problem and the solution is to build a chip writes queue that you execute when you aren't doing anything else. Writes to chip have the lowest priority essentially.

Sample rate of OPL2 is MCLK / 72 and with typical clock used on PCs (14.31818MHz / 4) the rate is ~49715.9Hz. OPL3 uses the 14MHz (4x NTSC) clock directly, sample rate won't change though. It does on later models (OPL3-L YMF289) which output 44.1KHz, there's a resampler in them and they also have a slightly different internal sample rate due to different clock they use (33.8688MHz, I imagine the internal rate is MCLK / 681 = ~49733 ?) which does result in audible differences, especially with all the fuzzy and noisy instruments.
OPL3 buffers the entire register set to do relax the timing requirements (and OPL3-L allow the set to be read back too).
OPL3-L allows one to use an i2s like DAC rather than the floating point things Yamaha uses, so depending on DAC used you can get a much lower noise level and overall better output signal.

_________________
http://www.tmeeco.eu

Another idea, if you're not doing it already: OPL2 register writes have no side effects. If you cache the last value written to each register, you can safely skip duplicates entirely. Won't help in the worst case, of course.


I keep forgetting the YMF262 wasn't the only version.


The YMF262's output is 16-bit offset binary; it's the YAC512 DAC that's floating-point. I know diddly squat about what other DAC chips (if any) are compatible though; I'm an emulator author not a hardware person.

The OPL2 does output floating point directly.

Yes, but the vast majority of MIDI messages take 2 bytes per message (all Note On, Note Off, Pitch Wheel, Controllers). Only repeated patch changes in the same channel are a single byte, and only if nothing else interposes.

"offset binary" is another way of saying floating point pretty much, if you look at the timing diagrams and descriptions you still see the usual 10 bits mantissa and 3bit exponent that gets sent to the DAC. The DAC will then use the exponent to shift around the mantissa part to make final full scale output. OPL3-L outputs full 16bits where this step is already done inside the chip so DACs used by previous chips will not be usable but you can use any generic DAC that works off i2s or similar data format, and 44.1KHz output is made so that you can do so without upsetting any of those generic DACs.

_________________
http://www.tmeeco.eu

I thought "offset binary" meant unsigned linear PCM: negative rail $0001, middle $8000, positive rail $FFFF.

Then in Yamaha's datashits it means binary that is being offset by another number (mantissa shifted by exponent) and not what the wikipedia article refers to.
Only OPL3L and few other late chips output regular signed PCM that standard DACs use, all earlier things use Yamaha's floating point format.

_________________
http://www.tmeeco.eu

No, the YMF262's output is as tepples describes - see here, among other places. This was specifically used by the RE community to get bit-exact emulation, which is much harder on the OPL2 because of the floating point.

Ok, then that settles it. Yamaha's Datashits are a poor source of info and I was just looking at them some days ago.
They don't actually explicitly tell that the chip does this or that, only very rough description that is mostly telling the same stuff as previous parts docs, and hence the confusion/misunderstanding on my part.

_________________
http://www.tmeeco.eu

I can see how you'd miss it, it's practically a footnote. Yamaha seems to pride itself on writing the vaguest documentation possible.