TK.

Hi, I guess that you are refering to the C wrapper, no? Thats an important detail ;-) the memory allocation is documented in the project.lkr file. All memory locations which are not protected are free for your application. Data in code segment: in assembler you would just write the data via "dw" directive into the code memory, and access it via tblrd*+ and TABLAT. In C you have to declare a global array with initial data, e.g. unsigned char my_table[] = {0x01, 0x02, 0x03}; everything else will be handled by the compiler. Further informations about data handling should be available in the SDCC documentation. Best Regards, Thorsten.

Anything is really strange with your setup. I remember the Autorepeat problem, which was also not explainable. I've no idea... Best Regards, Thorsten.

Hi Matteo, the vmidibox16e editor is not compatible to the PIC18F version of MIDIbox64E, maybe thats the reason why I didn't worked. I'm currently trying to update it (Windows programming doesn't make fun!). You also have to take care for the right mk_syx version, there is a pic18f variant, did you use it? For uploading the data I would suggest the new vsysexbox: http://www.midibox.org/mios_tools/sysexbox_18f_v1_0c.zip Just edit the midibox64e.ini example, assign the FF 01 xx (xx = bank number) to the buttons you want, type "perl mk_syx.pl midibox64e.ini" and upload the resulting .syx file with vsysexbox Hint: by default (means: after you've uploaded the application and so long you haven't changed any MIDI event) following SFB functions are assigned to the following buttons 17 = FF 08 41 @OnOff # SFB: select bank/group 18 = FF 08 40 @OnOff # SFB: Select Parameter with encoder when hold 19 = FF 08 11 @OnOff # SFB: Encoder in fast mode when hold 20 = FF 08 21 @OnOff # SFB: Encoder in slow mode when hold This means: so long you hold button #18, you can select the group with the first encoder, and the bank (if a bankstick is connected) with the second encoder Just try this out in order to get familiar with the possibilities. Best Regards, Thorsten.

Hi Matteo, the vmidibox16e editor is not compatible to the PIC18F version of MIDIbox64E, maybe thats the reason why I didn't worked. I'm currently trying to update it (Windows programming doesn't make fun!). You also have to take care for the right mk_syx version, there is a pic18f variant, did you use it? For uploading the data I would suggest the new vsysexbox: http://www.midibox.org/mios_tools/sysexbox_18f_v1_0c.zip Just edit the midibox64e.ini example, assign the FF 01 xx (xx = bank number) to the buttons you want, type "perl mk_syx.pl midibox64e.ini" and upload the resulting .syx file with vsysexbox Hint: by default (means: after you've uploaded the application and so long you haven't changed any MIDI event) following SFB functions are assigned to the following buttons 17 = FF 08 41 @OnOff # SFB: select bank/group 18 = FF 08 40 @OnOff # SFB: Select Parameter with encoder when hold 19 = FF 08 11 @OnOff # SFB: Encoder in fast mode when hold 20 = FF 08 21 @OnOff # SFB: Encoder in slow mode when hold This means: so long you hold button #18, you can select the group with the first encoder, and the bank (if a bankstick is connected) with the second encoder Just try this out in order to get familiar with the possibilities. Best Regards, Thorsten.

thats what I've expected... no, it should always send the same sysex message. no, Pitch Bend/Reset events are normaly not send. But if you've already uploaded an application, something like this could happen - but it depends on the program... Btw.: the startup behaviour is will documented under http://www.ucapps.de/mios_bootstrap.html Is the programmer still required? (PIC18F: the pinning is different, but this can be adapted, compare the original JDM with my 40-pin version http://www.ucapps.de/mbhp_jdm.html. But the programming algorithm is also different, which means: you need a software which supports PIC18F452 as well as your programmer) Best Regards, Thorsten.

Hi Justin, I hate wintendo - thats all what I've to say :-/ New release can be found here http://www.midibox.org/mios_tools/sysexbox_18f_v1_0c.zip Best Regards, Thorsten.

Do you receive always the same events? Or are they more like random events? Then I would assume that no program is running anymore due to a hardware problem (bad soldering, crystal not connected properly, or whatever... follow the troubleshooting guide once more) and that the events are received since the MIDI Out pin is floating... from this point it really makes sense to do all the tests you did before. Or your BSL is corrupted... there are a lot of possible reasons, which can only be clarified by doing all the suggested tests. No, the PIC has no JTAG interface, but in the Wiki you will find a lot of documentation about this topic http://wiki.midibox.org Also here: http://www.midibox.org/cgi-bin/yabb/YaBB.cgi?board=news;action=display;num=1088620086 Best Regards, Thorsten.

16V~ ist ganz schoen heftig bei einem LCD mit Hintergrundbeleuchtung. Das bedeutet, dass der 7805 ca. 11V * ca. 200 mA (je nach Displayausfuehrung) = 2.2V in Waerme umwandeln muss. Kann es sein, dass der 7805 so heiss wird, dass die eingebaute Thermosicherung greift? Ich wuerde das BL erstmal weglassen. MIOS bootet? Dann kann es wirklich nur noch an einem Verdrahtungsfehler liegen. Wurde das LCD irgendwann einmal sehr heiss? Dann koennte es sogar sein, dass es mittlerweile defekt ist. :-/ Gruss, Thorsten.

Hi, to your last question: no, because this isn't necessary. The boot loader is the only program which is active during the first 2 seconds after reset. It allows you to overwrite the whole flash memory via MIDI (without the location where the boot loader is located of course), therefore an erase function is not required. A proper MIDI connection is required anyhow when you want to use your application. If a program is running wild due to MIDI upload problems, then you must find a way to upload MIOS during the 2-second-boot-phase. This will bring the chip in a proper state again, all references to the old flash content (e.g. a corrupt application) will be cancled by this way. The strange thing is, that you don't see the upload request anymore. This is either related to a power problem (weak power supply unit, 5V not available after reset, therefore the MIDI message won't be received by your PC), or it is related to the (very low) possibility that during your experiments corrupted code has been executed unintentionally which destroyed parts of the boot loader, so that it doesn't run anymore. How to proceed: it depends on your equipment. Do you own a PIC burner? Then just write the boot loader into the flash again - if you still don't see an upload request, then check the power supply and/or follow the MIDI troubleshooting guide again. If you don't own a PIC burner, then first check the PSU. Secondly try to upload MIOS without waiting for the upload request, maybe it works - if nothing helps, send the PIC to somebody of the community who can burn the BSL into the chip again and who can possibly also upload MIOS and a test application, so that you've an easier starting point. Best Regards, Thorsten.

Hi Justin, thanks for testing! I wasn't able to reproduce the MIDI In problem based on your description, but maybe it has something to do with the MIDI IN Buffer Size which is specified in the MM component. I've increased it from 128 bytes to 2048 bytes (the same value which is suggested for MIDI-Ox), in the hope that it works better with all MIDI interfaces (I'm no windows expert...) The setup is now saved in the registry when you close the application. The new version is located here: http://www.midibox.org/mios_tools/sysexbox_18f_v1_0b.zip please give me feedback if the app is also working on other PCs. If this is ensured, I will continue with the MB64 and MB64E editor. Best Regards, Thorsten.

Hi, I remember that this problem can happen if the MF driver "assumes" that the fader has been moved manually - it's always difficult to find this out via software. I fixed this problem in MIDIbox MF with the "MIOS_MF_TouchDetectionReset" function. Unfortunately I haven't included this function into the MIDIbox LC application yet. So, could you please try out the following: open "lc_mf.inc", search for "LC_MF_FaderMove" and include the reset at the beginning of this function: LC_MF_FaderMove ;; save fader number in LC_FADER_NUMBER andlw 0x07 movwf LC_FADER_NUMBER #if TOUCH_SENSOR_MODE == 2 call MIOS_MF_TouchDetectionReset #endif ;; ... rest of the code does it help? Best Regards, Thorsten.

MB64_GLOBAL_CHANNEL is located above 0x7f, therefore you've to select the high-byte of the address with SET_BSR E.g. movf MIDI_EVNT_VALUE, W SET_BSR MB64_GLOBAL_CHANNEL movwf MB64_GLOBAL_CHANNEL, BANKED or: movff MIDI_EVNT_VALUE, MB64_GLOBAL_CHANNEL see also: http://www.ucapps.de/mios/mios_ram_handling.txt Best Regards, Thorsten.

Hi Axel, he can contact me if he want. I only need to know in which format his application sends data to the LCD. Maybe the Yamaha01X works a little bit different from LC/MC Best Regards, Thorsten.

Serge's good old SysEx loader has been enhanced for the PIC18F projects. It simplifies the up- and download of code and configuration data and is especially easier to use than MIDI-Ox - I hope that this will avoid a lot of confusion about MIDI feedback trouble, delay values, device IDs, etc... in the future. An introduction can be found here: http://www.ucapps.de/howto_tools_syxloader_18f.html Once it has been tested successfully by some users, the same data transfer capabilities will be integrated into the MB64 and MB64E editor. Note that this tool is not the Java based environment which is promised from time to time in the forum. "MIOS Studio" will be an advanced solution especially for MIOS development and core debugging, and it will not only run under Windows, but also on Mac and Linux. It will be released in the next days. But the SysEx loader will still be maintained as small, alternative solution for everybody who notice problems with MIDI-Ox and/or installing the Java runtime environment. Best Regards, Thorsten.

Ja, dann funktioniert es nicht mehr. Das gleiche Problem tritt auf, wenn man Gummihandschuhe anzieht, oder den Fader mit einem isolierten Schraubenzieher bewegt (so teste ich i.d.R die dazugehoerige Software, die Touch Sensor Events weiterverarbeitet) Gruss, Thorsten.

Yes, but you need a good headsink, or you have to mount it directly on a metal case. Best Regards, Thorsten.

Hi Robin, thanks for the input - I just found an error in the mb64_sfb.inc file (the same error exists in the MIDIbox64E and MIDIbox MF application). Quickfix: open this file, search for MB64_SFB_Handler_02 (or go directly to line 86) and change: ;; branch to the end if no bankstick available IFSET MB_STAT, MB_STAT_USE_BANKSTICK, rgoto MB64_SFB_Handler_02_Msg to: ;; branch to the end if no bankstick available IFCLR MB_STAT, MB_STAT_USE_BANKSTICK, rgoto MB64_SFB_Handler_02_Msg hope that this helps! Best Regards, Thorsten.

the new MIDIO128 release is now available in the MIOS download section: http://www.ucapps.de/mios_download.html ChangeLog: http://www.ucapps.de/midio128_changelog.html Best Regards, Thorsten.

The MIDIbox SID from Chriss:

The MIDIbox64 from Pierrot - one of the most beautiful cases I ever saw! :)

Hi Per S, thank you for the reminder. The changes are already made, but I haven't found the time to release it (which takes some time since I always have to do some checks before) Best Regards, Thorsten.

Hi Pierrot, my suggestion: check the control elements with a simple test application first, before uploading the MIDIbox64 application, because if anything is not wired correctly, it's more difficult to sort this out with a complex program which (e.g.) unintentionally switches banks, activates groups, morphs the controller setting, or whatever... effects which you cannot explained by yourself so long you haven't used them. So: begin with the buttons and LEDs. Upload MIDIO128 and check if each button triggers a single MIDI event. Send the same events back (e.g. with MIDI-Ox) to see if the appr. LED is working. The encoder should send two events (since its connected to two pins), depending on the rotation state. You could also use the dout_buttons application to check the LEDs (two buttons are used to select one of 128 LEDs), so that you don't need to send MIDI events Once this is working, continue with ain64_din128_dout128, each pot should send a single controller event. If you still notice problems, then just write down, which application sends which events --- this allows us to tell you which hardware connections are wrong. Based on your descriptions I would say that the AIN multiplexers are not working, and that the SCLK or RCLK line of the DIN/DOUT shift register chain is not or wrongly connected. Best Regards, Thorsten.

yes, it's just like the rectifer/buffer/regulation circuit between J1 and J2 of the core modul + a transformer. Many electronic shops have such premade PSUs for cheap money - e.g. Pollin (http://www.pollin.de) has a regulated PSU with +5 V/1 A, +12 V/0,25 A and -12V/0.25A output which is an excellent solution for MIDIbox SID and MIDIbox CV And it costs only 1.95 EUR! So, just open your eyes when you go through an (online) electronic shop :) Best Regards, Thorsten.

Hallo Tobi, ja, die Ladekurve wird periodisch ueberwacht - dauert die Entladung laenger als der Grundwert, kann man davon ausgehen, dass der Touch Sensor gerade beruehrt wird. Nein, Du brauchst keinen zusaetzlichen Kondensator. Du benoetigst noch nicht einmal einen speziellen Sensor, denn wenn Du den hochohmigen Eingang der Sensorschaltung beruehrst, entsteht bereits eine kapazitive Verbindung zur Erde (ueber Deinen Koerper), und diese Kapazitaet ist ausreichend gross, um die Pulsantwort zu verlaengern. siehe auch http://www.ucapps.de/mbhp/mbhp_din_touchsensors.pdf Gruss, Thorsten.

No, there is no problem with XP. Just follow the MIDI troubleshooting guide step by step --- all issues from the past are documented there, all users were able to get the upload running based on this guide, and I don't think that there is any new, unknown problem. http://www.ucapps.de/howto_debug_midi.html Best Regards, Thorsten.