Sauraen

Where did you get those nice character OLED screens? And how much were they? I just today ordered parts for two SEQ V4s--for a friend and myself--and we were a little disappointed with the blue-and-white LCDs we picked, though the price (<$10 each) was right.

Updated schematic (rev. 1e2) for MBHP_Genesis (rev. 1e) boards:

I updated the first post in the thread to explicitly state that this is not a project intended for users to be able to easily replicate. I have to admit that originally I was hoping it would become a successor to MIDIbox FM V1.4, but this hasn't happened for several reasons: the complexity of the design not being too community-friendly, my own lack of time to work on documentation, and not a very high level of interest in the community. Modulator, I will offer again: if you want to get started with this project, it IS possible, and your questions may spur me to better document what I've done. At the core, the synth consists of a MBHP_CORE_STM32F4 module with whatever MIDI I/O you want; two MBHP_OPL3 modules; and a MBNG-compatible front panel. The core and MIDI I/O board(s) are standard; the front panel requires certain buttons, but the actual hardware is completely compatible with MIDIbox NG, so you can lay out the buttons and encoders however you want; the MBHP_OPL3 modules are standard except each board has a separate /CS wire to the core--the parallel interface is described in the source code and is somewhat configurable, but I can document this a little more if you want.

The MBHP_Genesis boards are tested and working! Here is a video of an Atmel MCU playing a small test "song" on the two sound chips. https://www.youtube.com/watch?v=1nM5-QfIv_c

Hi modulator, I'm sorry that you expected a complete well-documented project. I suppose that early in development I was hoping that the project would be one that others online could follow along with, but it quickly became complicated and hack-y enough that I stopped thinking that was really feasible. As I'm sure you understand, it takes a significant amount of work to document something, and even more to produce it in a manner that can be easily replicated. Many users on the MIDIbox Forums build projects, for which they take photos, have forum threads about their work, etc., and never offer a complete project that someone online can buy parts for and just build it with no issues. Wilba's excellent projects were well-documented primarily because boards and parts for the projects were being sold on the MIDIbox Shop. Similarly, for my MIDIbox Quad Genesis project that is currently in development, I will be selling MBHP_Genesis boards, and therefore I have documented them well here. You say "I see absolutely no benefit from confusing projects that are not completed" but you seem not to realize that a) MIDIbox FM V2.1 is completed, at least as much as it probably will be; and b) I gain benefit from using the synth whenever I play it, which is almost every day. I'm sorry that you had to read a few dozen forum posts before realizing that MIDIbox FM V2.1 isn't a project that users can just go and build, but simply a synth I built. If you're still upset about this, consider this. The firmware I designed requires a lot of buttons, LEDs, and encoders on a front panel. Their particular configuration can be edited via MBNG commands, but the range of controls must be available for the synth to be usable. So if you wanted to make one, even if I had documented everything 100%, you would have to make an aluminum front panel and a custom front panel PCB, both of which will be expensive and time-consuming. From the other side, if you have time to put into this project and you want to move forward knowing that there will be a lot of challenges, I am happy to help and give whatever documentation I can. But at this point I cannot just make this into an easy project for everyone to build. Sauraen

They're available on eBay for only a few dollars. I don't remember which seller I got mine from, but it seems fakes are not too common, and you would only lose a small amount of money even in that case.

Thanks everyone! I'm in the process of testing the boards now. Please understand, writing the application code will be a major project for me next semester--I absolutely will be doing it, it's just that if you buy the boards now, it's not made yet. Just wanted to make sure it was clear. I'm planning the development to go like this: Testing MBHP_Genesis boards, making them available for purchase on MIDIbox Shop (to end of December).Developing front panel for MIDIbox Quad Genesis (version for myself and Josh Whelchel), including aluminum and custom PCB. Having those manufactured and assembling all the hardware (to mid February).Developing first application code, Tracker Mode. This code puts each chip on a different USB MIDI port and maps voices to channels and CCs to parameters; no front panel controls at all, just the core and the sound chips. I will do my best to follow that one tracker MIDI standard I saw somewhere. I will put up each of these applications as I develop them (on SVN).Developing second application code, VGM Player. This code will use a 2x40 LCD and a SCS-like minimal control surface on the DIN/DOUT port (since J10A/B are the parallel interface for the sound chips). The application will let the user stream VGM files from the SD card to a single chip pair. (Hopefully this will also be done by mid February, but probably not.)Developing MIDIbox Quad Genesis shell: front panel interfacing, more advanced high-priority sound chip writing, memory allocation, etc.Integrating Tracker Mode and VGM Player mode. Polyphony engine.Developing VGM-editing-from-front-panel parts of application code.Developing modulators and other features.

