Sauraen

New demo video! The front panel draws the state of the currently selected OPN2 or PSG voice. This is really just a test of the front panel API. (And a cool song!)

That looks like an interesting chip, though I'm not sure what you need a 16x8 matrix for. Yes, the digital inputs could be driven by a DOUT plus an additional line for Strobe (clock).

You're welcome, my pleasure! I guess I should have put up this video 2 years ago! ;) I only wish my high-quality recording of the audio hadn't messed up, so you could actually hear what I was saying and the details of the patches. And you're right, I only went over a single modulation connection, it supports up to 16 per voice. :) And I didn't talk about the features in the top left. Maybe I'll do another video soon.

I think you got it backwards, Key Scale Rate is the 1-bit parameter and Key Scale Level is the 2-bit parameter. One other thing, since switching between the operators is very common, you might want to consider having separate buttons to go to each operator, rather than one button to cycle through the four of them. Also please consider watching the video I posted in the MBFM2.1 thread. :)

Here is a video (especially for @Psykhaze) showing off the OPL3 and the features of MIDIbox FM V2.1. I apologize for the phone audio quality, I was also recording a high-quality audio version to sync with the video, but that got corrupted.

Glad to see you've seen the light of STM32F4! :) I would recommend a few changes on the operator portion of the front panel: Since you have two rows of 4 knobs, put Attack, Decay, Sustain, Release on one row. (Also fix the spelling of Release) Volume and Multiplier are the two most important parameters in FM synthesis--on my synth they're at opposite ends of a row, but you might consider putting them next to each other. I can't comment on your EG>Vol/LFO>Vol knob because my synth does modulation differently. Key Scale is not one but two parameters. There's Key Scale Rate, a 1-bit parameter for how much quicker the EG is on higher notes; and Key Scale Level, a 2-bit parameter for how much lower the volume is on higher notes. They're both important for shaping your patch to work well throughout the whole keyboard range, but neither should be on a knob. KSR should be on a button/LED like you have Sus (you do understand what this parameter does, right?), Vibrato, and Tremolo; I guess KSL could be on a button+4LED thing like your Operator selector. Some other thoughts: You seem to be implementing this like MIDIbox FM V1.4, where there are 6 4-operator voices and the percussion section. In reality, the OPL3 has 18 2-operator voices; 12 of which can be individually combined in pairs to form up to 6 4-operator voices, and 3 others of which can be combined to form the 5-drum percussion section. But this leaves 3 2-operator voices which can't be used with this scheme. This is the simplest solution, and I have to say that most of the complexity of MIDIbox FM V2.1 comes from the synth supporting arbitrary configurations of the 18 voices (within the OPL3's limitations), so I'm not sure I'd recommend you change your plan. But I just wanted to let you know what you're missing. :) Because the OPL3 has a number of waveforms (not just sine), you can make some pretty good sounds only on 2-operator voices; in fact I have almost a whole General MIDI patch bank completed, exclusively on 2-operator voices. I am planning to make a video this evening going over the capabilities of the OPL3 and MIDIbox FM V2.1.

Now I understand. The LFOs you're talking about are software LFOs implemented in the core. I was talking about the two hardware LFOs in the OPL3 (also called Vibrato and Tremolo). I might suggest, since what you want to build is mostly two MIDIbox FM V1.4s connected together, is that you use the existing Core and OPL3 modules, and only design your front panel at first. Once you have the software working for connecting the cores, design your base PCB.

I don't understand your confusion about the waveforms. Each operator has access to the 8 waveforms shown above. The drum mode is simply the last few operators with slight differences in their connections--the waveforms those operators use are the same 8 ones above. The LFOs have nothing to do with this; they each can only produce a sine wave (picture 1 above), and the only parameter they have is a single 1-bit depth parameter. I would really recommend you learn more about the OPL3. (Did you know that three voices of the OPL3 are completely ignored in MIDIbox FM V1.4?)

How many projects are you trying to do at once?! I use TL072/TL074 as my go-to op-amp for audio applications when a bipolar supply is available, and MCP6002/MCP6004 for +5V only. Any op-amp can do mixing, filtering, and amplifying; the characteristics that distinguish op-amps are more based on the overall application (audio, which determines the frequency range) and the supply voltage, rather than whether you're doing filtering or mixing.

