OSDev.org

Hey everyone,

For anyone who does not know, we have just finished updating our 8259A Programmable Interrupt Controller (PIC) tutorial.

Direct Link

This tutorial is fairly advanced. It covers:

• Interrupt Types- Hardware and Software.
• Hardware Interrupt Modes.
• Interrupt Vector Table (IVT) Concepts.
• IVT Map.
• PMode interrupt handling concepts.
• Hardware Interrupts
• 8259A Programmable Interrupt Controller (PIC)- Pin layout.
• 8259A Hardware connections.
• How hardware interrupts generate and execute.
• 8259A Internal and External Registers.
• 8259A Software IO Port Mappings.
• 8259A Commands.
• Initializing the 8259A PIC.

I still plan on adding some more information to the tutorial, such as history information. For the most part, I believe it is done.

Please let me know what you think, if you have any suggestions, comments, questions, or have any more information you would like to add.

Also, remember that this series is specifically meant for beginner systems developers. If you see anything that might be confusing, please let me know.

Thanks,

~Mike();
OS Development Series Editor

Hi,

neon wrote:Please let me know what you think, if you have any suggestions, comments, questions, or have any more information you would like to add.

I had a quick look (it looks good) - some notes...

1) You probably should mention local APICs and I/O APICs (even if all you do is say that they exist and aren't covered in the tutorial).

2) It'd be good to mention the PIC chip's spurious interrupt, why it's there and how an OS is meant to detect them and handle them.

3) In a few places you say "the processor has it's own internal PIC Microcontroller". AFAIK this is entirely wrong for 80x86 (even for modern AMD CPUs that have inbuilt memory controllers), and the PIC chips are built into the "PCI to LPC bridge" (or the chipset's southbridge). I'm wondering if you were thinking about the local APICs (which are built into the CPU, but are completely different and normally don't handle IRQs).

4) In the part about the Interrupt Mask Register (and possibly other places), you say "The 8259A Masks out all other interrupts until it recieves an End of Interrupt (EOI) signal". This isn't right - only lower priority IRQs are prevented. For example, if the PIC is waiting for an EOI for IRQ5, then IRQ4 won't be blocked but IRQ6 will be. The priorities go in this order: 0, 1, 8, 9, 10, 11, 12, 13, 14, 15, 3, 4, 5, 6, 7 (for e.g. IRQ 9 is higher priority than IRQ 3, which doesn't make sense until you think about how the cascade works). There's unused/unusual modes that mess with this (e.g. rotating priority, auto-EOI, etc), but they really aren't worth worrying about. Some OS's bypass the PIC's priorities (mask the IRQ in the PIC and send the EOI, then handle the IRQ, then unmask the IRQ) - I'm not convinced it's a good idea though (3 times as many expensive I/O port accesses).

5) I don't think you mention anywhere that for IRQs 8 to 15 you need to send an EOI to the slave PIC and the master PIC (unless it's a spurious IRQ 15, in which case you only send an EOI to the master PIC IIRC).

Hope that helps...


Cheers,

Brendan

Hello,

You are correct in that the 8259A's are built into the southbridge chipset. I am going to fix that asap. Thanks for letting me know.

All of the suggestions are great, and I thank you for taking a look I will see if I can add more content tomorrow, including all of your suggestions (As they are great )

Thanks again, and I am always looking for suggestions to help improve these tutorials.

neon wrote:Thanks again, and I am always looking for suggestions to help improve these tutorials.

One small error: in a table it says that IRQ9 is the CGA vertical retrace. This is wrong of course, since 1) the CGA does not interrupt on VR and 2) the PC-XT didn't have a second PIC in the first place (probably hit the C instead of the V key?). The PC-XT did use IRQ5 for the HDD however, if you like to mention that.


JAL

Hi,

jal wrote:One small error: in a table it says that IRQ9 is the CGA vertical retrace. This is wrong of course, since 1) the CGA does not interrupt on VR and

AFAIK the CGA and EGA do have vertical retrace interrupts. VGA and SVGA cards may or may not.

jal wrote: 2) the PC-XT didn't have a second PIC in the first place (probably hit the C instead of the V key?). The PC-XT did use IRQ5 for the HDD however, if you like to mention that.

The PC-XT would have used IRQ2. For backward compatability, when they added the slave PIC the IRQ 9 handler in the BIOS was a stub that called the IVT entry for interrupt 10 (where IRQ 2 would have been), so that older code that expected IRQ 2 still worked even though it was actually IRQ 9. Modern BIOSs still do this.


Cheers,

Brendan

Brendan wrote:

jal wrote:One small error: in a table it says that IRQ9 is the CGA vertical retrace. This is wrong of course, since 1) the CGA does not interrupt on VR and

