From: Seyil Yoon <wings AT interlog DOT com>
Newsgroups: comp.os.msdos.djgpp
Subject: Extended int 13h calls (e.g. ah=42h)
Date: Wed, 28 Oct 1998 15:52:47 -0500
Organization: UUNET Canada News Transport
Lines: 37
Message-ID: <3637841E.6579850F@interlog.com>
NNTP-Posting-Host: 209.47.85.27
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 4.5 [en] (Win98; U)
X-Accept-Language: en
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

Without getting into the details of extended int 13h calls, the
following does not
work:

__dpmi_regs    Regs;

Regs.h.ah    = 0x42;
Regs.h.dl    = ucDrive;
Regs.x.ds    = ulPacketBufferSeg;    //    Segment number obtained from
__dpmi_allocate_dos_memory
Regs.x.si    = 0;

__dpmi_int(0x13, &Regs);

Now, extended int 13h calls are definitely supported on the platform I
was
attempting to run this on, so that's not the problem. The only notable
thing about the call is that ulPacketBufferSeg is the segment number of
some memory allocated by __dpmi_allocate_dos_memory, and in that
chunk of memory, there is another value, ulBufferBufferSeg, which is the

segment number of another chunk of memory allocated by
__dpmi_allocate_dos_memory.
I don't know if this sort of multiple indirection / use of
__dpmi_allocate_dos_memory
is good or not, but regardless, the error value returned in Regs.h.ah is
1, which
means invalid function call (ah = 42h) or else invalid parameters.

The drive being accessed in question is a SCSI 9.1gig drive with
the extended int 13h support turned on on the SCSI adapter it is
attached to. The extended int 13h installation check (ah = 41h)
says that everything is fine, so I'm without a clue now. Any help
would be appreciated.

P.S. Please excuse this email if it is using all types of stupid fonts.