Suche Möglickeiten für einen LED-Editor

[mega-hz]

Hallo,

ich möchte einen Editor programmieren mit dem man die LEDs des Tastatur-Projektes vom Atari aus einstellen kann.

Es gibt 65 LEDs und der µC "horcht" auf der SIO auf Gerät 66.
Nach dem erstellen seines eigenen "Musters" kann dieses dann im µC-EEPROM gespeichert werden.
Es können auch mehrere Muster angelegt werden...
Um gleich mehrere oder alle LEDs die gleichen Werte zuweisen zu können, gibt es im µC dann spezielle Kommandos.
Ideal wenn z.B. alle Tasten warmweiss und die Consol-Tasten z.B. blau leuchten sollen.

Nun weiss ich nicht genau, wie sollte so ein Editor aussehen?
Alle Tasten auf dem Screen sichtbar?
Oder wenn eine Taste gedrückt wird, erscheinen 3 Eingabefelder für die RGB Werte?

Mir fehlt da sowas wie der Startschuss, um das Programm anfangen zu können.

Wer hat Ideen dazu?

[pps]

Sowas wie im Selbsttest wäre cool. Wahrscheinlich müsste man dazu dann die Farbe der Taste mittels GTIA Modus darstellen und darunter eine Beschriftung der Taste setzen. Aber dann könnte man es so richtig schön bunt machen...

[mega-hz]

Uii, mit GTIA?
Ich denke das weicht aber von der LED Farbe dann doch ab.
Zumal nach dem Editieren einer Taste sofort auch diese Farbe per SIO zur LED geschickt werden soll.

Mit Selbstest-ähnlich meinst Du dann alle Tasten sichtbar auf dem Screen? Wie beim Keyboard-Test?

[pps]

Uii, mit GTIA?
Ich denke das weicht aber von der LED Farbe dann doch ab.
Zumal nach dem Editieren einer Taste sofort auch diese Farbe per SIO zur LED geschickt werden soll.

Mit Selbstest-ähnlich meinst Du dann alle Tasten sichtbar auf dem Screen? Wie beim Keyboard-Test?

Dass die Farbe nicht zu 100 % abgebildet werden kann ist klar. Aber eine so ca. Darstellung kann man machen. 256 Farben sind ja möglich.

Selbsttest ähnlich: Ja so in der Art vom Tastatur Test hatte ich als Idee.

Taste drücken könnte den Wert ändern, mit shift + Taste dann entgegensetze Richtung.

[mega-hz]

ok, aber geht das überhaupt, mehrere Farben per DLI für jede Taste in einer Zeile?
Oder meinst Du nur die grade zu editirende Taste farbig darstellen?

[pps]

ok, aber geht das überhaupt, mehrere Farben per DLI für jede Taste in einer Zeile?
Oder meinst Du nur die grade zu editirende Taste farbig darstellen?

Über jeder Taste ein Feld mit GTIA Modus. Dann abwechselnd 16 Farben und 16 Grautöne dort. Dank PAL Blending hat man so 256 unterschiedliche Farben und kann das für jede einzelne Taste darstellen. So kann man auch am Screen das Muster sehen. Bastelt man noch save und load könnten Muster erstellt und getauscht werden.

Ich schaue mal die Tage, dass ich da Beispielcode bauen kann.

[mega-hz]

nur noch die Frage, wie man beide SHIFT Tasten getrennt einstellen kann...
Mit Maus drüberfahren und klicken... hier wohl eher schlecht

[pps]

Für Shift muss man da wohl sowas in der Art machen.
Vielleicht über Joystick oder Consolentasten.
Oder 2-stufig bauen. Erst die Tasten einstellen, so wie ich beschrieben habe und danach die Shift Tasten extra.

[pps]

Ich habe mal einen "mockup screen" mit Graph2Font gemalt. So kann man meine Idee vielleicht besser verstehen.
Hier gibt es allerdings jetzt "nur" 16 unterschiedliche Farben je Taste, da ich "nur" den 16 Farbmodus der GTIA verwendet habe. In den GTIA Zeilen muss später abwechselnd jeweils zwischen 16 Farben und 16 Helligkeiten umgeschaltet werden, dann hat man 256 (bei PAL eher "nur" 224) unterschiedliche Farben zur Visualisierung der Tastenfarbe. Beide Zeilen ergänzen sich da für das Auge.

Die g2f-Datei:

keylight_mockup.zip

(1.7 KiB) 10-mal heruntergeladen

keylight_mockup.xex

(1.47 KiB) 15-mal heruntergeladen

keylight_mockup.png (2.47 KiB) 433 mal betrachtet

[mega-hz]

cool!
Sieht gut aus!
Nur Reset, Option, Select, Start und Help fehlen noch.
Und Space hat 3 Taster/LEDs
Womit öffnet man g2f ?

[andymanone]

Womit öffnet man g2f ?

Ganz normal unter Windoof ...

g2f


Gtx.,
andY

[pps]

