VFD Türkis 2x40 / Netzteilfragen SID

[seppoman]

Hallo,

ich habe letzte Woche erst dieses Projekt entdeckt und nach einer Website-Schmöker-Nacht beschlossen, mir eine MidiBox SID zu bauen. Jetzt habe ich mir folgendes Display ersteigert:

http://cgi.ebay.de/ws/eBayISAPI.dll?ViewItem&item=3064807223

Das ist ein Futaba 2x40 VFD Display, für 21 Euro (sind übrigens noch 20 Stück verfügbar

Ich will das Gerät per “C64 PSU optimized” versorgen.

• Da ein VFD wohl bis zu 500 mA braucht, soll ich das Display dann über den regulären Anschluß versorgen, oder lieber direkt vom 64er Netzteil? Nachdem der 7805 nicht bestückt wird, kann ich diesen ja eigentlich nicht überlasten. Aber evtl. T1 bei der Helligkeitsregelung, oder ist das nur eine Steuerleitung ohne Stromfluß?

• Kann man sich im Rest der Core-“Netzteil”-Abteilung (also C3-6 und der Gleichrichter) bei Verwendung des C64-Netzteils nicht auch alles außer C5 sparen oder doch lieber normal bestücken, um bessere S/N zu erreichen?

• Produziert ein VFD irgendwelche Einstreuungen, die man abschirmen müßte?

Hoffentlich sind keine allzudoofen Fragen dabei, mein Halbwissen im Elektronikbereich ist noch ausbaufähig

Danke,

Seppoman

[T.K]

Hallo Seppoman,

am besten schliesst Du es direkt an das 64er Netzteil an. Wie Du schon richtig vermutet hast, wuerde es den T1 ueberlasten. Er steuert den Strom. Eine Helligkeitsreglung via PWM kann ich nicht empfehlen, dadurch entsteht Jitter an den analogen Eingaengen (und speziell beim SID: extremer Audio-Noise)

VFD Einstreuungen: keine Ahnung, habe solch ein Display noch nie betrieben. Vielleicht weiss jemand anderes mehr?

Bestueckung: 7805 und Gleichrichter weglassen, C6 ist ohne den 7805 nicht notwendig, tut aber auch nicht weh. C5 drauflassen und mit der 5V-Leitung verbinden.

Gruss,

       Thorsten.

[seppoman]

Hallo Thorsten,

erstmal Danke für Deine Antwort. Ich hab über Weihnachten fleißig gelötet, Montag kamen auch endlich die PICs aus Taiwan, und die ersten Töne kamen schon raus

Heute hab ich mich mit dem VFD beschäftigt (riesiges Teil übrigens, Gesamtbreite mit Platine 25 cm…). Nur leider bekomme ich nichts vernünftiges angezeigt. Der Cursor bewegt sich nach dem Einschalten nur ein Zeichen nach rechts und das wars. Die Belegung ist allerdings auch anders benannt, hoffentlich ist das Teil überhaupt kompatibel?

D0-D7 sind vorhanden, dann noch WR, SEL und BUSY. Ich hab das Ganze mal so verbunden:

RW -> WR

RS -> SEL

E -> BUSY

Enable und Busy kam mir sowieso komisch vor, deshalb hab ich das auch mal abgeklemmt (ein paar zufällige Zeichen, wohl zu schnell Daten bekommen), Select hab ich High und Low gesetzt, bringt aber alles nichts.

Seriell (mit 5V Signal) könnte man das Display auch noch betreiben, der I2C-Anschluß wird aber wohl ungeeignet sein (I2C ist wohl ein Bus und das VFD hat für seriell nur RXD und Busy).

Das Modul hat einen Toshiba TD62C950RF Chip drauf, über den ich im Netz nichts finde.

Ein Datenblatt fürs Nachfolgemodell (?) habe ich gefunden: http://www.futaba.com/display_modules/vfd_products/pdfs/M402SD07JJ.pdf

Hab ich überhaupt Chancen, das Display zu verwenden, oder muß ich damit unfreiwillig unter die Case-Modder gehen? )

