X-Authentication-Warning:	delorie.com: mailnull set sender to djgpp-bounces using -f
From:	kala AT sankya DOT com (Babu Kalakrishnan)
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: DPMI Interrupt latency ?
Date:	Tue, 29 Jan 2002 20:28:54 +0530
Lines:	28
Message-ID:	<slrna5de5e.5cd.kala@ganga.sankya.com>
References:	<Pine DOT SUN DOT 3 DOT 91 DOT 1020129153726 DOT 8440D-100000 AT is>
NNTP-Posting-Host:	ppp-200-2-67.bng.vsnl.net.in (203.200.2.67)
X-Trace:	fu-berlin.de 1012316828 39228287 203.200.2.67 (16 [76750])
X-Orig-Path:	kala
User-Agent:	slrn/0.9.6.2 (Linux)
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp
Reply-To:	djgpp AT delorie DOT com

On Tue, 29 Jan 2002 15:39:11 +0200 (IST), Eli Zaretskii <eliz AT is DOT elta DOT co DOT il> wrote:
>
>On Tue, 29 Jan 2002, Babu Kalakrishnan wrote:
>
>> Tried the way you suggested - but it doesn't seem to work if I try
>> invoking the hardware interrupt through a software (INT XX) call. I
>> hooked INT0D (IRQ5) from protected mode. But on reaching the shell, The
>> interrupt vector of Int 0d was pointing to the initial Real mode value
>> in ROM. I then tried calling Int8D (where the master PIC vector seemed
>> to be redirected to), but still my interrupt handler didn't seem to get
>> called. Does the code check if the interrupt is a genuine hardware IRQ
>> and skip calling the handler if it isn't ?
>
>AFAIK, only hardware interrupts are reflected to protected-mode 
>handlers.  Software interrupts don't get reflected.  It's in the DPMI 
>spec.  (There are a couple of software interrupts, listed in the DPMI 
>spec, that are exceptions.)

That makes sense - and would explains why my handler didn't get called.
My confusion was only regarding whether the DPMI server would accept 
INT 8D blindly as a hardware interrupt or if it would actually read the
ISR from the PIC  to determine that the interrupt was generated through
hardware before deciding whether to forward it or not. The latter seems
to be true at least with CWSDPMI. ( Wonder if PMODE/DJ checks this too -
I suspect it may not, that would explain one major source of the faster
response - Reading the ISR requires 2 I/O instructions !)

BK

- Raw text -