Problem mit BIOS Int 16h/Fkt. 11h Keyboard

[Nils S. (kruemeltee)]

Hi,

ich bin gerade dabei am einem Real-Mode Programm zu basteln und brauche 
dafür Tastatur-Eingabe. Die Funktion 11h aus int 16h scheint dafür 
perfekt zu sein. Jedoch habe ich ein paar Probleme damit.

In einer Schleife (beginnt bei "footer:") hole ich Zufallszahlen und 
nehme die für die Farbe für ein paar Zeichen die immerwieder geschrieben 
werden. Das funktioniert soweit wie es soll. Jetzt sollen da aber noch 
ein paar Tastendrücke ausgewertet werden, also springt die Schleife auf 
noch in jedem Durchlauf nach "keyboard_handler".

Dort wird int 16h/funktion 11h aufgerufen. Die Funktion wartet nicht auf 
einen Tastendruck, sondern setzt das Zero Flag oder nicht.
Das will ich auswerten an der Stelle direkt nach "int 0x16".
Eigentlich müsste da doch ein JZ (jump if zero) hin? Denn wenn ich da 
ein JZ habe, dann springt er sofort nach gotkey, auch wenn nichts 
gedrückt wurde. Mit JNZ springt er erst beim ersten Tastendruck dorthin.
Dann allerdings die ganze Zeit, bei jedem Durchlauf wieder.

Ich hoffe, ich habe die Dokumentation richtig verstanden... Zwei Fragen 
ergeben sich jetzt. Wieso JNZ statt JZ? Wie sage ich dem BIOS, dass ich 
den Tastendruck abgeholt habe und nicht dauernd wieder nach gotkey 
laufen will?

keyboard_handler:
         mov  ah, 0x11  ; get keyboard status without wait
         int  0x16      ; on return: ZF=0 if key pressed (data waiting)
                        ;            AX=0 if no scan code avail
                        ;            AH=scancode
                        ;            AL=ascii char or special function key
         jnz  gotkey
         nop
         ret
gotkey:
         mov   [rcv_key], al  ; receive ascii code of pressed key
         mov   dh, 6
         mov   dl, 10
         call  set_curs
         mov   al, [rcv_key]
         mov   bl, 0x47
         call  put_char
         ret
rcv_key db 0x00  


footer:  mov   dh, 20     ; row
         mov   dl, 0      ; col
         call  set_curs
         mov   cx, 400    ; 80x5 = 400 chars
loopfs:  push  ax
         push  bx
         push  cx
         push  dx
         call  rand       ; 8bit rand in AL
         mov   bl, al     ; BL=color for put_char
         mov   al, '%'    ; char to put
         call  put_char
         call  inc_cursor
         call  keyboard_handler  
         pop   dx
         pop   cx
         pop   bx
         pop   ax
         loop  loopfs
.hang_forever:  jmp  footer

Ich Teste das ganze in qemu und ab und zu dann auf echter Hardware. Auf 
beiden gab's schon unerwartete Phänomene...

[Clemens L. (c_l)]

Nils S. schrieb:
> Wie sage ich dem BIOS, dass ich den Tastendruck abgeholt habe

Das geht nicht. Aber du könntest den Tastendruck einfach abholen (Fkt. 
10h).

[Nils S. (kruemeltee)]

Vielen Dank, Clemens!

Ich dachte, wenn ich 10h verwende, dann lande ich bei gotkey und dort 
wartet er wieder auf einen Tastendruck.
So ist es genau das, was ich will:

keyboard_handler:
  mov  ah, 0x11
  int  0x16
  jnz  gotkey
  ; no keypress happened
  ret
gotkey:
  mov  ah, 0x10
  int  0x16    ; get keypress
  ; al has ascii of pressed key now
  ret

[Georg (Gast)]

Nils S. schrieb:
> und dort
> wartet er wieder auf einen Tastendruck.

Nicht wenn du vorher per Funktion 11h festgestellt hast, dass eine Taste 
verfügbar ist. Das ist der Sinn der Sache.

Georg

[Nils S. (kruemeltee)]

Georg schrieb:
> Nicht wenn du vorher per Funktion 11h festgestellt hast, dass eine Taste
> verfügbar ist. Das ist der Sinn der Sache.

Ja, so ist das ganze dann doch schlüssig. Aber erstmal ist das eine ganz 
neue Welt...

[c-hater (Gast)]

Nils S. schrieb:

> Ja, so ist das ganze dann doch schlüssig. Aber erstmal ist das eine ganz
> neue Welt...

Eigentlich ist es eher eine alte Welt.

Aber nur, was den PC betrifft. Im µC-Bereich sind solche 
Tastaturschnittstellen auch heute noch "state of the art". Und zu Recht. 
Denn sowas ist um Größenordnungen effizienter als z.B. die Blähungen, 
die Tastatureingaben unter etwa Windows oder Linux durchlaufen müssen, 
bis sie dann irgendwann endlich zur Anwendung durchdringen...

Wenn man sowas mal mit einem Debugger wirklich durch alle Schichten der 
Software verfolgt hat, dann sehnt man sich doch sehr intensiv nach dem 
guten alten BIOS zurück, wo alles noch dermaßen klar und simpel war...

[Nils S. (Gast)]

Ich habe mich heute auch noch durch den Code eines AT-Bios gewühlt um 
ein paar Sachen herauszufinden und war doch erstaunt wie einfach das 
alles eigentlich gehalten ist.

Leider kam ich zum Schluss, nun wohl doch direkt mit dem kbc zu reden. 
Ich brauche auch Key-Release-"Events", an die ich Anfangs nicht gedacht 
habe. Mit den Interrupts kam ich da zu keiner Lösung.
Etwa 100byte noch für die kbc-Kommunikation und eine State-Machine, die 
10 Tasten-Drücke und Loslassen auswerten soll und entsprechend 
springen...