Vielen Dank,

Seppoman

[T.K]

Super, dass Du schon etwas hoerst.

Aber mit dem sehen - hm - das VFD hat im Vergleich zu einem Standard Display ein voellig anderes Bus Interface. Es kann kein Read, stattdessen muss man die Busy-Leitung pollen. Auch die Kommandos - bspw. zum Setzen des Cursors - sehen voellig anders aus.

Mit MIOS kann man solch ein Display ueber einen “Custom LCD Driver” ansteuern (siehe die app_lcd* Beispiele), aber um die Programmierung muesstest Du Dich selber kuemmern…

Gruss,

       Thorsten.

[seppoman]

Hallo Thorsten,

danke für die schnelle Antwort

Das hab ich schon befürchtet. Meinst Du, es ist einfacher, das VFD seriell oder parallel anzusteuern? Oder gibt es evtl. eine Möglichkeit, mit ein paar Bauteilen dazwischen den seriellen Anschluß nach I2C zu konvertieren, und dann einfach den I2C-Treiber zu benutzen?

Ich hab mir gerade das MPLAB heruntergeladen und werde versuchen, erstmal den vorhandenen Treiber zu verstehen - von Assembler hab ich bisher noch wenig Ahnung (ein paar nette Spielereien mit Lauflichtern haben wir mal in der FH programmiert, aber das war alles kürzer als 20 Befehle … )

Hast Du evtl. ein paar Links, bei denen ich mich zum Thema Parallelport-Handling usw. einlesen könnte?

Vielen Dank,

Seppoman

[T.K]

Wahrscheinlich ist der parallele Treiber am einfachsten zu programmieren. Morgen veroeffentliche ich den Source Code zu MIOS, darin findest Du den CLCD Treiber, den Du als Vorlage hernehmen kannst. Viel muss nicht geaendert werden, lediglich das Polling –> vereinfacht! <– sich!

Sonderzeichen werden von diesem Display wohl nicht unterstuetzt, deshalb koennen die huebschen Bargraphs nicht angezeigt werden.

Gruss,

       Thorsten.

[T.K]

Du findest den CLCD Treiber nun auch als “Custom Driver” in der MIOS Download Section.

Was muss geaendert werden - an der Hardware:

TEST# auf +5V klemmen

SEL# mit der Enable Leitung verbinden

WR# mit R/W

Busy mit R/S – vorsicht: hier einen 100 Ohm Widerstand in Serie schalten, damit es waehrend des Bootens keinen Kurzschluss gibt (Busy ist ein Ausgang). Ausserdem wuerde ich noch einen 10k Pull-Down vorsehen, damit der Core weiterlaeuft, falls das Display mal nicht angeschlossen ist

Software:

In der Initialisierungsroutine den R/S Pin auf TriState (Input) setzen:

bsf TRISD, USER_LCD_PIN_RS

Der restliche Initialisierungscode fliegt raus, weil sich das Display selbst initialisiert

USER_LCD_Data: “Select Data Register” fliegt raus. Da es nur einen Datentransfermodus gibt, und die Zeichen < 32 Steuerzeichen sind, wuerde ich die Routine so umschreiben, dass nur Zeichen >= 32 uebertragen werden. Ansonsten gibt das Display wohl hin und wieder wirre Zeichen aus, oder macht gar nichts mehr

USER_LCD_Cmd: hat bei Deinem Display eine voellig andere Bedeutung. Ich wuerde die Routine so umschreiben, dass sie lediglich Zeichen < 32 uebertraegt

USER_LCD_WaitUnbusy: dieser Code wird schlicht und einfach durch folgenden Ersetzt:

USER_LCD_WaitUnbusy
        IFSET   PORTD, USER_LCD_PIN_RS, rgoto USER_LCD_WaitUnbusy
        return

