From:	Mitch Randall <mitch AT ncar DOT ucar DOT edu>
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: Lauching ASPI from DJGPP
Date:	Thu, 25 Sep 1997 09:13:47 -0600
Organization:	National Center for Atmospheric Research
Lines:	35
Message-ID:	<342A7FAB.5554@ncar.ucar.edu>
References:	<Pine DOT SUN DOT 3 DOT 91 DOT 970925112805 DOT 22174D-100000 AT is>
NNTP-Posting-Host:	mitch.atd.ucar.edu
Mime-Version:	1.0
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp

> Eli Zaretskii wrote:
>
> I cannot be sure without seeing the original Watcom code, but I think
> the following is the source of your trouble:
> 
> >    /* point real mode data structure to real mode entry point */
> >    regs.x.cs = aspientry >> 16;
> >    regs.x.ip = aspientry  & 0xFFFF;
> 
> It should say instead this, I think:
> 
>      regs.x.cs = aspientry >> 4;
>      regs.x.ip = aspientry  & 0xF;
> 
> Real-mode addresses are formed by segment*16+offset.  Multiplication
> by 16 is equivalent to a shift by 4 bits, not 16.

I noticed that myself when I dug up the watcom code after not having seen 
it for a couple years. However, the variable aspientry comes from an IOCTL 
call:

handle = _open("SCSIMGR$",0);
numbytes = ioctl(handle,DOS_RCVDATA,4,(int)&aspientry);

the integer aspientry is just a convenient place to put the 16 bit segment 
and 16 bit offset which is returned by the SCSIMGR$.  The code would have 
been more readable if I had passed the address of an array of two shorts.  
However, I've verified that the contents of the dpmi structure (cs and ip) 
are identicle in the working watcom version and the non-workiing DJGPP 
version. I've also just printed aspientry in both versions and compared; 
they are identicle.

Any other suggestions?

Mitch Randall

- Raw text -