TK.

It always makes sense to output some values on a LCD, or just to send them out via MIDI to get some kind of logfile (here you only have to ensure that the MIDI protocol won't be violated - means: first byte should be a status byte like 0xF0, thereafter as much bytes as you want, but 7th bit should never be set (ensure this by masking it with 0x7f - the stream must end with a 0xf7) Best Regards, Thorsten.

Ever wanted to know the performance of your LCD? -> please find a benchmark in the MIOS Download section. From the header: ; ; LCD Performance Measuring Application ; ; This is some kind of benchmark which helps to evaluate the performance ; of various character and graphical displays, as well as the execution ; speed of a custom LCD driver ; ; 16 characters are print 4 times (-> 64 characters), the execution time ; is measured with timer3, prescaler 1:8 - this means, that the counter ; result has to be multiplied by 8 and 100 nS (@40 MHz) to get the ; absolute delay ; ; The result will be print on LCD, but also sent via MIDI ; (F0 <hex-digit 1> <hex-digit 2> <hex-digit3> <hex-digit4> F7, MSB first) ; ; And here the results: ; ; Displaytech LCDs from Reichelt: ; o 2x16 KS0070B (HD44780 compatible): 3252 * 8 * 100 nS = 2.60 mS ; o 2x20 KS0076B/KS0063 (HD44780 compatible): 3177 * 8 * 100 nS = 2.54 mS ; o 2x40 KS0076B/KS0063 (HD44780 compatible): 3056 * 8 * 100 nS = 2.44 mS ; o KS0107/0108 based 240x64 GLCD (sold out): 6124 * 8 * 100 nS = 4.90 mS ; ; For reference: 2x40 with 4-bit interface, nearly no difference! ; o 2x40 KS0076B/KS0063 (HD44780 compatible): 3108 * 8 * 100 nS = 2.48 mS ; ; Various displays: ; o Matrix Orbital via IIC: 4612 * 8 * 100 nS = 3.69 mS ; o T6963C in vertical mode: 10647 * 8 * 100 nS = 8.51 mS ; o T6963C in horizontal mode: 37420 * 8 * 100 nS = 29.93 mS (!!!) Have fun - and publish your results here! :-) Best Regards, Thorsten.

