Sauraen

I desoldered one OPL3 and YAC512, and it was more difficult than soldering them; in fact I don't know of a single electronics application where desoldering is easier than soldering (when you want to not destroy the part, of course!). But if you are really uncomfortable with buying from overseas, and you can get a soundcard that cheap that has them, go right ahead. The two tricks to desoldering are: 1) start by adding some extra solder to each leg, and then 2) thread a very fine wire under all the legs so when you melt the leg on the end, you can pull the wire forward and it will come through and separate the leg from the board. For banksticks, I would recommend you build the module on veroboard (prototyping board) so it is easy to add more ICs if you start running out of space. IMHO you should start with 4 or all 8, it's not worth bothering for just one. For the power supplies, you have two options. In either case you will need a 7-10VAC wall transformer, connected to J1 of the core module, to supply +5V. But you also need to power the OPL3 module. The standard way is to use a +/-12VDC bipolar power supply like this one from MFOS . But if you're comfortable with a little modding, you can modify the OPL3 board to be able to run off that same +5V supply, powering it from the regulated +5V output from the core module. Here's the and the resulting Wiki article. I would not recommend the latter if you're not familiar with electronics, though; it's not hard to construct, but it's a relatively new addition. That's all if you only want to control your MIDIbox FM from your computer. Adding the screen is as easy as plugging it in, and you can always build and add a control surface later (obviously more work).

Hi lilakmonoke! In my experience it's not that hard to solder the OPL3 and YAC512s--it's more time-consuming than soldering through-hole stuff, but not really harder. First melt a bit of solder onto each of the pads without the IC there. Then, holding the chip in place on the board with one hand and the iron with the other, push the leg into the solder with the iron, melting the solder. Do this for the two diagonally opposite corner legs first, and make sure the chip is aligned properly so all the legs are right on top of their pads. Once it looks good, do the other two diagonal corners and check again for alignment. Finally push each leg down into the solder, waiting about 20 seconds every couple legs to let the chip cool down again. If a connection doesn't "look" good (you can sort of see with a magnifying glass if the solder has flowed onto the leg), add a bit more solder and see if that does the trick. Finally use a multimeter in continuity test mode to make sure there's no connection between any adjacent legs. If you want to be really thorough, follow each trace and do a continuity test between the OPL3 leg and wherever the trace connects to (obviously these should all show a connection). As far as where to get them from off ebay, I bought two YMF262s and four YAC512s from ebay seller smallpartsbigdifference (http://www.ebay.com/...tsbigdifference) for my build. They combined the shipping on the two orders (for a total price, including shipping, of $15) and all six chips work. They arrived about a week after ordering them, which is pretty good for Asia -> USA. (To be clear, you only need one OPL3 and two YAC512s.)

I've been looking for something like this for a while--specifically just looking for DB50XGs, but this would work too. It would fill a gap between the old-school but all-controllable sounds of MIDIbox FM and my high-end orchestral samples. That said, if it's just basically a hardware soundfont player, I have a large (~1 GB) collection of similar old-school soundfonts I can always load up into a DAW and make music in. That's not quite the thing for live performance, though. tl:dr; Cool!

Just started working with one of these for my job, and immediately started thinking about a possible port / extension of MIOS32! System: $45 1 GHz CPU with floating-point accelerator 512MB DDR3 RAM @ 800 MHz (plus CPU caches and RAM) 20M polygons/sec 3D graphics Two 200MHz 32-bit PRU processors with separate cache and RAM Included peripherals, all of the following supported simultaneously: USB Client (miniUSB to computer) USB Host (USB A to MIDI controller, etc.) Ethernet miniHDMI, up to 1080p @ 24fps Onboard 2GB eMMC (bootable) microSD card slot (bootable or data) 3 bidirectional UART (MIDI ports) plus one additional UART output only 1 SPI (DIN/DOUT) (there's two, but the other conflicts) 1 I2C (GM5, etc.) (there's two, but the other conflicts) ~20 free pins GPIO (SCS, software-based SPI for LCDs, parallel interface to SID, OPL3, etc.) I know one of the problems with Raspberry Pi was the lack of support for a FreeRTOS-based solution. For this board, there's a library from TI (free but probably closed-source) that includes USB and Ethernet drivers intended to work in a no-OS or RTOS environment: http://beagleboard.org/project/starterware/

Not in MIDIbox FM V1.4 / SammichFM, but yes in the upcoming The OPL3 itself has 6 4-op voices (that can be individually split into 2-op voices for a total of up to 12), plus 3 plain 2-op voices, plus 3 2-op voices that optionally become the 5-voice percussion system. The current versions of MIDIbox FM (V1.4 and SammichFM) have the 6 4-op voices permanently in that configuration, plus the percussion mode, and they never use those 3 extra 2-op voices. MIDIbox FM V2.0 allows you to configure all 18 2-op voices as you wish (within the limits of the chip). It's not a matter of rewiring, it would require a major overhaul in software of the synth engine, and I'm not sure the PIC microcontroller could handle it.

According to the YM2413 (OPLL) application manual, which is basically an OPL2 with some preset instruments: [boldface and brackets are mine] I'm not sure if this is only a characteristic of OPL3 or a misleading statement in the datasheet, but the white noise component of the "metal" sound in Hi-Hat is significantly affected by the choice of wave for the HH operator 33(14): choosing Abs-Sin will make the output only white noise, Sqr will make the output only "metal sound" with no noise, Sin gives a balanced mix of the two, and the other waveforms are somewhere in the middle. Thus, unless they specifically programmed the wave selection value to affect the mixing of a separate white noise generator with the "metal sound", I suspect the white noise is generated by feedback as shown above.

I've looked for a clear explanation of all the parameters in the OPL3's percussion mode, but I've never found one. So I sat down with my MIDIbox FM V2.0 Prototype and drew a diagram of what parameters influence what sound, with a vaguely accurate idea of how they do so. To be clear, these are the parameters for the two channels and four operators that are made into HH/SD/TT/CY within the OPL3, not any parameters specific to MIDIbox FM V2.0. There has been much misinformation circulating on the 'net about these instruments, specifically which instruments' tuning can be controlled. Vladimir Arnost's helpful breakdown of the OPL3 datasheet, the "Programmer's Guide to Yamaha YMF 262/OPL3 FM Music Synthesizer", states that "only Bass Drum, Snare Drum and Tom-Tom frequencies can be set. Cymbal and Hi-Hat frequencies are fixed." TK states in the MIDIbox FM V1 user manual that "Due to OPL3 limitations it isn't possible to use independent frequencies on HiHat/Tom/Cymbal (Bass Drum has it's own frequency and the base frequency of the Snare Drum is static and can only be multiplied)." The Adlib Tracker help page helpfully says "This mode is slightly hard to use (particularly the "SD/TT/TC/HH" tracks) so it is not recommended unless you know how it works or gain familiarity with it after several experiments :-)" In contrast, I have found that all the percussion instruments' frequencies are modulatable, but the "metal noise" waveform which the HH and CY are based on is generated from some sort of modulation (sounds like ring mod) combining the two channels' frequencies (i.e. the frequencies that also apply to SD and TT respectively), so they are not independently modulatable. This is why there's a picture! This fact is not the least of the oddities of this mode. However, one thing to note: the HH sound is in one way technically the most complex sound the OPL3 can generate, since nowhere else in the synth but in HH and CY is a sound modulatable by two frequencies independently (as opposed to the integer FMults), and HH has the addition of feedback.

After a lutenist friend was bugging me about electronic musicians being lazy by always playing in equal temperament, I implemented a custom temperament system for MIDIbox FM V2.0: You can select standard equal temperament, or set up a custom temperament system entirely from the front panel. The custom temperament system allows you to select a base note and specify that note's frequency, and then set up all the other notes from an octave as whole-number ratios from the base frequency. Changing what note the tuning is centered around preserves the ratios and recalculates everything, so if you change keys you only have to adjust one value. The ratios are preset to a modified just intonation, but you can make it almost whatever you want. The two main limitations are that all the octaves of one note letter are fixed to multiples of the same pitch (i.e. you can't do 24-note scales or other weird things like that), and that due to OPL3 limitations, some pitches will glitch if you try to make them too far from their equal-tempered version (e.g. you can make an E tuned like an F, but maybe not like an A).

