TK.

Hallo Hallucinogen, momentan ist es noch nicht moeglich, aber geplant ist es. Genauso wie das MTC Display --- ich muss lediglich mal wieder Platz auf meinem Schreibtisch kriegen und die erforderliche Hardware aufbauen, bevor ich diese Funktionen in die Applikation einbauen kann, deshalb dauert's ein bisserl... Gruss, Thorsten.

Hallo Lemonhorse, WOW! Ich bin sehr beeindruckt ueber das Video, und auch ueber die Dinge, die Du sonst noch so treibst - ein Theremin-SID ist schon etwas wirklich ausgefallenes! :) Schoen zu lesen, dass die PIC16F877 Version problemlos laeuft, ich habe sie nur noch in der Slave-Konfiguration getestet (ohne LCD, deshalb habe ich die falsche Versionsnummer uebersehen). Mit V1.5 wirkt sich der Depth-Parameter intensiver aus, mit maximaler Tiefe kann man nun bspw. ueber den gesamten CutOff-Bereich modulieren. Auch die Pitch und PW Modulation ist intensiver geworden. Ein Tip am Rande: fuer der/die/das Theremin macht es Sinn, den CC fuer das "Modulation Wheel" zu nutzen, und diesen dann auf den Zielparameter zu fuehren. Dadurch kannst Du nochmal zusaetzlich die Intensitaet sowie die Nullage beeinflussen: (CC #3: Init Value, CC#14: Depth, CC#118: Zielparameter) Gruss, Thorsten.

could you please check if it works when you upload all patches a second time? Best Regards, Thorsten.

You've assigned your MIDIbox LC to MIDI port 1, no? ;-) Best Regards, Thorsten.

Hi Dan, does this mean that only the first out is affected, or both MIDI Outs? To the SysEx issue: that's the M$ driver bug which is descriped at the USB module page: Note: this means also that the SysEx upload to PIC16F cores cannot be realized w/o a change in the vmidibox editor. MIDI-Ox cannot be used to upload a dump to PIC16F based MIDIboxes. Best Regards, Thorsten.

Ok, so just continue with digging. ;-) In fact the probability to overwrite the bootstrap loader is extreme low (it never happened during my own code development sessions yet), so if you could work out under which circumstances this can be reproduced (detailed description + sources + .syx file), you could help me to improve the stability. Best Regards, Thorsten.

Hi Matteo, so, you hear a short tune when you connect the BankStick - this means that the EEPROM has been regognized. ...what should happen? Did you select the Patches via Program Change? Note that Patch #1 is the internal patch stored in EEPROM, patch #2-128 are the external patches stored in BankStick. Best Regards, Thorsten.

P1 C1 1--- means that Patch 1 (the internal patch) has been loaded, assigned to MIDI Channel 1, SID1 is selected. Did you check the BankStick patches 2..128? Which patch names are visible? Best Regards, Thorsten.

Hi Ilmenator, no, MIOS denies the access to the bootstrap loader space, and I'm very sure that the SysEx upload works properly. I guess that you've modified the application and didn't take the allocated memory into account. Program code which crosses the 0x7c00 boundary will not be stored in flash memory, you should receive a ...0E xx F7... message during the upload which notifies that you did something 'illegal'. But the 'goto's into this area will not be removed (the part below 0x7c00 will still be executed), therefore it's possible to execute code of the bootstrap loader with improper settings - yes, and in this case parts of the flash memory could be overwritten. The SID_BANK_Write* routines are at the end of the application, so this must be the reason... If you need more memory for your modifications, you could remove the string settings defined in cs_menu_cc_table.inc (saves 2k!) Best Regards, Thorsten.

Hi Dan, thats correct, the whole windows system hangs during the EEPROM upload procedure. It also hangs some time when the MIDI driver is running and the USB cable is disconnected. But it should be recovered after about 30 seconds (this strange behaviour was also very confusing to me). You can always ensure that the USB chip is working by downloading the .hex file into SRAM (->use the Download button, not the EEPROM button for this test) Best Regards, Thorsten.

Hi Dan, fantastic! This means that MBHP_USB is working under XP (in principle), great news! How did you edit the names exactly? Could you please write a short HowTo (maybe with a snapshot) for the USB page? Bootproblem: I guess that you haven't burned the correct file into EEPROM. mbhp_usb.hex is the file which can be loaded directly into SRAM on-the-fly (nice for developing). But the SRAM content will be lost during power-off mbhp_usb.iic is the correct file. The required steps for the burning procedure can be found in ez-usb/HOWTO_BURN_EEPROM.txt Best Regards, Thorsten.

Hi Dan, the to-COM option itself should work, but the string is located to a wrong memory location, this causes the wrong output (I've to recompile the firmware...) Best Regards, Thorsten.

Fine fine :) Configuration of DINX4: note that this info is MB64/MB16E specific, the firmwares haven't been ported to MIOS yet (should be done in August...). In the meantime you can already use your box with the ain64_din128_dout128 application. F1/F2/F3/F4 are common MIDI triggers, only in the MB64SEQ firmware they are assigned to special functions. LCD: it seems that (most) connections are correct, the LCD will be initialized. But you should see at least a copyright message 2 seconds after startup, and thereafter a READY message. Possible problem: maybe one of the data lines (D0-D7) is missing. Best Regards, Thorsten.