The pointer calculation part could be wrong (looks dangerous ;-) - why not initialising FSR0 with CHANNEL_GAIN_7 before the outer loop will be entered, and accessing the register with POSTDEC0, so that it will be decremented automatically (But I'm not sure if this is the error...) Best Regards, Thorsten.

Hi, yes, it should be 5V - maybe a short. Btw.: there is a better measuring diagram which can be found here: http://www.ucapps.de/howto_debug_midi.html Best Regards, Thorsten.

No, in the main.asm somewhere within the USER_Init function Best Regards, Thorsten.

No, too much effort... :-/ Best Regards, Thorsten.

Hi, DrBunsen: I will do what I can (and what the PIC18F is able to do ;-)) ok, here some news: although the code is very modular now, I noticed that the performance of the SEQ_CORE is much better than expected. The worst case processing time I measured was about 150 uS (microseconds!) when all 4 tracks are playing arpeggios simultaneously. In the last days I only made some small additions to the user interface (ca. 50% is implemented), but mostly was busy with tweaking on some nifty sequences (see also the bottom of this posting) - to check the usability and to get some ideas which features make the editing easier. Sometimes I'm also changing some previous concepts, e.g. in the meantime there is a 3rd version of the arpeggiator which is now more understandable, resp. more intuitional than the versions before Once the user interface is ready, I will think on features like Morphing (no problem), Grooves (needs some evaluation) and Chains (...of pattern), and so on... Concerning the chain mode: with some cut backs it could be possible to play 4 patterns at the same time, in other words: to play 16 tracks. Drawback: only one pattern can be hold in the edit buffer and modified live, the other 12 tracks have to be played directly from BankStick. A good compromise for a simple step sequencer, isn't it? :) Ok, and here some impressions about the current design state (I don't work daily on it, only when I have some sparetime and feel motivated, so I cannot say you anything about the date of the first release): Some panel views (will be enhanced by more views): Ok, and here some auditable results for people who maybe don't know what they can expect from a simple step sequencer :) Very experimental (the original is about 3 hours long, but I forgot to record it ;-)), many Fx have been added, some of them are also controlled from the MBSEQ via CCs. all patterns made with MBSEQ and recorded with Logic whenether they worked (means: the MBSEQ doesn't play the whole song - yet) http://www.midibox.org/midibox_seq/mbseq_v2_demo1.mp3 Just an arpeggiator test, nothing more - edited within 5 minutes, played some random chords and took the best ones ;-) Only the lead sound is controlled from MBSEQ (you hear the MIDIbox SID in action :)), the drums are comming from my Groovebox which acts as MIDI clock master in this example. http://www.midibox.org/midibox_seq/mbseq_v2_demo2.mp3 Best Regards, Thorsten.

Do you have access to the MIDI Out of the slaves? Then you could use the CRC application to ensure that MIOS has been uploaded correctly, just add following lines to USER_Init: movlw 0xf0 call MIOS_MIDI_TxBufferPut swapf CRC_H, W andlw 0x0f call MIOS_MIDI_TxBufferPut movf CRC_H, W andlw 0x0f call MIOS_MIDI_TxBufferPut swapf CRC_L, W andlw 0x0f call MIOS_MIDI_TxBufferPut movf CRC_L, W andlw 0x0f call MIOS_MIDI_TxBufferPut movlw 0xf7 call MIOS_MIDI_TxBufferPut and MIOS should return the CRC digits after startup (see also the download page - MIOS V1.5b returns: F0 06 0F 05 0D F7 Best Regards, Thorsten. /edit: new version now available in the download section

Dan, your designs alway have a special touch - great :) Best Regards, Thorsten.

Hallo, die Analyse mit dem Oszi hat folgendes ergeben: Der Update des gesamten 2x20 Displays dauert ca. 800 uS (bei einem 2x40 HD44780 Display ca. 1.6 mS), die Abarbeitung von CS_MENU_UpdateCCPara ca. 1.2 mS. Doch damit nicht genug: in CS_MENU_UpdateCCPara wird faelschlicherweise ein zweiter Display Update requested, und der wird dann ca. 200 uS spaeter zusaetzlich abgearbeitet. Das bedeutet, dass bei einem 2x40 Display die eintreffenden CCs ein Delay von mindestens 2.8 mS + 1.6 mS erzeugen. Falls zwischendurch erneut ein CC eintrifft (was innerhalb dieser langen Zeitspanne durchaus moeglich ist), wird erneut ein Update erzwungen, und dieses unregelmaessige Verhalten kann durchaus zu einem hoerbaren Jitter fuehren. Abhilfe: in "CS_MENU_UpdateCCPara" den unnoetigen DISPLAY_UPDATE_REQ rausschmeissen, so dass schonmal 1.6 mS eingespart werden den unteren Teil von SID_MIDI_CC wie folgt aendern: #if CS_ENABLED == 1 IFCLR CS_MENU_MODE, CS_MENU_MODE_EDIT, rgoto SID_MIDI_CC_NoUpdate ;; request update of CS parameters bsf CS_STAT, CS_STAT_UPDATE_PARAMETERS ;; force a display update bsf CS_STAT, CS_STAT_DISPLAY_UPDATE_REQ SID_MIDI_CC_NoUpdate #endif Vorteil: zero delay, Nachteil: die im CS gespeicherten Parameter koennen nur noch im Edit Modus von extern veraendern werden - das ist aber verkraftbar. Bleiben noch zwei weitere Aenderungen, die ich dann demnaechst einbauen werde: - einen speziellen Update Request, der lediglich die untere Zeile updated, um das Delay auf 400 uS zu minimieren. Die Uebertragung eines einzelnen MIDI Events dauert 1 mS, die LCD Ausabe wird sich nicht mehr bemerkbar machen - viel mehr Aufwand ist an dieser Stelle also gar nicht notwendig. - beim Wavetable-Sequenzer werde ich das WT_STATE_NEXT flag durch einen Counter-Mechanismus ersetzen, so dass er niemals aus dem Takt kommt. Diesen Mechanismus habe ich mittlerweile auch in die MBSEQ eingebaut, sie laeuft nun selbst nach einer Stunde noch synchron zur Masterclock. Soviel zu diesem Thema... ;-) Gruss, Thorsten.

Hello again, ja, Du kannst Encoder an die MIDIbox64 anschliessen, dazu muesstest Du jedoch den Source Code leicht modifizieren. Siehe auch: http://www.ucapps.de/tmp/mios_enc_integration.txt Gruss, Thorsten.

Hallo Martin, das sollte eigentlich mit SFB #02 [00-0F] problemlos funktionieren. Siehe auch: http://www.ucapps.de/midibox/midibox64_sfb_table.txt Scheinbar hast Du SFB #00 01 verwendet? Gruss, Thorsten.

Das mit dem USE_GLCD flag schaue ich mir irgendwann einmal an... Ja, die SID Applikation geht noch davon aus, dass es sich bei LCDs mit ID > 0 grundsaetzlich um ein graphisches LCD handelt. Deshalb gibt es nun das USE_GLCD flag, aber es wird so noch nicht funktionieren, das ganze befindet sich wie gesagt in Vorbereitung und wird vielleicht ab MIOS V1.6 oder spaeter in voller Schoenheit funktionieren (Prioritaet: ziemlich niedrig, zumal die Applikationen daran angepasst werden muessen) Das mit dem Busy hast Du wie bereits erwaehnt falsch verstanden. Es geht hier nicht darum, Zeichen zu unterdruecken, sondern eher darum, dass MIOS nicht in einer Endlosschleife haengen bleibt, wenn mal zufaellig kein LCD angeschlossen ist. Buffern: das moechtest Du nicht wirklich! Die MIDIboxSEQ kann bspw. 2x80 Zeichen darstellen, das sind 160 Byte, die kann man fuer schoenere Dinge verwenden. Das Control Surface der MBSEQ habe ich uebrigens etwas geschickter programmiert, hier werden nur die Items upgedated, die sich wirklich geaendert haben. Optimiert und verifiziert habe ich das ganze mit einem Oszilloskop (ein Item-Refresh dauert ca. 200 uS). Den Aufwand koennte ich auch irgendwann einmal fuer die MIDIbox SID treiben, aber nicht heute, und auch nicht in den naechsten 1-2 Wochen, aber vielleicht danach? Schaunmer mal... das waere jedenfalls der bessere Weg. Echtzeit: hier uebersiehst Du, dass die Echtzeit-Tasks jederzeit die Display-Ausgabe unterbrechen koennen, deshalb braucht die Ausgabe auch manchmal etwas laenger. Wenn es soweit kommt, dass andere Low Priority Jobs (wie bspw. der Wavetable-Handler) zu lange warten muessen, geht man normalerweise her und splitted die Display-Ausgabe in zwei oder mehrere Teiljobs, die dann mit jedem USER_Tick alternierend ausgefuehrt werden. Dies waere eine Loesung, wenn sich der Display-Inhalt komplett aendern wuerde, aber bei der MBSID ist es ja nur ein kleiner Teilbereich, deshalb wuerde sich hier die gleiche Methode wie bei der MBSEQ besser eignen. Du schreibst: mit der DISPLAY_UPDATE_REQ Methode wird so etwas aehnliches bereits gemacht. Es wird nicht sofort refreshed, sondern nur dann, wenn CS_MENU mal wieder dran kommt. Und das ist auch normalerweise ausreichend, solange die Displayausgabe < 1 mS dauert. Wenn bspw. viele MIDI Events aufeinmal eintreffen, arbeitet MIOS_MPROC erstmal den gesamten Buffer ab, bevor USER_Tick aufgerufen wird. Du verwendest ein 2x40 Display, hier dauert die Ausgabe doppelt so lange. So habe ich die MBSID noch nicht betrieben, und deshalb ist mir dieses Performanceproblem auch noch nicht so bewusst geworden. Ich verwende auch normalerweise kein Modwheel, sondern aendere die Parameter direkt am Control Surface... Aber wie ich bereits oben schrieb, gibt es geschicktere Methoden, das auszumerzen, allerdings kann man das nicht in 5 Minuten erledigen, sondern muss gezielt die Timings mit einem Oszi ausmessen und dort optimieren, wo es wirklich Sinn macht. Wenn ich mal nichts besseres zu tun habe (vielleicht hast Du ja mitbekommen, woran ich gerade bastle...) werde ich mir das mal anschauen. Companion: das ist die Loesung speziell fuer sehr langsame LCDs (insbesondere fuer die billigen graphischen LCDs), bei der die Befehle in einem grossen Buffer aufgefangen werden. Aber Dir waere wohl dann mit der Aenderung im MBSID CS_MENU bereits geholfen - abwarten und Tee trinken. Update ausbauen: klar, kannst Du machen, siehe sid_midi.inc, SID_MIDI_CC - dort stehen die beiden Update Requests. Schmeiss die mal raus, dann sollte das MOD-Wheel keine Auswirkungen auf das Timing haben. Du koenntest dieses Verhalten auch ueber einen zusaetzlichen Button steuern, wie waere es bspw. mit dem "CS_MENU_MODE, CS_MENU_MODE_EDIT" flag? Wenn es nicht gesetzt ist, einfach die beiden Befehle ueberspringen. Ich sehe uebrigens gerade, dass dort "CS_STAT_UPDATE_PARAMETERS" gesetzt wird - das ist evtl. der eigentliche Uebeltaeter, muesste ich auch mal mit dem Oszi ausmessen und gegenenfalls auf Zeit (und nicht auf Codegroesse) optimieren Aber wie ich bereits angedeutet habe: momentan liegen meine Prioritaeten woanders. Ich betreibe meine MBSID gerade mit der MBSEQ, da benoetige ich keinen Wavetable-Sequenzer ;-) Gruss, Thorsten.