Here's a video showing off the chorus module I just added, plus velocity sensitivity and sustain pedal/smart notestacks:

I feel cool for having heard of Diode mA three days before one of his songs went viral: Look at the views! Though I suspect it got posted somewhere with the tag "DOS dubstep" and that's why everyone watched it... :shifty:

I'm pretty sure I didn't modify anything that would have disrupted that, and I checked, the same thing happens with an untouched copy of MIDIbox NG. Try it yourself, go into your current working copy, change APP_BIG_STACK_SIZE to 1000000, and see if it compiles. Edit: Don't worry about it, I came up with a workaround that was better than my original attempt. Originally, that function was called when you press a softkey labeled "Go!", which means the function was being called from the stackful of functions dealing with MBNG DIN matrix handling and pool searching. Instead, I just made a small array holding flags for whether to load or save a patch to each channel next frame, and moved the actual calling of the SD-card-reading functions to a function that was only a couple of functions deep from the loop in APP_Background. So the stack below it is much less filled up.

It's strange, I see this in all the files as you've described it, but no matter what I change MIOS32_MINIMAL_STACK_SIZE to in mios32_config.h, the application still compiles using the same amount of RAM. I changed it to 1000000 and it still works--it shouldn't be able to allocate 1 MB of RAM to hold the stack, if the core only has 64 kB! (In case it matters, this is a modified MIDIbox NG.) Is there any way it's reading FreeRTOSConfig.h before mios32_config.h?

