Some collected history about the x86 interrupts

Nilesh: I figured out some things ....
Nilesh: pan barech shya goshti maahiti nahin aahet
Uv: for example ?
Nilesh: for ex: IRQ kaase assign hotat
Uv: IRQ is dependant on legacy architecture decisions
Uv: the x86 family always had a single interrupt line
Nilesh: that is the old 8259 Interrupt controller na ?
Uv: as a result multiple devices that wanted to interrupt the processor had to follow an elaborate procedure to inform the main processor that 1. I want to interrupt you 2. "I" am <specific> device
Nilesh: and you could optionally cascade another one on it ?
Uv: correct
Uv: the 8259 takes of those devices that would not be able to talk in the language of x86
Uv: *takes care
Uv: x86 <-> 8259 <-> upto 8 devices
Uv: the alternate (and actually the most common hardware configuration) is:
Nilesh: right did that mean that with 8259 controller the maximum devices that could connect were 8 and 15 if cascaded ?
Uv:correct
x86 <--> 8259 <--> 7 devices
+<---> cascaded 8259 <--> 8 more devices
Uv: giving a total of 15 connectable devices
Uv: but now think about this:
Nilesh: ok ?
Nilesh: how would a driver know that its device is on this specific IRQ line ?
Uv: how can cascading be possible without those 8259's talking to each other and establishing a strict discipline about what to tell the x86 proocessor ?
Nilesh: correct yes they should have a understanding between them
Uv: first lets look at what x86 wants
Nilesh: ok
Uv: whenever x86 gets a signal on its one and only interrupt line, it waits for "someone" to put an additional data byte explaining the IRQ that fired
Nilesh: I see
Uv: the original idea (historical) was that the devices would be able to define this on their own
Nilesh: right
Nilesh: so would specific devices have to be connected to specific lines ?
Uv: but device manufactures told Intel to go sod off because it would unecessarily add cost and complexity to their simple devices
Uv: thus the 8259 was born
Uv: something that would just have interrupt inputs on its right edge for "simple" devices
Uv: and on its left edge, it would have a single interrupt line output and enough circuitry to feed the x86 the IRQ that caused the interrupt
Nilesh: hummm I making some sense out of this
Uv: before i386, this IRQ value was directly used to offset into the interrupt dispatch table
Uv: IRQL value right shifted by 2 (3?) to get offset value
Uv: sorry left shifted
Uv: i dont remember the exact shifting count - and right now too distracted to calculate it myself
Nilesh: :)
Nilesh: OSR vaale he kaahich shikvat naahin
Uv: this information could be a part of a more expensive "advanced course"
Uv: I dont know
Uv: nevermind
Nilesh: no they are pretty tight fisted about sharing finer details
Uv: in i386 and later, depending on the current mode of the processor, either the real mode IVT (offest from real address 0x0) or the protected mode interrupt descriptor table (IDT that can be located anywhere in memory) is used
Uv: but if you remember (if you have done) DOS assembly programming, you will remember that you had to actually write the address of your interrupt handler in the table
Nilesh: yes I remember that I wrote a few TSRs
Uv: there always was a previous value that you had to save... remember?
Uv: someone used to pre-fill those values... who was that ?
Nilesh: yes
Nilesh: let me guess
Nilesh: are you asking about SYS / COM file ?
Uv: that "someone" was a combination of the BIOS and DOS
Nilesh: I was about to say that.....
Uv: as part of boot up , the BIOS initialized some vectors, while DOS initialized others
Uv: 13h, 16h, 17h, were the "BIOS interrupts" and 21h was DOS umbrella interrupt
Nilesh: yes I guess 21 had file related interrupts etc
Uv: correct!
Nilesh: infact I had written a TSR that would prompt the user name a password if he would do a CD
Nilesh: cd to some directory
Uv: you said "file related interrupts" - which should indicate that the file system code was in int 21h.
Nilesh: right
Nilesh: I dont recollect the subcodes though
Uv: thats fine
Nilesh: I referred Ray Duncan for that
Uv: nevertheless, try remembering the lowest BIOS interrupt
Uv: the lowest BIOS interrupt was 10h
Nilesh: the timer ?
Nilesh: hummmm
Nilesh: I guess timer was 8 or 7
Uv: I mean software interrupt that provided "non-hardware" functionality
Nilesh: ok
Nilesh: I see
Uv: 10h = 16 decimal
Uv: thats the first number after 15
Nilesh: right
Uv: see the significance ?
Nilesh: hummm no
Uv: the first BIOS interrupt HAD to be at 10h because it could not reliably assign any of the lower vectors to software interrupts
Uv: because the 8259 could have 15 interrupts
Nilesh: ah right
Nilesh: how are your concepts so clear ?
Uv: party because I learnt assembly from my father :)
Nilesh: :)
Uv: the rest because I did electrical engineering
Uv: so anyways
Uv: how was it always certain that the timer interrupt was at IVT 8 and keyboard was always at 9?
Uv: etc?
Uv: and div by zero was 0 ?
Nilesh: because I guess DOS did that ?
Uv: I broke my head looking for an answer to this for a loooong time
Nilesh: or the Intel BIOS did that ?
Uv: nope the answer is not so technical as DOS or Intel decided it
Nilesh: ok
Uv: because if you look at the pure description of any x86 processor and the 8259, there is no place that says 8 MUST be timer
Nilesh: right
Uv: but think about it a bit: the first BIOS was created by IBM
Nilesh: ok
Uv: those guys had to write handlers for every device
Nilesh: right
Uv: and the hardware kept changing
Nilesh: hummm right
Uv: the sinplest way for them to reduce the constant changes
Nilesh: right
Uv: would be to make permanent the IRQ assigned to "standard devices" on a "standard motherboard"
Nilesh: right
Uv: and thus was born the IBM AT compatible motherboard standard
Nilesh: :)
Uv: some hardware designer just arbitrarily decided that IRQ 8 was the timer.
Uv: as simple as that :D
Nilesh: :))
Uv: and it became a standard that EVERYONE in the world followed
Nilesh: cool
Uv: now some IRQ were permanently set in stone
Nilesh: Keyboard ?
Uv: like the timer, the keyboard and mouse, etc
Nilesh: I see
Nilesh: the timer interrupt changed right ?
Uv: some others like the HDD and floppy became permanent later on
Nilesh: its no more 8 right ?
Uv: some others like sound cards still behave in non-standard ways
Nilesh: I see
Uv: timer is still 8 btw :D
Nilesh: I see
Uv: but! in protected mode, the IRQ and the IRQL are not related in the way they were in real mode
Nilesh: right
Nilesh: IRQL is CPU agnostic
Nilesh: ?
Uv: IRQ 8 is timer, but the IRQL at which the timer interrupt will run is IRQL 1
Nilesh: I see
Nilesh: right
Uv: the hardware interrupt and the software handler are two different things
Uv: even though their notifications (IRQ and IRQL) seem similar
Uv: btw, do you mind if I edit this conversation a bit and put it in my tech blog ?
Nilesh: absolutely
Uv: thanks
Nilesh: what is your blog URL ?
Uv: it will be a better idea to store it so others can also read
Uv: heh theres not much right now
Nilesh: Yuvraj thanks alot for spending your time explaining some basic stuff
Uv: no problems dude - its been a pleasure!
Nilesh: thanks
Uv: there is a little bit more to tell about interrupts though: if you want to hack at writing device drivers for standard devices on your own, then look at the AT and XT standards from IBM for reference.
Uv: that will give the IRQs that you are to hook to
Uv: and then read about Interrupts from MSDN / your favourite Windows Internals book
Uv: then the connection between many concepts should be obvious
Nilesh: wow that is a fabulous project to work on
Nilesh: sure I will take it up
Uv: enjoy! me goes back to work :)
Nilesh: sure thanks

Collected hacks for future reference

Using Skype on AMD64 Ubuntu.
Lord of the Ring0. This works with VirtualBox as well. The pipe name "\\.\pipe\com_1" should be used for VirtualBox - it doesn't come into the text box by default.
Configure OpenVPN on Windows.
Enable NVIDIA video drivers.
Sign Powershell scripts.
Installing UT2004 in Linux.
Unshield 64 bit.
Adding notepad to the the system context menu.