TK.

142 is an example and nothing else. Please read the details under http://www.ucapps.de/mios_bootstrap.html Best Regards, Thorsten.

Hi Thomas, sorry, the URL was not correct, its: http://www.ucapps.de/midibox_sid_csB.html To the upload procedure: You have to edit the main.asm assemble the .asm file to a .hex file convert the .hex file to a .syx file with "perl hex2syx.pl -device_id 0x01 main.hex" upload the .syx with MIDI-Ox These steps are described under http://www.ucapps.de/howto_tools_mpasm.html And remember: MIDIbox Link must be active, otherwise the slave won't get the incoming data Best Regards, Thorsten.

MIDIbox SID doesn't support pots, but only rotary encoders. Thats the better solution anyhow - you want to have jumpless switching when changing the oscillator, LFO, ENV, SID number - or the whole patch Best Regards, Thorsten.

Hallo, welche Soundkarte hast Du denn? Und welcher Treiber laeuft darauf? Ich kann mich an einen Fall erinnern, wo jemand einen veralteten Treiber verwendet hat, der mit SysEx probleme machte. Gruss, Thorsten.

Hi Robin, I would suggest to create a copy of the main.asm which which comes with the bs_xfer package, because it already contains all required settings (and therefore documentates the requirements and answers your questions) From main.asm you can include one or more .inc files which contain the converted binaries. Hint: after the assembler has been passed, you will find the address offsets to the converted binaries in main.lst - they are starting at 0x400000, the last 4 digits (16 bits) are equal to the BankStick addresses. Best Regards, Thorsten.

Hi Thomas, ok, from the beginning: Slave1 responds with "F0 00 00 7E 40 01 0F 00 00 F7 " The MIOS device ID is set to 1, but the SID device ID is still zero. This means that you haven't prepared your slaves yet like described under http://www.ucapps.de/midibox_sid_csB.html (search for "preparation"). Alternatively you can change the SID device ID in the main.asm header, search for "DEFAULT_DEVICE_ID" where also some additional comments can be found. (Side note: I will add an optional autoconfiguration in one of the next releases, because it seems that most people forget to change the ID - seems that spending more time in coding is always better than writing documentation ;-)) this is a misbehaviour which I don't understand exactly. Do you mean that the slave plays a note regardless if Link is enabled or not, or do you mean that the slave plays a note, but never stops to play it although a Note Off event has been sent by MIDI-Ox? these are general configuration settings and sound patches which are normaly sent by the master to the slaves. The slaves don't need to send it (since there are no receivers behind the slave...), so its ok when you just disable the CS (Control Surface) functions by setting "CS_ENABLED" to 1 in main.asm. But as I wrote in the comments: this is no requirement - it's just a good idea to disable the CS functions for the slaves - so this doesn't lead to a misbehaviour perfect! This means that the MIDI connections are ok This is correct, with link disabled all incoming messages are blocked by the master. But it's good that you mentioned it - this means that you've really activated the link - and no other button function. So - next steps: reconfigure the slaves by editing the main.asm file (thats the simplest way), upload the new firmwares through the master (link must be enabled), and repeat the whole testing procedure. Best Regards, Thorsten.

Please read http://www.ucapps.de/midibox_seq_options.html Search for the topic "Detented or Non-Detented Encoders" detented rotary encoders means in german "Endlosregler mit mechanischer Rastung" Best Regards, Thorsten.

Hi Robin, I thought that the checksum question became obsolete since you will use the hex2syx.pl script which calculates the checksum automatically. Maybe you've misinterpreted the term "sum of bytes". It should mean: the checksum is the addition result of all bytes within the address/counter field and all bytes of the dump field. Than it will be negated, so that the checksum within the SysEx file + the calculated checksum (which will be calculated by MIOS during the upload) results to zero The checksum is a 7-bit value, therefore only the first 7 bits are used (thats the "& 0x7f") Best Regards, Thorsten.

Hi again, I've updated the bs_xfer package (MIOS Download -> bs_xfer_v1_6.zip) It now also contains a script which allows you to convert a plain binary file to assembler text, it can be found in the tools directory (tools\bin2asm.pl) So, here the flow to bring plain binaries into the BankStick: use bin2asm.pl to convert your binary file to assembler you can copy&paste several assembler files to a single assembler file. Only requirement: the overall number of bytes should not exceed the 32768 boundary (0x407fff) if you are using a 32k BankStick, or 65536 (0x40ffff) if you are using a 64k BankStick use MPASM to get a .hex file use hex2syx.pl to get a MIOS upload file You will notice that this conversion process simplifies the creation of the BankStick content a lot, since you are able to move and rearrange the converted binary files with a text editor to free BankStick addresses Best Regards, Thorsten.

