Busy wait for DX7 programmer?

[NoobDog]

Hi, as the name indicates i'm a noob, not to c-programming but to electronics. Whatever, i managed to build sucessfully a midibox fm. As fm enthusiast in general, it was fun doing it but i want to go on.

On of my wet dreams is a midibox DX7 programmer in the style of the Jellinghaus programmer, a very rare hardware object. I made my first steps using the mbfm knobs and buttons as interface and was quite successful, i already was able to program a patch randomizer for the beloved DX. And here is where the trouble start. This thing is a dinosaur and very very slow, particularly the midi buffer is very easily overloaded. So basically i need a wait() function when sending out sysex data (e.g. a whole program) to the dx. There is no such function in the current API, and when i search the forums, i found some posts indicating that the only remedy is to send between each useful sysex call a few acknowledge messages, so any descent synth should just dump them or not even recognize them, and this would then generate the required space in between the calls. Sadly this is not the case at all with the DX. It constantly sends itself such acknowledge messages, and that's why i belive, it also receives such messages. A prove for my thesis is, that when i have MIOS-studio in between the "DXProgrammer" and the DX, this one filters out the acknowledge sysex's, and everything works fine, but a soon as i connect it directly to the synth (definitely a thing a want to do ;), it has the same buffer overflow problemz as before.

Can anybody help me write a descent busy wait function in MIOS C Style? I know very well how to do this on a computer, but to PIC programming i'm also very a noob. I can post the code, but i don't think this is very interesting for the current topic.

greetings

ND

[stryd_one]

http://www.ucapps.de/cmios_fun.html#MIOS_Delay  ;)

[NoobDog]

ups, sorry, i must have had an old documentation. i can find the declaration in the c header, but did not find it in the docs. you can remove the entire thread if you like and if you can, nothing interesting to other forum readers.

when i searched the forums i must have found old posts where a wait was not jet implemented.. i'm sure i saw a post by tk where he was pointing out this solution with the ack-msgs

thanx

[stryd_one]

No worries man. If you can memorise the whole function reference exactly, and you also teach me how, I'll give you a cookie. ;D

[TK.]

How about sending "dummy realtime messages" like 0xfe to add a defined delay between the SysEx commands. The DX7 shouldn't react one these events, and it doesn't hurt if one or more bytes get lost.

This would be the most simple solution. All others are more complicated.

The problem: since the MPROC parser and AIN/ENC/DIN handler are running with the same priority, it isn't possible to wait for an acknowledge message parsed from MPROC_NotifyReceivedByte() hook while waiting in DIN_NotifyToggle(), ENC_NotifyChange() or AIN_NotifyChange() for this message before continuing sending new SysEx messages (Sidenote: only MIOS32 will allow an elegant interaction between these tasks by using methods provided by a RTOS)

Possible solutions for PIC based MIOS:

a) program a "mailbox" system where the AIN/ENC/DIN handler puts new SysEx commands (in compressed format to save RAM) into a queue.

In addition, program a SysEx parser which checks for acknowledge messages and notifies this to a queue handler.

The queue handler has to be added to the Tick() hook. It checks for new messages, and sends them if the previous message has been acknowledged by the SysEx parser.

Disadvantage: high RAM consumption

b) there is a hidden hook in MIOS which allows you to parse incoming MIDI bytes interrupt driven. It has to be executed so fast as possible, therefore there is no (official) link to the C wrapper. In other words: this hook has to be programmed in assembly language.

The parser which matches with your requirements is very simple, maybe it would already be sufficient to check for 0xf7?

Using this method simplifies the programming model dramatically:

  - clear "F7" notifier (a volatile, global variable)

  - send SysEx message to DX7

  - wait until "F7" notifier has been set to 1 by the interrupt driven MIDI receiver

  - done

Disadvantage: you have to learn a bit assembly language, and I don't have the time to support you that much ;)

Programming example for including the interrupt driven hook into a C application:

http://svnmios.midibox.org/listing.php?repname=svn.mios&path=%2Ftrunk%2Fmodules%2Fmidi_rxtx_leds%2F

Programming example for a tiny SysEx parser which resists in this hook:

http://svnmios.midibox.org/filedetails.php?repname=svn.mios&path=%2Ftrunk%2Fapps%2Fexamples%2Fasm%2Fled_digits_mtc%2Fmtc.inc

Best Regards, Thorsten.

[NoobDog]

thorsten, your support is very much appreciated! i guess i should learn som ASM ;). when i get on with any of the suggested solutions and when this project reaches a descent stage of development, i will keep the community informed.

thanx again!

nd

[Ashiman]

im basically listening arcade soundtracks via. "bridgem1" in the last few weeks ( YM2151 chipset) Im more than happy this topic is rolling and will checking ebay for DX7 :) As far I know DX7-II is YM2612 , playing that in winamp thru emulator , very cool as well.