TK.

Hi LO, it seems that this is no transmission error, since CC #4B is properly incremented (...5A, 5B, 5C, 5D, 5E...). On a bad MBLINK connection I would assume a totally different - or invalid - MIDI event. "B1 48 xx" is assigned to a pot, isn't it? Did you seperate the analog from the digital wires (are the wires itself shielded, or only the whole cable?) Do you have more logfiles? Best Regards, Thorsten.

Hi Robm, you don't need to buy those sensor ICs, MIOS provides a software based solution - up to 128 capacitive touch sensors can be connected :-) A schematic diagram can be found here: http://www.ucapps.de/mbhp/mbhp_din_touchsensors.pdf This article describes, how it works: http://www.midibox.org/cgi-bin/yabb/YaBB.cgi?board=concepts;action=display;num=1062462975;start=1#1 Best Regards, Thorsten. FAQMARKER

Hallo Nova, ich kann eigentlich nur das wiederholen, was in den letzten Tagen schon des oefteren anklang: alle unbenutzten analogen Eingaenge (-> Port J5) muessen auf Masse gelegt werden! Ansonsten zu dem Thema, wie man merkt, ob MIOS korrekt aufgeladen wurde: an der Checksumme waehrend des Transfers, oder mit Hilfe des CRC-Tests (siehe MIOS->Download). Aber bei Dir ist wohl alles glatt gelaufen... Noch ein Tip: solange keine Motorfader angeschlossen sind, sollte das "ENABLE_MOTORDRIVER" flag in main.asm auf 0 gesetzt werden Gruss, Thorsten.

Dieses (geniale) Foto hast Du aber nicht mit einer digitalen Kamera gemacht, oder? Gruss, Thorsten.

Hi Erik, in theory you could control it via the debug SysEx protocol provided by MIOS itself (it allows you to execute any function - like MIOS_AIN_UnMuxed), but it's much simpler just to set the appr. option in the main.asm file of the MIDIbox64 application. Best Regards, Thorsten.

Far from it - they are the highlights of this forum! :-) Best Regards, Thorsten.

Since it turned out that KS0107/KS0108 based displays with 240x64 resolution are not available anymore, I'm thinking about an alternative way for controlling graphical LCDs without performance loss. It's clear that this requires a second microcontroller, but on the other hand the total-costs of this solution are less than I payed for my high-performance Displaytech 64240A. So, a conceptional (!) preliminary (!!) schematic can be found here: http://www.ucapps.de/mbhp/mbhp_lcd_companion.pdf The "companion core" will be connected via Port J15 of the MIOS core module. The parallel bus interface works asynchronous (Request/Acknowledge line), will provide double data rate (8 bit during the request phase, 8 bit after the acknowledge phase), and will support read and write transactions. Up to 8 companions will be addressable in this way, and it depends on the implementation how much displays can be connected to a single companion. ;-) However, MIOS will provide a generic bus protocol for this interface, and a 2nd layer protocol for graphical as well as for character displays. In this way, low-cost displays based on the polular T6963C can be connected to the MIOS core without performance loss, but also any other display - the companion core just has to process the protocol. (Sidenote: not only displays can be connected in this way, but any device which requires fast data transfers) (Sidenote2: see this posting http://www.midibox.org/cgi-bin/yabb/YaBB.cgi?board=concepts;action=display;num=1067480170 for a solution provided by Duggle which will be perfect for slow data rate peripherals) Important: this is a concept, which I will possibly realize next year. I cannot guarantee that it will work yet! The purpose of this posting is just to inform you about a possible solution before you purchase overpriced KS0108 based displays at EBay or wherever. Best Regards, Thorsten.

I already wrote this in a PM, but it could be interesting for everybody: The 7219 gives you no advantage compared to the already existing solution (http://www.ucapps.de/mios/leddigits_16.pdf) which will be integrated into the MIDIbox LC sooner or later. The 7219 is something like a serial 16 bit register with command interface. Two of them allocate 32 bits in a serial chain, and this is exactly the same number which is allocated by the leddigits_16 module. But the driver for a 7219 is totally different - and thats an disadvantage. So, the use of a 7219 makes only sense if enough pins are free to drive this serial chain seperately. And this isn't the case for MIDIbox LC (assumed that a KS0108 display is connected). Btw.: the driver is similar to that used by mbhp_aout Best Regards, Thorsten.

You can be sure that I would signalise a major hardware change which would make the old hardware obsolete at least one year before such a step ;-) Best Regards, Thorsten.

fixed Best Regards, Thorsten.

Hi Iain, programming a PIC16F628 with JDM & ICprog fails. I guess that this is an imperfection at the software side, since other chips are working ok JDM under Linux: I would also be interested in a solution! Vectorboard: I made my first JDM on a vectorboard, it was easy and still works w/o problems. I don't have a picture of the bottom right here (just only the small picture which can be found at the MBHP_JDM page), but the placement & routing is just a 1:1 copy of the schematic. Best Regards, Thorsten.

uclaros: thanks for the feedback - good to know that this implementation is flexible enough! :) Nat: this cannot be explained with one sentence, you will find the answers in the source code ;-) Best Regards, Thorsten.

Cool!!! :) Best Regards, Thorsten.

