Ihr habt es ja nich anders gewollt
Jetzt müsst ihr nen technischen Vortrag ertragen (nich erschrecken vor dem bissl
asm)
Wat macht eijentlich SetKeyboardLED?
Da stell'n mer uns ma janz dumm und sagen....
nen LED Status kann man beim Keyboard setzen, indem man einen zwei Byte-Code-Kommando an den Tastaturport sendet. (Bitte merken darauf komm ich nochmal zurück)
Also was passiert nu?
1. ne Schleife wartet, bis der Tastaturpuffer leer ist.
Code:
in al,64h ;
and al,00000010b ; den Keyboard inputbuffer prüfen
jz makeLED ; wenn der Leer ist ... loslegen
2. jetzt schicken wir ganz schnell ein $ED an $60
Code:
mov al,0edh ; Keyboard LED output Kommando $ED
out 60h,al ; an die Adresse $60 schreiben
3. Prüfen, ob der Befehl von der Tastatur angenommen wurde
4. jetzt machen wir alle 3 LEDs an
Code:
mov al,00000111b ; Keyboard LED output Kommando 111
out 60h,al ; an die Adresse $60 schreiben
ok, ok, ok... zwischendrin fehlen n paar Befehle aber das soll ja jetzt auch bloß als Anschauungsmaterial dienen.
Dem aufmerksamen Leser ist sicher aufgefallen, daß hier das Risiko besteht, daß zwischen dem Senden von $ED und 00000111 die Tastatur (also der Mensch durch drücken einer Taste) eine "Taste" in den Buffer schreibt, die dann als LED Kommando gewertet würde. Unter DOS und
Win9x kann man das unterbinden indem man den Interrupt exklusiv für sich reserviert (
asm -> cli) und nachher die Interruptkontrolle wieder freigibt (
asm -> sti). Aber leider macht uns XP da nen Strich durch die Rechnung, da sowas nur möglich ist, wenn die Anwendung im Kernelmodus läuft.
Bitte Beachten- Das Risiko kann dadurch minimiert werden, daß Intervall zum setzen der LEDs zu verlängern (daß die Tastatur auch mal ne Chance bekommt)
- ältere XT-Controller unterstützen dieses Vorgehen nicht
- sehr neue Controller können auch spinnen
- das Readme der Unit enthält ne Disclaimer-Section!!!
zur Beruhigung aller... chaosben ist immer noch dabei das irgendwie anders zu lösen (good luck man
)