USER_LCD_Strobe_Set und USER_LCD_Strobe_Clr:

hier muss die Polaritaet geaendert werden, da SEL# ein Low-Aktives Signal ist. Aus “bcf” wird “bsf”, aus “bsf” wird “bcf”

USER_LCD_Clear: hier muss das entsprechende Steuerkommando an das LCD gesendet werden

USER_LCD_CursorSet: dito

Gruss,

       Thorsten.

[seppoman]

Hi Thorsten,

tausend Dank für die ausführlichen Infos Ich habe gestern abend schon den MIOS Quellcode runtergeladen und die ganze Nacht mit der PIC-Assembler-Referenz und der CLCD Routine verbracht. Zumindest teilweise verstehe ich glaube ich, was da passiert. Mit Deinen Tips hast Du mir aber wohl mindestens 1-2 Tage Nachdenken erspart

Wegen Initialisierung: Laut Datenblat ist das Display nach dem Einschalten in Vertical Scroll mode mit aktiviertem Cursor. Wird das Display sowieso wo anders auf Normal ohne Cursor gesetzt, oder muß ich das doch hier machen?

Naja, ich werd mich heute Abend mal ausführlich damit beschäftigen und weiter berichten

Viele Grüße,

Seppoman

[seppoman]

Hallo,

so, nach einer langen Nacht geht das Ganze jetzt einigermaßen. Das Einzige was noch nicht richtig funktioniert, ist die Cursor-Positionierung.

---

USER_LCD_CursorSet

     movlw      0x10                    ;Cursor positionieren

     call      USER_LCD_Cmd

     SET_BSR      MIOS_LCD_CURSOR_POS

     movf      MIOS_LCD_CURSOR_POS, W, BANKED

     cpfsgt      0x3F

     call USER_LCD_CursorSet_Y1, 1

     rgoto      USER_LCD_Cmd

USER_LCD_CursorSet_Y1

     andlw      0x3F

     addlw      0x28

     return 1

---

Hierbei wird die zweite Zeile nicht korrekt verarbeitet. Weshalb die 1 bei call/return sein muß, weiß ich nicht, geht ja sonst auch ohne, aber hier Chaos. Mit 1 kann man in der ersten Zeile positionieren, die zweite ist aber falsch - das Display zählt in der zweiten Zeile direkt weiter, 28h ist also das erste Zeichen.

Wenn ich z.B. auf (MIOS)Zeichen 40h will, springt das Programm in die Unterroutine (hab ich überprüft), ändert aber anscheinend trotzdem nichts an der Positionsadresse, d.h., das Zeichen erscheint bei 40h nach Zählung des Displays. Was irgendwie komisch ist, denn selbst wenn ich in der Y1-Routine einen Denkfehler hätte, irgendwas müßte sich trotzdem ändern. Hast Du ne Idee?

Zu den Sonderzeichen: Das VFD kann auch selbstdefinierte Zeichen. Kann man die über den Custom-Treiber auch einbinden, oder müßte ich dafür die CLCD-Routine direkt ändern?

Und gleich noch ne Frage: Seitdem ich das VFD dran habe (hatte vorher testweise ein kleines LCD) zeigt mir MIDI-OX immer beim Einschalten ein Bündel beliebiger MIDI-Daten (Noten, Controller, Realtime usw.). Das Display produziert also wohl beim Start irgendwelche Störungen. Kann man die mithilfe von z.B. einem dicken Elko an der Display-Versorgung vermeiden?

So, nachdem die Nachbarn schon wieder wach werden, muß ich doch mal Schlafen gehen

Viele Grüße,

Seppoman

[T.K]

Also irgendwie sieht das ganz seltsam aus, weder call noch return erlauben ein zweites Argument. Der Assembler scheint an dieser Stelle wohl etwas zu tolerant zu sein.