Hi, This is strange - it would mean that there is a negative voltage between Vss and Rx, but under normal circumstances this should never happen. Did you also check the connections based on the schematic? http://www.ucapps.de/mbhp/mbhp_core.pdf The most frequently reasons for MIDI In problems are: bad solderings or junctions exchanged wires at the MIDI In jack non-functional MIDI Interface at the other side misconfigured MIDI software (the last two points aren't your problem) It isn't so easy to ensure that the optocoupler hasn't been damaged, maybe you should check the Rx port with a direct connection to the PC: Best Regards, Thorsten.

I guess that this display is HD44780 compatible, but I wouldn't buy it - the high backlight voltage requires a second power supply unit, and for the -7V bias voltage you've to use a DC/DC voltage converter like shown here: http://www.ucapps.de/mbhp/mbhp_glcd0.pdf In fact it will cost you more (trouble) than a common LCD. Best Regards, Thorsten.

Sure... the SID application handles J5 like a DOUT, but by integrating this function into MIOS, you can do anything with the timeout counter you want (e.g. display the status on LCD, etc...) Best Regards, Thorsten.

The modification of cs_menu_print.inc and cs_menu_table.inc would be the first step, but I guess that some more changes would be required in cs_menu.inc. I don't want to support this option for two reasons: memory limitations (yes, the SID application is nearly out of memory, I possibly have to remove cs_menu_cc_table.inc to free some memory again), and "featuritis": than more features which I'm not using by myself, than more difficult for me to ensure that all options are still working with a new release. The first problem could be fixed by putting the strings into a BankStick (up to 8 EEPROMs can be accessed now). But I won't do this for the official version in order to reduce the complexity The second problem has to be solved by yourself: change the code for your needs. Best Regards, Thorsten.

Hi Ilmenator, a nice idea! I will integrate two timeout-counters for the MIDI In and MIDI Out buffer into the next MIOS release (since it would be usefull for other applications, too) so that this function can be easily integrated. Best Regards, Thorsten.

Two well made MIDIboxes from the US: Justin aka Goyousalukis (Texas) David aka 2skee (California)

Here the current status of Steve's MIDIbox LC - he wrote:

Here are some first impressions from David's (Dawe) MIDIbox LC. The panel is made by a big machine using a laser to cut.

Noch nicht, aber sie hat bei mir immerhin eine hoehere Prioritaet, weil mit der PIC18F Version die Einschraenkungen aufgehoben werden sollen, die auf der MIDIbox64 SEQ Seite unter "Limitations of the PIC16F based firmware" aufgelistet sind. Gruss, Thorsten.

This list contains all crystals (part numbers + distributors) which have been sucessfully tested with the PIC16F or PIC18F. Please add your crystal if it isn't in the list to help other users! PIC type / URL / frequency / order number / price Small variants (recommented): PIC16F / http://www.reichelt.de / 20 MHz / 20,0000-HC49U-S / 0.24 EUR PIC18F / http://www.reichelt.de / 10 MHz / 10,0000-HC49U-S / 0.24 EUR Large variants (obsolete): PIC16F / http://www.reichelt.de / 20 MHz / 20-HC18 / 0.44 EUR PIC18F / http://www.reichelt.de / 10 MHz / 10-HC18 / 0.44 EUR

Hi, this crystal *should* also be ok, but I cannot guarantee this 100%. Biggest problem is, that some distributors don't specify the serial or parallel type, although it's very important. I will start a new topic now where all people should write down the ordering numbers of successfully tested crystals. To your core module problem: if the crystal would run with the wrong frequency (due to the serial type), the Tx pin would be active anyhow. The baudrate would be wrong, but this isn't the point here. So I guess that there is something else (something really strange...) which causes the startup problems. There aren't that much pin connections which are necessary to get the PIC running: o Pin #1 (MCLR#) must be connected via a 100 Ohm resistor to +5V o Pin #11 (Vdd) must be connected to +5V o Pin #32 (Vdd) must be connected to +5V o Pin #12 (Vss) must be connected to ground o Pin #31 (Vss) must be connected to ground o Pin 13/14 must be connected to the crystal & caps and thats all... So, since you measured all voltages, and since the crystal cannot cause a startup problem where the Tx pin doesn't get active, it must be a problem either with the PIC18F itself (try the verify option of IC-Prog in order to ensure that they bootstrap loader is still in flash memory) or with the 33 pF caps. Are you sure that these are 33 pF (pico-farad) caps which you using (I remember somebody who used 33 nF caps instead) Best Regards, Thorsten.

I removed the frames in one of the last versions, looks more aesthetical thats a good question - I also notice such failures sometimes when the motorfaders are moved (once or twice during a long-term session, quickfix: change to another display page, and back to the last page), but I wasn't able to determine if this is a soft- order hardware related problem. Now, where you are writing that you noticed the same, it's time to continue with the analyzation. Possible software problem: maybe a variable which is written to the wrong memory location --- errors which are hard to find. On the other hand: the MIDIbox SID is working extreme stable under heavy load, so I guess that it's more hardware related - here it could be possible that motorfader movements are causing some kind of noise on the LCD data lines... however, I will inform you when I know more. From my impression the encoders are not working fine with removed detent, sometimes they change the direction due to unstable digitil signals. Some days ago Steve wrote in an email how to improve the response by bending the wiper contacts. Steve - I guess it's ok when I quote your EMail? The speed setting will not help in this case. Best Regards, Thorsten.