Hallo Andy, einen Softwarefehler kann ich nahezu ausschliessen - von solch einen Effekt hat noch nie jemand berichtet (aber nunja, irgendwann ist immer das erste mal...). Wie verhaelt sich der Core eigentlich im UnMuxed betrieb - sprich: wenn die Multiplexer deaktiviert sind und MIOS die 8 analogen Kanaele direkt convertiert? Dazu muss das main.asm File der MB64 wie folgt geaendert werden: #define DEFAULT_NUMBER_POTS 8 #define DEFAULT_MUX_ENABLED 0 Idealerweise sollten in diesem Fall 8 Potis an J5 angeschlossen sein, aber um die Stabilitaet der Conversion Results zu ueberpruefen, kannst Du jetzigen Verbindungen auch erstmal so lassen wie sie sind. Falls das nicht hilft, AIN Module abklemmen und Potis direkt anschliessen. Falls das immer noch nicht hilft, dann muss einfach irgendwo etwas falsch angeschlossen sein (ueberpruefe vor allem die Vdd und Vss Pins am PIC - und zwar gegen Masse sowie gegen +5V) Gruss, Thorsten.

Yes - workaround: the strings could be outsourced into a BankStick. With MIOS V1.4 data can be uploaded to all 8 BankSticks like common program code, but I haven't found the time yet to change this in the application. (Btw.: I'm currently building some new powerful sound features into the MBSID, based on suggestions from a real SID expert - stay tuned ;-)) Best Regards, Thorsten.

I've planned to improve this in the future (do avoid more questions regarding this topic ;-) Best Regards, Thorsten.

You could ask SmashTV :-) Best Regards, Thorsten.

Hrmpf! I didn't know that the MIDI remote implementation of Cubase SX is so imperfect... BUT: It's funny, I just realized that I already took care for forwarding the received value to the common LED state register: btfsc MB64E_CFG0, MB64E_CFG0_MIDILEDS, BANKED; only if MIDILEDS flag set andwf INDF0, F ; (MB64E_BUTTON_VALUES_SR0) andwf INDF1, F ; (MB64E_MBUTTON_VALUES_SR0) this means: a) the "MIDI LEDs" flag has another function in the MIOS implementation compared to the PIC16F firmware which has to be documented a) don't change the LED map, just enable the "MIDI LEDs" flag with vmidibox or the mk_syx script and it will work :) Best Regards, Thorsten.

Hallo Pearl, leider kann ich dazu erstmal nur eines sagen: "interessantes Phaenomen". Thomas T. hat mal aehnliches berichtet, er verwendet die SMD Version des PIC18F452 und konnte ebenfalls nichts in das interne Flash einprogrammieren, obwohl MIOS die korrekte Checksumme zuruecklieferte. Den aktuellen Status weiss ich nicht. Interessant waere auf jeden Fall, was nach dem Upload im Flash steht. Stecke den PIC nochmal in den JDM und lese das Flash aus - falls da nur einsen (FF FF F ...) drinnen stehen, weiss ich zumindest, dass bei Dir der gleiche Effekt aufgetreten ist. In diesem Fall kann ich nur vorschlagen, dass Du mir einen PIC mal zuschickst, so dass ich nach der Ursache suchen kann. Gruss, Thorsten.

Ein Multimeter wuerde schonmal weiterhelfen um festzustellen, ob die Spannung an den Potis wirklich konstant bleibt. Du verwendest sicherlich zwei AINX4 Module - hast Du hier schonmal die Versorgungsspannung direkt an den ICs ueberprueft? Wenn bspw. am Vdd Eingang keine +5V anliegen, kann es schonmal vorkommen, dass der 4051 trotzdem fuer eine Weile richtig funktioniert, weil er quasi indirekt ueber die Select-Leitungen versorgt wird. Doch sein Verhalten ist nicht mehr deterministisch und kann sich mit der Zeit aendern. Gruss, Thorsten.

Forum-Leser wissen mehr... ;-) Gruss, Thorsten.

Could you try the MIDImon application? It should display the correct BPM - if not, check your Cubase setup. Note that MIOS V1.4b is required to get this working! Best Regards, Thorsten.

Hi Wise, my suggestion: branch to another routine which handles the shift buttons seperately. Do nothing if the shift button is pressed. Loop through all "general purpose" buttons when the shift button is released and check the button status - MIOS_DIN_PinGet will return 0 when a button is hold down - in this case send the "off" status of the "old" layer and the "on" status of the "new" layer. Don't forget to have fun! ;-) Best Regards, Thorsten.

Hi LO, the first core should be assigned to device ID "00", the second to "01", etc... Why doesn't your core regognize the incoming SysEx blocks if it's assigned to another device ID: because the SysEx blocks are assigned to device ID 00 by default. So long as the Java GUI is not available, this means that you've to generate a new .syx file with the correct ID. See also: http://www.ucapps.de/mios_bootstrap.html Topic "Converting .hex to .syx", the last two snapshots For changing the device ID of mios_v1_4b.syx: see the README.txt file which is included in the .zip archive Best Regards, Thorsten.

Hi Christoffer, not the MIDI time code, but MIDI clock has to be sent by your application. Best Regards, Thorsten.