View Single Post
Old Oct 23rd, 2007, 8:08 PM   #4
lectricpharaoh
Caffeinated Neural Net
 
lectricpharaoh's Avatar
 
Join Date: Jun 2005
Location: Wet west coast of Canada
Posts: 889
Rep Power: 4 lectricpharaoh will become famous soon enough
Re: Questions about interrupts

Quote:
Originally Posted by Grich
Is int 21h still used?
If you're writing DOS programs in assembly, then yeah.
Quote:
Originally Posted by Grich
If there is an alternative, what is it?
The two main alternatives would be using the BIOS (which the INT 21H call might thunk down to, depending on the system and console drivers in place) and doing direct writes.

If you're interested in going via BIOS, be aware that it's generally a slow operation. Some of the BIOS character-mode output functions let you control color and stuff, which can be nice, but other than that, they offer nothing over the higher-level DOS calls. If you still want to go this route, grab yourself a copy of Ralf Brown's Interrupt List, which is an invaluable resource for any x86 DOS programmer (side note: Ralf's port list is also great if you want to do hardware fiddling via port I/O).

If you're interested in direct video writes, you need to know a few things. First is the current video mode. Second is the number of rows; the video mode alone might only determine that you are in, say, an 80-column mode, without making a distinction between 80x25 and 80x43/80x50. From the video mode, you can determine the address of the character-mode frame buffer, and from the dimensions, you can determine the size of the buffer. This ignores BIOS 'video pages', but you'll be set to page 0 immediately after a mode set; unless your console driver uses pages or fast scrolling via changing the frame buffer address, you'll be fine (and buggered otherwise). You'll also need to write your own translation routines for 'special' characters that have some particular action, such as BEL, BS, CR, and LF. You typically don't want to print a graphical character for these. As a final cavaet: direct video writes do not update the cursor position. You'll need to do this yourself, either via BIOS INT 10H, or port I/O. If you're interested, I can dig up some old code for this (but I'm not at home now, so it might take me a while).
Quote:
Originally Posted by DaWei
The int instruction multiplied the interrupt value by the length of an address (4 bytes in the olden days) and fetched the address of the function from the location indicated by that value.
Ahh, the good old interrupt vector table.

Quote:
Originally Posted by DaWei
Doing so was a Bad Thang, generally, unless one also called the replaced address when one was finished with one's replacement function. This is called "chaining" and it still exists today.
I remember when I was a wee lad, and being impressed by the stack abuse in the Borland library sources used to achieve chaining without multiple INT calls (the caller's return address was replaced, and the IRET chained to the next handler).
Quote:
Originally Posted by DaWei
EDIT: Dang it. It took me seven minutes to write this post. Narue beat me in there with a concise, short and sweet answer.
Yeah, and you both beat me. Think how I feel!
__________________
A man's knowledge is like an expanding sphere, the surface corresponding to the boundary between the known and the unknown. As the sphere grows, so does its surface; the more a man learns, the more he realizes how much he does not know. Hence, the most ignorant man thinks he knows it all. - L. Sprague de Camp
lectricpharaoh is offline   Reply With Quote