TK.

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.

Hi Chriss, I just have answered your questions in the new Step B documentation. MIOS V1.3 and the updated SID application can now be found in the MIOS download section. Hope that the interaction with the STEC11B is working now :) Best Regards, Thorsten.

Yes, the PIC16F877A is working, you only have to take care with the JDM programmer. This chip has a special setup, and you need to increase the IO delay to 20 in order to lower the programming voltage. Best Regards, Thorsten.

It's ok :) Best Regards, Thorsten.

See MBHP->MIDIbox SID->Step B and Step C for further details. :) Best Regards, Thorsten.

MIOS V1.3 is now available for download, it comes with some new features for the near future: it's now possible to integrate an own LCD driver which is not natively supported by MIOS. See also the docs under Concepts->MBHP->LCD up to 8 BankSticks can now be addressed over the same IIC bus by using the MIOS_BANKSTICK_CtrlSet function. Note that this feature doesn't work with the EEPROM M24256 from ST, but only with Microchip EEPROM 24LC256. See also the docs under Concepts->MBHP->BankStick the MIOS_HLP_Dec2BCD function can be used to convert a 16 bit decimal value to BCD (for example to send the digits of a decimal number over the MIDI interface or to display the numbers on a LED digit display) MIOS_LCD_PrintBCD4 and MIOS_LCD_PrintBCD5 can be used to print 16 bit values in decimal form the MIOS_MF_StartupSpeedSet allows to give the motorfaders a "kick" when they are starting to move (can be tried with the mf_calibration application. The MIDIbox LC application now includes a calibration menu) the speed modes of the encoder driver have been rewritten, see the MIOS_ENC_SpeedSet description for further details. The "enc_speed_v1_3" application allows to test the various settings. Best Regards, Thorsten.

Since I will port all PIC16F firmwares to MIOS, you will have some very nice examples sooner or later. However, the integration is already possible and very easy: every MIDI event will be notified in USER_MPROC_NotifyFoundEvent ;; -------------------------------------------------------------------------- ;; This function is called by MIOS when a MIDI event has been received ;; which has been specified in the CONFIG_MIDI_IN table ;; Input: ;; o number of entry in WREG ;; o first MIDI event byte in MIOS_PARAMETER1 ;; o second MIDI event byte in MIOS_PARAMETER2 ;; o third MIDI event byte in MIOS_PARAMETER3 ;; -------------------------------------------------------------------------- USER_MPROC_NotifyFoundEvent return you have to copy the received bytes into variables which then will be taken by the MIDI learn function to assign the event to a button/knob/encoder or whatever. If this info is not enough, please wait for the ported firmwares Best Regards, Thorsten.