Ich nehme an, dass diese Funktion alle Zeichen ab 0x40 nach 0x28 mappen soll. Das koennte man auch so schreiben:

USER_LCD_CursorSet
      movlw      0x10
      rcall      USER_LCD_Cmd

      SET_BSR      MIOS_LCD_CURSOR_POS
      movf      MIOS_LCD_CURSOR_POS, W, BANKED

      BIFSET      MIOS_LCD_CURSOR_POS, 6, BANKED, addlw -(0x40-0x28)

      rgoto      USER_LCD_Data

Der Trick: in der zweiten Zeile ist Bit 6 gesetzt - das BIFSET macro (dahinter steckt die btfsc Instruction) tested dieses Bit und zieht 0x18 (0x40-0x28 ) davon ab - so wird aus 0x40 eine 0x28

Sonderzeichen: Du koenntest in mios_vectors.inc “MIOS_CLCD_SpecialCharInit” und “MIOS_CLCD_SpecialCharsInit” auf Deine eigenen Funktionen umlenken

Vermeiden der Stoerungen waehrend des Einschaltens: dazu kann ich nicht viel sagen, ich habe noch nie mit einem VFD gearbeitet, weiss nicht, wie das mit der Stromaufnahme ausschaut. Vielleicht ist auch einfach nur Dein Netzteil zu schwach, so dass es waehrend des Einschaltens zu einem kurzen Spannungseinbruch kommt.

Gruss,

     Thorsten.

[seppoman]

Hallo Thorsten,

Vielen Dank, mit Deinem Code funktioniert das Ganze wunderbar

Zu meiner Routine:

Laut PIC-ASM-Referenz im Datenblatt erlauben call/return einen zweiten Parameter:

Syntax: [label] CALL k [,s]

[…] If ’s’ = 1, the W,

STATUS and BSR registers are

also pushed into their respective

shadow registers, WS, STATUSS

and BSRS. If ‘s’ = 0, no update

occurs (default). Then, the 20-bit

value ’k’ is loaded into PC<20:1>.

Bei return genauso.

So ganz verstehe ich die ganze Register/Adressierungs-Geschichte nicht, aber ich hatte den Eindruck, daß irgendwie WREG nicht vernünftig verarbeitet wird, und die 1 dazu bringt das Ganze wenigstens irgendwie zum Laufen…

Warum das weder mit noch ohne 1 geht, verstehe ich nicht.

falls W > 3F, sprung, dort den Teil unter 40 holen und 28 dazu

Wenn W z.B. 40h ist, müßte andlw 0x3F -> W=0 ergeben. 28h dazu -> 1.Zeichen 2. Zeile…

Naja, ist nicht so wichtig, mit der BIFSET-Lösung ist ja alles OK. Die Subroutine hab ich auch nur gebaut, weil ich nicht wußte, wie man mit einem einzigen Befehl einen Wert abzieht, da die subXX-Befehle ja immer W von etwas abziehen und nicht umgekehrt…

Sonderzeichen: Wie funktioniert das mit den Vektoren, bzw. woher weiß ich, wohin der Vektor zeigen muß? (wie gesagt, mit der ganzen Speicherverwaltung kenne ich mich noch nicht aus)

Wegen Netzteil: Ich verwende C64-PSU-Optimized. Momentan hängt daran außer dem VFD nur der Core und eine SID-Platine. Interessanterweise gibt es keine Random-Events, wenn man beim SID-Modul die 14V-Leitung abklemmt, auch nicht, wenn ich das zweite SID-Modul auch noch mit 5V anschließe. Das C64-Netzteil hat 1,5 A bei 5 V, Das Display zieht max. (also wohl beim Einschalten) 1 A. nur 1 Core und 1 Sid werden keine 500 mA brauchen?

Viele Grüße,

Seppoman

[seppoman]

Hi Thorsten,

Noch eine Frage (sorry wenns langsam etwas viele auf einmal werden…):

