Mail Archives: djgpp/1997/04/15/10:30:21
On 15 Apr 1997, David Orme wrote:
> I have, and 18.2, and the surrounding sections. It says to put the variable
> address into di and ignore es. This I did, and successfully caused a
> "SIGSEGV" program halt.
You have misread the FAQ. It says to do so only for those functions that
int86 supports (and gives a pointer to a list of such functions in
section 18.1).
The best way to call software interrupts is to not rely on int86 at all,
but call `__dpmi_int' instead (also explained in the FAQ). Do not be
tempted by the apparent ease of porting 16-bit sources when you use
`int86': it's a real trouble-generator, and should be avoided at all
costs. Just use `__dpmi_int' and most of your woes will miraculously go
away. For example, the DJGPP library functions call `__dpmi_int' almost
always and ignore `int86'.
> r.h.ah=0x4f;
> r.h.al=0;
> s.es=FP_SEG(VESA_ptr);
> r.x.di=FP_OFF(VESA_ptr);
>
> int86x(0x10,&r,&r,&s); /* here's where it "crashes" with */
int86 doesn't support the VESA functions, that's why it crashes. It's
exactly the situation described in section 18.1, which see.
> why my program halts. I converted to _dpmi_regs and __dpmi_int, but they
> don't support sending your own buffer (VESA in this case) to the interrupt.
You need to move the data to the transfer buffer and set ES:DI to the
address of the transfer buffer. This is also explained in section 18.2 (I
hope you have the latest release 2.10 of the FAQ).
> Please help, as the information in the FAQ isn't very helpful (in this
> instance at least).
Please tell which parts of the explanation in the FAQ aren't clear. As
far as I could see all your problems are discussed there, but maybe the
wording isn't clear enough.
- Raw text -