Since you cannot wait for the release... ;-) ; ========================================================================== ; In this table all encoder functions are listed ; the number and the position of entries are static and cannot be changed ; without a modification in cs_menu_enc.inc! ; ========================================================================== CSENC_ENTRY MACRO function, parameter, menu, page_offset, cursor_pos db function, parameter, menu, ((page_offset&0x0f)<<4) | (cursor_pos&0x0f) ENDM ;; available functions: ;; CSENC_ENTRY parameters: ;; - the ID itself ;; - the variable offset (see app_defines.inc, variables begin with CS_SID_*) ;; - the menu in which the variable is located (see cs_menu_tables.inc) ;; - the page offset (which menu item should be at the left border) ;; - the cursor position of the menu item #define CS_MENU_ENC_CHANGE_SYS 0x00 ; to change any internal parameter directly #define CS_MENU_ENC_CHANGE_OSC 0x10 ; to change parameter of currently selected OSC #define CS_MENU_ENC_CHANGE_LFO 0x20 ; to change parameter of currently selected LFO #define CS_MENU_ENC_CHANGE_ENV 0x30 ; to change parameter of currently selected ENV ;; CSENC_ENTRY parameters: ;; - the ID itself ;; - other values should be zeroed #define CS_MENU_ENC_CHANGE_MENU_P1 0x40 ; to change menu parameter #1 #define CS_MENU_ENC_CHANGE_MENU_P2 0x41 ; to change menu parameter #2 #define CS_MENU_ENC_CHANGE_MENU_P3 0x42 ; to change menu parameter #3 #define CS_MENU_ENC_CHANGE_MENU_P4 0x43 ; to change menu parameter #4 #define CS_MENU_ENC_CHANGE_MENU_P5 0x44 ; to change menu parameter #5 (if 2x20 display) #define CS_MENU_ENC_CHANGE_MENU_P6 0x45 ; to change menu parameter #6 (if >2x20 display) #define CS_MENU_ENC_CHANGE_MENU_P7 0x46 ; to change menu parameter #7 (if >2x20 display) #define CS_MENU_ENC_CHANGE_MENU_P8 0x47 ; to change menu parameter #8 (if >2x20 display) #define CS_MENU_ENC_CHANGE_MENU_P9 0x48 ; to change menu parameter #9 (if >2x20 display) #define CS_MENU_ENC_CHANGE_MENU_P10 0x49 ; to change menu parameter #10 (if 2x40 display) ;; CSENC_ENTRY parameters: ;; - the ID itself ;; - the CC number ;; - the menu entry will be ignored ;; - the page offset will be ignored ;; - the cursor pos will be ignored #define CS_MENU_ENC_CC_Rel1 0x50 ; to send a relative CC at channel 1 (for assign function) #define CS_MENU_ENC_CC_Rel2 0x51 ; to send a relative CC at channel 2 #define CS_MENU_ENC_CC_Rel3 0x52 ; to send a relative CC at channel 3 #define CS_MENU_ENC_CC_Rel4 0x53 ; to send a relative CC at channel 4 #define CS_MENU_ENC_CC_Rel5 0x54 ; to send a relative CC at channel 5 #define CS_MENU_ENC_CC_Rel6 0x55 ; to send a relative CC at channel 6 #define CS_MENU_ENC_CC_Rel7 0x56 ; to send a relative CC at channel 7 #define CS_MENU_ENC_CC_Rel8 0x57 ; to send a relative CC at channel 8 #define CS_MENU_ENC_CC_Rel9 0x58 ; to send a relative CC at channel 9 #define CS_MENU_ENC_CC_Rel10 0x59 ; to send a relative CC at channel 10 #define CS_MENU_ENC_CC_Rel11 0x5a ; to send a relative CC at channel 11 #define CS_MENU_ENC_CC_Rel12 0x5b ; to send a relative CC at channel 12 #define CS_MENU_ENC_CC_Rel13 0x5c ; to send a relative CC at channel 13 #define CS_MENU_ENC_CC_Rel14 0x5d ; to send a relative CC at channel 14 #define CS_MENU_ENC_CC_Rel15 0x5e ; to send a relative CC at channel 15 #define CS_MENU_ENC_CC_Rel16 0x5f ; to send a relative CC at channel 16 ;; CSENC_ENTRY parameters: ;; - the ID itself ;; - the CC number ;; - the menu entry will be ignored ;; - the page offset will be ignored ;; - cursor pos holds the register number (0x00-0x0f) in which the absolute value will be stored #define CS_MENU_ENC_CC_Abs1 0x60 ; to send a absolute CC at channel 1 (for assign function) #define CS_MENU_ENC_CC_Abs2 0x61 ; to send a absolute CC at channel 2 #define CS_MENU_ENC_CC_Abs3 0x62 ; to send a absolute CC at channel 3 #define CS_MENU_ENC_CC_Abs4 0x63 ; to send a absolute CC at channel 4 #define CS_MENU_ENC_CC_Abs5 0x64 ; to send a absolute CC at channel 5 #define CS_MENU_ENC_CC_Abs6 0x65 ; to send a absolute CC at channel 6 #define CS_MENU_ENC_CC_Abs7 0x66 ; to send a absolute CC at channel 7 #define CS_MENU_ENC_CC_Abs8 0x67 ; to send a absolute CC at channel 8 #define CS_MENU_ENC_CC_Abs9 0x68 ; to send a absolute CC at channel 9 #define CS_MENU_ENC_CC_Abs10 0x69 ; to send a absolute CC at channel 10 #define CS_MENU_ENC_CC_Abs11 0x6a ; to send a absolute CC at channel 11 #define CS_MENU_ENC_CC_Abs12 0x6b ; to send a absolute CC at channel 12 #define CS_MENU_ENC_CC_Abs13 0x6c ; to send a absolute CC at channel 13 #define CS_MENU_ENC_CC_Abs14 0x6d ; to send a absolute CC at channel 14 #define CS_MENU_ENC_CC_Abs15 0x6e ; to send a absolute CC at channel 15 #define CS_MENU_ENC_CC_Abs16 0x6f ; to send a absolute CC at channel 16 CS_MENU_ENC_TABLE ;; OSC "Env" Layer ;; Function name parameter menu offset cursor pos CSENC_ENTRY CS_MENU_ENC_CHANGE_OSC, CS_SID_VOICEx_DELAY, CS_MENU_OSC, 0x03, 0x03 CSENC_ENTRY CS_MENU_ENC_CHANGE_OSC, CS_SID_VOICEx_ATTACK, CS_MENU_OSC, 0x03, 0x04 CSENC_ENTRY CS_MENU_ENC_CHANGE_OSC, CS_SID_VOICEx_DECAY, CS_MENU_OSC, 0x03, 0x05 CSENC_ENTRY CS_MENU_ENC_CHANGE_OSC, CS_SID_VOICEx_SUSTAIN, CS_MENU_OSC, 0x03, 0x06 CSENC_ENTRY CS_MENU_ENC_CHANGE_OSC, CS_SID_VOICEx_RELEASE, CS_MENU_OSC, 0x03, 0x07 ;; OSC "Misc" Layer ;; Function name parameter menu offset cursor pos CSENC_ENTRY CS_MENU_ENC_CHANGE_OSC, CS_SID_VOICEx_TRANSPOSE, CS_MENU_OSC, 0x09, 0x09 CSENC_ENTRY CS_MENU_ENC_CHANGE_OSC, CS_SID_VOICEx_FINETUNE, CS_MENU_OSC, 0x09, 0x0a CSENC_ENTRY CS_MENU_ENC_CHANGE_OSC, CS_SID_VOICEx_PORTAMENTO, CS_MENU_OSC, 0x09, 0x0b CSENC_ENTRY CS_MENU_ENC_CHANGE_OSC, CS_SID_VOICEx_ARPEGGIATOR,CS_MENU_OSC, 0x09, 0x0c CSENC_ENTRY CS_MENU_ENC_CHANGE_OSC, CS_SID_VOICEx_PULSEWIDTH, CS_MENU_OSC, 0x09, 0x0d ;; OSC "Assign" Layer ;; Function name parameter menu offset cursor pos CSENC_ENTRY CS_MENU_ENC_CC_Abs16, 0x10, 0x00, 0x00, 0x00; HERE: CSENC_ENTRY CS_MENU_ENC_CC_Abs16, 0x11, 0x00, 0x00, 0x01; Abs. Register CSENC_ENTRY CS_MENU_ENC_CC_Abs16, 0x12, 0x00, 0x00, 0x02; number CSENC_ENTRY CS_MENU_ENC_CC_Abs16, 0x13, 0x00, 0x00, 0x03; (0x00-0x0f) CSENC_ENTRY CS_MENU_ENC_CC_Abs16, 0x14, 0x00, 0x00, 0x04 ;; LFO section ;; Function name parameter menu offset cursor pos CSENC_ENTRY CS_MENU_ENC_CHANGE_LFO, CS_SID_LFOx_RATE, CS_MENU_LFO, 0x00, 0x02 CSENC_ENTRY CS_MENU_ENC_CHANGE_LFO, CS_SID_LFOx_DEPTH, CS_MENU_LFO, 0x00, 0x03 ;; Filter section ;; Function name parameter menu offset cursor pos CSENC_ENTRY CS_MENU_ENC_CHANGE_SYS, CS_SID_FILTER_CUTOFF, CS_MENU_FIL, 0x00, 0x01 CSENC_ENTRY CS_MENU_ENC_CHANGE_SYS, CS_SID_FILTER_RESONANCE, CS_MENU_FIL, 0x00, 0x02 ;; Env "Env" Layer ;; Function name parameter menu offset cursor pos CSENC_ENTRY CS_MENU_ENC_CHANGE_ENV, CS_SID_ENVx_DEPTH, CS_MENU_ENV, 0x01, 0x01 CSENC_ENTRY CS_MENU_ENC_CHANGE_ENV, CS_SID_ENVx_ATTACK, CS_MENU_ENV, 0x01, 0x02 CSENC_ENTRY CS_MENU_ENC_CHANGE_ENV, CS_SID_ENVx_DECAY, CS_MENU_ENV, 0x01, 0x03 CSENC_ENTRY CS_MENU_ENC_CHANGE_ENV, CS_SID_ENVx_SUSTAIN, CS_MENU_ENV, 0x01, 0x04 CSENC_ENTRY CS_MENU_ENC_CHANGE_ENV, CS_SID_ENVx_RELEASE, CS_MENU_ENV, 0x01, 0x05 ;; Env "Assign" Layer ;; Function name parameter menu offset cursor pos CSENC_ENTRY CS_MENU_ENC_CHANGE_MENU_P1, 0x00, 0x00, 0x00, 0x00 CSENC_ENTRY CS_MENU_ENC_CHANGE_MENU_P2, 0x00, 0x00, 0x00, 0x00 CSENC_ENTRY CS_MENU_ENC_CHANGE_MENU_P3, 0x00, 0x00, 0x00, 0x00 CSENC_ENTRY CS_MENU_ENC_CHANGE_MENU_P4, 0x00, 0x00, 0x00, 0x00 CSENC_ENTRY CS_MENU_ENC_CHANGE_MENU_P5, 0x00, 0x00, 0x00, 0x00

Who brought up this rumor? I spent a lot of effort to minimize the latency and I'm very sure that the PIC16F as well as the MIOS implementation is faster than most of commercial controllers (I tried some during the last AES in munich and was very surprised how slow the M-Audio controllers are... ;-) Every 200 us (microseconds, not milliseconds!) the AIN driver samples an analog input. Since V1.2 MIOS comes with the same "dynamic priority" feature like the PIC16F firmwares - the two last moved pots/faders are sampled more often than the other pots. This decreased the latency from 12.8 ms (at 64 pots) without this feature to less than 2 ms (64 pots) with dynamic priorities. The latency of all 128 digital inputs (also rotary encoders) depends on the "update cycle", minimum and default value is 1 ms! Best Regards, Thorsten. P.S.: a lower latency makes no sense, as the transmission of a CC (3 bytes at 31250 baud) takes ca. 1 ms

It was your idea to use the MIDIbox SID CS as a skeleton... It's very hard for me to tell you exactly which functions are usefull for you, which not. I tried to make the code modular, so that cs_menu_* identifies the stuff for the control surface, but sometimes I had to make compromisses (i.e.: app_defines.h includes all variables for SID and the CS part, or sid_ccin.inc is directly used by the CS code) However, I guess that nobody but me is able to understand the complete code - it wasn't my intention to create a learning example with the MIDIbox SID application. Some programming tricks are based on experiences I made 15 years before, it would fill a book to explain all relations ;-) I guess that you only need ca. 25% of this code for your own application, it's maybe better to start from scratch and to take the CS implementation only as a source of inspiration. Best Regards, Thorsten.

