Beiträge von Henning im Thema „Overlay64: Modul zur Anzeige von digitalen Schaltzuständen auf dem Bildschirm“

    Das liegt daran, dass du aus irgendeinem Grund immer wieder einen neuen Screen definierst.

    Jeder Screen hat eine eigene Kopie aller Zeilen. Welche Zeile am Ende aus welchem Screen tatsächlich angezeigt wird, hängt davon ab, welcher Screen der bei der sukzessiven Auswertung der Kriterien und Screen-Modi zuerst als aktiviert erkannt wird und die Zeile für sich beansprucht.

    In diesem Fall beansprucht dein Kernal-Screen die erste Zeile zuerst. Lösche mal alle "screen always" bis auf die erste Zeile, dann sollte es dem entsprechen, was du erwartest.

    Siehe auch Bitte melde dich an, um diesen Link zu sehen. als Beispiel für die Verwendung von screens.

    Ich habe die Bitte melde dich an, um diesen Link zu sehen..

    Änderungen bestehen im Wesentlichen in der Verbesserung der USB-Geräte-Erkennung unter Windows (offenbar hauptsächlich in Version 8 problematisch).

    Wer Probleme mit der Geräteerkennung unter Windows hat und daher auch Probleme mit dem Update über den "update" Befehl der overlay64.exe hat, für den gibt es zwei Möglichkeiten:

    1. Wer ein Programmiergerät hat, kann die Bitte melde dich an, um diesen Link zu sehen. damit extern auf den Atmel schreiben.

    2. Wer kein Programmiergerät hat, kann den LM1881 temporär aus dem Sockel entfernen. Danach ist zwar keine Anzeige mehr möglich, das Gerät sollte allerdings dann verläßlich erkannt werden, so dass der "update"-Befehl verwendet werden kann.

    Ansonsten enthält diese Version einige kleinere Bugfixes beim Parsen der Konfigurationsdatei und kann nun auch auf MacOSX gebaut werden.

    Im Einzelnen:

    • USB interrupts werden nicht länger während der Anzeige temporär deaktiviert
      (gemeldet von Richard van der Wolf)
    • Fehler beim manuellen Aktivieren des Bootloaders korrigiert
    • Fehler beim Parsen von Zeilen mit Gleichheitszeichen behoben (gemeldet von Sven Arke)
    • Fehler bei configure/make unter MacOSX behoben (Dank an Rene Stopper für die Zusammenarbeit)
    • Unter Linux: Bash-Completion für das overlay64 binary

    Vielen Dank

    Was mich noch interessieren würde ist die letzte Zeile "KEYBOARD LOCKED - ENTER PASSWORD"
    Was genau bewirkt das?

    Da wird doch das CHARSET abgefragt, soweit ich sehe.

    Das ist nur eine kleine Spielerei, mein erster Charset besteht komplett aus X. Nur wenn ich die Tastatur mit dem Keyman sperre (lock), schalte ich auf diesen Charset um, damit man auch nicht mehr lesen kann, was gerade auf dem Bildschirm steht. Und das kann das Overlay dann als Indiz nehmen, dass die Tastatur gesperrt ist, und einen entsprechenden Text einblenden. Nicht sonderlich sinnvoll, aber geht halt.

    Das zeigt allerdings, wie man einen Text mit "screen always" nur dann einblenden kann, wenn mehrere Leitungen zusammen in einem bestimmten Zustand sind. Für alle anderen Zustände der Charset-Leitungen greift die allgemeine Regel, dass ein screen mindestens einen effektiven Write-Befehl auslösen muss, um letztendlich aktiviert zu werden.

    Die screens werden von 0 beginnend nummeriert:

    control 3 manual 0 -> schaltet deinen ersten screen ("manual")
    control 3 manual 1 -> schaltet deinen zweiten screen ("notify")

    Und was der absolute Hit wäre ist, das ich sowohl bei bit-Änderung den Manual Bereich für 5 Sekunden EIN schalten kann sowie auch mittel der Steuerleitung 3 AUS und EIN schalten kann.
    Geht das?

    Kein Problem, dann musst du den Screen als "notify" definieren aber halt mit einem "manual" control schalten.

    Ich mache das in meiner config genauso, siehe Bitte melde dich an, um diesen Link zu sehen.

    Mein MixSID-Screen ist notify und zeigt sich also immer kurz, wenn sich was ändert. Mein Reprom-Screen ist nur manual. Beide schalte ich zusammen über eine Leitung im manual mode ein/aus, wenn ich eine dauerhafte Anzeige mit "allen" Informationen will:

    control 16 manual MIXSID_AND_REPROM


    Und den Mixsid-Screen nochmal kurzzeitig über ein control notify, wenn ich nur mal kurz gucken will (keyman zieht Kontrolleitung kurz runter und wieder hoch):

    control 17 notify MIXSID

    Wobei MIXSID_AND_REPROM als "0 1" definiert ist und MIXSID als "0".

    Eine control-Anweisung kann auch mehrere screens schalten.

    Ändert allerdings leider nichts an dem fehlerhaften Verhalten.
    Gut, kann ich damit leben das ich den LM permanent raus/rein heble. Der Sockel wird's schon verkraften.

    Ich habe das Problem bei mir reproduziert und behoben. Ohne weitere Informationen kann ich auch nichts weiter tun.

    Das mit den write's habe ich jetzt soweit verfolgt das sich offensichtlich Texte in Zeilen, wo bereits Texte eingefügt wurden, an einer anderen Stelle nicht erneut setzen lassen.

    Das ist das implementierte Verhalten und das ist auch so dokumentiert.

    Gibt es irgend einen Trick wie man die permanente komplette Anzeige mittels Steuer-Leitung komplett ausblendet und wieder einblendet?

    Du willst keine permanente Anzeige? Dann solltest du auch nicht "always" verwenden sondern "manual".

    1881 für den Flashvorgang zu entfernen, löst das Problem.
    Was ich jetzt allerdings mal nicht als entgültige Lösung ansehe...

    Es scheint, als hättest du Bitte melde dich an, um diesen Link zu sehen. komplett übersehen. Den LM1881 zu entfernen war nur ein Tipp, um dir das update auf diese Firmware zu erleichtern.

    Werden write's mitten im Code gesetzt, also nach einem sample, werden diese nicht am Screen angezeigt. Writes müssen demnach immer ganz am Anfang des Codes stehen.

    Falsch. Es gibt einfach kein "nach einem Sample" in diesem Sinne.

    sample 1 0 # SD2IEC ID A6, A7
    when 00 write 0 49 "11"
    when 01 write 0 49 "10"
    when 10 write 0 49 "09"
    when 11 write 0 49 "08"

    write 0 45 "ID:"

    Das letzte write gehört natürlich noch zu "when 11". Es können auf eine when-Klausel durchaus mehrere Befehle folgen. Ein Zeilenumbruch hat wie oben beschrieben keine semantische Bedeutung, es gibt generell keine den aktuellen Kontext explizit terminierende Schlüsselwörter, die nicht gleichzeitig einen neuen Kontext öffnen würden. Das aktuelle "when" wird erst implizit durch die nächste "when", "sample" oder "screen"-Anweisung terminiert.

    Screen notify funktioniert einfach nicht.

    Kann ich leider nicht reproduzieren.

    Der Rest funktioniert soweit.

    Da die von mir zuletzt angehängte Firmware noch nicht heruntergeladen wurde, gehe ich davon aus, dass sich "der Rest" nicht auf die USB-Erekennung unter Windows 8.1 bezieht.

    Irgendwie hab ich den Verdacht als würde sich das spießen.

    Vielleicht könntest du deinen Verdacht nochmal etwas präzisieren, u.U. sogar durch einen eindeutigen Testfall inklusive erschöpfender Beschreibung des erwarteten sowie des beobachteten Verhaltens konkretisieren. In dieser Form werde ich daraus nicht schlau, außer, dass irgendetwas wohl nicht so funktioniert, wie du es erwartest.

    Wie auch immer: Leerzeichen und Zeilenumbrüche sind (außer innerhalb von Zeichenketten und im Falle von Kommtentaren) äquivalent, d.h. es können durchaus mehrere Direktiven nacheinander auf einer Zeile stehen:

    screen manual sample 0 when 0 write 0 0 "foo" write 0 10 "bar" when 1 write 7 7 "quux"

    Bit 0 ist bei mir die RESET-Leitung die nach jedem KERNAL-wechsel kurzzeitig auf LO gezogen wird.
    Der Screen notify sollte dann auch kurz den Text RESET einblenden.

    Was auch immer Bit 0 heißen soll, (ich sehe da nur "sample 2"), und was immer auch "kurz" hier heißen soll, versuch's doch mal mit

    Code
    screen notify
    	sample 2
    		when 1 write 0 2 "RESET"

    Dazu nur soviel: die Auswertung erfolgt wann immer dafür Zeit ist, d.h. immer, wenn gerade nichts gerendert werden muss, und somit je nach Konfiguration durchaus auch mehrmals pro Frame. Und alles andere ergibt sich aus den beschriebenen Regeln.

    Henning, wenn du es schon erfreulicherweise für windows anpasst dann sei bitte so gut und teste das mit windows 10 ...8.1 nutzt doch sogut wie keiner mehr! Danke.

    Willi, lies doch bitte nochmal den letzten Absatz meines vorherigen Beitrags. Vor allem vor dem Hintergrund, dass ich dir bereits einen Bausatz geliefert habe. Deine Chance, zur Abwechslung mal etwas Konstruktives beizutragen...

    DerSchatten:

    Ich habe jetzt bei mir Windows 8.1 installiert und konnte das Problem dort jetzt auch reproduzieren und weiter eingrenzen. Offensichtlich ist Windows 8.1 sehr viel weniger tolerant, was geringe Verzögerungen bei der Enumeration von USB-Geräten angeht, als es noch Windows 7 und generell Linux und MacOSX sind.

    Anbei eine Firmware-Version, die das Problem zumindest auf meinem frischen Windows 8.1 System behebt.

    Ich empfehle, das kombinierte Firmware Image "overlay64-application-and-bootloader-1.2.hex" (oder .bin) in einem externen Programmiergerät über ISP zu programmieren.

    Alternativ kann auch die "overlay64-application-1.2.hex" über "overlay64 update overlay64-application-1.2.hex" programmiert werden, dazu muss das USB-Gerät allerdings zumindest einmal korrekt erkannt sein.

    Sofern die Erkennung der Geräte mit dieser Firmware auch bei dir nun verlässlich funktioniert werde ich kurzfristig eine neue Firmware-Version veröffentlichen.

    Allgemein gilt:

    Da ich primär auf Linux entwickle und die Unterstützung unter Windows und MacOSX von meiner Seite aus nicht mehr als ein Zugeständnis ist, bin ich bei Problemen unter Windows auf eure konstuktive Mithilfe angewiesen, da ich höchstens ein Windows-System zur Verfügung habe und somit keine Möglichkeit habe, auf allen anderen Windows-Varianten zu testen. Ich muss dabei davon ausgehen, dass die Geschichte prinzipiell überall funktioniert, sofern sie auf meiner Windows-Variante läuft.

    Vielleicht erklärst du nochmal genau, was du machst, Schritt für Schritt.

    Hast du die von mir angehängte firmware geflasht? Über ein externes Programmiergerät? Dabei das application-and-bootloader image verwendet?

    Wie wird das Overlay mit Spannung versorgt? Schließt du erst VCC und GND an und danach D+ und D-? Oder hast du das Overlay jetzt wie vorgesehen angeschlossen, so dass es vom C64 versorgt wird?

    Unter Zadig muss als Treiber "WinUSB" gewählt werden. Die libusb-1.0.dll, die mit der Overlay64-Software geliefert wird, ist allerdings nicht der Treiber im Sinne von Zadig, sondern nur eine Bibliothek. Wäre die nicht da würde die overlay64.exe auch nicht starten, da sie gegen diese gelinkt ist.

    Ansonsten: Auf meinem Windows 7 (das einzige mir zur Verfügung stehende Windows-System) funktioniert das, mehr kann ich dazu leider nicht sagen. Das Verhalten der vorherigen Firmware unter Windows 7 ist sowohl nachvollziehbar als auch reproduzierbar.

    Das bedeutet, die Platine benötigt vorher Saft bevor die Datenleitungen verbunden werden?

    Nein, das ist ein reines Softwareproblem. Windows fängt mit der Enumeration an, bevor die USB-Schicht auf dem Atmel vollständig initialisiert ist. Linux ist da einfach geduldiger.

    Die Firmware wird in der nächsten Version dementsprechend angepasst, so dass die Enumeration dann auch direkt nach dem Einschalten des bereits verbundenen Overlays funktioniert.

    EDIT:

    Ich hatte mir testweise die VCC Leitung auf die USB-Buchse verbunden damit ich die Hardware unabhängig vom C64 programmieren kann.

    Sorry, jetzt habe ich's begriffen. Ja, in deinem Fall musst du dann erst VCC und GND zur Platine führen und nach ein paar Sekunden erst die Datenleitungen verbinden, wenn du das Gerät in dieser Weise getrennt vom C64 programmieren willst. Das wird natürlich dann auf Dauer umständlich, daher hänge ich dir hier schonmal die Dateien für eine Firmware-Version an, in der das Problem nicht mehr auftauchen sollte, jedenfalls funktioniert es mit meinem Windows 7. Entweder das kombinierte Image im externen Programmer flashen oder nur den Anwendungsteil über "overlay update". Für letzteres müsste natürlich auch erstmal das USBasp Bootloader-Device über Zadig vorbereitet werden.

    Ich habe mal versucht, das Problem auf diversen Windows-Versionen und Installationen zu reproduzieren und habe dieses Verhalten auch teilweise nachvollziehen können.

    Offensichtlich ist Windows je nach Version etwas ungeduldig, wenn es um die Enumeration des Geräts geht.

    Bitte probiere mal folgendes: C64 ausschalten, USB-Kabel vom Windows-PC abziehen, dann zuerst den C64 einschalten, ein paar Sekunden warten und dann erst das USB-Kabel mit dem PC verbinden. Dann sollte das Gerät korrekt erkannt, werden und in Zadig als "Overlay64" erscheinen.

    Zumindest funktioniert das unter dem Windows 7 System, auf dem ich beim Einschalten des Geräts mit bereits verbundenen USB-Kabel das von dir beschriebene Verhalten reproduzieren konnte.

    Die korrekte Erkennung des Gerätes unter Windows äußert sich vor Installation der Zadig-"Treiber" so, dass das Gerät zwar im Gerätemanager als "unbekanntes Gerät" gelistet wird, unter "Eigenschaften -> Details" jedoch die korrekte USB-ID angezeigt wird (1d50 6100). Ist die USB-ID vorhanden, kann Zadig das Gerät erkennen und die Treiber für den Zugriff über WinUSB (libusb) können installiert werden.

    Dann kann man das ganze nur im Betrieb im C64 programmieren?

    Nein, du kannst den Overlay gern beim Programmieren aus einer anderen Quelle versorgen, wenn es für dich praktischer ist, zum Programmieren jedesmal komplett auszubauen oder zumindest alle Eingangs- und Kontrolleitungen abzuziehen. Ich sehe ehrlich gesagt keinen Sinn darin, deshalb ist die Platine, wie sie ist.

    Das bedeutet es werden hier zwei Unterschiedliche Potenziale miteinander verbunden.
    Abgesehen davon muss man jedes mal die komplette Apparatur zum PC schleppen.

    Es handelt sich um ein self-powered USB device, dort wird VUSB nicht verbunden. Ansonsten wäre es möglich, dass in einem ausgeschalteten C64 ein Atmel hängt, der über USB mit Strom versorgt wird und an dessen IO-Ports irgendwelche Leitungen des C64 bzw. mit diesem verbundene Zusatzhardware hängen, ohne das im Vorfeld klar wäre, um welche Leitungen es sich genau handelt.

    Geht PIN 1 der USB-Buchse wirklich ins leere???

    Ja. Genau wie beim Keyman, wenn der Jumper so gesetzt ist, dass der Keyman durch den C64 versorgt wird.

    Ich tendiere dazu, es in der nächsten Revision des Keyman genauso zu machen wie beim Overlay, d.h. der Jumper fällt weg und eine Versorgung unabhängig vom C64 wird nicht mehr möglich sein. Der Keyman ist je nach Jumper Host- oder Self-Powered, was nicht besonders glücklich ist, da die Verantwortung für den jeweils korrekten Anschluss der Versorgunsspannung in der jeweiligen Betriebsart beim Benutzer liegt.

    Das Overlay bietet insgesamt 24 Eingangsleitungen. Leitungen 0-15 sind sowohl an der linken als auch and der lechten Seite verfügbar und eignen sich somit für den Anschluss von zu überwachenden Leitungen (sample), die letztendlich weitere Hardware kontrollieren.

    Leitungen 16-23 befinden sich am Pinheader unten rechts und eignen sich besser als Kontrollleitungen (control), da sie nicht durchgeschliffen werden.

    Die Firmware unterscheidet hier allerdings nicht. Jede Leitung kann als Eingangs- und/oder Kontrollleitung verwendet werden.

    Kurzes Update: Ich habe die Bitte melde dich an, um diesen Link zu sehen. veröffentlicht.

    Es wurden Verbesserungen an der Software und an der Firmware vorgenommen. Die Hardware bleibt unverändert.

    Änderungen:

    Die Logik für die Aktivierung von einzelnen Bereichen (screens) wurde verbessert. Ein screen wird nun unabhängig von anderen Regeln nur dann aktiviert, wenn sich aus der Auswertung mindestens eine Schreiboperation ergibt.

    Ein weiter Betriebsmodus für screens namens "always" wurde hinzugefügt. Ein solcher screen wird (fast) immer angezeigt, unabhängig vom Zustand von Eingangs- oder Kontrolleitungen, sofern die obenstehende Regel auch zutrifft.

    Es muss nun auch nicht mehr zwingend für alle möglichen Zustände ein Befehl angegeben werden.

    Mit diesen Verbesserungen wird es möglich, immer nur dann einen Text anzuzeigen, wenn eine oder mehr bestimmte Leitung in einem einzigen bestimmten Zustand sind. Bisher mussten immer alle Zustände abgedeckt werden.

    Ansonsten gibt es nur ein paar bugfixes und Verbesserungen unter der Haube.

    An die Besteller: Die Bausätze sind in Arbeit, es dauert noch ein paar Tage. Die Atmels werden natürlich mit der aktuellen Firmware 1.1 ausgeliefert.

    Kann man die auch in einen SX-64 einbauen?

    Du kannst das overlay im Prinzip in jedes Gerät einbauen, das ein analoges Videosignal (S-Video oder Composite), 5V Versorgungsspannung und digitale Signale zum Überwachen liefert.

    Wo genau du welches Video-Signal im SX64 anschließen kannst, kann ich leider nicht sagen, da ich mich da nicht auskenne. Sofern der interne Monitor S-Video (Chroma und Luma) bekommt, gehst du an Luma, handlet es sich um ein Composite-Signal, nimmst du einfach das. Wichtig ist nur, im Fall von S-Video nicht direkt an die LUMA-Ausgabe des VIC zu gehen, sondern an das (im normalen C64 durch den HF-Modulator) verstärkte Signal. Also einfach dort anschließen, wo das Signal zum Monitor geht.

    Vielleicht weiß ja jemand anders hier mehr dazu.

    Kann man eigentlich den Output des Overlay64 ein und ausschalten? Oder bleibt der dauerhaft im Bild eingeblendet?
    Wenn der Output sowieso sich wieder ausschaltet, dann sieht man das gezucke nur für wenige Augenblicke und ich kann auf die zusätzliche Komplexität durchaus verzichten.

    Man muss ihn sogar explizit einschalten. Es gibt für jeden selbstdefinierten Abschnitt (screen) einen Modus, entweder "manual" oder "notify". Ist manual gewählt, muss der screen über eine als Kontrolleitung (control) definierte Leitung aktiviert werden, dort kann wieder zwischen zwei modi gewählt werden (notfiy = kurze Einblendung (2 sek) bei steigender Flanke (Taster), manual = immer an wenn Leitung low (Schalter)). Ist ein screen selbst im notify-Modus, wird er immer automatisch für 2 sek eingeblendet, wenn sich eine der durch ihn überwachten Leitungen ändert. (Das ist aber alles nochmal genauer auf der Website beschrieben).

    Ich habe bei mir zwei "screens" definiert, einmal oben die Anzeige von Kernal und Charset, einmal unten die Anzeige der aktuellen MixSID-Parameter. Eine Leitung kontrolliert beide "manual", diese bediene ich mit einem "Schalter". Ich kann also erst mal die Anzeige aller Informationen ein- und ausschalten. (Siehe screenshot oben).

    Dann habe ich noch eine zweite Kontrollleitung, die diese beiden Screens kurz einblendet, bedient mit einem "Taster". Da drücke ich einmal kurz drauf, und alle Informationen werden einmal eingeblendet.

    Zusätzlich ist der screen für die MixSIDs auf notify gesetzt, d.h. immer wenn ich irgendwas am MixSID schalte, wird der untere Screen automatisch kurz eingeblendet. Zusätzlich habe ich bestimmte MixSID-Leitungen an weitere screens gehängt. Wenn ich z.B. den Adressierungsmodus (Parallel/Stereo) wechsle, wird zusätzlich oben noch eine Bestätigung eingeblendent ("Switched to Stereo Mode" oder "Switched to Parallel Mode").

    Ein "Immer an"-Modus gibt es bisher gar nicht (könnte ich aber problemlos einbauen, wenn gewünscht).

    Bei dem "Gezucke" handelt es sich eher um eine leichtes Flirren, das manchmal auch (je nach Phasenlage) zu einem etwas langsameren vertikalen "Durchlaufen" eines kleinen "Versatzes" wird. Der Text ist aber immer gut lesbar.

    Wie gesagt kommt es da auf die Einstellung des Betrachters an. Ästhetisch betrachtet könnte es etwas schöner sein, aber praktisch, also in dem Moment, wo ich einfach nur etwas wissen will (Welchen Kernal habe ich gerade nochmal? Welcher SID spielt gerade?) interessiert das eigentlich nicht. Da macht man einen kurzen Blick und fertig.

    Freak: Vielen Dank für diesen äußerst konstruktive Beitrag :) Das hast du aber nicht mal eben heute nachmittag zusammengebastelt, oder? Wieso sagst du nicht mal was? Mensch... :verehr:

    Damit hat man eine 20MHz-Taktfrequenz des AVR, die synchron zum 15,625kHz-HSync ist...

    Damit müsste auch USB laufen, habe ich aber nicht getestet.

    Aber lohnt sich das überhaupt?

    Mir war ehrlich gesagt gar nicht klar, dass man die 20Mhz mit dem PLL auch einfach nur mit einem anderen Takt synchronisieren kann. Ich war bisher der Meinung, PLL dient hauptsächlich zur Multiplikation.

    Wenn es 20Mhz sind sollte USB auch laufen. Dann spräche auch prinzipiell nichts dagegen, das so zu machen. Trotzdem würde es die Komplexität und den Preis deutlich erhöhen....

    Gibt es eine "einfache" Möglichkeit, diese "Asubaustufe" nachzurüsten?

    Das wäre auch meine Idee... da muss ich mal drüber nachdenken. Da könnte man sicher noch eine Platine oben drauf stecken, vielleicht im LM1881-Sockel steckend und über dem AVR schwebend.

    Ich persönlich bin zwar immer noch der Meinung, das das Modul so wie es ist seinen Zweck völlig erfüllt, aber ich könnte auch verstehen, wenn jemand das lieber 100% statt 99%tig hätte.

    Ich setze mich in jedem Fall mal mit Bitte melde dich an, um diesen Link zu sehen. in Verbindung...