Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
You said you have a working IDT. Does that mean you have also remapped all of the IRQ's to higher interrupts (since the first 32 are system interrupts). Most people
remap the PIC so that IRQ0-7 go to 0x20 - 0x27
and IRQ8-15 go to 0x28 - 0x2f. If you have done that,
and re-enabled interrupts (STI), you should already be getting signals on your 0x21 routine (for IRQ 1.)
Just remember to do this at the end of your ISR for the keyboard interrupt:
mov al,0x20
out 0x20,al
...or your keyboard ineterrupt will fire only once!
Hope this helps.
Paul
Tom wrote:
COOL! I found out how to make my own interrupt ( 30h ) that prints whatever I want?
Are hardware interrupts slow?
If not, could I make my OS based ( verysmall partly ) on ints?
Thank you,
if you're in pmode, an interrupt is *really* slower than a function pointer. you should avoid interrupt calling as long as you remains in kernel mode (thus, having kernel-to-kernel interrupts is imho a bad idea).
for user-to-kernel, the only alternative is the call gate.
an INT instruction through an interrupt gate is about 99 cycles, and i guess the call gate will be roughly the same.
perhaps you can consider using SYSCALL extension (processor-specific: not the same code under AMD and Intel, unfortunately -- has a lot of context constraints, too
That's interesting because I was just thinking about this very same topic last night when I was trying to sleep. I was thinking how user programs would call the kernel. All of my kernel functions can be triggered with INT 40h but I was thinking of a faster way.
My kernel always resides at 0x100000 so couldn't user programs just call kernel functions directly? Their entry point would always be predictable. Of course, there should be a KERNEL.H file or something that assigns function names so you aren't just calling NUMBERS. So, I would do something like this:
fillscreen(0xffffff)
And kernel.h defines 'fillscreen' as being a function, with one integer parameter that points to 0x107324 (for example.)
You might want a JUMP table instead so that if you change your kernel code, you don't have to regenerate your function header file. (not to mention corrupting any user programs you already wrote.) And if this jump table came at the BEGINNING of your kernel, the jump table itself will not get moved when you add/delete kernel code. Of course, you would need a jump PAST the jump table at the beginning.
My kernel always resides at 0x100000 so couldn't user programs just call kernel functions directly?
No, don't do this. Provide a way of calling kernel functions through interrupts.
The reason for this is that the kernel code will want to run in ring 0 (privileged) whereas user code needs to be in ring 3 (unprivileged). If ring 3 code tries to call ring 0 code the CPU will trigger a page fault or general protection fault.
Interrupts are slower than normal function calls but the protection is worth it. If you're worried about the speed decrease, consider putting more code into the kernel. For example, instead of calling the kernel once per graphics command, why not batch commands in a memory block then trigger a kernel interrupt and pass that block? Then the kernel can run through each command in the block before returning.