Hardware > Hardware (Classic 16-/32-Bit)

Tastatur mit CapsLock Controlle

<< < (15/27) > >>

rainers:
Arthur schrieb:

--- Zitat ---Und schon getestet?   ;D
--- Ende Zitat ---

Dafür bin ich zuständig  ;D ;D ;D

Die erste Schaltung ergab: Geht, aber nicht ganz.
Die LED geht mal an, mal nicht, mal flimmert sie, manchmal muß man länger drücken.

Arthur:
Das lässt doch hoffen das noch was daraus wird.

ToPeG:
Versuchen wir erst mal die Taste zu entprellen.

Diese erweiterte Schaltung macht zwei Messungen und entscheidet danach, ob Die Taste gedrückt oder gelöst ist.

guest2696:
 :o Hi, also bei aller Hochachtung vor euren Bemühungen:  :o

Ihr konstruiert hier TTL-Gräber wohingegen "Power without the price - JIL Atari" die CL-Led vor 20 Jahren im Layout schon vorgesehen hatte (...die dann leider wie Dutzende andere Sachen nicht realisiert wurden !).  -  

Das CapsLock.Prg hat wenn auch unsauber programmiert unter TOS 1.04 die LED zum Leuchten gebracht. -
Es geht also auch ohne zusätzliche TTL-Gatter - Ausschließlich per Software! -

Ich hatte mich der Hoffnung hingegeben, jemand von euch könne hier vielleicht zwei winzige Assembler-Listings beisteuern:

* CL-Led an
* CL-Led wieder ausDies könnte ich beispielsweise unter GfA-Basic in einem Accessory (ACC) implementieren: Mit Bios(11,-1) zyklisch (alle 0,5 - 1 Sek. würde mir pers. schon reichen!) den CL-Tastenzustand abfragen und entsprechend das eine oder andere Assembler-Programm aufrufen.

Edit: Bei mir wäre die TTL-Hardware-Lösung denn auch noch aus einem anderen Grund unbrauchbar: Ich benutze ein Mega-ST-Keyboard im Wechsel an zwei STs (mit Umschalter); Während der eine ST mit irgendwas beschäftigt ist, kann ich an dem anderen arbeiten. - Die Hardware-Lösung ist dem nicht gewachsen.

Gruß soldermaSTer

ToPeG:
Will ich ja auch so ähnlich machen. Nur brauche ich Zeit das zu programmieren. Es ist halt Aufwand alles vorzubereiten. Und ich bin schon bei mehreren Sachen beschäftigt.
Ein Schaltplan hinzuwerfen ist nicht schwer, das mache ich in 10 Minuten. Zum Programmieren brauche ich ein paar Stunden ruhe.

Nebenbei. Es braucht kein Assembler.  Etwas GFA Code reicht:
Ungetestet:

--- Code: ---'
PROCEDURE led_on
  LOCAL adr%
  ' Kommando, Adresse, Bytecount, Bytes
  ' 20,       0006,    02,        FFFF
  kbd$=""
  adr%=VARPTR(kbd$)
  dpoke(addr%,&H2000);
  dpoke(addr%+2,&H0602;
  dpoke(addr%+4,&HFFFF);
  ~XBIOS(25,5,L:adr%)
RETURN
'
PROCEDURE led_off
  LOCAL adr%
  ' Kommando, Adresse, Bytecount, Bytes
  ' 20,       0006,    02,        FFFE
  kbd$=""
  adr%=VARPTR(kbd$)
  dpoke(addr%,&H2000);
  dpoke(addr%+2,&H0602;
  dpoke(addr%+4,&HFFFE);
  ~XBIOS(25,5,L:adr%)
RETURN
'

--- Ende Code ---

Nachdem ich mir den Code das IKBD angeschaut habe meine ich das es unnötig ist die aktuellen Werte auszulesen. Die IKBD-Funktionen werden zwischen den TastaurMatrixAbfragen gemacht. Das heißt beim schreiben stört man die normalen Tastaturfunktionen nicht.

Was ich noch nicht heraus gefunden habe ist, ob die Tastatur selber die das Gesetzte Bit wieder zurück setzt, wenn es den Port ansteuert. (So was würde ich bei Atari Erwarten  :-\ ) Dann muss man das setzen regelmäßig, sehr schnell machen, damit die LED nicht flackert.

Hat jemand Erfahrung wie man sich mit GFA-Basic mit dem XBRA Verfahren in Interrupts einhängt? Ich kenne nur die schmutzige Variante. Alten Vector speichern und und neuen einsetzen. Am Ende des Programms das wider zurück. Ich würde das gerne Sauber machen, damit es auf möglichst vielen Systemen läuft. Weiterhin wäre es gut wenn jemand einer Liste der Cookies hätte, die ich prüfen solte. Nicht alle Systeme haben einen IKBD.

Wäre schön wenn man auch PC-Keyboards unterstützen könnte. Da müsste ich aber wissen wie ich es am einfachsten heraus finden kann welches System läuft.

EDIT: Zu lange nicht mehr mit dem System gespielt. Fehler im Code korrigiert.

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete