TK.

Hallo Ulrich, ich kann Dir den Bootstrap Loader in den PIC flashen. Meine Adresse findest Du im ucapps.de Impressum, schicke mir den PIC einfach zusammen mit dem Rueckporto zu. Gruss, Thorsten.

In the meantime I had some fun with VGA on my Spartan III board... no need for PIC hacking anymore ;-) Best Regards, Thorsten.

I don't own the source code of the windows application, maybe you could ask the name for such extensions Best Regards, Thorsten.

Hi, you could use the debug functions of MIOS Studio in order to check if anything is working. For instance, the MIOS_DIN_SRGet function allows you to check the current state of the buttons. If this function doesn't work at all (no response from core), it could mean that MIOS hasn't been uploaded correctly. In general it makes sense to upload the most recent releases of MIOS and the MIDIbox application. Best Regards, Thorsten.

Hi Jorge, updating MIOS on SID slaves is a not so well documented "corner case" - you have to reset the slave core manually. This can be done with a short cable, which is connected to ground - just tip it on the MRST# pin (pin 1) of the SID which should be updated. Thereafter send MIOS to the slave within 2 seconds. If you are using MIOS Studio, you have to enable the "Don't use feedback from core" option Best Regards, Thorsten.

Hi, for distances > 20 cm I would suggest to use the common MIDI port instead of the MIDI Link port. The functionality is the same, but the signals are more stable over such distances. Best Regards, Thorsten.

TB303 breakout box: no, I cannot tell you how it will look like exactly. I can only say, that it will have up to 24 buttons and up to 16 LEDs (means: 3*74HC165 and 2*74HC595). It won't get additional knobs, since they are already part of the control surface (step C) Best Regards, Thorsten.

the link was wrong, it's: -> http://www.ucapps.de/mios/midibox_sid_v1_7_303beta9.zip Best Regards, Thorsten.

Meine letztes Paeckchen aus den USA hat ca. einen Monat gebraucht, dabei lag sie wohl die meiste Zeit auf dem Zollamt - obwohl ich letztendlich keinen Zoll bezahlen musste... Gruss, Thorsten.

Hi, maybe this posting gives you some inspirations: http://69.56.171.55/~midibox/forum/index.php?topic=4140.0 with 512k backuped SRAM you don't need a BankStick Best Regards, Thorsten.

(I've no solution) Best Regards, Thorsten.

It's described here: http://www.ucapps.de/midibox_seq.html (search for hardware costs) Best Regards, Thorsten.

Hi, why not changing the pinning with the soldering iron? ;-) Best Regards, Thorsten.

0E 06 means: MIDI timeout - it seems that your MIDI interface (of the PC) has a problem - did you also try it with MIOS Studio? Best Regards, Thorsten.

