TK.

This time I will report a bug to avoid that you stumble accross the same problem... following discrepancy cannot be explained yet: if MIDI Merger is enabled and the core receives common MIDI events (like Notes, CC, ...) as well as a MIDI clock, the common events forwarded to the MIDI Out are sometimes corrupted. Sometimes means: with a propability of ca. 1% - therefore hard to reproduce. I won't have the time to fix this in the next days. So, if you notice such a problem, don't use MIDI clock and MIDI Merger at the same time! Best Regards, Thorsten.

Still mysterious, but fine that it works ;-) I will fix the software in the final release, so that the documentation matches with the implementation. This means, that you have to swap the pins again later. Best Regards, Thorsten.

Super, freut mich, dass es nun doch noch geklappt hat. :) Ja, es ist normal, dass die aelteren SIDs heiss werden. Ist halt NMOS Technologie... spaeter hat Commodore auf CMOS umgestellt, diese Chips werden dann nicht mehr so heiss. Gruss, Thorsten.

It should be clear that this is a copy&paste error in the comments, no? Because it explains the pin mapping of the input pins, and not of the output pins... I will fix the comment (sooner or later...) Best Regards, Thorsten.

Hi Christoffer, you are right. I've already fixed this imperfection, but haven't made a new release due to the effort... So, here the required changes: open cs_menu_ms.inc, search for the CS_MENU_MS_Send_SysExDump function and the "bsf CS_STAT, CS_STAT_DISPLAY_INIT_REQ" instruction. Remove this line thereafter open "cs_menu.inc", search for the CS_MENU_PatchUpdate function and insert "bsf CS_STAT, CS_STAT_DISPLAY_INIT_REQ" at the end of this function (before the return instruction) This will also fix the problem with the channel selection in the CFG menu Best Regards, Thorsten.

Hallo, danke fuer die ausfuehrliche Antwort! Mit diesen Details kann man sich schon viel eher vorstellen, wo evtl. die Ursache fuer das Problem liegt. Von der Softwareseite her machst Du alles richtig. Ich wuerde nun auf ein elektrisches Problem tippen. Evtl. ist die Spannung an J1 zu niedrig, so dass Vdd waehrend des Programmiervorgangs einbricht. Erhoehe mal die Eingangsspannung auf ca. 9V-10V. Falls das mit Deinem Netzteil nicht geht, deaktiviere probehalber das LCD Backlight (das verbraucht den meisten Strom). Gruss, Thorsten.

Perfect! :) Best Regards, Thorsten.

Hallo Jan, meine Beweggruende stehen auf der MBHP_CORE Seite: 8051: die meisten Derivate wie 80c535 benoetigen externe Memories, die schnelleren Varianten sind schwer aufzutreiben. Zilog und Motorola: zu langsam und schlechte Produktpflege Gruss, Thorsten.

The AOUT works perfect and has been successfully tested with this equipment: http://www.midibox.org/midibox_gallery/francois1.jpg The reason why the MBHP_AOUT hasn't been officially released yet is just that I'm planning to create a 64 multiplexed channel extension with S&H chips which will require an extension port. Once the MIDIbox SEQ has been finished, I will continue with this design. Best Regards, Thorsten.

Hi Dan, this would require some small changes.... in a lot of different files. Sorry, too much effort for me, I cannot help you to realize this. Best Regards, Thorsten.

Hi, a jitter > 3 is definitely too high. Seems to be a problem with the power wiring to your faders. Maybe it helps when you make the connections to Vs/Vd of J5 shorter. Best Regards, Thorsten.

> Its sending lots of midi messages actually over all 16 channels and pretty fast too. This means that you haven't tied the open (unused) analog inputs to ground... > On the wiring is VD (CORE) the same as VCC (LCD)? yes Best Regards, Thorsten.

Siehe http://www.midibox.org/cgi-bin/yabb/YaBB.cgi?board=concepts;action=display;num=1068921201 Wilba ist gerade mit seiner Familie umgezogen, deshalb kann es mit der Release noch ein wenig dauern. Aber das, was er bereits programmiert hat, funktioniert schon ziemlich gut :) Gruss, Thorsten.

Hallo, also wenn die Daten nur so "runterrauschen", wuerde ich vermuten, dass bei Dir das Delay zwischen den F7 Events noch auf 0 eingestellt ist --- muss aber auf 750 mS stehen: Aber an der Device ID koennte es ebenfalls liegen. Wie sieht der Upload Request genau aus? Gruss, Thorsten.

Hi, KS0066 works w/o problems. I'm also using some LCD modules with this controller. If you are sure that the PIC is running (does it send some MIDI messages?) then it must be a wiring problem. Last time a friend had a simmilar problem, and the reason was that one of the 16 cables was broken inside the 2-row connector - this problem was very hard to find.. :-/ If we had soldered all cables again, we possibly were able to fix this faster... so my tip: desolder the ribbon cable from the LCD and the core module, maybe check all 16 wires with a multimeter, and solder it again. Best Regards, Thorsten.

Hi Twin-x, Still the same problem? Then open a new topic Best Regards, Thorsten.

No, much more than 36 ppr cannot be natively handled by MIOS due to the minimum capturing cycle of 1 mS (the driver is optimized for up to 64 common rotary encoders). But it's possible to program a dedicated driver for higher resolutions - Tip: use MIOS_Timer with a capturing period of about 100-200 uS Best Regards, Thorsten.

Do you mean that the joystick just should send two different MIDI events for X and Y axis? This already works - just connect the pots to two different AINs Best Regards, Thorsten.

Alright ;-) Best Regards, Thorsten. P.S.: Hint - no, it doesn't work due to the limitations of the LC protocol

See http://www.ucapps.de/howto_debug_midi.html Best Regards, Thorsten. SUPER FAQMARKER

Hi Alex, could it be that your MIDI interface has an automatic MIDI Thru (feedback) which is active so long as no MIDI port has been opened by the software? This would explain everything, because in this situation the upload request will be looped to the MIDI In of your core module, and the BSL will remain in "listen" mode. If this is the reason, I will add this issue to the MIDI Troubleshooting Guide Best Regards, Thorsten.

Aus diesem main.hex wird das main.syx generiert, das Du dann via MIDI aufspielst. Dieses main.hex enthaelt lediglich den Applikationscode - und nicht das Betriebssystem. Deshalb macht es keinen Sinn, die Applikation einzeln via JDM in den PIC zu Brennen, wenn der Rest fehlt. Gruss, Thorsten.

Are you really sure that you are using Bootstrap Loader V1.1b? (available since 30.3.2003) How to test this: o Send any MIDI events to the box (just use a MIDI sequencer) o reboot the box (Power off/on) If it doesn't reboot until MIDI cables are diconnected: you are using the (very) old BSL v1.1 or lower If it boots: then I need more input from your side - under which circumstances does it work, when not? Best Regards, Thorsten.

Hi, thanks for the remark at the end, because the MIDI In LED effect indicates that there is a feedback loop in your host application - did you enable some kind of "MIDI Thru" function? This would also explain why the second MIDIbox stalls for 2 seconds before it continues. Please also ensure that you are using the most recent MIOS version V1.5b! Best Regards, Thorsten.

Hi, thanks for your input. It's really strange, because the left side digits are handled by the same code like the right side digits, so why does Digit14/15 display the chars from Digit8/9 and vice versa? Of course, this could also be fixed by software, but I guess it's better when I build the hardware and check it by myself (this can take some weeks...) in order to avoid a documentation disaster. till then you can use the hardware fix Best Regards, Thorsten.