TK.

Hi Thomas, my suggestion: just send me your core module, it will save your time and give me the possibility to explore the most mysterious upload problem of the last year ;-) Best Regards, Thorsten.

gr@s! :-) Best Regards, Thorsten.

Hi Jost, thanks for the input! Other interfaces are not working with a buffer size < 2048, so it's difficult to specify values which fits with all requirements. :-/ Maybe with the upcoming Java environment this will work better without modifying any value. Best Regards, Thorsten.

The protocol is identical to HD44780. All what you need to do is to adapt the "Y Offset" values. A table for different display types can mostly be found in the applications which get use of the 2 additional lines (example: see the main.asm header of MIDImon or MB64) Best Regards, Thorsten.

Yes, you can power if with a battery. A user tried to power the merger from the MIDI line, it worked very unstable and not with every synth - so, I cannot recomment this. Best Regards, Thorsten.

Hi Nickca, a lot of programming effort is required to change the Magic MIDI Delay into an arpeggiator - however, this isn't really necessary. Just wait some days until the MIOS based MB64SEQ will be released (it's currently in beta state) - it already provides an arpeggiator function for up to 4 tracks, and every track can control any MIDI event (Notes, Controllers, etc...) or analog output. I've added a note stack handler to improve live playing - it really rocks once you understand how it works :) You don't need a box with 64 pots/faders/rotary encoders and a lot of buttons to get use of MB64SEQ, the sequencer data can also be controlled via SysEx. Similar to the MIDIbox SID you can store a single pattern in EEPROM (minimal solution for the guys who are planning to store/restore patterns with their PC) and 127 additional patterns in every BankStick (prefered solution). This means in other words, that you could also configure the setup from a PC and send the ready-made pattern to the sequencer. Realtime-editing is supported! (nice possibility: the arpeggiator-pattern can be modified on-the-fly during playing from Cubase/Logic :-) ) I've also planned to implement a jsynth based editor (similar to MIDIbox SID), but it can take some weeks until I will find the time for this. Best Regards, Thorsten.

Maybe I'm a little behind - where did you introduce your mixer? Best Regards, Thorsten.

Hi Defred, your design seems to be ok for a LCD-less MIDIbox Best Regards, Thorsten.

Hi Wilba, I just remembered that CC#8 will only re-trigger a new note when a note is already active (played with a common Note On command). So, a CC won't give you a new insight. Two suggestions: Watch the Note Stacks from 0x1c9-0x1d4, they should contain the semitone numbers of the played notes. You could also send a dummy MIDI event from interesting functions to check if it has been executed, example: SID_MIDI_NoteOn movlw 0xfa call MIOS_MIDI_TxBufferPut ;; ... I'm curious about the reason! Best Regards, Thorsten.

Follow this instructions: http://www.ucapps.de/howto_debug_midi.html thanks!

dito - same procedure as every year, you know. ;-) Btw.: I won't have access to the forum and to my emails until 1st January. Best Regards, Thorsten. P.S.: pay_c: I guess you mean the 6581 or the 8580?

Hi Defred, no, it isn't so easy to destroy a PIC. I've (unintentionally! ;-) ) tortured it several times with Vdd > 10V or with shorts at the IO pins, but all of my PICs are still working. Thats one of the reason why I still prefer this chip in a hobbyist project :) I cannot give you a tip how to check if a PIC is working or not, since I don't own a damaged one. ;-) You will notice no difference between a sample and a purchased PIC "is that bad if the data in box never toggles during my tests": YES! This must be the error in your JDM circuit - check the signal paths between DTR/CTS and RTS. Check also your serial cable to the PC the pull up doesn't disable the code protection, but the LVP = low voltage programming mode. The JDM won't work in this mode, therefore the pull-up is required code protection is something completely different. It's just a flag in the config sector which has to be "burned" into the PIC. The flag is disabled in the .hex file of the bootstrap loader, so no reason to take care about it. however, if this would be the reason (but it isn't!), you could reset the code protection with the "blank" command Best Regards, Thorsten. FAQMARKER - since I don't want to repeat this info again and again ;-)

Cool! I've added a note to the troubleshooting guide. Best Regards, Thorsten.

Hi Wilba, you could try CC#08 to trigger a note: B0 08 3c: Play C-3 B0 08 00: Note Off if this doesn't work, there is propably a problem with the sound patch you are using (very strange!) Best Regards, Thorsten.

Dieter Bohlen

alright -thanks! :) Best Regards, Thorsten.

So far as I remember you should read FFFF on a blank chip. But this can change from time to time, it depends on the flash process which is used on silicon. The invert options won't help, the JDM works only with non-inverted signals. What you could do: check the voltages during the burning procedure with a multimeter. Don't use a scope or any grounded instrument for this, because this will result to a short circuit. Best Regards, Thorsten.

Hi Wilba, sorry for this stupid answer, but have you also checked the MIDI channel? You could also send some note events from MIDI-Ox, just enable the virtual keyboard and press some keys. The channel can be changed with the "+" and "-" key of the keypad (so far as I remember...) Best Regards, Thorsten.

If every slave is assigned to a different MIOS device ID, all what you have to do is to push the Link button and to send the dump to the slave via the master. Best Regards, Thorsten.

Best solution would be the MIDIbox.org portal - thats the idea behind this website - just send the stuff to Poeloq (note that he is currently very busy) Best Regards, Thorsten.

Yes, Mike shipped the boards at 16th december, so if you have luck you will get it before christmas :) Best Regards, Thorsten.

arumblack: sure, the PIC16F877A will also work, you only have to take care for the correct device setting in IC-Prog. My tip: before asking such questions, use the powerfull search function of this forum, because this question has been answered several times before. Ladybug: yes, your JDM is ok, it must be a configuration problem. You didn't answer to my question if the same address cannot be written regardless of the IO delay (and the PC) you are using. It's very very very important for me to know what happens then, otherwise I cannot sort out the root cause. The message "the file does not contain a device ID value" can be ignored, the assembler doesn't include a device ID into the .hex file. You can disable this message somewhere in the preferences... Best Regards, Thorsten. P.S.: the .hex file is correct, it has been released one year ago, and many users tried in during this time P.P.S.: other PIC16F firmwares can be found here: http://www.ucapps.de/pic16f_firmwares.html

icescraper

You mean that IC prog stops burning at address 420h regardless of which IO delay and regardless of which computer you are using? Or do you notice any differences? Is it a PIC16F877 or a PIC16F877A? Best Regards, Thorsten.

Yes, your assumptions are correct... To the PCBs: don't ask me, ask the community! :-) Best Regards, Thorsten.