delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/2002/09/13/10:30:24

Message-ID: <BDD73AE8AEE3EF438E07420C2600E9F65C913D@qtiexch0.qgraph.com>
From: "Sisco, Michael" <mdsisco AT qtiworld DOT com>
To: "Djgpp (E-mail)" <djgpp AT delorie DOT com>
Subject: Fw: Using XMS for DMA with DJGPP and CWSDPMI
Date: Fri, 13 Sep 2002 09:30:18 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Reply-To: djgpp AT delorie DOT com

I know that there have been a number of posts on this in the past, and I've
gone back and read them all, and have made good progress using the
information found there, but I'm still stuck.

We are using CWSDPMI as our DPMI server, and I have read how CWSDPMI uses
all available XMS if there is not an external memory manager running. We are
running HIMEM alone and have indeed seen the 0x0A return code from our XMS
call (all available XMS memory is allocated). According to the other
postings, one can get past this problem by loading EMM386 (as long as NOVCPI
is NOT specified on the command line). The problem is that on our system, if
we add the emm386 line to config.sys, then our application hangs as soon as
the XMS driver function 0x0900 (allocate XMS block) is called. We are
calling the driver function 0x0800 (query free XMS memory) successfully and
are told that there is approx 61MB of XMS memory available, and we are only
attempting to allocate a 300KB block. We are using the
__dpmi_simulate_real_mode_procedure_retf() function and are apparently using
it correctly, since we have been able to successfully retrieve the XMS
Driver version and verify the amount of extended memory available.

I've seen enough posts on this subject to know that someone has worked
around this issue. Any help they could provide would be greatly appreciated.



- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019