On 21 Jan 99, at 19:10, Dave Perry wrote:
> Can someone clear this one up for me?
>
> Before you install an operating system on a computer where are all
> the IRQ and I/O addresses kept for all the hardware on your system?
Short question, with a long answer.
The Intel x86 CPUs include an INTerrupt instruction. "INT 08" tells
the CPU to save some status information (including where it is in the
current program) and jump to the code pointed to by the 8th (well,
actually ninth, because there's a 0th) entry in the IVT (Interrupt
Vector Table).
That's a mouthful, but in "DOS" real mode, the IVT is just the bottom
1K of RAM -- 256 32-bit addresses. The ROM startup code will set
initial values in this area, and then the OS and other programs may
insert their own code pointers to take over some functions.
How does this relate to IRQs? Well, when any IRQ line is signalled,
the CPU saves its current status (just like for the software INT
instruction), finds out what IRQ line was signalled, adds that to a
special offset value, and uses the result as the index into the IVT.
IRQs 0-7 are almost always mapped to IVT entries 24-31. [Those were
all there were on the original PC and XT, so entries starting at 32 got
assigned for other uses. IRQs 8-15 therfore use a different offset,
and are mapped higher up in the IVT.]
When the ROM BIOS initializes the IVT, it has two basic choices --
point an entry at a trival piece of code that will ignore the interrupt
and resume execution, or point it at code in the ROM that handles that
interrupt. It's generally going to do the latter for many IRQs, and
for some interface routines reached through IVT entries 16-23. IVT
entry 19 will be pointing to a set of disk-handling routines, which
will be used to read the MBR (Master Boot Record), which contains code
that will start up the OS.
The initial IRQ handlers installed by the ROM BIOS only know about
device addresses and IRQs that are (a) well-known/traditional/standard
or (b) configured in the CMOS setup or (c) assigned by PnP. Any
additional settings may need to be passed as parameters to device
drivers loaded by the OS.
I hope that answers your question.
David G
The PCBUILD web site always needs good submissions. If
you would like to contribute to the website, send any
hardware tech tips or hardware reviews to:
[log in to unmask]
|