A few comments: Do not make boards in a graphics program (e.g. Illustrator). I tried something like this once and it was a big mistake. Your statement that Eagle .brd files is the common standard for manufacturing boards is incorrect. The common standard is Gerber files (a folder's worth of these, one per board layer, plus one for drills, etc.) Board houses directed at hobbyists will sometimes accept .brd files to make things easier for their customers, but all they do internally is open the .brd in Eagle and export Gerbers. KiCad generates Gerbers with no problem. I haven't used those libraries, but I'll mention that I tend to avoid all libraries and make my own components most of the time. (I've done this with Eagle and KiCad, and this is policy where I work too.) For any complex part, you don't want to rely on someone else getting every pin right; at work we have a system of metadata on the parts which has to be updated even if we import a part from another library. In KiCad, the default libraries tend to have hidden power and ground pins, which I really dislike--they get automatically connected to the "right" nets, which can easily be the wrong nets.

I use KiCad for all my PCB designs (except at work, where I use Altium...) It's free and open source, and there's no size restriction, but it's even more poorly documented than Eagle. But once you get used to it, and you learn how to work around its limitations, there's not much you can't do with it. You should definitely lay out the front panel as a matrix rather than each button/LED individually. I'm not sure how to program for that in PIC/MIOS, but in MIOS32 the BLM_X driver works very well. I don't know anything about the wavetable; in fact, I was going to have a wavetable feature in MIDIbox FM V2.1 and then never got around to implementing it. I believe it's a sort of sequencer for control changes, but other than that I don't know. The two LFOs in the OPL3 are sine wave LFOs (or some pseudo-sine-wave, it's hard to tell); there's no adjustable waveform, just 1-bit global adjustable depth. The drums don't have any other waveforms either; they're based on normal FM voices with a few changes. I will again urge you to start with the MIOS32 version. You will have more than enough challenges as it is.

I can see that you might want to start by modifying the existing PIC code so you don't have to write everything from scratch, but I'm not sure if it would be worth the labor. I would definitely recommend starting with STM32F4: MIOS32 and the toolchain are well-developed and easy to use, and you won't run out of CPU or RAM nearly as easily. You said this processor is overpowered and even "useless", but I can tell you that I first built MIDIbox FM V2.0 with the LPC17 core, and it lagged when playing large (30+ voice) MIDI files; this went away with the STM32F4 core, so it was just powerful enough! I have to admit it was heavyweight code, running the entire MIDIbox NG underneath as well as 16 modulation connections per voice; but still, none of this would have been possible on the PIC core.

Hi Psykhaze, I see. Good luck! I know nothing about the details of the MBFM V1.4 firmware, but if you have any questions about the OPL3, I might be able to help. Sauraen

Hi Psykhaze, Glad you're finding things you like, and I hope my past and future work can help you! I would definitely not recommend combining the OPL3 and OPN2, unless you want to just use MIDIbox hardware and the operating system (and my drivers for each chip) and write the application code entirely yourself. What you're describing in terms of double OPL3 is exactly MIDIbox FM V2.1. You mention using shift registers to connect them to the STM32F4, but that isn't necessary, they're connected by a parallel interface to J10A and J10B. I made a little page for you here describing it: http://wiki.midibox.org/doku.php?id=midibox_fm_21 If you follow this, even if you end up using your own application code, you can still use my opl3 module drivers. But you should definitely consider just going with MIDIbox FM V2.1, most of your work will be done already. You mention four stereo outputs. You can do that, but MIDIbox FM V2.1 is intended to have the four channels from the two chips each mixed, so that there are just four outputs (L, R, and two aux sends), and voices from either chip can play to all four of these. The idea is that it's almost like there's one super-OPL3 which has double the number of voices. Would you like me to make a video going over the features of MIDIbox FM V2.1, so you can decide if you want to use that or make your own application? Sauraen

