We’re big fans of the Zynq, which is an answer to the question: what do you get when you cross a big ARM processor with a big FPGA? So it isn’t surprising that [GregTaylor’s] project to emulate the OPL3 FM Synthesis chip in an FPGA using the Zynq caught our eye.
The OPL3 (also known as the Yamaha YMF262) was a very common MIDI chip on older PC sound cards. If you had a Sound Blaster Pro or 16 board, you had an OPL3 chip in your PC. The OPL3 was responsible for a lot of the music you associate with vintage video games like Doom. [Greg] not only duplicated the chip’s functions, but also ported imfplay from DOS to run on the Zynq’s ARM processors so he could reproduce those old video game sounds.
The Zybo board that [Greg] uses includes an Analog Devices SSM2603 audio codec with dual 24-bit DACs and 256X oversampling. However, the interface to the codec is isolated in the code, so it ought to be possible to port the design to other hardware without much trouble.
To better match the original device’s sampling rate with the faster CODEC, this design runs at a slightly slower frequency than the OPL3, but thanks to the efficient FPGA logic, the new device can easily keep up with the 49.7 kHz sample rate.
Using an FPGA to emulate an OPL3 might seem to be overkill, but we’ve seen worse. If you prefer to do your synthesis old school, you can probably get a bulk price on 555 chips.
I have a Tyan Thunder 2 ATX with an OPL3-SA3 and an OPL4-ML… not sure what software acutally takes advantage of them though. NetBSD is the only OS I know of that is recent that will output sound on it!
So what is the final bitstream builder for these Zybo boards, still Xilinx ISE?
I ask because the Zync chips are able to handle partial reconfiguration (changing part of the bitstream without stopping and halting the whole chip, allowing an FPGA-CPU to stay in control) but the addon for ISE is into the crazy price range for a student.
the tools to use for zynq is Vivado. you don’t need partial reconfiguration to not halt the whole chip with Zynq, without a bitstream it is just a regular dual core ARM, the programmable logic is separate from the processor system
I’m not saying I want to keep the whole system outside the FPGA, though. Let’s say I’ve got a sigma-delta ADC on the FPGA that I want to keep running while doing a partial reconfiguration on the rest of the FPGA LUTs and pins and timers and . . .
For that, I would need partial reconfiguration. And some of the ideas I’ve got floating around are a bit more complicated.
WebPack ISE claims to support the early Zynq chips, but requires a $1000 per seat license for partial reconfiguration. Vivado . . . doesn’t say, it says it can do it (which ISE does too) but a price or add-on isn’t listed. I see, in the xilinx forums some people needing the Plan Ahead plug in for Web Pack Vivado, but prices still aren’t discussed.
For hobby uses, partial reconfig is never worth the effort. For commercial uses it’s almost never worth the effort.
The reason is that PR adds complexity to what is already a complex problem. There is a very simple configuration method of using a single bitstream. There’s a slightly less simple method of adding a fallback bitstream, to help recover from fatal config errors. Both of these can be implemented with no external parts (aside from the PROM holding the images).
The only compelling reason to use PR is to save money. You have partitioned the design into functions A, B, and C, which are mutually-exclusive for circumstances X, Y, and Z. To fit A+B+C into the FPGA is not possible it crosses the utilization limit. The fastest and highest-quality solution is to use a larger FPGA which can fit A+B+C, which of course costs more.
The PR solution would be to load the base image plus A, B, or C. Unfortunately, while using PR decreases cost, it also increases dev time, and also decreases quality due to the new and numerous ways to error out on the config. You will need to spend more time managing the config process itself, as well as logistics with the different bitstreams. (Which image do you load at poweron, how do you determine the A/B/C functional needs, how are those bitstreams stored, are the streams valid/present/error-free, how do you recover from a corrupt bitstream, what do you do if you can’t recover automatically and need to restart the whole system….) It’s a lot more work. And then you have to test and debug all that.
If you can fit the ABC design, make a single bitstream. If you can’t fit the ABC, then use external circuitry to program one of three different images for the task at hand. Easy-peasy.
BTW, if you have spartan-3 boards, you should be able to use the older ISE 12 to implement PR in those parts. I’m not sure, but I think vivaldo was the point at which Xilinx started to charge for the feature.
I played a LOT of Doom. With an SB16. And that sound is spot on. Just need to add a DAC channel for the roar of the Pinkies.
@Quin: Xilinx has a brand new toolchain for 7-series devices on up called Vivado. I find it much nicer than ISE, and the free WebPack version does indeed support partial reconfiguration, though the ZYBO comes will a full Design edition license of Vivado device-locked to the Zynq SoC on the board: http://www.xilinx.com/products/design-tools/vivado/vivado-webpack.html
Thanks you, that’s exactly the info I was looking for. Makes the price of the ZYBO more tolerable if all the options are available to play with.
I wonder if this would be useful for the Midibox project?
Zynq is too Zpensive
Is $99 too much? http://www.xilinx.com/products/boards-and-kits/1-7i4a8t.html
FM synthesis is severely limited when not paired with wavetables and analog-like filtering. I’d rather go for emulating traditional subtractive and/or different types of additive synthesis.
That’s pretty debatable, man. The vast majority of arcade games from the mid 80’s through the mid 90’s used all manner of Yamaha FM synthesis chips, from the YM2151 to the YM2203 to the YM3834. While they were often paired with other sound chips such as the Atari POKEY or the General Instruments AY-3-8910, as well as sample playback chips like various OKI chips, the latter were typically just used for sound effects, with the YM chips and PSGs used for music.
The problem isn’t that FM synthesis is inherently limited, the problem is that the YMF262 was simply an updated version of the YM3812, which had crap capabilities compared to more advanced chips like the YM2151.
To clarify what you were saying, the YMF262 was actually much more capable than the YM3812 (OPL2) that it replaced, adding 4-operator synthesis with several modes (including additive synthesis), many more channels, simple stereo, new base waveform shapes and built in rhythm instruments. The “problem” I guess you might say is that it did remain reverse compatible with the YM3812, and thus many games were not written to take advantage of it’s additional features. The Descent clip was actually written for the YMF262 (OPL3).
And yes FM synthesis is versatile, I’ve heard it’s just challenging to work with as a musician to find the right sound. The OPL3 supports modes of additive synthesis BTW, check out page 12-13: https://github.com/gtaylormb/opl3_fpga/blob/master/docs/ymf262.pdf
Didn’t the Yamaha DX-7 synth use only FM synthesis?
Yes. Dunno what qwerty is talking about. So sure.
Too bad the Descent mid isn’t the HMI version of the tracks.
I learned about why some tracks in Decent always sounded very distinct on my SB16 and why they used a format other that general MIDI for their BGM. A number of tracks have alternative versions that use “.bnk” files to change the instruments. http://www.shikadi.net/moddingwiki/AdLib_Instrument_Bank_Format
It would be awesome if this emulator could handle those files. I might have to get my hands dirty with the Descent source and teach it to use this board if it can!
It’s not playing back midi, it’s playing back raw OPL3 register dumps (captured in DOSBox) so should be very close (identical?) to the end result of the format you describe I believe.
Ah, then I’ll bet Descent didn’t see the hardware it wanted. It may be time to do some homework on the SB16 to see how software programed those registers and see how I could emulate that interface. Maybe DOSBox can forward the appropriate MMIO and IO port accesses to a driver in the host OS to ship out over USB.
If I ever get back to my UEFI port of Doom, it could be awesome to use a board like this too if it can handle the SFX as well.
I didn’t really appreciate the chip at the time, but as an adult, this really hits me right in the nostalgia organ.
Descent definitely recognized an OPL3 because it is using stereo and the second register bank. Do you have a recording of what you expected it to sound like?
Also yes it would be totally sweet to forward the register writes over USB from DOSBox to the card. I’ve been thinking about it. And yes, man this stuff is so nostalgic.