Mail Archives: djgpp/1996/08/17/05:16:52
snarfy AT goodnet DOT com wrote:
>I just wanted to say thanks to everybody who has responded. I now
>have my interrupt code working without using _go32 type wrappers. It
>seems as though I needed to 'movw ___djgpp_our_DS, %ds' to get it
>to work, and now everything works happily.
Check out the libints thing I wrote... admitted, it's hell to use
somebody else's code (at least it is for me!) but if everyone used it
for everything, then we could put all the good stuff in it and cut
back on parallel development!
ASSUMING a version of djgpp with __attribute__((section)) fixed comes
out :-)
>Now I have just one more (and probably final) interrupt problem. As
>far as I can decipher from the FAQ, if you install a pmode interrupt
>handler, the DPMI will automagically reflect all real mode interrupts
>into pmode.
Yup.
> Here is where it gets hazy, however;
Yup!
> If I install a
>real mode interrupt handler AND a pmode interrupt handler, will
>the DPMI still reflect the real mode interrupts to pmode first? If
>that's the case then I don't know why you would install a real
>mode interrupt handler (and why there would be a DPMI function to do it.).
>If you do install both a real mode and a pmode handler and the DPMI
>DOES send the real mode interrupts to the real mode handler, then
>I have another question:
I think it's time to clear this up once and for all.
One moment, please, I'll go read the DPMI spec...
Hardware interrupts always go to protected mode first... there is a
default protmode handler installed by the DPMI host for each interrupt
that reflects to real mode. DPMI handlers that chain to the previous
pmode handler will therefore end up redirecting to real mode.
The reason for installing real mode ints is for software interrupts...
like if you wrote a protected mode mouse driver, you'd hook realmode
int 0x33.
I read some interesting stuff about iret not restoring the interrupt
flag: it suggests an sti before iret. Woops. I didn't do that in
libints! That's something for the next release :-)
It never gave me any trouble, though... the keyboard still works after
the test handler being installed, under CWSDPMI. Charles - does
CWSDPMI not set IOPL so as to disable popping the interrupt flag?
>What does a real mode handler need to do? All I want the
>real mode handler to do is to 'iret'. The interrupts I'm servicing
>aren't crucial, so I can miss the ones that happen in real mode. The
>interrupt reflection will kill me though, so when I'm in real mode
>I just want to 'iret' those interrupts. I've written some code to
>do it, but it blows up on me (@ symbols randomly all over the screen).
From what I read, they'll be reflected to pmode first, anyway.
>I do everything the FAQ says. I allocate the conventional memory
>with __dpmi_allocate_... and I put my code at that location with
>dosmemput(). Then I put the lower 4 bits of the segment returned
>by __dpmi_allocate into the offset16 field of the __dpmi_raddr and
>the rest of it (segment & 0xFFF0) into the segment field.
If dpmi_allocate() returns a segment, as I imagine it would, then just
put that value into the segment field and zero in the offset16!
>my interrupt code is as follows:
>_my_rm_irq0_hook:
>cli
>sti
>iret
>_my_rm_irq0_hook_end: /* for locking & allocating dos ram */
>I probably don't need the cli, sti, but I wasn't sure.
Shouldn't do, in real mode. The interrupt will cli automatically, and
the iret will restore the saved interrupt state.
> Then I install
>the interrupt with __dpmi_set_real_mode_interrupt(). Kabloowee. Do
>any guru's out there care to comment? :)
Well I guess I'd better start acting like a guru :-)
Regards,
ABW
--
I have become... Comfortably numb...
Alaric B. Williams Internet : alaric AT abwillms DOT demon DOT co DOT uk
<A HREF="http://www.hardcafe.co.uk/Alaric/">http://www.hardcafe.co.uk/Alaric/</A>
- Raw text -