🚀 go-pugleaf

In article <1990Oct10.163006.8081@Octopus.COM> stever@octopus.COM (Steve Resni
ck ) writes:
>Heres's a good question for you PC guru types ...
>
>On 80286 and 80386 processors, int 12 is designated as a stack fault exceptio
n.
>So far so good. Also on PC's in general, IRQ4 is designated as the default
>interrupt for COM1. Since IRQ int numbers are IRQ += 8, IRQ4 becomes int 12
>also. My question is, how does the system determine what interrupt to vector
>where and how are "separate" interrupt vectors defined? I have some serial
>code which needs to tweek int vectors from time to time. The code is all
>there to handle the serial interrupts, but there is no vector chaining
>being done. I can force an int 12 by mov'ing 0 into SP and pushing AX onto
>the stack, and I get my default "stack fault exception" message. What magic
>is being done here?
>
>Thanx, in advance....
>
>Steve

Code written for DOS generally ignores the fact that 286 and 386 hardware
exceptions vector into the same places as hardware interrupts. The most
common way I've seen this dealt with is for the non-BIOS handler (serial
port in this case) to assume that the interrupt was meant for it. If it
finds that there is no reason to have received the interrupt, pass it along
to the previous handler. By this I mean that you would look at the serial
port hardware, if there was no interrupt generating condition (output buffer
empty, character received, etc.), assume that the interrupt was an exception
and let the BIOS handler have it.

This does not always work since the interrupt may have been generated by the
processor on an exception and then the serial port hardware might receive a
character. I always assume that the exception condition will not clear itself
so when I return from my interrupt handling the exception will happen again
and then I'll pass it along. Unclean, maybe, imperfect, yes. But this is DOS
not UNIX, we will always be limited by what must be able to run on an 8088
in a box that is older then some of us (not me, of course).

Ed
ekalenda@cup.portal.com