Hi Robin, you are right, I forgot to update the documentation about the EEPROM16 type, it must be PIC18F452 - EEPROM16 doesn't work due to an imperfection in the MPASM assembler you are also right with the documentation error concerning the internal flash readout counter - ch must be 0x20 But regarding the SysEx upload: it isn't possible to write any plain MIDI data (like SysEx strings) into the BankStick, they have to be encoded by the hex2syx script to another format. It's too complicated to convert an existing data dump into the MIOS upload format without this script. So, what you have to do: you have to write a script which converts your binary files to assembler text, so that the assembler can generate a .hex file, which can be thereafter converted to a .syx file by hex2syx.pl The assembler format can be found in bankstick_content.inc Best Regards, Thorsten.

Hi John, I've modified the description about the output drivers to point out that the pull-up/down resistors have to be added to each DOUT pin. I'm not sure if this was clear enough... The OE# pin doesn't consume power - it's just a logic input. Maybe you should draw a schematic so that it's easier to review your plans. ".gif" should be the prefered format for drawings, ".bmp" or ".tiff" are not displayed directly by a webbrowser, and ".jpg" is normaly only used for pictures... Best Regards, Thorsten.

Ok, here some basic checks - please write down your obervations on every single item: connect the first slave (with MIOS and SID device SID 0x01) directly with your PC: PC MIDI Out -> SID Slave 1 MIDI In SID Slave 1 MIDI Out -> PC MIDI In Start MIDI-Ox and enable the virtual keyboard (Actions->Keyboard). Press "Q" on your keyboard to play a Note - do you hear a sound? Restart your slave module (Power Off/On), which Upload Request string is received by MIDI-Ox? It should be: F0 00 00 7E 40 01 01 F7 (Slave with Device ID 1) disable the virtual keyboard (uncheck Actions->Keyboard), open the SysEx tool (View->SysEx) and type following SysEx strings into the Command window: f0 00 00 7e 40 01 0d 02 00 00 13 00 00 00 01 00 00 00 00 f7 f0 00 00 7e 40 01 0d 02 00 03 5d 00 00 00 03 00 00 00 00 f7 Start the transfer with Command Window->Start/Receive SysEx The slave core should return following SysEx strings (they are copied into the Display Window) F0 00 00 7E 40 01 0F 00 01 F7 F0 00 00 7E 40 01 0F 00 00 00 00 00 00 F7 If the numbers are looking different - which numbers do you see exactly? If these tests are working, try the same through the master module. Means: PC MIDI Out -> SID Master MIDI In SID Master MIDI Out -> SID Slave 1 MIDI In SID Slave 1 MIDI Out -> PC MIDI In Enable the Link (press the Link button), otherwise it won't work. Play a note like described above - results? NOTE: Link must be enabled! Restart the modules - results? disable the virtual keyboard and send the SysEx debug commands like described above - results? NOTE: Link must be enabled! Best Regards, Thorsten.

Hi, No, the PIC18F doesn't provide a second USART, and a software implemented serial interface can never run in parallel to the absolutely compute power intensive SID synth engine that I wrote. And especially not to all the other tasks which are running in parallel like display handler, button/rotary encoder handler, etc... So, you need an external merger for best results, and I guess that you already know http://www.ucapps.de/midimerger.html For MIOS programming you need to learn Assembler. Please search in the forum for additional infos regarding this topic. Best Regards, Thorsten.

Hi John, thats a really clever idea! Yes, you can wire all OE# pins together in order to control the output drivers. If the drivers are not enabled (OE# = 5V), all DOUT pins are in high impedance state, which means that they are floating. In order to get a stable logic signal (either 0V or 5V), you have to add 10k Pull-Up or Pull-Down resistors to the DOUT pins, similar to the way it has been done on the DINX4 module. These resistors will define the default state of each individual pin. I'm not sure if Smash already loaded MIOS into the PIC. If the upload request message will be repeated every 2 seconds, MIOS is not available. Btw.: maybe it's simpler just to modify the pin configuration directly in midio_presets.inc and to build a new application instead of using the .ini file. Currently the upload of a .syx data (not code) file is a little bit tricky, since MIDI-Ox has to be reconfigured for inserting delays between every byte. Many users already stumpled about this problem --- all those different setups are too confusing. Therefore I will change the upload format after my holidays so that it is the same like used for MIOS and MIOS applications (and therefore the MIDI-Ox setup doesn't need to be changed). What I want to say: if you notice problems during the upload of a configuration (a .syx derived from a .ini file), just change the pin definitions directly in the application code. I will make this step easier next month. Best Regards, Thorsten.