Great! So sorry for all the trouble, till yesterday I was very sure that especially the MIDI Rx handler is 100% bugfree (ok, it was before MIOS V1.4 ;-)) and therefore assumed an hardware problem - such errors are very common when existing code will be extented after so long time and when no testsuite exists which covers all functions to ensure that they are behaving like before the changes. Note: the final MIOS V1.5b is different from yours, please use the released binary to avoid confusion if anything should fail again Best Regards, Thorsten.

How does it behave when you just solder the D6 input to another button? Best Regards, Thorsten.

Since I had to release a new MIOS version anyhow, I added some code which is necessary to access a 4bit display. Just use mios_v1_5b (or higher) and add following lines below USER_Init: ;; use a CLCD, E input of first CLCD at D.7, E of second CLCD @C.4 ;; using the 4-bit interface: ;; -> connect MBHP_CORE:J15:D7-D4 of the core module to D7-D4 of the LCD ;; -> left MBHP_CORE:J15:D3-D0 of the core module open! ;; -> tie D3-D0 of the LCD to ground movlw 0x37 | 0x80 ; E1: D.7, 4bit interface movwf MIOS_PARAMETER1 movlw 0x24 | 0x80 ; E2: C.4, 4bit interface movwf MIOS_PARAMETER2 movlw 0x00 ; LCD type 0 call MIOS_LCD_TypeSet It doesn't matter if you connect a second display or not to the core, this is just an excerpt from the MIOS_LCD_TypeSet example... Best Regards, Thorsten.