Ich versuche gerade, den Treiber in die SID-Applikation einzubauen. habe app_lcd getauscht. PIC ID sowohl mit Typ 0 als auch Typ 7 gesetzt. MIOS 1.5 unverändert hochgeladen. In SID sowohl mit als auch ohne

USER_INIT

     movlw      0x07

     call      MIOS_LCD_TypeSet

probiert.

und bekomme nur entweder wirres Zeug (wohl wenn typ0 oder auto) oder MIDI-Display per SysEx.

Woran liegt das, hab ich was vergessen?

Vielen Dank,

Seppoman

[T.K]

Der Stromverbrauch von Deinem Display ist ziemlich hoch, nunja… musst Du mal ein wenig herumfrickeln.

Vektoren: ersetze “EQU <MIOS-addresse>” einfach durch ein “EQU <USER_LCD-adresse>”. Du musst die Adresse nicht als Zahl angeben, hier reicht auch das Label

Hast Du das “, 1” hinter den call und return Befehlen mittlerweile entfernt? Mir ist eingefallen, warum ich diese Option aus meinem Hirn geloescht habe - weil man sie innerhalb einer MIOS Applikation niemals anwenden sollte

MIOS verwendet bereits die Shadow-Register fuer den schnellen Kontextswitch bei Interrupts. Wenn Deine LCD Routine nun die Shadow-Register ueberschreibt, kracht es, sobald ein Interrupt die Displayroutine unterbricht.

Weil ich Deinen Code nicht kenne, kann ich ansonsten nur noch raten - vielleicht verwendest Du TMP1? Sollte innerhalb eines Treibers aber niemals eingesetzt werden - nur die die im Header angegebenen Register sind erlaubt, es gibt spezielle temporaere Register fuer den Display Driver (MIOS_GLCD_TMPx)

Gruss,

       Thorsten.

[seppoman]

Hi Thorsten,

ich bastle weiter am Treiber-Einbinden herum, ohne Erfolg. Jetzt wollte ich versuchen, in MIOS den CLCD-Treiber einfach direkt anzupassen. Compilieren konnte ich das MIOS, aber das hex2syx hat mit folgendem Fehler abgebrochen:

You are trying to overwrite the MIOS adress range.[..]

Ich hab jetzt mal versucht, einfach den Original-Quelltext zu compilieren, mit dem gleichen Ergebnis. Ist da in Deinem Release noch irgendein kleiner Fehler, oder mache ich was falsch?

Bis dann,

Seppoman

---

Edit:

durch die Frage von psytron in Latest News bin ich selber draufgekommen  : Ist natürlich klar, daß, wenn man MIOS hochlädt, man den MIOS Adress Range überschreibt. Peinlich, peinlich

Der Treiber funktioniert wunderbar, einzige kleine Macke: beim Durchschalten der Patches flackern in der ersten Zeile manchmal kleine “x” an den Stellen vor den Zahlen auf. Werd mir mal die CS_MENU-Routinen anschauen, ob diese iXe auch so gesendet werden und mein Display einfach träger als normal ist, oder obs doch noch irgendwie am Treiber liegt. Für Sonderzeichen hab ich provisorisch einfach x00 und x01 auf die ASCII-Symbole “Doppelpfeil” umgelenkt, da das allgemeingültig-MIOS-konforme Definieren von Zeichen etwas aufwendig ist - Das VFD hat nur 5x7 Pixel, also müßte man erstmal die Tabelle umwandeln, und die Pixel werden verschachtelt übertragen, also erstes Byte ist Zeile 1[1..5],Zeile 2[1..3] usw. Die SID-Applikation gibt ja sowieso nur die Pfeile aus, und dafür reicht << und >> erstmal.

Trotzdem wäre es natürlich gut, den Treiber als User LCD einbauen zu können, damit man

1. nicht bei MIOS-Updates jedesmal im Code rumpfuschen muß und

