Mail Archives: djgpp/1996/07/06/19:00:14
> Hi there... I'm writing low level stuff in DJGPP 1.12m4, in this case
> a sound driver. It hooks IRQ 5, which is int 0x0D.
Bad idea. Hardware interrupts aren't stable in V1.1x.
> occasionaly, without provocation, it bombs out with "Unsupported INT 0x0D"
Int 0x0D isn't actually the hardware interrupt, but the exception. You have
had a general protection fault. The registers should tell you where the
problem is. If you write them all down, and examine the failure point
with EDEBUG32/symify and the values of the registers, you can figure out
what to fix. Pay particular attention to selector values and check the
GO32 source to see if you are failing in GO32 also.
> P.S. Why do I have to do this? It still mucks up without, but what is
> this DPMI distinction between RM and PM ints?
A RM int is one which is only seen if your program is executing in Real Mode,
like in the middle of a DOS or BIOS call. The PM ints only happen in protected
mode (in your code). In real DPMI, when you hook a PM int it automatically
hooks the RM int for you (so what you have done is not necessary).
> I don't want to use v2 since my code will not work under DPMI (the
> video driver directly accesses video RAM with 0xE00A0000... there is
> no DPMI-able method that fast, am I correct?)
Wrong. In V2, you can do:
#include <sys/nearptr.h>
__djgpp_nearptr_enable(); /* Only need to call once in program */
char *video = (char *)(0xa0000 + __djgpp_conventional_base);
(or something very similar). Then your code will run in many more
environments and be much more stable.
Programs which depend on 0xe00xxxxx type addresses are easy to port to
V2 with either sys/nearptr.h or sys/farptr.h. Only graphics programs which
depend on the 0xd00xxxxx type graphics driver auto-paging are difficult to
port (and are the only ones which probably justify keeping V1.x around at
all).
- Raw text -