Hi Jens, I've created a new version which should work better now, but not all "imperfections" can be fixed, due to various reasons. -> http://www.ucapps.de/mios/midibox_sid_v1_7_303beta9.zip I wrote about the reasons some time ago, but since the answers are spreaded over this forum, I will summarize them here (with some new insights and outlooks) additional hardware for TB303 sequencer: thats possible, my private blocking point is, that I haven't found a nice case for a "breakout box" yet (which then will be connected to a joystick port of the C64 case). I don't want to start with the implementation before I've a ready-built hardware, because it makes a big difference when everything is right in place before the programming phase, or if some stuff can only be prepared but not be tested. Play mode: yes, thats a known "problem". I had to decide if I either send a "play command" via SysEx, or via a common MIDI note. I prefered to use a MIDI note, since it is transfered faster (minimum latency) and since it is compatible with the old PIC16F hardware (I didn't know that your slave uses it - but it seems that it was good that I considered this) Sending a note instead of SysEx has also the advantage, that if SIDs are assigned to the same channel, they will be started at exactly the same time without a delay. Doing the same with SysEx would mean that I would have to implement something like a "broadcast" function (SysEx message which is taken independent from the Device ID), and this would increase the code size too much for such a minor feature. For the PIC16F firmware it wouldn't be possible (out of memory) Continue playing while changing a complete patch: this would lead to many unwanted side effects and wouldn't work properly in all cases. A patch change does not only refresh the SID registers, but especially resets the whole sound engine, which is so mighty like a soft synth. There are many dependencies between the registers (values which have to be stored and written back after the change), which makes such a feature to a mess for a programmer. A proper patch change without reset would also require that the whole patch data is transfered to the SID as well as to the sound engine within one update cycle (0.8 mS), this is not possible with the PIC. It's especially not possible to send so much data to the slaves within this short timewindow, since the transfer takes ca. 260 mS. Update of incoming CC values: it should work better now, parameters to the master SID are updated regardless of the menu page. The change will be visible after one second (worst case), but it should never got lost now (in edit mode!) Update of CCs to slaves: nearly impossible with the concept. At the time where I started with the implementation of the SID application on the PIC18F I had to decide how to store the data structures. I choosed a dual storage method: one compressed structure which reflects the SysEx dump and which is easy (and fast) to handle for the control surface when multiple SIDs have to be serviced, and another structure which is optimized for the sound engine. A third structure is given by the CC->parameter assignments, but this is (fortunately) not stored in memory, but directly transfered into the SID and SysEx memory. This works fine in most cases, but it has disadvantages which must be accepted. E.g., since it is possible to change multiple parameters with a single CC (e.g. CC#16 which changes the transpose value of all three oscillators), an incoming CC cannot be easily mapped to a byte in the SysEx structure. The current solution is to read back the data from the sound engine data storage and copy it into the SysEx storage when the CPU has some free time. This works fine, but only for the master SID, because the control surface has no access to the sound engine storage of the slave SIDs (unidirectional interface...) Another solution could be to write a large function which decodes the incoming CCs and passes them to the appr. registers of the SysEx structure. This would work for the master and the slaves, but it would consume so much code memory, that other features would have to be removed. Therefore I prefered the "cheaper" solution. There are two good points which I want to mention here: 1) for the MIDIbox FM I solved such problems very early in the design phase - MBFM has a single data structure which is optimized for SysEx/CC and OPL3 accesses (it took some time to find out all relationships) - so, in MBFM the data is always consistent 2) sometimes I'm thinking about a major redesign of the SID application which doesn't consider compatibility issues, but results into an "perfect" implementation based on my experiences in the last years. But on the other hand I think that the current implementation isn't that bad, that everybody can live with such imperfections when he knows how to handle with it... However, just another remark: if the PIC18F4620 wouldn't have that f*cked EUSART and CPU bugs, all these issues wouldn't exist anymore, because this chip offers twice the flash memory, and much more RAM... the existing firmware could be freely extended without such "50% solutions". So, my hope is, that Microchip releases a new chip revision, so that it is possible to make the application perfect without the previously mentioned redesign. Best Regards, Thorsten.

Hi Jens, I put the changes into this version: http://www.ucapps.de/mios/midibox_sid_v1_7_303beta8.zip (see CHANGELOG.txt for the handling) Could you please check if everything is working now? Best Regards, Thorsten.

Hi Taylor, ok - now I understand what you mean with pulse effect. It's possible to dim the LEDs via pulse-width-modulation. It wouldn't cost much performance (and wouldn't consume too much memory) if only one or two LEDs are dimmed, but for 50 LEDs I see no chance to integrated this into the MBLC application - the CPU load is already very high, especially when the host application sends a lot of MIDI events at the same time. An additional PWM handler for so much LEDs would provoke MIDI buffer overruns. Best Regards, Thorsten.

Hi, the midibox_seq package contains preassembled .hex files, but even if you would have to rebuild the project, it wouldn't cost you additional money - the MPLAB IDE from Microchip is available for free Best Regards, Thorsten.

I've currently no clear picture of what you are trying to do, therefore I cannot give you a clear answer. I asked for the MIOS application, because the implementation will heavily depend on the program which has to be modified. E.g., the MIDIbox64/64E is programmed in assembler, the MIDIbox LC (new version) in C. On the other hand: in my oppinion it is not really useful to integrate flashing LEDs into a Logic Control emulation, because the host flashes the LEDs by itself if required. E.g., when you select the Solo button, the Mute LEDs of all not-soloed tracks will flash. An additional flash algorithm from MIDIbox internal would propably only confuse. Best Regards, Thorsten.

Hi Gerald, it sounds like the power routing is not correct, if Vs and Vd are not connected, the ICs are powered through the data lines, and this can cause such effects. J1 seems to be ok, so check especially J2 (the 5V domain) No, the Vs pin of J1 should be left open if the wiring is based on the mbhp_4xsid_c64_psu_optimized.pdf diagram, otherwise you would get a ground loop which would increase the background noise Best Regards, Thorsten.

Hi Jens, I was able to reproduce issue 2) - I will fix this in the next version 4) the combination SIDx + menu button is really clever, I will go for this solution (about 10 lines of additional code...) Best Regards, Thorsten.

It's now possible to switch between the pattern sets in v2.3 Best Regards, Thorsten.

The change is now available in v2.3 Best Regards, Thorsten.

A new release with some nice new features :) From the ChangeLog: MIDIbox64SEQ V2.3 ~~~~~~~~~~~~~~~~~ o the clock can now be divided by BPM/1,2,3,..15,16 for each track seperately. Before this change it was BPM/1,2,4,8,16,32,64 It's possible to switch back to the old behaviour with the DEFAULT_BPM_DIVIDER_BEHAVIOUR switch in main.asm o the song menu handling has been overworked: - for 2*2x40 LCD option, there is now an additional info screen at the right side (second display) - song mode can be enabled/disabled in song menu by pressing the SONG button (again) - if not in song mode, the pattern set will be changed immediately (see usecases below for the reason) - song position now named A1..P8 instead of 1..128 for easier orientation - song positions are now divided into parts A..P, each part consists of 8 pattern sets, each pattern set can be looped up to 16 times. - song number, song position, loop/jumps now controllable with the general purpose buttons Usecases of the new song handling: a) for song mode enter the song menu and press the button twice. Press the "A" button + one of the 16 GP buttons to select the song Press the "B" button + one of the 16 GP buttons to select the part -> the sequencer will change to the part immediately, if the sequencer was not running before, it will be started automatically b) this allows you to divide a song into multiple parts. At the end of a part, you can either set a jump to the first step of the part (so that the part loops), or you can set a jump to the next part. Note: if a song part consists of 8 song positions, it is not possible to set an additional jump. The sequencer will jump to the next part automatically (this ensures compatibility) c) it's always possible to change the part during the sequencer is running - it won't affect the realtime behaviour :) This allows you to change between breaks/fills/chorus or whatever during a live session d) If you don't want to use the song mode, the new handling is still useful for you - it allows to save up to 128 pattern sets within a song. Press the "A" button + one of the 16 GP buttons to select the song Press the "B" button + one of the 16 GP buttons to select the part (this already provides a quick access to 16 pattern sets) Turn the datawheel to select pos 1..8 within a part Similar to song mode, changes will take place immediately without affecting the sequencer timings. The selected pattern set will loop endless until you are changing to a new one [/code] Best Regards, Thorsten.

Great! Looking forward for the public version! :) Best Regards, Thorsten.