AFAIK the CGA and EGA do have vertical retrace interrupts. VGA and SVGA cards may or may not.

I am absolutely 100% positive the CGA does not have an interrupt on vertical retrace. EGA and (older?) VGA do.


JAL

Hi,

jal wrote:

Brendan wrote:

jal wrote:One small error: in a table it says that IRQ9 is the CGA vertical retrace. This is wrong of course, since 1) the CGA does not interrupt on VR and

AFAIK the CGA and EGA do have vertical retrace interrupts. VGA and SVGA cards may or may not.

I am absolutely 100% positive the CGA does not have an interrupt on vertical retrace. EGA and (older?) VGA do.

You're right - it was EGA..


Cheers,

Brendan

Thanks for the feedback! I will see if I can fix those errors by the weekend.

Speeking of video, I started working on a VGA programming tutorial. I am still deciding on how I should format it though, as it covers several controllers, such as the DAC, CRT, VGA, et al. Like this tutorial, I want to cover everything as deep as possible.

I plan on staying 32 bit as well, and no Bios. Unlike this tutorial, the video one will include alot of examples in tested C++ that may be used in a 32 bit kernel. Please note, it only includes examples to help demenstrate things. It does not show how to develop a video driver by any means.

It will take awhile for this tutorial, so I decided to start it now.

Any more suggestions are always appreciated

Thanks!

neon wrote:Speeking of video, I started working on a VGA programming tutorial. I am still deciding on how I should format it though, as it covers several controllers, such as the DAC, CRT, VGA, et al. Like this tutorial, I want to cover everything as deep as possible.

Don't, it's a waste of time. There are plenty of good VGA tutorials around, and VGA is really a thing of the past. Noone wants to program the VGA. VESA perhaps, but not VGA. And to cover everything "as deep as possible", you'd have to go the way of Ferraro, or at least the FreeVGA project.

I plan on staying 32 bit as well, and no Bios.

You can't do a proper mode switch without BIOS. All other VGA BIOS calls are indeed not usable, but the world has known this since the late 80s.

Unlike this tutorial, the video one will include alot of examples in tested C++ that may be used in a 32 bit kernel. Please note, it only includes examples to help demenstrate things. It does not show how to develop a video driver by any means.

I really don't see the point of it. Like I said, there are plenty of VGA tuts around, with tons of source code examples. And nobody wants to program plain VGA, unless your taking on some embedded device that has VGA.

It will take awhile for this tutorial, so I decided to start it now. Any more suggestions are always appreciated :)

Stop right now, and focus on something more usefull. Like a VESA tutorial. That could be mildly interesting.

Thanks!

You're welcome. I just saved you a lot of work.


JAL

jal wrote:You can't do a proper mode switch without BIOS.

There's a link on this page about switching VGA modes without using BIOS calls - it does seem to have a lot of library references that an OS would have to support, though...

Cheers,
Adam

Not to mention the listings on the wiki: VGA Hardware, so yes you can change modes without using the bios. All it takes is a driver, and most chips support the VGA register set anyway.

I can even get 800x600x16 out of most cards without using the bios

@neon: I really think there's enough information around already. Besides I wrote the mentioned wiki article to properly document the details of the video card and have something more useful than FreeVGA. Problem is that all the details are cross-checked over many video cards to get a good idea of what's happening. If you intend to supply free code, I invite you to add them to the wiki instead.

AJ wrote:There's a link on this page about switching VGA modes without using BIOS calls - it does seem to have a lot of library references that an OS would have to support, though...

Well, on a standard, non-SVGA VGA card, it's fairly easy (just a few arrays of register writes). And perhaps nowadays, nVidia, ATi and Intel emulate the VGA perfectly on start-up. I do remember however, that in the early days of SVGA cards (during which I was actively doing all sorts of low-level hardware and graphics programming), most SVGA cards failed to initialize properly, as they needed various of their extended registers to be initialized as well, even for (or maybe even to enter) VGA emulation mode.


JAL

Combuster wrote:Not to mention the listings on the wiki: VGA Hardware, so yes you can change modes without using the bios. All it takes is a driver, and most chips support the VGA register set anyway.

Yes, a driver substitutes the BIOS (I'm not claiming modern OSes use the BIOS to switch modes). But many video cards may (as I said in my reply to AJ, it's been a while since I actually programmed gfx cards, so I might be wrong) need additional, non-standard VGA registers to be set before they are properly intialized.


JAL

jal wrote:But many video cards may (as I said in my reply to AJ, it's been a while since I actually programmed gfx cards, so I might be wrong) need additional, non-standard VGA registers to be set before they are properly intialized.

Actually, they don't

Combuster wrote:Actually, they don't :wink:

Are you talking about recent cards, or also the old ones (S3, ET3000/4000, etc.)? I specifically remember having problems with some of those back then.


JAL