TK.

A second AOUT_LC module is not supported, this is documented in the ChangeLog (which you've translated ;-). Therefore you will see the previous values of the first two outputs at the second two outputs again Best Regards, Thorsten.

This is really strange. Could you please post detailed step-by-step instructions how to reproduce this behaviour? 1) power-on MIDIbox 2) press select button 1 3) scroll with the encoder completely to the end of the main menu page 4) press 5th select button Is this how you are trying it, or is there something between step 1) or 2) (or between the other steps?) Best Regards, Thorsten.

Hi Tim, just want to mention, that it could be, that your encoders are not connected correctly. Just try the three different pinning combinations, one should work much better. Best Regards, Thorsten.

It works with my MBSID, with and without BankStick. Does anybody else notice the same effect? Best Regards, Thorsten. P.S.: are you using the latest release?

Hi Gerald, this is not possible with MBSID, there is not enough space for the translation table Best Regards, Thorsten.

I've developed an algorithm which can reproduce the bug on a deterministic way (see also this article: http://forum.microchip.com/tm.aspx?m=85120), but it requires a second core (with another program which is not described in this article), and a scope to catch the triggers. However, there is an easier, but not so deterministic way: enable the MIDI merger, and send & receive a large SysEx dump with MIDI-Ox. When you compare the dump (function provided by MIDI-Ox) you will sometimes (!) see additional zero bytes Best Regards, Thorsten.

Could you please contact Mike and inform him about this error? (I also see, that one pin of R8 is open... compare it with the original layout to see how it should be connected) Best Regards, Thorsten.

Ok, so: MIOS and bootloader are up-to-date, you propably never need to update them anymore. Now it's time to debug the LCD. Infos can be found here: http://www.midibox.org/dokuwiki/doku.php?id=lcd_module_liquid_crystal_display On the other hand: if you can't wait to get some sounds out of the SID and want to troubleshoot the LCD later - just upload the MIDIbox SID application, and connect the SID module Best Regards, Thorsten.

I must say, that this is exactly what I've expected, therefore I urged you to doublecheck the gameport MIDI in this way - mainboard based MIDI interfaces are sometimes not reliable, don't know if this is related to the chipset, or to the windows driver. Therefore you can find this info at the bottom of the troubleshooting page, but most people just ignore this hint, and expect the problem somewhere else... don't know, how this "trouble" can be avoided... To the upload errors: this behaviour is correct (invalid address), everything works well. Just read this thread again, look especially for the hints given for the mios v1.9 and bootloader v1.2 update procedure. Please read also the README.txt file of the MIOS update package Best Regards, Thorsten.

So, this means you can try a direct connection to the gameport like described here: http://www.ucapps.de/mbhp/mbhp_midi_gameport.gif Note the the optocoupler has to be removed from the core board! Direction of the Diode: just compare it with the original schematic, which is available at the MBHP_CORE page Best Regards, Thorsten.

Could you please also answer my questions? Otherwise I've no clear view of your issue. Best Regards, Thorsten.

Nein, weil ich weiss, dass er in meinem Fall nicht weiterhilft - der PIC ist ja nicht ausschlieslich mit dem Datentransfer beschaeftigt, sondern soll auch noch andere Dinge tun. Ich habe diesen Workaround mit dem Microchip Support ausdiskutiert, nachdem ich den Bug reported hatte - in meinem Fall hilft er nicht weiter. Es hat viel Ueberzeugungskraft gekostet (drei Reports verteilt ueber mehrere Monate mit Beispielprogrammen und Oszi-Snapshots), bis der Silicon Bug als solcher akzeptiert wurde. Und scheinbar wurde er ja nun zumindest fuer den PIC18F4620 und aehnlichen Derivaten gefixed, beim PIC18F4550 kann es also nicht mehr lange dauern... Gruss, Thorsten.

For those who are interested, the stereo version: http://www.midibox.org/midibox_seq/mbseq_v3_demo1.mp3 Best Regards, Thorsten.

We will see, I've enough MIOS code for a validation under realworld conditions ;-) Best Regards, Thorsten.

This could be a problem around the offset pots P2 and P4, maybe the -12V connections are missing? Best Regards, Thorsten.