Bitte dran denken. Es ist nur ein mockup. So ist das noch nicht optimal gelöst. G2f kann echt viel, aber auch nicht alles so, dass man es optimal im eigenen Programm nutzen kann. Hier würde ich z.B. nur die Tastenbeschriftung im Zeichensatz Modus machen und dann für die Farben direkt echten Grafikmodus nehmen. So kann man die Farben einfacher darstellen. Als Zeichensatz Grafik müsste man da je Farbe 16 Zeichen basteln. Das wird eher nicht funktionieren.

Wegen der Shift Tasten muss man dann halt für das Nutzerinterface was basteln, damit man die auch ändern kann. Vielleicht zunächst die Tasten einstellen, danach dann die beiden Shift Tasten.

Übrigens sind es am Ende wahrscheinlich nochmals 16 Farben weniger, die man darstellen kann. Ich tippe mal darauf, dass es kein Weiß bis Schwarz mit den LED gibt...

[mega-hz]

die LEDs können 3x256 Werte pro Farbe, also RGB.

Das Programm kannte ich überhaupt nicht, scheint ja ein richtig cooles Tool zu sein!

Bei druck auf eine der Shift-Tasten kommt dann ein Pop-Up mit der Frage Links oder Rechts

[pps]

So, hier mal das Grundgerüst in der Art, wie ich es vorgeschlagen hatte. Es sieht auf PAL Rechnern natürlich besser aus als auf NTSC, aber auch dort kann man die Unterschiede in den Farben sehen.
Ungetestet ist noch ein weiterer Schritt: Man könnte die Farben noch im "Flicker Modus" alternieren (also GTIA9 und GTIA11 wechseln jeden 2. VBI). Vielleicht sieht das dann noch besser aus.

keylight_v0.zip

(29.58 KiB) 5-mal heruntergeladen

keylight_v0.png (52.45 KiB) 219 mal betrachtet

Wie man sieht sind unten mal locker 6 und mehr Zeilen für das Eingabeformular und weitere Informationen möglich.

Meine Idee wäre in etwa so:

• User tippt auf Taste

• unten kommt dann die Taste und eine Möglichkeit den Hexwert #RRGGBB direkt einzugeben/editieren

• bei SHIFT muss noch abgefragt werden welche taste man drücken möchte

• bei SPACE dann natürlich, welche LED

• nach RETURN kommt man wieder in die Tastenauswahl

• in der Eingabe kann man ja noch den Programm Exit einbauen und auch ein load/save Feature

[pps]

So, nach der feierlichen Zeugnisübergabe meiner "Kleinen" habe ich mal das angesprochene Umschalten umgesetzt.

keylight_mode_switch_v1.zip

(13.98 KiB) 7-mal heruntergeladen

keylight_mode_switch_v1.png (51.52 KiB) 188 mal betrachtet

Das Bild ist dank eingeschaltetem "frame blending" etwas besser, als in Echt.
Unter den Funktionstasten ist eine Zeile mit allen Farben in selber Helligkeit., dann kommt ein "Rot" in verschiedenen Helligkeiten, danach ein Grün, dann ein Blau in Helligkeiten.
Bisher sind die Farben noch nicht NTSC "sortiert".

[mega-hz]

Sieht schon ganz nett aus, aber ich habe da ein (Verständnis-)Problem mit WUDSN:

Wenn ich ein neues Projekt, also in diesem Falle Deins, einlade (open-file/*.asm)
dann fehlt mir das "bauen und ausführen" Icon:

Screenshot (763).png (11.91 KiB) 147 mal betrachtet

Bei vorigen Projekten ist das da:

Screenshot (764).png (10.8 KiB) 147 mal betrachtet

ist im gleichen Pfad gespeichert wie die "funktionierenden" Projekte...
Ne Idee woran das liegt?

[pps]

Klicke im Navigationsfenster (links oben) mal auf den Pfad und drücke dann F5 für das Aktualisieren.
Wenn das nicht hilft, könnte es auch sein, dass .asm nicht mit dem Atari Assembler verknüpft ist in den WUDSN Einstellungen.

EDIT: Wenn ich oben den Pfad so sehe, ist es wirklich noch nicht im Workspace importiert. Also F5 und es sollte dann gehen. Wenn nicht, hast Du vielleicht eine ungünstige Konfiguration des Workspace, wo Du immer alles erst hinein verlinken musst. Dort gibt es dann über einen Rechtsklock im Navigationsfenster auch eine Option dazu.

[JoSch]

Wenn möglich, sollte man eine Gamma-Korrektur einbauen, da Menschen Helligkeit nicht linear wahrnehmen. Die Tabelle, die ich immer nutze ist: https://cdn-learn.adafruit.com/download ... ection.pdf

[pps]

Wenn möglich, sollte man eine Gamma-Korrektur einbauen, da Menschen Helligkeit nicht linear wahrnehmen. Die Tabelle, die ich immer nutze ist: https://cdn-learn.adafruit.com/download ... ection.pdf

Denke, dass ist eher unmöglich. Wir haben ja maximal 256 Farben, die wir am A8 darstellen können mit dieser Methode. Alleine jedes einzelne Register von RGB hat genauso viele mögliche Einstellungen. Zudem ist der RGB Farbraum im verfügbaren Raum des ATARI sehr beschränkt wiedergegeben. So gibt es besonders viele Töne von Lila bis Blau-Grün, aber kaum was im Rot Bereich.
Die Farben werden also in jedem Fall eher ein Gimmik auf dem Bildschirm werden.

Die Eingabe habe ich mir so gedacht, dass man dann nach Drücken der Taste (bei RESET wird das noch tricky) eine Eingabemaske mit den RGB Werten in HEX zu sehen bekommt. Das ist dann unabhängig von den Bildschirmfarben sehr eindeutig. Nach Bestätigung wird dann ja auch sehr wahrscheinlich auch die Tastenfarbe direkt geändert und man kann den echten Farbton direkt sehen.

Ich hatte übrigens auch einen Modus mit Rot, dann Grün, dann Blau Bildern. Aber das flackert so heftig, dass es keinen Sinn macht. Aber dort wären dann jeweils 256 Farbtöne möglich, wie es die Tasten ja bieten. Das Umsetzen vom RGB Raum wäre da auch toll gewesen. Aber es geht einfach nicht.

Edit: Ach ich lese gerade im Dokument. Du meintest für die LED ein Gamma... Das würde natürlich bedeuten, dass wir direkt für die ATARI Farben was einstellen können. Also, was am BS zu sehen ist, ist dann direkt auch, was die Taste macht. Dann müsste man den Nutzer auch nicht mit HEX-Werten quälen, sondern gibt ihm einfach eine Farbselektion und er bekommt, was er sieht. Für solche Arbeit, benötige ich dann aber wirklich eine der Tastaturen, damit ich das einbauen kann. Muss ja sehen, ob das auch passt.

[pps]

So, hier mal eine Version mit kompletter Farbtabelle und einem Anfang für die Tastenabfrage (man kann mit esc aktuell einen Reset durchführen).

keylight_mode_switch_v2.zip

(21.54 KiB) 3-mal heruntergeladen

keylight_mode_switch_v2.png (89.72 KiB) 85 mal betrachtet

Das Bild ist wieder mit "frame blending".

Ich tippe mal, dass die kompletten Grautöne eh nicht möglich sind. Dann hätten wir also 16 Farbkombinationen weniger für die Tastatur. Bei unseren PAL Rechnern sind die Farben für $10-$1ff und $f0-$ff letztlich auch gleich, was nochmals 16 Farben weniger bedeutet. Aber 224 unterschiedliche Farbwerte bleiben dann noch übrig.

[mega-hz]

Klicke im Navigationsfenster (links oben) mal auf den Pfad und drücke dann F5 für das Aktualisieren.
Wenn das nicht hilft, könnte es auch sein, dass .asm nicht mit dem Atari Assembler verknüpft ist in den WUDSN Einstellungen.

EDIT: Wenn ich oben den Pfad so sehe, ist es wirklich noch nicht im Workspace importiert. Also F5 und es sollte dann gehen. Wenn nicht, hast Du vielleicht eine ungünstige Konfiguration des Workspace, wo Du immer alles erst hinein verlinken musst. Dort gibt es dann über einen Rechtsklock im Navigationsfenster auch eine Option dazu.

Hmm, ich weiss echt nicht, wo Du meinst mit klicken auf den Pfad...
Kannst Du mir Screenshots machen?

Und da es sich nur um eine 6/800 XL Tastatur handelt, wäre es schön, wenn die Consol-Tasten auch rechts übereinander dargestellt werden.
Ich denke auch das es gut ist, nach einer Änderung der Farbe diese sofort per SIO zum LED-Controller zu schicken, dann sieht man gleich das Ergebnis.
Es wäre auch gut, wenn die eingestellten Werte der grade zu behandelten Taste "gemerkt" werden, so daß man bei der nächsten Taste den Wert gleich übernehmen kann.
Denn es wird ja meist so sein, daß viele Tasten die gleiche Farbe bekommen sollen.

zum Testen könnte ich Dir zwar keine Tastaturplatine aber einen Controller mit einem 65LED Stripe zukommen lassen!
Ich habe zwar noch ältere Prototypen-Platinen mit LEDs da, jedoch fehlen bei diesen an jeder LED ein 100nF Kondensator.
Ergebnis ist: alle LEDs erzeugen so viel Störungen, daß ein programmieren fast nicht möglich ist.
Das hilft dann nicht.
Hättest Du denn auch die Möglichkeit eine Arduino-IDE zu benutzen um ggf. neue Firmware in den Controller zu flashen?

[pps]

So, habe gerade einiges mit Wolfram offline geregelt...
Hier das XL Layout:

keylight_xl_v3.zip

(50.16 KiB) Noch nie heruntergeladen

keylight_xl_v3.png (82.2 KiB) 16 mal betrachtet

Screenshot mal ohne "frame blending"