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
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.

- Raw text -