Fine that you finally found the reason :) The lower MPU401 entry should be removed - this is the input port. Best Regards, Thorsten.

Thats the trick behind this solution: with two boards I'm able to adjust the distance between the encoders, the buttons and the panel so that it will fit perfectly. With one board I wouldn't have this possibility, thats also a reason why I got rid of this idea. I didn't cut the legs of the LEDs, so I'm still able to adjust them, too. I aggree with you, an integrated map function in the LCD menu and/or a MIDI Learn function (like available on all PIC16F MIDIboxes btw.) would be nice, but unfortunately I see no free memory for such a function. The current CS implementation consumes more memory than expected (feature overload!!!), therefore I've to be very carefull before adding more details. Only solution would be a dedicated core for the control surface or a second BankStick, but I'm trying to prevent this in order to limit the complexity of the hardware (for myself it wouldn't be a big problem, but when you read the Troubleshooting board, you possibly understand what I mean ;-)) Current solution: there is a table which allows you to assign the controllers. For changes you have to upload the whole application. My frontpanel matches with the C64 case, it's no 19" rack design. I've no interest in adding an digital output or input, my RME soundcard is already great - the SID delivers no digital audio stream, the output stage and the filter are analouge. Also the audio in is analouge. Yes, my box is stuffed with 4 SIDs - it rocks! :) Best Regards, Thorsten.

Update for the schedule: nearly the complete StepC surface is now working, only the modulation matrix is not ready for use as I need to mount the LEDs on the panel before I can write the driver. I will beta-test the firmware this evening (making a new demo song) and release an hopefully bugfree version tomorrow. :) Btw.: I also fixed some bugs of the last release: - sometimes the Bankstick upload didn't work properly because the CS menu disturbed the transfer; - by selecting a SID the parameters which have been changed before were overwritten - the rotary encoder sometimes stumbled because of a too low sample frequency (3 ms instead of 1 ms) - detented Alps STEC11B didn't work properly - incoming CC data were not displayed - ... Another note: users who want to use a minimal control surface with multiple SIDs (Step B) have to add 7 additional buttons and 7 LEDs. It's not possible to select the SID(s) from the menu anymore due to a new button handling (multiple SIDs can be selected at once by holding one SID button and pushing the additional SID buttons), and it's also not possible to enable the CC, Link and Edit mode from the menu. Be prepared! ;-) Best Regards, Thorsten.

