TK.

The .syx file contains blocks which are assigned to a dedicated device ID. The only way to switch to another ID is to replace the appr. entry in the SysEx stream by the new ID, or to generate a new .syx file with the hex2syx.pl script (-device_id <id>). The "mios_upload.pl" script allows to change the device ID on the fly so that no new .syx file has to be generated. But this script runs only under Linux The planned Java GUI which will also run under Windows will provide the same possibilities MIOS itself has not been released for Device ID 0, as the the Java GUI will allow to change the device ID on the fly. If somebody want's to help me, he is free to program this Java GUI for us, because I'm not sure how long it can take until I will find the time for this task. Temporary solution: I could give you the mios_v1_3.hex file which allows you to convert .syx files for different device IDs. Alternatively you could change the device ID manually in the mios_v1_3.syx file (for every code block which begins with F0!). The main.hex file of the SID application is already available in the .zip archive. Best Regards, Thorsten.

Could you please check the next try? ;-) (same location, once more: untested) Best Regards, Thorsten.

Hi Pay, the capacitor specs are depending on so much parameters that it would be too difficult for a newbie to decide which values is the right one for his design. So I used the biggest value, which is good enough for a clean value when also a LCD with backlight and a lot of LEDs are powered from the same module. Of course, if your PSU already contains a cap, you can left out the one of the core module. Or if you don't use the analog inputs and therefore a clean voltage is not important, you can also replace it by 100 uF or 470 uF... Regarding the crash issue: I'm totally unsure how to reproduce this, my monitor runs fine but maybe your application sends any event (maybe an invalid event??) for which the firmware has not been prepared? Best Regards, Thorsten.

The LCD bus isn't multimaster capable, the only way would be to switch between all data and control lines (=11 signals) with a bidirectional switch (since the data bus goes to both directions) --- too difficult :-/ But for the records: one of the next MIOS examples will demonstrate how to use the new "customized LCD" driver (app_lcd.inc) to send all messages which are normaly printed on a LCD via MIDI to another MIDIbox in order to share a LCD. The "app_lcd.inc" file can be linked into any MIOS application. Only the application which displays the messages must be prepared for this capability (like MIDIbox LC), it has to provide a function which switches between different display buffers. I know that this isn't the answer which you want to hear, but it's just an inspiration for a possible solution which works w/o problems. Best Regards, Thorsten.

Geoff, if you are using a MIDIbox64 it's ok, this firmware doesn't provide an unmultiplexed mode like MIOS. Yes, you can leave out the unused ICs, you just only have to connect the open analog lines to the PIC with ground - in the same way like the remaining analog pins of the PIC for the second AINX4 module have to be connected to ground. Best Regards, Thorsten.

*grin* ;-) This is just a link to an article which describes the SID CS handling (so that this info doesn't get lost) http://www.midibox.org/cgi-bin/yabb/YaBB.cgi?board=news;action=display;num=1056228123;start=15

Just some comments to prevent the scare that LED rings or a replacement is required: my own surface is not stuffed with LED rings. The values are displayed on LCD instead. Maybe I should left some words to the workflow before you start to create your panel: when I press the OSC Select button. The SID CS jumps to the OSC menu immediately. If the OSC menu was already active, the cursor stays at the same position, otherwise the cursor jumps to the first menu item. The OSC number will be incremented, but also mixed OSC combinations can be selected. There are 6 button states for 6 different oscillator combinations the behaviour of the OSC Ctrl button is similar, but it has only three states: Envelope, Misc and Assign Layer. Every time I press this button the LCD changes to a menu view so that the 5 encoders are matching with the 5 menu items. using the OSC Select or OSC Ctrl button is also important if you want to change a parameter which is not assigned to any rotary encoder or functional button - just press the OSC/Ctrl button for a quick change into the OSC menu and select the menu item with the rotary encoder beside of the LCD when an encoder is moved, the menu page changes quickly to the same view like above this means: by using the OSC Ctrl button you can make the values visible on the LCD, and by using the OSC button you can select the 6 oscillator combinations (if more than one is selected at the same time, the values of the first oscillator will be displayed). Also by moving the rotary encoder, the values will be visible. Btw.: because of this LCD<->Button<->Encoder interaction, a 2x20 LCD is absolutely recommented. Ok, now some words to LED rings: they are nice to have, but in my oppinion they won't give you much more. Due to the (perfect ;-)) interaction with the menu interface, I'm more concentrated on the LCD and (especially) on the sound than on my fingers which are tweaking the knobs and selecting the functions. But don't forget the LEDs next to the buttons - they are important for an ergonomic handling. LED bars: a good replacement for LED rings, maybe even more ergonomic but not required LED digits: nice to have but not really important. Please note that you need 3*14 = 42 digits to display the decimal values of 14 encoders. But only two additional DOUTX4 modules can be connected, and every DOUTX4 module can only be stuffed with 12 digits maximum (due to the multiplexing method). Best Regards, Thorsten.

Yes, the last two shift registers of the DOUT chain are reserved for the modulation matrix. I just have added the 56 LEDs to the schematic (I've a nice animation in mind which could be showed during the startup phase ;-)) http://www.ucapps.de/midibox_sid_cs/mbsid_dout_default.pdf Best Regards, Thorsten.

The order of pins depends on the display, not on the controller. Yes, the signals are the same - please search for a datasheet of your display if you are unsure. Best Regards, Thorsten.

If the description of MIOS_HLP_Dec2BCD doesn't help (see Concepts->MIOS->Functions), please wait for the example application. Yes, this function helps to display values on LED digits. Best Regards, Thorsten.

It's also my new toy ;-) The updated version can be found here: http://www.ucapps.de/tmp/mios_upload_b.zip Unfortunately the return messages of a debug command will not be received (too fast) - possibly I've to rewrite the receive handler so that input and output streams are handled in parallel. However, something for the next days... Best Regards, Thorsten.

I prefer perl ;-) Could you please check if this script works on your system: http://www.ucapps.de/tmp/mios_upload_a.zip The next version will also support the MIDI IN in order to print the return message and to compare the checksum. Best Regards, Thorsten.

I've to learn how to use pipes so it can take some minutes. ;-) However, a quickfix for the debug function can be found here: http://www.ucapps.de/tmp/mios_v1_3atmp.zip Best Regards, Thorsten.

I've the same problem with ALSA. But since I own the MBHP_USB, I'm able to use MIDI again :) I just noticed that the debug function has a bug - the working register (WREG) will not be written correctly, you will see a "-" instead. I will fix this and I will write an upload script for MIOS .syx files, so that it is possible to update the new code under Linux. Best Regards, Thorsten.

Maybe it would be the best solution for us all when I just release a downstripped version of the SID CS code (called MIDIbox TC2) which already includes some examples for the XG card. My advantage would be that I will get a perfect interface for my own XG (sooner or later...) developed by you, and your advantage will be that you don't have to reinvent the wheel. In this way MIDIbox TC2 would also give the basics for other customized control units. When Do you plan to start with the hardware? :) Best Regards, Thorsten.

Perfect! The KS0066 is HD44780 compatible, so it will work with LCD type #0 :) I just remember that I also own a display with this controller. Best Regards, Thorsten.

Cool! Duggle, could you please try the following setting - this will be the upcoming suggestion, but I want to ensure that it works on all systems w/o problems: buffer size 2048, number of buffers: 4 Best Regards, Thorsten.