Hi TK, Just wrote a function to save some data to a file on the SD card, and once I got past the initial problems with my naming convention and the function actually ran, I get "!! HARD FAULT !! at PC=0x0001b6fe". Looking in project.lss, this is a line of assembler from the function void xPortPendSVHandler( void ), which I am assuming is part of FreeRTOS. So assuming that it is my code that has a null pointer or something, and not an undocumented problem with FreeRTOS :smile:, how do I find where my mistake is? MiosStudio didn't print a stack trace, just this one line. Thanks, Sauraen Edit: This is bizarre. It's crashing 0.8 seconds after not only the function I just wrote returns, but everything else I'm running has returned (the "Finished drawing screen").

Looks good, nice work! And glad to be able to help. :)

I bought two YMF262s and four YAC512s from ebay seller smallpartsbigdifference (http://www.ebay.com/usr/smallpartsbigdifference) for my build. They combined the shipping on the two orders (for a total price, including shipping, of $15) and all six chips work. They arrived about a week after ordering them, which is pretty good for Asia -> USA. If you're in Germany ("Utsource" :) ) I don't know if shipping or charges would be different.

Geez, you're fast! It took me a few hours to assemble the OPL3 boards for my build, and it's been hundreds of hours over the last two months for everything else. Then again, both of my builds have been big, flashy, and required a ton of custom code (which is still not done for either of them, heh heh!).

Now for a demosong that I didn't write, featuring drums, a non-crashing MIDI event handler, and overflowing (30+) voices: The song is Dr. Fruitcake's "Mario's Tropical Paradise" OC ReMix. Anyone else have nostalgia for the heyday of the MIDI file? :smile:

:blush: I found the infinite loop... :bug: If a note on was received that was unable to fit in the voices and was put on the notestack, and then the note off for that note was dropped, and then another note on was received for the same channel for the same note, AND if allowing multiple same notes was enabled, the MIDI handling routine would infinite loop. The reason I didn't find this sooner is because I thought that if I had hung the MIDI-handling thread, the core would be unable to receive any more MIDI messages. I didn't realize that each new message could in effect spawn a new thread. Anyway, I learned some things about embedded systems OS design, so that's good. And I wound up making a stress-test MIDI file that tries to send 2.3 MB of standard MIDI messages in about 15 seconds, which now, while it still leaves the synth playing 36 hanging notes, does not leave it crashed! Thanks for the help.

Hi TK, Thanks for the help. Before seeing your message I tried increasing the amount of code enclosed by interrupts-disabled, that just led to increasing the frequency of hangs. Back to original code... In my case I am receiving MIDI messages via USB, though I would like to make sure this will work over UART as well. The interrupts are disabled for less than 10 us at a time (writing to a register in a sound chip), but when many registers need refreshing, that function is called from a loop, so the interrupts are disabled most of the time during a longer period (e.g. 100 us), but enabled for short periods during that time. Do you expect this to be a problem? In any case the problem I'm having is not that there's a lot of MIDI messages being dropped, but that part of the application is hanging. To help track down where in the execution of APP_Background it was hanging, I created a global variable that it would write different values to between executing different sections of my code. Since the MBNG frontpanel control is all still working while it's hung, I have it displaying that number on the screen, and I can get it to refresh that even after it's crashed. After doing this a few times, it appears to be crashing at random points throughout the loop of APP_Background--not just, for instance, during the sound chip refreshing routine (when interrupts are disabled), and often while it's not executing any of my own code at all. So I'm guessing the problem is not in any of the actual code being executed in APP_Background. What happens if there's an error in code it's executing based on receiving a MIDI message--will that cause APP_Background to stop running, but allow future MIDI messages to be received and MBNG front panel button/LED stuff to keep working? For instance if there's an infinite loop in my MIDI handler function, would that cause the above symptoms?

Hi TK, I should know this already, but if a standard MIDI message (not SysEx) is received while execution is between a MIOS32_IRQ_Disable() and MIOS32_IRQ_Enable(), does the message get dropped, or does it go in some sort of queue for processing later? If so, is this allocated in real time from the heap, or something else? Is there any chance of this overflowing? Is is the case that immediately upon calling MIOS32_IRQ_Enable(), the interrupt occurs and the message is processed? Or is it only once per millisecond? I've been having some trouble with a custom application where everything works fine for an arbitrarily long time as long as the MIDI data being sent to the core for processing is relatively sparse, but after about 3 minutes of playing a song into it with a whole lot of data very quickly, the APP_Background() thread hangs (most likely somewhere in my code), but MIDI communication with MiosStudio and MBNG front panel control continues to work fine (i.e. FreeRTOS is still running). Thanks, Sauraen

If you pause and zoom in the video where it says "Sound IC", you can see that it's a YMZ284 PSG, not exactly equivalent to what's in the NES (the NES has two pulse waves, a triangle wave, and noise, and both pulse waves have pulse width control and independent envelopes; this chip just has three square waves and noise.with one envelope according to the datasheet). And it looks like there's a custom-programmed MCU next to it, plus some sort of ADC for the mics.