2. der Treiber genauso wie die anderen Custom Treiber einzubinden ist - wenn ich alles fertig habe, wäre es wohl schon für den einen oder anderen nützlich, wenn der Treiber hier in die Sammlung aufgenommen würde und dann nicht alles anders ist als sonst.

Warum wird bei MIOS_LCD_Cmd und MIOS_LCD_Data eigentlich bei Typ 7 nicht USER_LCD_Cmd/Data aufgerufen? Wenn ich das richtig sehe, macht _Cmd bei Typ6 und Typ7 gar nichts, _Data nur bei Typ7 nichts? Wobei das ja eigentlich nicht der Grund für die fehlende Ausgabe bei der SID-Applikation sein kann, denn bei der CLCD7-Beispiel-Applikation gehts ja auch.

Jedenfalls Langer Rede Kurzer Sinn: Wie integriere ich einen Custom Treiber in die Applikation, so daß er auch wirklich verwendet wird und nicht das MLCD aktiviert wird?

Vielen Dank,

Seppoman

[T.K]

Kannst Du mir mal das geaenderte mios_clcd.inc zuschicken? Dann mache ich Dir ein app_lcd.inc daraus.

Warum es kein USER_LCD_Data und USER_LCD_Cmd gibt? Weil die Bedeutung je nach Display-Typ voellig verschieden ist.

Die x’en sind evtl. die Sonderzeichen, vielleicht auch der Cursor. Wie auch immer, das wuerde sich mit einem sauber programmierten Custom LCD Treiber aendern.

Gruss,

       Thorsten.

[seppoman]

Hallo Thorsten,

so, nachdem ich mal nen Tag Auszeit von Assembler gebraucht und ein paar Sachen an der Hardware weiter gebaut habe, bin ich wieder am Treiber. Das mit MIOS_LCD_Cmd / Data ist jetzt klar, die müssen ja beim Custom Treiber gar nicht von außen angesprochen werden.

Die iXe hab ich inzwischen gefunden. In CS_MENU baust Du die erste Zeile des Menüs auf, indem Du erst “Pxxx  C xx  ----” schreibst, und dann die tatsächlichen Informationen drüberschreibst. Wenn man den String einfach in "P       C                   " ändert, sieht man auch keine iXe mehr. Liegt also tatsächlich daran, daß das Display wohl recht langsam ist. Interessant fand ich, daß auch wenn man z.B. das Mod-Wheel bewegt, bei jedem MIDI-Event das Display upgedated wird, was ja im Hauptmenü auf jeden Fall unnötig ist. Meinst Du, daß das fürs Timing nachteilig ist (weil MIOS evtl. aufs Display wartet), oder ist das egal?

Im Save-Menü flackert die erste Zeile, was wohl auch an der Geschwindigkeit liegt. und sobald man hier in P# geht, blinken erste und zweite Zeile abwechselnd. Ist das normal? Wenn nein, hast Du ne Idee, was man dagegen machen kann?

Jedenfalls maile ich Dir gleich mal die mios_clcd zu. Vielen Dank schon mal!

Und schon wieder ne neue Frage:

Ich baue mir gerade die Frontplatte, auf der (u.A. wegen dem großen Display) nicht genug Platz ist, um sowohl für OSC als auch für ENV 5 Encoder zu montieren. Jetzt hab ich mir überlegt, daß ich ja dem OSC-Encoder-Layer-Schalter noch ne vierte Ebene samt LED verpassen könnte, so daß man zwischen OSC Envelope, OSC Misc, ENV Envelope und Assign (Menu_P1..P5) schalten kann. Ist das ein großer Aufwand?

Viele Grüße,

Seppoman

[T.K]

Also wenn Du den Bildschirmaufbau auf diese Weise verfolgen kannst, dann wuerde ich Dir dringenst empfehlen, mit der Frontplatte zu warten und nach einem anderen Display ausschau zu halten.