Hi Tim, in normal mode, the encoders should increment without skipping values. The right place to setup this is mios_tables.inc (which you've already found). Did you also try the DETENTED and DETENTED2 setting? Even when you encoders are non-detented, the results could be better. An oversight can be found here: Best Regards, Thorsten.

INFO: It turned out that the new chip revision still contains the EUSART bug, therefore this article is obsolete. The original article was: ------------------------------ So, PIC18F4620: according to a recently published errata sheet (http://ww1.microchip.com/downloads/en/DeviceDoc/80282a.pdf), Microchip has finally released a new B4 silicon, where the EUSART bug is fixed. These are really good news for all future MIDIbox projects, because this means that in some months PICs will be available where the MBHP_IIC_MIDI module won't be required as a workaround solution for a reliable MIDI Out port anymore! My proposal is not to buy PIC18F4620 devices yet until some of us have verified that the right revision is available in the appr. shops. In general I think it makes sense to wait until november to ensure, that older revisions are out of stock, thereafter we could try the new one (the revision number can be checked with a program). Maybe companies like Mouser or Farnell could also be asked via email or phone before... For those who cannot wait, they can also use in future the combination of CORE and IIC_MIDI module - it works perfectly, but increases the complexity (-> lower success rate for electronic newbies) A new revision of PIC18F4550 (USB device) has not been announced yet. Best Regards, Thorsten.

Die Firmware ist fertig, ich finde aber keine Zeit, das ganze Geraffel zu dokumentieren. Der letzte Snapshot von Maerz liegt unter http://www.ucapps.de/tmp/mbhp_usb_pic_snapshot.zip Gruss, Thorsten.

I think that you are mixing something. The definitions in mios.h are constant values which are used to address the desired encoder mode from the application code. All values in mios.h should never be changed, this is "low level stuff" The MBSEQ application only differs between "normal" and "fast" encoder settings. They are selected in SEQ_BUTTON_Fast (file seq_buttons.inc), and only allow one parameter for fast mode: DEFAULT_ENC_SPEED_VALUE Do you really need different values? If so, the source code has to be changed in seq_buttons.inc, and in addition somewhere within the USER_Init function, since by default the "normal" mode is selected, which doesn't need further initialisations Best Regards, Thorsten.

In one of your older posts I can see that you are using a MPU-401 MIDI interface. Is this part of your mainboard, or a soundcard? Did you check that the interface itself is working, e.g. with a direct loopback PC MIDI Out -> PC MIDI In? Just to ensure... If this is a gameport based interface, you could try a direct TTL connection over the MIDI Link port of the core w/o optocoupler. This maybe gives you some more input, what is working. Best Regards, Thorsten.

Bastelloesung... Siehe http://www.ucapps.de/mbhp_iic_midi.html USB bietet fuer jeden MIDI Port eine eigene Pipe, ausserdem gibt es eine Art Handshaking, so dass Daten nicht verloren gehen koennen. Ich bezweifle, dass sich der Aufwand lohnt. Zumal der COM Port sowieso ausstirbt Gruss, Thorsten.

Here again a video from a debugging session. After the last changes, some features are not working properly anymore (e.g. multi triggers), however, there is a lot of new stuff instead ;-) -> MBSEQ runs in song mode, a lot of arpeggiators are active, some CC lines for trancegate effect, most tracks are configured for 32th note resolution, one track runs with 2/3 speed. Best Regards, Thorsten.

Hi, the speed values can be changed in the .asm file you are using - either main.asm, or setup_mbseq_v2.asm - search for "SPEED" Nice to hear, that this is the only problem :) Best Regards, Thorsten.

Du moechtest also vom Linux Treiber aus "Load Sharing" betreiben? Das wuerde theoretisch funktionieren, erfordert jedoch Kenntnisse in der Treiberprogrammierung. Die maximale RS232 Baudrate ist 115200 Baud, der Mikrocontroller sollte sich in diesem Fall nur noch um das Routen kuemmern, da die Bytes alle 80 uS eintreffen. Zusaetzlich koenntest Du auch ein Handshaking ueber die RTS/CTS Leitungen realisieren, um einen potentiellen Datenverlust von vorneherein zu vermeiden. MIOS ist hierfuer nicht geeignet, es wuerde auf eine eigene Firmware und einen zusaetzlichen Mikrocontroller herauslaufen. Solange Du die MIDIbox als Controller betreibst, wird es mit der to-COM Schnittstelle keine Probleme geben. Ein vollwertiger MIDI In/Out erfordert wesentlich mehr Entwicklungsaufwand auf uC und Linux Seite - viel Spass ;-) Eine bereits laufende Loesung waere die Verwendung des MBHP_USB, oder MBHP_USB_PIC Interface (MBHP_USB_PIC ist nicht offiziell released, und auch nicht dokumentiert, laeuft aber - auch unter Linux - mit bis zu 5 MIDI In und Outs) Gruss, Thorsten.

no... Best Regards, Thorsten.