Date:	Tue, 20 Oct 1998 19:09:52 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	"Miles F. Bintz Ii" <bintzimf AT clarkson DOT edu>
cc:	djgpp AT delorie DOT com
Subject:	Re: More interrupt handling questions
In-Reply-To:	<Pine.A41.3.96.981019120058.36676A-100000@polaris.clarkson.edu>
Message-ID:	<Pine.SUN.3.91.981020190842.19902A-100000@is>
MIME-Version:	1.0
Reply-To:	djgpp AT delorie DOT com

On Mon, 19 Oct 1998, Miles F. Bintz Ii wrote:

> Just to verify, if I wanted to write an ISR  for IRQ 4, I would install it
> into vector 0x0c, correct (in DPMI)?

Yes.

> I have a PCI device whose interrupt line is 0 on bootup.  I manually set
> this to IRQ 4 in the config space and then tell the card that its OK to
> start issuing interrupts.

IRQ4 is used by the COM1 port.  Are you sure your device doesn't
conflict with COM1, like if you have a serial mouse or a modem
connected to COM1?

> void ISR() {
>     disable();

I'd advice against using `disable'.  The interrupt handler is called
with interrupts disabled anyway, and even if not, the particular
interrupt that you hook is masked by the PIC until you send an EOI.
So if you are worried because of a possible reentrancy, don't be.

Disabling interrupts should be only needed if you manipulate some
critical data, like SS and SP.  If you need that, it is much better to
emit CLI and STI in inline assembly, since `disable' and `enable' call
a DPMI service which has a tremendous overhead.

>     /* can I call this in my ISR or does this end up being 
>        a far call?
>      */
>     _farpeekl(yadda, yadda)

You can call _farptr functions from an ISR.  (I don't understand your
question about it ``ending up as a far call'': why does it matter, and
what do you mean by a ``far call''?)

>     /* Signal EOI: do I need to do this? */
>     outportb(0x20, 0x20);

Yes, you do need the EOI: otherwise, you will never see the interrupt
after the first time, because the PIC automatically masks the
interrupt when the IRQ line is asserted by the device, and don't
unmask it until you say so by sending the EOI.

> Some other tidbits: I realize that the wrapper isn't locked in memory, but
> I don't believe the system is paging.  I'm currently running under win95,
> but I think there is still plenty o' memory available.  The same things 
> happen when I run with cwsdpmi.

First, even if you believe that no paging happens, it is best to lock
everything (by setting the appropriate _CRT0 bit in
_crt0_startup_flags) for your first attempts, until you get everything
working.

And second, I think the IRQ conflict with the COM1 port is the prime
suspect.  I suggest to find an unassigned IRQ and try again.

- Raw text -