The boards came! I am very busy at the end of this semester, but I'm in the process of working out the details so that these boards can be sold on SmashTV's MIDIbox Shop (once I've tested one!), probably starting around mid-December. They will be available for $5 each. Please keep in mind that the application code for MIDIbox Quad Genesis has not yet been developed--if you are buying the boards now, you will have to write your own application, whether using one of the MIDIbox core modules or any other microcontroller. The boards use a standard 8-bit parallel interface that's directly compatible with any 5V microcontroller, and compatible with 3.3V/3V boards using appropriate level shifters (see the wiki pages at http://www.midibox.org/dokuwiki/doku.php?id=mbhp_genesis and http://www.midibox.org/dokuwiki/doku.php?id=mbhp_genesis_ls ).

Revision 1e of the MBHP_Genesis boards have been ordered! The price for the bare boards will be $5 each. When they arrive, I will assemble and test one (with a similar AVR-based test program to the one I've been using, not the Core_STM32F4 that will be eventually used), and then begin taking orders for boards and parts kits. Here are the production revision (1e) schematic and board images: And the full-size version of the schematic (click image, then click Full Size, then click image to zoom to full size--it's 3000x2000):

Here's the rev. 1d pictures: Low-res schematic if the one below does not work: http://midibox.org/forums/gallery/image/3046-mbhp_genesis-module-rev-1d-schematic/

Scratch that pricing--an engineer buddy gave me a tip on a board house in China, which gives an online quote that's 70% less than the one I was looking at previously (from a top US board house)! If all goes well with them, I can get a price at which I can easily sell the boards for $5 each. This might even put the large front panel boards in reasonable price territory!

Thank you--I will do more research. :) As far as the timer ISRs for the sound chips, I didn't answer the question because it's complicated--the synth will be playing several (maybe more than 30!) VGM files from RAM at the same time, which can include up to 4 sampled streams. Depending on the load, the system may do different things. But I expect the typical behavior of the ISRs to be that they run for about 2-5us, then return, then get triggered again in another 5-10us. It should never be that they are running continuously for anything near 500us, but they will have to interrupt any MIDI-handling code many times. I don't expect to use IIC in this synth at all, I will probably disable the whole peripheral.

A quick project update: Since my last post I built a prototype board for the MBHP_Genesis module above, which led me to fix and tweak some things in the design. (Also thanks yogi about that pull-up!) I've also added an additional chip, an 8-bit latch for the SN76489 data lines, and associated circuitry. This allows the MCU to write a byte to the sound chip, then immediately use the bus for other things without corrupting the write. The MBHP_Genesis board takes care of latching the data value, waiting for READY to go high, and then un-/CS-ing the chip at that time. The MCU can read from the (other) register on the board to check on the status of the READY line; in the older design above, doing so would corrupt the write. This is similar to how the OPN2 works, you write an address and data and then you can use the bus for other things, and you can read from the chip to see if it's ready for another write. I've also changed plans a bit on the clock circuits. The board will support a standard 8-DIP oscillator or a 5x7mm SMT oscillator for each chip. The synth engine will contain logic to optionally adjust the frequency of notes on each chip from the source VGM file to match the clock you're using. This is because I wasn't able to find a good source of 7.67MHz (or 7.68MHz) oscillators to get the YM2612 to run at its original NTSC frequency. I want to confirm a couple circuit changes on my prototype, and then I will start taking orders for the boards. Here's the planned pricing, let me know what you think: Bare MBHP_Genesis board: $5 (double-sided, standard soldermask, one-sided silkscreen, 3.6" x 2.45", rectangular-pattern isolated mounting holes)Guaranteed-working set of one YM2612 and one SN76489: $5 (these will be from a lot, of which I have tested a few of the chips, but not every individual chip is tested--if yours don't work, you can get a refund)I will also have YM3438s, SN76494s, and SN76496s available, tested similarly as above, prices TBDComplete parts kit for one board (other than sound chips), including 8.00MHz oscillator for YM2612 and 3.579545MHz oscillator for the SN76489: $10Assembly service per one board: $20 soldering alone but no testing, $50 tested and confirmed working (total $75 including parts for one complete, tested board)

Thank you for the input, sorry for not getting back to this sooner. I was under the impression that using FreeRTOS meant: Tasks run for a fixed 1ms each and are automatically switched, the only way to temporarily disable this being to disable global interruptsOnly one ISR exists in the system, it's for the 1ms timer used by the OS, no other ISRs can be enabled or the OS will breakIs this not correct? Why aren't incoming UART bytes buffered in any way? Why aren't they saved to RAM using DMA? Yes, there would be a small latency (<1ms) but this means bytes would never be lost (unless there was a buffer overrun). In MIDIbox FM V2.0/V2.1 the 1ms task switching is plenty fast, as there's no reason the OPL3s would have to be updated faster than this. But in MIDIbox Quad Genesis, there's a mode in the OPN2 where sampled audio is played back on the sound chip, and the CPU has to write each sample one-by-one with no buffering. So there has to be an interrupt at 44.1kHz which cannot get delayed by more than 10us or so. Also, this interrupt will have to be able to play samples on four OPN2s at once--I think I can get the timing code right, but this has to be absolutely highest priority. I read over the STM32F4 DMA application note, it's pretty confusing, but it does look like DMA channels can be set up to handle receiving UART bytes. Is there any other peripheral that needs extremely fast service? How about USB MIDI? I know very little about USB packets, but I'm assuming they go in some sort of buffer. The SPI interface to the SD card isn't time-critical, right?

Hi TK, Is there any way to use MIOS32 functions without FreeRTOS? For my upcoming MIDIbox Quad Genesis project, there's some really precise timings on writing to the sound chips, and I need much better than 1ms resolution between tasks, plus several different ISRs which modify each others' conditions and keep custom state information between them. (This is on the STM32F4 core of course.) Besides the main synth loop "background task" which I will take care of, the only other peripheral functions being done by the synth will be USB and UART MIDI, SPI for the SD card, and SPI for the front panel DIO matrix. The latter can have its timing interrupted at any point with no problem; but I'm a little concerned about the other two. Where among these is DMA used? Can I set up their DMA Complete interrupts to be lower priority than the sound-chip-write interrupts? How often do I have to service USB MIDI DMA Complete interrupts for the communication not to get messed up? Basically, I know how to do each of these things individually in an embedded system, I want to know what parts I have to cut out of MIOS32 to get more complete control of them. Do you have any information for how to set these things up in a MIOS32 app? A lot of #MIOS32_DONT_USE_WHATEVERs? Thanks, Sauraen