So, it this correct: you've ensured that each Core/SID module is working individually? You can hear a sound when they are in the "master position" - means: than they are directly connected to a keyboard or PC? If this is true, I could give you some SysEx commands which help to determine the system state. Best Regards, Thorsten.

Jim Henry wrote a superb guide about LCD soldering which is not only interesting for beginners - thanks Jim! http://www.midibox.org/users/jim_henry/building_a_midibox_lcd_cable.pdf Don't miss the other documents written by users which can be found here: http://www.avishowtech.com/midibox/modules.php?name=Content

Hallo, prinzipiell wuerde so etwas schon funktionieren, nur sollten die Kabel nicht zu lang sein - ab > 1m kann es kritisch werden. Gruss, Thorsten.

Hi Ian, just send me your modified source code and I will sort out what is going wrong... Best Regards, Thorsten.

Hi, here you can find a conversion table for hexadecimal to decimal format: http://www.ascii.cl/conversion.htm yes, thats absolutely correct! :) yes, you can overwrite the flash more than 100000 times It's also possible to program a function into the MIDIO128 application which enables/disables the DIN/DOUT handler. Such a function could be controlled from a free input - everything no problem, but somebody has to implement (and documentate) this... Best Regards, Thorsten.

Hi, SC shows more activity since its also used for the DIN/DOUT modules of the control surface. Are you sure that the highlevel is 8V? However, since your master module is working, propably not (it should be 5V) Ok - your slaves are running, otherwise the SC pin wouldn't toggle. The slaves don't forward common MIDI events like Note or CC to the MIDI Out - thats normal. The slaves don't send an acknowledge on incoming SysEx events - this would be the case if the SID device ID doesn't match. But if the SID device ID is not set properly, you should hear a sound on incoming notes anyhow - the MIDI channel is independent from the SID device ID. The slaves are running when their MIDI In is directly connected to the MIDI Out of your keyboard. I'm really confused and have no explanation why your setup doesn't work :-/ Best Regards, Thorsten.

Yes, you could do this --- but, so long you are using MIOS V1.6, and the slaves are running standalone, this is no software issue, and therefore there is no need for reprogramming the chips. Next test: connect the MIDI Out of the master module with your PC, start MIDI-Ox, switch to SID 2, 3 or 4 and turn a knob --- you should see some SysEx messages. Turn-on the Link and play a note with your keyboard: you should see the note in the MIDI-Ox input monitor If this works, connect the MIDI In of your PC with the MIDI Out of a slave instead. With this configuration you won't see the original SysEx parameters, Notes, CC's anymore, but you should see a SysEx acknowledge message (F0 00 00 7E 46 <device number> 0F F7) every time the slave receives a SysEx parameter which is addressed to him. This means in other words: when you switch the control surface to SID2, monitor the MIDI Out of the first slave, change a parameter (like Cut-Off), you should see F0 00 00 76 46 01 0F F7 after every parameter change. Best Regards, Thorsten,

Moment - stucking notes? This remembers me on a bug in an older MIOS version... are you using the most recent release? MIOS V1.6 (Don't mix it with MBSID V1.6...) Best Regards, Thorsten.

Which MIDI channel is assigned to the slaves? Note that the master directly controls the MIDI channel - means: if your slave is running standalone, the channel could be different The channel is displayed in the main view, but also in the CFG menu Best Regards, Thorsten.

Hi, MIOS can do everything, it's me who cannot do everything ;-) However, the song position can be sent with a Meta event (-> mb64e_meta.inc). You need to save the song position in two registers (since the position is a 14 bit value...), and you have to write a function which increments/decrements the counter and sends the F2 event with the resulting song position. It's also possible to receive the song position in order to update the internal registers. A F2 receiver is already implemented in the MB64 application, and it should be available for MB64E once I find the time to align the versions (I'm planning an enhanced version which can run on the MB SEQ hardware anyhow). Release: in ca. 3-4 months or earlier Best Regards, Thorsten.

Oh - you never wrote that you own a scope. This makes debugging much more easier! :) The Rx and Tx pins are high (5V) when no MIDI message is received/sent. At the master Rx pin you should see proper digital pulses when a MIDI message is received. Suggested time base: ca. 250 uS/div - trigger on falling edges! Once the Link is enabled, you should see the same pulses ca. 300 uS to 1 mS later at the Tx pin. This is the signal which goes directly to the slaves. Means: this signal should be visible at the Rx pin of each slave. If not, you've definitely a short between the Master Tx pin and the slave Rx pins. Remove the connections to the slaves, connect them again step by step and check the Tx signal of the master between each step Best Regards, Thorsten.