C++arl wrote:Hi!
My question is wether (spelling?) or not the keyboard ISR (IRQ 1, interrupt 0x21 in my case) should fire of by itself when registrating a keystroke, or does one have to call it 'manually' via a "int 0x21" command. Currently i have to manually call this ISR to get the scancode, but isnt that wrong? I have read that this ISR should fire of by itself if you've done everything right. I would be most gratefull if anyone could help me out on this one.
Just for the record:
I have enable interrupts, reprogrammed the PIC, set up a correct IDT and i know everything works fine because when i call other interrupts they function.
thx ~~ C++arl
There is a difference between Hardware Interrupts and Software Exceptions.
In your example, it looks like you remapped the IRQs to be just above the 32 reserved interrupts (positions 0x20-0x2F)... this should be fine. This would indeed make IRQ1 into Interrupt 0x21.
When a keystroke signals the appropriate lines and generates an interrupt, the CPU checks the established Interrupt Descriptor Table with an index that is based upon whatever Interrupt Number is assigned to the respective IRQ by the Programmable Interrupt Controller. If a valid Interrupt Descriptor is found at the entry that the index specifies, then the interrupt occurs... task/context switches and whatnot... and the specified interrupt routine executes.
So, basically, all you need to do is make sure the PIC is configured correctly, that your IDT and IDTR is setup correctly... and that there is appropriate code in place to run as the interrupt routine. Each time that a keystroke (scancodes, actually) occur, your IRQ1 routine can simply read the scancode byte from port 0x60... store it somewhere for processing... and IRET back to the running process.
If you have done this already, and it is not working... then you need to deduce what the problem could be. If you say that you can call INT 0x21 through software exception (INT instruction) then it should *ideally* work equally well when asserted by hardware. In this case, I would first have a routine to disable and re-enable the keyboard controller.
C++arl wrote:Turns out I have missed out the PIT. After some reading about it there is just one thing I dont understand about the PIT. How does the PIT help me in this?
When the PIT raises IRQ0, is IRQ0 then supposed to call IRQ1 to check if something was written?
If that is the way you want to do it. I, personally, only use the PIT/IRQ0 for task switching assurance and the system timer. If you want, your IRQ1 handler can read the scancode and call a routine that determines what to do with the scancode (e.g. translate to ascii and send as an event through IPC to process XYZ.)