Diese Dummy-Zeichen erscheinen bei einem normalen Display vielleicht fuer 50 uS (Microsekunden!) - sind also voellig unauffaellig, bei Dir liest es sich so, als wuerde es sich um Millisekunden handeln. Diese Latenz waere fuer einen MIDI Controller vielleicht noch akzeptabel, aber einen Synth macht das unbrauchbar.

Auch die Dummy-Display-Updates sind voellig akzeptabel, weil sie normalerweise nicht weh tun. Der Aufwand, unnoetige Updates zu erkennen und zu verhindern steigt schnell ins Unermessliche (und wer soll das alles testen? Nach solch einer Aenderung traut man sich ja gar nichts mehr neues mehr einzubauen ;-)), deshalb habe ich das gar nicht erst angefangen und gehe lieber auf nummer sicher - bevor ich wochenlang den Fehler-Reports im Forum nachgehen muss…

Das Erweitern des OSC-Layers ist kein besonders grosser Aufwand, aber Du muesstest dich halt selbst darum kuemmern. Ich kann das mit meiner Hardware nicht testen. Hint: cs_menu_io_tables.inc, cs_menu_buttons.inc, cs_menu_leds.inc

Gruss,

       Thorsten.

[seppoman]

Hi Thorsten,

zur Abwechslung mal wieder auf Deutsch

weiß nicht ob Du meine Mail bekommen hast mit dem Treiber, aber das “in einen Custom Treiber umwandeln” hat sich eventuell erledigt (außer die Sonderzeichen-Geschichte). Ich hab mir den iic Treiber mal angeschaut und festgestellt, daß Du im iic Treiber kein

     ;; notify that no graphical LCD is connected

     bcf      MIOS_BOX_CFG0, MIOS_BOX_CFG0_USE_GLCD

drin hast, obwohl das laut Datenblatt auch ein CLCD ist. Deshalb hab ich die Zeile aus meinem Treiber mal rausgenommen, mit dem Ergebnis, daß er jetzt problemlos als Custom Treiber mit nomalem MIOS drunter funktioniert. Ist damit die Sache ok, oder hat es irgendwelche Nachteile (Timing), diese GLCD-Einstellung zu haben? Wenn ich das richtig gesehen habe, wird dadurch bei der Cursor-Positionierung eine GLCD-Routine verwendet, die einige Operationen mehr durchführt.

Timeout-Routine hab ich mal versucht, allerdings weiß ich ehrlich gesagt nicht, ob sie funktioniert. Bei den ARPSEQ-Sounds führt das schnelle Hinundherdrehen von Mod-Wheel oder Encodern zu Timing-Problemen, die aber mit dem Timeout-Versuch auch nicht anders sind. Kannst Du die Auswirkungen der Timeout-Flags etwas erklären? Wozu gibt es .._TIMEOUT0 und .._TIMEOUT1? Wird bei Timeout das Display-Update zurückgestellt und erst wieder versucht, wenn dazwischen Realtime-bezogene Sachen erledigt wurden? Wenn das so ist, würde es dem Timing helfen, wenn der Timeout-Loop nicht bis 0xff zählt (wie im CLCD-Treiber) sondern früher abbricht?

Wie Du siehst, hab ich mich noch nicht ganz damit abgefunden, das Display aufzugeben, weil 1. es einfach geil aussieht, und - wichtiger - ich letzte Woche schon das Loch dafür in die Frontplatte geschnitten habe…

Übrigens hab ich gesehen, daß mit meinem 2x16-LCD die iXe auch beim Durchschalten zu erkennen sind. Bei dem haben allerdings Mod-Wheel-Bewegungen nur minimalen Einfluß aufs Timing.

Bis dann,

Seppoman

[T.K]

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.

[doc]

[glow=red,2,300]- aber ihr wollt es ja immer billig [/glow]

…Entschuldigung, ich kann mir das Lachen kaum verkneifen… aber wo TK recht hat, hat er Recht ! ;D