This "service pack" adds support for CLCDs with 4bit interface and contains an important bugfix for the MIDI receiver in conjunction with keyboards which are sending MIDI events in Running Status mode See also: http://www.ucapps.de/mios_changelog.html There is no new source code package, but the changes are available in the CVS Best Regards, Thorsten.

Hi Dan, strange - did you ensure that you've uploaded the change correctly? Or better: could you please check this MIOS version in your environment http://www.ucapps.de/tmp/mios_v1_5b.syx.zip Best Regards, Thorsten.

Hallo, das MIOS_BOX_CFG0_USE_GLCD Flag hat eigentlich (noch) gar keine Bedeutung. Ich habe es erst in MIOS V1.5 eingebaut und werde es im Laufe der Zeit auch in den Applikationen verwenden. Diese konnten bisher nur ueber den Display Type feststellen, ob ein CLCD oder GLCD angeschlossen ist. Weil aber ein User LCD auch ein CLCD sein kann, und weil es spaeter auch mal eine Companion Chip Loesung fuer GLCDs, die quasi ein CLCD emulieren, geben wird, hielt ich diese Loesung fuer angemessen. Wann ist ein CLCD ein CLCD: wenn es die Moeglichkeit gibt, 8 Sonderzeichen gemaess der HD44780 Spec zu uebergeben. Das ist bei Deinem Display nicht der Fall. Die SID Applikation verwendet momentan noch ein internes GLCD Flag, aber wie sich das auswirkt, schaust Du Dir lieber im Source Code an, das schreibe ich hier jetzt nicht auf... (schau einfach in das main.lst, dort befindet sich der gesamte Code) TIMEOUT1/TIMEOUT2 ist ein 16-bit counter, der dafuer sorgt, dass der LCD Driver deaktiviert wird, wenn kein Display angeschlossen ist. Mit Performance hat das nichts zu tun. Xe: was meinst Du mit Durchschalten? Es gibt durchaus Performance-Engpaesse in der MIDIbox SID, bspw. wenn ein Patch fuer einen (oder mehrere) SID Slaves umgeschaltet wird, oder wenn viele CC's gleichzeitig eintreffen und verarbeitet werden muessen. Das kann man aber nicht aendern, bedenke was da staendig im Hintergrund laeuft (die SID Engine sid_sw.inc ist so etwas wie ein virtueller Synth, und die ganzen DIN/DOUT Shiftregister wollen auch zuverlaessig versorgt werden) und dass die Slaves ueber MIDI mit Daten gefuettert werden (das Versenden eines Patches dauert ca. 250 mS!) - die einzige saubere Loesung waere hier, einen separaten PIC fuer das Control Surface herzunehmen, jeden Slave mit einem eigenen BankStick zu bestuecken und die Kommunikation nicht ueber die MIDI Schnittstelle laufen zu lassen - aber ihr wollt es ja immer billig ;-) Gruss, Thorsten.

