Mail Archives: djgpp/2014/07/11/22:01:15
On Fri, 11 Jul 2014 09:35:57 -0400, Johann Klammer
<klammerj AT nospam DOT a1 DOT net> wrote:
> On 07/11/2014 02:48 PM, Mateusz Viste wrote:
>> I have to admit I had no occasion yet to play with interrupts in DOS
>> (other that from a user point of view). What you write sounds very
>> convincing. And I have read in some MPU401 documentation that it is
>> likely to emit INT 9 at some occasions.
>>
>> For a test, I tried to handle the INT 9 with a "do nothing" function in
>> Turbo C, and now when my program ends, I have no keyboard anymore (ie. I
>> can press keys, but no reaction happens at all). :) Haven't tried to
>> catch the interrupt in protected mode yet, as it looks somewhat complex
>> (according to the DJGPP docs) - way more convoluted than doing it in
>> real mode at least.
>>
>> In any case, thanks for the hint! I will try to play with interrupts
>> this weekend and see what happens.
>>
> Interrupt 9 is not necessarily interrupt 9 in dos_setvect.. I believe
> there was an offset involved...
>
> That's me setting a handler for the parport interrupt:
>
> _dos_setvect( pp->intr+0x08, ex_isr );
> (using Openwatcom, though.. there may be differences)
>
> seems there's 0x08 to be added...
>
> Interrupt vector 0x09 is the keyboard interrupt(IRQ 1) in DOS. You
> hooked it and forgot to restore it to previous value....
In DJGPP for PM (with DPMI):
r.x.cs=segment;
r.x.ip=offset;
r.h.bh=1;
r.x.cx=0;
r.x.ss=0;
r.x.sp=0;
r.x.flags=0;
__dpmi_simulate_real_mode_procedure_retf(&r);
You can try __dpmi_simulate_real_mode_interrupt() with DJGPP.
It's what you're supposed to use, but it sometimes WON'T work
as expected ... That's why I've use the other function.
In OpenWatcom for RM:
handler=MK_FP(segment,offset);
_dos_setvect(vector,handler);
int86(vector,&r,&r);
In OpenWatcom for PM (with DPMI):
r.w.ax=0x0201
r.h.bl=vector;
r.w.cx=segment;
r.w.dx=offset;
int386(0x31,&r,&r);
RMI.SS=0;
RMI.SP=0;
RMI.flags=0;
r.w.ax=0x0300
r.h.bl=vector;
r.h.bh=1;
r.w.cx=0;
s.es=FP_SEG(&RMI);
r.x.edi=FP_OFF(&RMI);
int386x(0x31,&r,&r,&s);
RMI is a user defined struct with the registers and segment
registers to match what is required by the DPMI specification.
OpenWatcom doesn't provide this (or didn't). The s is
'struct SREGS' and r is 'union REGS' as provided by OpenWatcom
in include i86.h.
OpenWatcom's DOS/4GW DPMI host doesn't support the DPMI 0x0301
call "Call Real Mode Procedure With Far Return Frame".
So, that's why the extra work for PM with OW.
The preprocessor define __DJGPP__ and __WATCOMC__ can be used
to differentiate compilers. The preprocessor define __386__
can be used to differentiate RM and PM OpenWatcom code.
Rod Pemberton
- Raw text -