OSDev.org

Hello,
I know almost everything about the PIC and its reprogramming but I don't know how to use it practicly (How to link it with my hardware drivers).
I also have another question regarding the "hlt" instruction. Isn't supposed to halt the CPU? I tried to put it in my OS but CPU usage remained 100%.
Thank you for any help.

The "hlt" instruction will stop the CPU until the next interrupt occurs. Then it will run the ISR and then continue with the code after the hlt instruction. If you want to hang without 100% usage try the following:-
Pete

note that depending how your PC emulator is configured may leave you with 100% CPU usage or not when the virtual processor is idle.

If there are soo much interrupts to handle on the VPU or if the VPU tries to maximize the 'useful' job by immediately issuing the next timer IRQ when the cpu has no instruction to execute, you'll end up with 100% cpu usage (on your real cpu) even when the emulated one is asleep ...

hello,

I have four questions:
1- I reprogrammed the PIC and redirected the keyboard IRQ to my keyboard handler but there's a little problem: when I press a key, it is printed to screen but when I press one more key nothing gets printed. Bochs is telling me that the keyboard internal buffer is full. What is this buffer all about and is it possible to make it bigger?
2- What do I have to include in my keyboard handler other than the code that reads the keyboard port for a key?
3- When an IRQ is being called, the PIC will tell the CPU what happened... but how can the OS know that? I'm asking that question because when I will be making my shell how will I be able to know that the user pressed a key and that I have to insert it in a buffer and than parse the buffer to execute a specific command.
4- Another thing, when I use the "hlt" instruction, Bochs tell me "WARNING: HLT instruction with IF=0!". What does this mean?
Thanks for any help.

ManOfSteel wrote: 2- What do I have to include in my keyboard handler other than the code that reads the keyboard port for a key?

Well, what I have, the handler "translates" the scancode to a normal key, for example, if an A is pressed, the handler will make it an A.

3- When an IRQ is being called, the PIC will tell the CPU what happened... but how can the OS know that? I'm asking that question because when I will be making my shell how will I be able to know that the user pressed a key and that I have to insert it in a buffer and than parse the buffer to execute a specific command.

Simple, if IRQ0 is called, it calls the interrupt handler that's hooked to that interrupt.
The interrupts depends on where you programmed it to, the most common solution is 0x20 till 0x2f (slave included).
So, IRQ0 will be interrupt 0x20.

4- Another thing, when I use the "hlt" instruction, Bochs tell me "WARNING: HLT instruction with IF=0!". What does this mean?
Thanks for any help.

IF means interrupt flag, if it's zero, you disabled interrupts.
If it's disabled, and you do an HLT command, the "computer" will halt.

ManOfSteel wrote: hello,

I have four questions:
1- I reprogrammed the PIC and redirected the keyboard IRQ to my keyboard handler but there's a little problem: when I press a key, it is printed to screen but when I press one more key nothing gets printed. Bochs is telling me that the keyboard internal buffer is full. What is this buffer all about and is it possible to make it bigger?

Each key received by BOCHS is temporarily stored until the virtual PC can handle it. afaik, there's no way to extend the size of that buffer nor any reason to want it to be extended.

If you don't get anything past the first keystroke, make sure you sent a "end of interrupt" signal to the PIC (no, auto-EOI doesn't work on a PC) and that you have no mouse handler messing with the 8042 atm.

Hi,

It's a bit off-topic, but Auto-EOI does work for the first PIC chip (on all computers I've tested), but doesn't work for the second PIC chip.
Can become (with Auto-EOI):
Using Auto-EOI prevents the PIC chip from prioritizing IRQs (which may be bad), but can save some (slow) IO port writes.


Cheers,

Brendan

Hello,
Thanks everybody, everything is much clearer now.
Now, can you tell me what are the basic things I should include in my IRQ handlers? Should IRQ 2 and 9 be handled?
Thanks for any help.

ManOfSteel wrote: Now, can you tell me what are the basic things I should include in my IRQ handlers?

What do you mean ?
The only basic thing in my IRQs are EOI, resetting DS to 0x10.
It all depends what the IRQ is meant for

Should IRQ 2 and 9 be handled?

No, I don't think so, I don't have it handled.

Hi,

ManOfSteel wrote: Now, can you tell me what are the basic things I should include in my IRQ handlers? Should IRQ 2 and 9 be handled?

IRQ 2 should be left unmasked in the PIC, so that it is never generated. IRQ 9 should be treated the same as any other IRQ from 0x08 to 0x0F.


Cheers,

Brendan

Now, can you tell me what are the basic things I should include in my IRQ handlers?

What do you mean ?

In the keyboard IRQ handler, I have to put code to take a key from the keyboard and pass it through the scan code table. What do I have to do, for example, with the floppy or HDD IRQ handlers (read a sector?) or with the timer IRQ handler (redefine the clock rate?), ...

ManOfSteel wrote: What do I have to do, for example, with the floppy or HDD IRQ handlers (read a sector?)

Yes, but remember, both can do DMA actions as well (the standard from the floppy driver, the most recommended way of transfering things)

or with the timer IRQ handler (redefine the clock rate?), ...

I update the clock..., and it you can place the scheduler there as well

The only thing that is common to all IRQs is that you have to acknowledge the end of interrupt to the PIC.

And no, i wouldn't bet my horse on the auto-EOI feature, since i've seen some weirdly simplified implementations that didn't behaved as expected (e.g. that let you enter parameters that would be meaningless with "real" 8259 chips wired as they should and still behave as if you entered the 'right' parameters)

What you have to do in (for instance) a floppy, HDD, nic IRQ depends on what you asked to the hardware in first place. In such systems, the IRQ is usually the notification of some command's completion (like the end of a DMA transfer, or the availability of some data in the controller's cache).