Hi Pilo, I've no idea how to make the LCD brighter... :-/ Yes, you could try to find out the exchanged data lines by printing different chars. I can suggest two solutions: If you like the Unix feeling (like me! :-)), just install Cygwin (http://www.cygwin.com), this is a nearly complete Unix environment running under Wintendo. Perl and Emacs are part of the standard release (the setup program allows you to select all the programs which you would like to use, thereafter the appr. packages will be downloaded and installed automatically) Another, maybe faster solution for the first tests: you are able to execute any function via MIDI by using the debug feature which is integrated into MIOS. I just have inserted this tool into the MIOS release http://www.ucapps.de/mios/mios_v1_3.zip (debug/mkdbg.pl) Examples: Search in mios_vectors.inc for the address of the appr. function. Or search in the .lst file if an application function should be executed. Run the mkdbg.pl script with the appr. parameters and send the generated SysEx string to the core. clear the display - the address of MIOS_LCD_Clear is 0x2d04. Start the mkdbg.pl script with following parameters: perl mkdbg.pl exec MIOS_LCD_Clear.syx 0x2d04 0x00 0x00 0x00 0x00 Print a character (here: 0x40 = @) - the address of MIOS_LCD_PrintChar is 0x2d28: perl mkdbg.pl exec MIOS_LCD_Char.syx 0x2d28 0x40 0x00 0x00 0x00 Hope that it still works ;-) Best Regards, Thorsten.

The KS0065 is just only a segment or column driver. Are you sure that the display is only stuffed with this chip, or is there any additional controller which provides the bus interface? Best Regards, Thorsten.

Hi Matteo, possibly yes - I've programmed the MIOS based firmware in a way which allows me to use all algorithms with multiple databases, so that another SID could be driven in parallel - in theory. But in practise I expect some effort for the details. First I want to finish all the planned features and projects before I do such a step. From my personal point of view this is a low-priority task Every additional core module just only costs about 20 EUR As I already built the 4-core solution, I don't need it for myself, it would only be some kind of sport to demonstrate the power of the PIC18F... A PIC18F core which drives 2 SIDs will not be able to handle the control surface in parallel (due to RAM limitations). And controlling SIDs without the control surface makes no fun. So at least two cores would be prefered anyhow. So in fact, please don't expect a release this year. But if somebody else with programming skills would like to modify the application for this option - step forward :) (I can provide some more technical details if required) Best Regards, Thorsten.

The GPC mode is my private pleasure, very limited, reduced to my own needs and therefore not documented. However, it could be improved in the future. It could also be completly changed... Encoders: values will be incremented faster when you turn the encoder faster. It's the same effect like known from a computer mouse. Sometimes also called "progressive mode" Sorry for the open questions reg. MIDIbox LC --- everything will be documented as soon as the application is complete, and this can still take a while... Best Regards, Thorsten.

Yes, a BankStick is very slow, a read needs ca. 100 uS (microseconds), a write ca. 10 ms (but you can write 64 bytes at once in order to improve the performance). However, these delays are not caused by the PIC, but by the IIC protocol. It's clocked with 400 kHz, and 40 bus cycles are necessary for a random read. Writes are taking much longer due to the general EEPROM limitations. For a lot of fast RAM the PIC is the wrong processor, but do you really need so much RAM direct accessible? Wouldn't it help to transfer the informations into a RAM buffer before they are required? Best Regards, Thorsten.

Hi Uclaros, due to performance reason this features uses always the internal bank for driving the LEDs. The events which are stored in the BankStick and assigned to the Buttons will not be used for the LEDs. (this limitation will be solved in the MIOS version). Best Regards, Thorsten.

Possibly you bought a HD44780 with japanese character set - the characters are stored in ROM, there is no way to switch to another set :-/ Best Regards, Thorsten.

My holidays are over, so it could take a while until I will find to start with the MB16E port. However, "vertical" and "horizontal" mode sounds nice, it shouldn't be a problem to integrate this into the MIOS based version. 256 parameters should be possible (however, thats the limit, since also 2*256 MIDI events have to be stored in RAM in order to process the incoming stream as fast as possible) Best Regards, Thorsten.