TK.

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.

Thank you! :) I've good news: I found out the trick how the original C64 power supply unit shifts the 9V AC to a higher voltage level in order to power the SID. It just adds the 5V DC via a 1N4001 diode - this DC voltage is not used to power the C64 logic... Schematics can be found here: http://www.ucapps.de/mbhp/mbhp_sid_c64_psu.pdf http://www.ucapps.de/mbhp/mbhp_4xsid_c64_psu.pdf Note that the ground connections have to be wired like shown above in order to avoid 50 Hz buzz on the Audio Outs. Next step will be the integration of 4 Audio Outs, a USB plug and a second MIDI In/Out into the C64 case... ;-) Best Regards, Thorsten.

Hi Kent, good ideas :) I will integrate the BankStick solution and the possibility to move the master fader in a second layer. Sly: yep - the speed option works nice :) The SID Control surface already uses it; with MIOS_ENC_SPEED_FAST and divider parameter 1 it is possible to increase a 7-bit value with a half revolution of the encoder - when it is turned fast. When it is turned slow you still will get 48 increments for this half revolution. Higher dividers are usefull for values with a higher resolution - this is demonstrated in the enc_speed example. Best Regards, Thorsten.

Here some application related numbers: The MIDIbox SID is currently the most complex application, especially because of the "software synth" engine for LFOs, Envelopes and Pitch. The update cycle of this synth is 800 uS, the PIC16F implementation takes about 500-600 uS, the PIC18F application about 200 uS MIDIbox Sequencer: the PIC16F implementation takes about 250 uS for every MIDI clock (@140 BPM the period of a MIDI clock is 17.8 mS). PIC18F: not implemented yet, but very relaxed Best Regards, Thorsten.

The main target during the implementation was to make the drivers as fast as possible to have enough performance free for the applications. I measured the execution time of every critical routine like the shift register driver, the analog pin and MIDI handler with a scope and fought for every clock cycle :) It's hard to say how much MIOS really takes, as most drivers are scalable. Example: you can decrease the update frequency of the SRIO driver if you think that 100 uS/1 ms (=10%) performance loss is too much. With an update cycle of 10 ms (which is already fairly good for buttons, but not for rotary encoders), the load is only 1%. You can also decrease the number of shift register, for example to 4. In this case the driver only takes about 25 uS, makes 2.5% system load (1 mS update cycle) cause by the SRIO driver per millisecond... However, I already thought about a profiler which allows to measure the performance of system tasks and applications, but currently my priorities are on other tasks ;-) Best Regards, Thorsten.