PayC: Does it only happen when you connect a keyboard to your SID master? Could somebody please check if the mentioned IRQ_TMP2 workaround does help? If so, I will release a new MIOS version with fixed MIDI receiver, so that this workaround is not required anymore. Best Regards, Thorsten.

The ground connection is the problem, think about how the voltage regulation unit of the NanoVerb is built, and from where it gets its ground. Measure the NanoVerb ground against the SID ground, it must be between 5V and 14V, no? Once you connect both grounds together, you will shorten the PSU. I see now proper way to solve this with the optimized PSU circuit. How does the PSU of the NanoVerb looks like? Best Regards, Thorsten.

Kaum ist ein Tag vergangen, habe ich schon wieder das ARP Konzept geaendert. Das was vorher in den 16 Styles festgelegt war (die Zuordnung der Akkordnoten auf die 16 Steps) kann man nun frei zuweisen. Jeden einzelnen Step kann man zusaetzlich um -8 bis 7 Okatven transponieren - in der Praxis kommt man so schnell zum Erfolg :) Gruss, Thorsten (schraubt jetzt weiter)

Hallo, Da stimmt etwas mit etwas mit dem JDM nicht. Selbst wenn Dein Mainboard nur mit einem schwachen RS232 Treiber bestueckt waere, muesste die Spannung am MCLR# immer noch >10V sein Gruss, Thorsten (ist diese Woche ebenfalls auf XP umgestiegen)

Ok, bug found :) All applications which are using the USER_MIDI_NotifyRx hook and which are overwriting IRQ_TMP1 are affected. This register is also used by the MIDI receiver to save the received byte - the routine is so old, that I have overseen this, in the meantime nearly all MIOS routines are using internal temporary registers, so it's time to do the same for the MIDI receiver. ;-) Quick Bugfix: open sid_rxtx_midi.inc and replace IRQ_TMP1 by IRQ_TMP2 I will provide a proper solution (new MIOS release) tomorrow. Best Regards, Thorsten.

Alright - slowly but surely I believe that this is --> a MIOS BUG <-- concerning the so called "running status". This could explain, why the MIDIbox of Doc runs correctly when he uses the MIDI merger, because all PIC16F based firmwares can handle the running status correctly, for MIOS I haven't tested this for a long time I will check this Best Regards, Thorsten.