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: References: 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 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