Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Software Interrupts 2

Status
Not open for further replies.

BagelBob

Programmer
Apr 13, 2001
7
US
I'm as nubie as nubie can get - if I told you my background
you wouldn't believe it.
If you think my querry would best be answered by "reading a
good book", I would appreciate an Author, Title, Publisher
and Copywrite. Similarly, if you know of a tutorial which would answer the question, how about a URL?
If you can think of a tech-forum more suited go my level of
(non) knowledge, I'm all ears.
Now, the question:
I'm confused, perhaps fuzzy would be a better characteriza-
tion, about software interrupts.
Does every os have an IVT?
Is there some sort of convention about interrupt identifica-
tion and function? I know that if I'm running my program
under DOS I can put the service identifier in reg A and do
an int 21h (DOS Services). But, what if I'm not in DOS?
Does int 21h call some other os code module in some other
os? Is there an 80h in DOS, or is this somehow "reserved"
for Linux(Unix?). And, if they are reserved, who sets the
Standards?
And, what about the BIOS interrupts? My BIOS is my BIOS, so
I ASSUME that a 10h or 11h is independent of the os, but I
really don't know - could it be that they work together, i.e., if I fire off an int 10h while under DOS will it grab
the same code off the CMOS as under some other (unprotected)
os? Since BIOS is proprietary software, will my Award 6.0
have the same interrupts as some other vendor's? - in terms
of function, not code, of course. In short, across different BIOS's and OS's does int xx always have the same
inputs and (more importantly) outputs? And, if so, who
gives out the code and enforces the usage? It's all quite
fuzzy to me.
 
You can say that there aren't much standards around the interrupts area just because of efficiency. So interrupt xx won't do the same in all OSs. Also DOS interrupts are invented because all BIOSs are/used to be different; so DOS interrupts are actually some sort of standardization.
If you want to know all the functions of all interrupts under DOS, I advise you to check out Ralph Brown's Interrupt List: Regards,
Bert Vingerhoets
vingerhoetsbert@hotmail.com
Don't worry what people think about you. They're too busy wondering what you think about them.
 
Now correct me if I'm wrong, but the Interrupt Address Table for the x86 family of processors has to be hard coded due to the microcode in the processor. When an Int signal is given, the processor has to know where to transfer control to in order to handle. For the x86 family of processors, The addresses for these routines are contained in the first 1024 bytes in memory, irrespective of OS. It is my understanding that this is hardwired into the processor and cannot be changed. However, just what those Interrupt routines do is determined by the OS.
 
Dear brother prattart,
I doubt ur understanding. As such there is no
MicroCode assosiated with the processor.
Ur understanding about where the IVT is located
is PUCCA if x86 was in real mode ! The behaviour of
x86 in PM is different for interrupts. In PM they call it as IDT (interrupt descriptor Table . This Table can be
anywhere in memory. The address of which is loaded in
memory by an "LIDT" instruction ( avail only in PM ).
All these is reqd for the processor to get the Vector
Address when an interrupt comes !

Let me throw some light on what happends when an interrupt
is issued by a device. x86 processors have only 1 interrupt
line. This line has to be shared by all IO devices.
SO IBM ( i think so) people came up with 8259, PIC which
would route interrupts from various IO devices into the
processor. PICs can be cascaded to support nearly 64 devices. In case of SMP motherboard, there are something
called IOAPIC, Local APIC. These are all quite advanced
ones.
The interruot that is fired from the device reach the
8259 which inturn checks priority etc etc... and asserts
the INTR line of the processor.
The processor instantly saves the PC and flags and
queries the PIC for more information by asserting the INTA
( Interrupt acknowledge ).After that the processor starts an "INT" instruction cylce. PIC parallely returns
a number ( say 'n' ), so that the processor effectively
executes a "int n" s/w instruction.

Its the job of the OS to program the PIC ( Program Interrupt Controller, 8259 ) for "n"s. For exp,
in DOS timer always hits you at INT 8 because, DOS
programs the PIC to generate Vector numbers starting from
8. So the next IRQ keyboard hits u at 9 and so on
and in LINUX timer would interrupt at INT 32 (coz 0-31 are reserved for processor exceptions in PM).

If this seems to be interesting for u,
visit "I have a collection of reference materials that i am
using to write a small OS.( PM, 386 ). It would be very instructive for you. I have also put the sources therein.

Warm Regards,
Sarnath.K
Do not rejoice that ur code works.
it might be a special case of an error :-(
 
Every OS has to have an IVT because the 80x86 series expects an IVT.

Windows and OS/2 gives a "compatibility box" which separates DOS programs from native Windows and OS/2 programs. Windows and OS/2 provide services which emulate the DOS calls.

Generally, ah (the high byte of the ax register) is used for the function code, and al for the subfunction if any. With the mouse (Int 33h), however, ax contains the function code.

Standards are set by the "survival of the fittest" scheme. If your system is used a lot, then the interrupts it uses become standard.

Some extensions *might* change Int10h and other interrupts, but you can be sure that they will pass on whatever they can't handle to DOS or BIOS. If they change a function you need, these extensions usually attempt to react in ways compatible to the expected operations.

Most "IBM-PC compatibles" nowadays offer compatibility down to the herware level. This generally implies that compatibiltiy exists at the BIOS function level also. So AWARD BIOS's will react similarly to Pheonix or IBM BIOS's with regards to the functions. *SOME* differences (due to bugs or misconceptions) exists but you'll need a manual for that....

How bout this:
DOS Programmer's Reference
written, edited and published by Que Corporation
4th edition is copyright 1993.

I got a local reprinted version for about 189.90 Philippine Pesos, or about 4 American dollars some years ago.
 
Every OS has to have an IVT because the 80x86 series expects an IVT.

Windows and OS/2 gives a "compatibility box" which separates DOS programs from native Windows and OS/2 programs. Windows and OS/2 provide services which emulate the DOS calls.

Generally, ah (the high byte of the ax register) is used for the function code, and al for the subfunction if any. With the mouse (Int 33h), however, ax contains the function code.

Standards are set by the "survival of the fittest" scheme. If your system is used a lot, then the interrupts it uses become standard.

Some extensions *might* change Int10h and other interrupts, but you can be sure that they will pass on whatever they can't handle to DOS or BIOS. If they change a function you need, these extensions usually attempt to react in ways compatible to the expected operations.

Most "IBM-PC compatibles" nowadays offer compatibility down to the herware level. This generally implies that compatibiltiy exists at the BIOS function level also. So AWARD BIOS's will react similarly to Pheonix or IBM BIOS's with regards to the functions. *SOME* differences (due to bugs or misconceptions) exists but you'll need a manual for that....

How bout this:
DOS Programmer's Reference
written, edited and published by Que Corporation
4th edition is copyright 1993.

It includes BIOS, EMS, XMS, DPMI, Mouse, Task Swapping, as well as DOS interrupts. Couple of errors (usually in sample code - don't enter the code, just study it, there are a few bugs there which become abvious upon study). Later editions may have corrected them.

I got a local reprinted version for about 189.90 Philippine Pesos, or about 4 American dollars some years ago.
 
Does anyone have sample code for loading the Interrupt Descriptor Table? I would be very interested in seeing that.
 
Cboxgo,
I have a sample code at my page Jus download small kernel i had developed ( just 40k )
directory "kernel/386traps.c" or "kernel/386intr.c".

Hope it helped

Sarnath
Do not rejoice that ur code works.
it might be a special case of an error :-(
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top