Hi Psykhaze, To answer your questions: 1) MIDIbox Quad Genesis (and its smaller cousins, MIDIbox Genesis Tracker and MIDIbox VGM Player, all of which use the MBHP_Genesis board), create the sound of a Sega Genesis / Mega Drive. Just listen to some music from this system on Youtube compared to some OPL3 music, and you'll get the overall idea. It's similar, but each has some strengths the other lacks. The OPL3 has more powerful operators and four-op voices, and it has a FM percussion system; the OPN2 (on the Genesis board) has sampling capabilities, a more powerful LFO, and the board also includes the SN76489 PSG chip for square waves and noise. 2) Yes, OPL3, OPN2, and PSG are all available for $2-$5 each. 3) Yes, both MIDIbox Quad Genesis and MIDIbox FM V2.1 are much more full-featured than MIDIbox FM V1.4. MIDIbox FM V2.1 supports two OPL3s, is fully multitimbral (each MIDI channel plays a different patch at the same time), has a powerful modulation system and a simple drum sequencer, etc. Here is a typical example of its use, playing a large MIDI file. MIDIbox Quad Genesis has a different architecture, it's based on playing VGM files from Genesis games, and even normal patches are actually implemented as very short snippets of VGM files. All of this is way beyond the PIC core--it can barely interface with an SD card, let alone stream four VGM files in parallel from it. Here's the bad news, which also addresses (4). MIDIbox FM V2.1 is as finished as it will ever be, and the code is available on SVN, but there's little-to-no documentation. When I originally started the project, I wanted to make this the official successor to MIDIbox FM V1.4 (hence the name). But basically my ambition ran away with me, and I ended up making a synth that was way too complicated and kind of hacky internally, which led me to think nobody would want to build it, which led me to not want to document it, which led to nobody wanting to build it. Now it's not impossible: the software is there for you, and the hardware isn't too crazy--it's the standard STM32F4 core and OPL3 board and a MBNG-compatible front panel. All you need to know is the connection between the OPL3 module and the core, which is very simple, and you need to design a front panel that has controls corresponding to mine, which is at least conceptually simple since you're just following the MIDIbox NG project. I can document these two elements without too much trouble, if you want to go this route. MIDIbox Quad Genesis IS a project that is designed to be well-documented and reasonable for other people to build. In fact MIDIbox VGM Player is already "released", meaning all the documentation and code is available, and MIDIbox Genesis Tracker should be out soon as well. But MIDIbox Quad Genesis itself, the one with the giant front panel, won't be in a releasable state until later in the summer--there's a LOT of code to write. At that time front panel boards will be available, as well as the design files so you can order the matching aluminum front panel and the 3D printed parts. None of these synths work well with an in-between control surface. There is sammichFM, but that has custom interface code--unless you want to do some real programming it's not easy to change what controls are available. tl;dr: If you want a synth project that you can start now that's been well-vetted by the community and is very well designed within its limitations, go with MIDIbox FM V1.4. If you want a cool crazy Genesis synth with a giant front panel chock full of LEDs, wait around for a few months and then build a MIDIbox Quad Genesis. If you want a project that's more of an organizational challenge--and you want to design and build a front panel from scratch--MIDIbox FM V2.1 is for you. Sauraen

So I noticed that despite the STM32F4 having 192k of RAM, I could only have application code (plus MIOS32 of course) allocate up to about 128k. I found this by increasing the heap size until the app wouldn't link, and then checked the size of the larger arrays used in MIOS32 and my application. Since my application uses dynamic memory allocation, having the heap be as big as possible is critical. I found that the stack position is defined in STM32F407VG.ld, explicitly as _estack = 0x20020000, with a comment saying this is the end of the 128k RAM on the AHB bus. What does this mean? Why can't we use the remaining 64k of RAM? I tried changing this to 0x20030000, and (predictably) the application refused to start. So how would it be possible to get access to the remaining RAM? Edit: I found the other 64k of RAM, evidently it's in a separate section at 0x10000000, and I think it can't be accessed by DMA (which significantly limits its usefulness for many applications). I thought switching from LPC17 to STM32F4 would get rid of the memory segmentation issues, but I guess not. In any case, how do I get static/global variables allocated in that segment?

