Date: Tue, 20 Oct 1998 19:09:52 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: "Miles F. Bintz Ii" cc: djgpp AT delorie DOT com Subject: Re: More interrupt handling questions In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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.