Ok, it was a firmware issue - now both IOs are working perfectly with Linux. For the records: in difference to the Microsoft driver, the Linux solution is multiclient cabaple and has no problems with long SysEx strings ;-) The new firmware can be found here: http://www.ucapps.de/mbhp/mbhp_usb_v1_1.zip Best Regards, Thorsten.

Update: I've installed a new kernel and Alsa driver from this (nice!) site: http://ccrma-www.stanford.edu/planetccrma/software/system.html#kernel The MBHP USB module will be regognized immediately by the kernel (Plug & Play without further installation :-)): MBHP USB Manufacturer: Thorsten Klose Speed: 12Mb/s (full) USB Version: 1.10 Device Class: 00(>ifc ) Device Subclass: 00 Device Protocol: 00 Maximum Default Endpoint Size: 64 Number of Configurations: 1 Vendor Id: ac89 Product Id: 8ef1 Revision Number: 0.01 Both MIDI OUTs (/dev/midi0 and /dev/midi1) are working ok Both MIDI INs are routed to /dev/midi0 I will check if the MIDI IN problem can be fixed in the firmware or if the Linux driver needs an adaption. Best Regards, Thorsten.

this USB-MIDI driver is obsolete and doesn't work with the current Linux version, the update has been partly integrated into the kernel, partly into ALSA... I will write something about the required installation steps so soon as I've some time (my own Linux installation is fairly old, I've to update the kernel, some libraries, etc. to get ALSA 0.9.3 or 0.9.4 running..). Best Regards, Thorsten.

Hi Elliot, yes, a rotary encoder allocates 2 DIN pins, therefore "only" 64 encoders can be handled by one core module. In parallel this core could also handle 8 motorfaders or 64 non-motorized faders by using 2 AINX4 modules. However, this isn't your requirement. So, some words to the mutlicore-solution: maybe the port of MB64 will simplify the realization of a solution like discusses here: http://www.midibox.org/cgi-bin/yabb/YaBB.cgi?board=concepts;action=display;num=1047922838 but so long as I haven't started with this work I cannot provide further details. And please also keep in mind that for a complete customization you need to learn PIC programming in order to modify the application for your needs. The 128 DIN/128 DOUT/64 AIN application is one of the most stable ones ;-) The encoder driver has been improved in MIOS V1.3 (additional speed modes, release maybe tomorrow) The MF driver runs fine with Alps motorfaders, but currently it's unclear if it runs as well with panasonic faders. Best Regards, Thorsten.

The MPU401 input is still mapped to the MPU401 output, you have to delete this routing (right-click on the entry -> delete) Best Regards, Thorsten.

Do you have the 13.2V during programming now, or only during reading? Don't try to increase the voltage above this level, it could destroy the PIC. If it still doesn't work, it's maybe a good idea to try the programmer on another PC (time to visit a friend... ;-) Best Regards, Thorsten.

During programming I get 13.2V, so it seems that the voltage of the titanium programmer is not high enough. If the hardware is similar to the JDM, you are maybe able to adapt the resistor/diode values? However, this wouldn't be a "quick" solution. I've no other idea... Best Regards, Thorsten.

Hi Robin, ok, the keyboard test showed that the input port is mapped to the output port. This is some kind of internal feedback which definitely disturbs the upload. So, go into the Options->MIDI Devices menu, disable the "automatically attach inputs to outputs" switch, open the port map of the MIDI out and remove the MIDI In from this map. This should (hopefully) help :) Best Regards, Thorsten.

Hi Dan, no there isn't an application available for testing the MTC display - just wait some days until I've finished the SID CS... ;-) 2nd core: sure, this works. Just upload the MIDIbox LC application with a different configuration into the second core. Only the MIDI In of this core has to be connected in this case. The GPC option is only an immediate solution, the final one will be more powerfull. It allows you to send up to 128 CC's to another program, i.E to Reaktor. You will see 8 CCs on the display when entering this mode, they can be controlled by the 8 V-pots. With the Jog-Wheel you are able to shift the "V-pot window" to the other CC's. However, the final GPC mode will also support the Motorfaders, customized strings and customized MIDI events. Best Regards, Thorsten.