The first official release of MIDIbox VGM Player is available now! This is a small build which allows you to play VGM files on one or more MBHP_Genesis modules with a minimal control surface. In my case I just took my mostly-complete MIDIbox Quad Genesis and traded the massive front panel for a tiny one with 6 buttons and an encoder: Wiki page: http://wiki.midibox.org/doku.php?id=midibox_vgmplayer Firmware: http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fsynthesizers%2Fmidibox_vgmplayer%2F It's not a particularly hard project, and most of the information someone will need (someone who is familiar with MIDIbox in general) will be found at the MBHP_Genesis module page, http://wiki.midibox.org/doku.php?id=mbhp_genesis, which is very detailed. So the documentation for the project itself isn't that extensive right now--but I'm looking for feedback about this. Meaning, post here if you get stuck with something, and I'll answer your question and add the information to the wiki. More features will be added over time, as I develop the VGM driver even further for use with MIDIbox Quad Genesis. Planned features include: autodetection of presence and number of MBHP_Genesis boards, autodetection of actual chip clock speeds and obeying VGM file clock speeds to get frequency commands right in all cases, realtime tempo and pitch controls.

Four VGM files at the same time:

MIDIbox Quad Genesis Unit 01 (the second one) is mostly completed, there's a couple minor issues with the front panel that I'm ignoring for now, but it's working fine for testing VGM-related things. I've converted the VGM playback code I used in the test application into a proper module driver, and I'm in the process of making it more powerful and adding features to it so that it can be the basis of all three MIDIbox Genesis projects. I've changed some of the data structures around and have moved all the SD card reading off the sound chip ISR to a separate thread. Very soon I should be implementing the advanced task switching algorithm TK and I have been discussing, enabling even higher performance out of the VGM playback engine. I can't promise anything quite yet, but I hope to have a video within a week or so of streaming several VGM files at once, one to each of the MBHP_Genesis boards. In conjunction with that, I'm working with what will be MIDIbox VGM Player. So that those who are curious can get started on hardware, it consists of: MBHP_CORE_STM32F4 with SD card No MIDI I/O required (besides that necessary to upload code, i.e. USB MIDI) One or more MBHP_Genesis modules attached to the core via MBHP_Genesis_LS level shifter 2x16 or larger character LCD Mini "front panel", consisting of one 74HC165 connected to DIN with the following connected to it: 0: encoder A 1: encoder B 2: button "Enter" 3: button "Menu/Back" 4: button "Softkey 1" 5: button "Softkey 2" 6: button "Softkey 3" 7: button "Softkey 4" It'll just play VGM files in the root directory of the SD card, with some options. Assuming I get this working, it will support playing multiple VGM files at the same time on multiple boards if you have them connected.

MIDIbox Quad Genesis Unit 01 (the second one) is mostly completed, there's a couple minor issues with the front panel that I'm ignoring for now, but it's working fine for testing VGM-related things. I've converted the VGM playback code I used in the test application into a proper module driver, and I'm in the process of making it more powerful and adding features to it so that it can be the basis of all three MIDIbox Genesis projects. I've changed some of the data structures around and have moved all the SD card reading off the sound chip ISR to a separate thread. Very soon I should be implementing the advanced task switching algorithm TK and I have been discussing, enabling even higher performance out of the VGM playback engine. I can't promise anything quite yet, but I hope to have a video within a week or so of streaming several VGM files at once, one to each of the MBHP_Genesis boards. In conjunction with that, I'm working with what will be MIDIbox VGM Player. So that those who are curious can get started on hardware, it consists of: MBHP_CORE_STM32F4 with SD card No MIDI I/O required (besides that necessary to upload code, i.e. USB MIDI) One or more MBHP_Genesis modules attached to the core via MBHP_Genesis_LS level shifter 2x16 or larger character LCD Mini "front panel", consisting of one 74HC165 connected to DIN with the following connected to it: 0: encoder A 1: encoder B 2: button "Enter" 3: button "Menu/Back" 4: button "Softkey 1" 5: button "Softkey 2" 6: button "Softkey 3" 7: button "Softkey 4" It'll just play VGM files in the root directory of the SD card, with some options. Assuming I get this working, it will support playing multiple VGM files at the same time on multiple boards if you have them connected.

BLM_X works well and was relatively easy to use. I even fixed a couple bugs in it along the way. :)

Thanks TK! This is the kind of solution I was looking for. I will give it a try. It might be a couple weeks before I get to it though.