OSDev.org

When I tested my keyboard IRQ handler, the following strange thing happened:

(my kernel entered a waiting loop for character input)
(I pressed some key)
The keyboard IRQ handler was called and retrieved the scan code from port 60h. It received 0FAh (ACK).

Now there were two possibilities:

1. If I acknowledge receival of 0FAh by toggling bit 7 in port 61h, the keyboard controller fires IRQs with 0FAh in an endless loop.

2. Otherwise, no more IRQs are generated, no matter which key is pressed.

The same happens if I send a command instead of pressing a key.

What am I doing wrong?

Here is a simplify version of my keyboard IRQ handler, maybe it is usefull to resolve your problem:

isr_kerboard:

cli ; Disable interrupts

push ax
push bx
push cx

; Get the scan code and the control byte

in al, 0x60 ; Get the scan code
mov ah, al ; Move it to 'ah'
in al, 0x61 ; Get the control byte
mov bl, ah ; Save the scan code at 'bl'

; Acknowledge with an off/on sequence

or al, 0x80 ; B7=1
out 0x61, al ; Disable the keyboard
and al, 0x7F ; B7=0
out 0x61, al ; Enable the keyboard

; Here you must identify a possible extended key! (I not include it)

; Return the scan code into 'al'

mov al, bl ; Move scan code to 'al'

; Send acknowledge to the PIC (Needed to get another key interrupt)

mov al, 0x20 ; ACK command
out 0x20, al ; Send to the PIC

pop cx
pop bx
pop ax

sti ; Enable interrupts

iretd

The original IRQ handler do many more things, but I believe it is enough to resolve your problem. I don't remember were I get the code I conform later, but there is well information about keybord at:

http://www.nondot.org/sabre/os/articles ... aceDevices

Regards
pepito

Your problem may be that you are not telling the PIC that the interrupt has finished and therefore you will receive no more interrupts.

Add the following somewhere in the interrupt routine (must be in all IRQ interrupt routines).

mov al,20h
out 20h,al

This tells the pic to allow further interrupts. Dont change any bits in port 61h

Hope it works

That is exactly what my keyboard handler does. It sends 20h to the PIC.
If I change bit 7 in port 61h, I keep on receiving ACKs. If I don't, no more IRQs come through.

Now it works - as long as I don't press any xxxLock key. As soon as I try to switch the LEDs, I am bombarded with ACKs. Everything else works fine.