Interrupts?
-
WhoDoo
Interrupts?
I just started writing a C-kernel. I found an article that said that I cannot use interrupts when being in protected mode? is that true? I tried some inttrupts, using inline-ASM, in my kernel and the computer just rebooted. What can I do in PM, any interrupts or how should I plot pixels, reboot the computer, wait for the user to press a key, and so on?
-
Curufir
Re:Interrupts?
What they mean is you can't use the BIOS interrupts.
When in protected mode interrupts are handled differently. Software interrupts work just fine in protected mode (Most OS use one for their system calls), but until you write some code to actually handle them then calling an interrupt will just result in a triple fault which will show up as a reboot.
Basically all the BIOS code that does things like disk drive operations, printing, plotting, keyboard input, etc is no longer there when you are in protected mode. If you want similar functionality you're going to have to write your own routines to interact with the hardware. Protected mode gives you a blank canvas, paint on it what you will ;D.
When in protected mode interrupts are handled differently. Software interrupts work just fine in protected mode (Most OS use one for their system calls), but until you write some code to actually handle them then calling an interrupt will just result in a triple fault which will show up as a reboot.
Basically all the BIOS code that does things like disk drive operations, printing, plotting, keyboard input, etc is no longer there when you are in protected mode. If you want similar functionality you're going to have to write your own routines to interact with the hardware. Protected mode gives you a blank canvas, paint on it what you will ;D.
-
Whodoo
Re:Interrupts?
Thank..how does these interrupts work? If I want to do somthing real simple, e.g. wait for the user to press a key..would be very nice with just a few lines of source 
-
Curufir
Re:Interrupts?
Unfortunately it's not something you can do in just a couple of lines of code.
Steps to getting a keypress (Just the keypress) might be something like this.
When setting up your kernel:
Disable interrupts.
Setup an IDT which includes an interrupt gate in the IDT that points to your keyboard handling routine.
Remap the PICs so that the keyboard IRQ calls your keyboard handling interrupt.
Unmask the PICs for only the keyboard IRQ.
Enable interrupts.
Now when someone hits a key the keyboard handling interrupt will be called.
When handling you might want something like:
Pull the scancode of the key from the keyboard buffer
Use some memory location as a flag to indicate a key has been pressed.
Store the scancode in a buffer somewhere.
Acknowledge the IRQ and IRET out of the keyboard handling routine.
Then when you need to wait for a keypress you can just put in a busy loop that checks the state of the flag to see if a key has been pressed (I'd advise using an HLT in the loop).
***
That scheme isn't set in stone (Ask a question in this forum and you'll usually get a different answer from each person), but can at least be expanded for when you want real keyboard input. As you can see there are a few steps, and of course you'll need to know how to program the PICs/Keyboard controller. Setting up interrupts/IRQ/Exception handling isn't that difficult, but it's something you're going to have to do.
Welcome to OS programming, where you're handed a box of straws and are trying to build a skyscraper ;D.
***
Note that one alternative to this is to drop back to real mode and use the BIOS interrupts for your keypress detection. IMHO figuring out the switch back is likely to prove more difficult than just implementing interrupts and will just stall your OS development (Which is why I didn't bother explaining it).
The choice is, of course, yours.
Steps to getting a keypress (Just the keypress) might be something like this.
When setting up your kernel:
Disable interrupts.
Setup an IDT which includes an interrupt gate in the IDT that points to your keyboard handling routine.
Remap the PICs so that the keyboard IRQ calls your keyboard handling interrupt.
Unmask the PICs for only the keyboard IRQ.
Enable interrupts.
Now when someone hits a key the keyboard handling interrupt will be called.
When handling you might want something like:
Pull the scancode of the key from the keyboard buffer
Use some memory location as a flag to indicate a key has been pressed.
Store the scancode in a buffer somewhere.
Acknowledge the IRQ and IRET out of the keyboard handling routine.
Then when you need to wait for a keypress you can just put in a busy loop that checks the state of the flag to see if a key has been pressed (I'd advise using an HLT in the loop).
***
That scheme isn't set in stone (Ask a question in this forum and you'll usually get a different answer from each person
), but can at least be expanded for when you want real keyboard input. As you can see there are a few steps, and of course you'll need to know how to program the PICs/Keyboard controller. Setting up interrupts/IRQ/Exception handling isn't that difficult, but it's something you're going to have to do.Welcome to OS programming, where you're handed a box of straws and are trying to build a skyscraper ;D.
***
Note that one alternative to this is to drop back to real mode and use the BIOS interrupts for your keypress detection. IMHO figuring out the switch back is likely to prove more difficult than just implementing interrupts and will just stall your OS development (Which is why I didn't bother explaining it).
The choice is, of course, yours.
