Message-ID:	<68C4CF842BD2D411AC1600902740B6DA02CDC252@mcoexc02.mlm.maxtor.com>
From:	"Dykstra, Sean" <Sean_Dykstra AT maxtor DOT com>
To:	"'djgpp AT delorie DOT com'" <djgpp AT delorie DOT com>
Subject:	Help on physical memory (not again!)
Date:	Fri, 13 Apr 2001 10:20:20 -0600
MIME-Version:	1.0
X-Mailer:	Internet Mail Service (5.5.2653.19)
Reply-To:	djgpp AT delorie DOT com

Hello all!

I work for a hard drive manufacturer and my group develops tools (hardware
and software) for testing hard drives.  A brief background so you can
understand where we are coming from:

We develop portable test tools.  We currently have our primary tool
compiling and running on the following platforms:
o  DOS (16 bit)
o  DJGPP for DOS (32 bit)
o  Windows 95/98/ME 
o  Windows NT
o  Linux 
o  Macintosh (no drivers yet)

Our test tools need to allocate 32 Mb of physical buffer space for testing
the new 48 bit address LBA transfers.  These transfers are DMA based.  We
obviously cannot meet these needs in the 16-bit DOS world, so we would LOVE
to use DJGPP.  Currently the Windows based stuff is working, but often we
still need to boot to a floppy.

The Windows DDK has some good resources for allocating physical memory and
mapping it into application space.  I think I have come up with the
equivalent with DJGPP, but I have a few concerns.  The primary reason for
needing a near pointer is because of portability issues with the various
platforms.  (The app is already written, and creating macros for all of the
buffer pointer deref's would be a royal pain).

I am currently using __dpmi_map_device_in_memory_block () with great
success.  I first allocate a buffer of 32Mb using malloc, then I allocate
32Mb of PHYSICAL memory using XMS, then I use the
_dpmi_map_device_in_memory_block.

My Concerns:
1)  This requires that I allocate two buffers (for a total of 64Mb).  Is
there a way around this?  It basically means that in order to run from a
floppy I must have a 128Mb system, when I really only need 64Mb once the app
is running.  Can I delete the malloc'd buffer immediately and cheat using
the address returned, or will this cause problems with future mallocs?

2)  Note from the DPMI spec for Map Device In Memory Block: 
If the DPMI host is not virtualizing the device, it must disable any memory
caching on the mapped pages; in particular, on the 486 or later, the PCD
(page cache disable) bit must be set in the page table entries.  

Is my only detriment on # 2 performance?  Are there any real dangers about
doing this?  I can live with the performance issue, as my benchmarks have
showed that in most other aspects DJGPP is 50% to 200% faster than the DOS
version I am using now. 

I have been truely greatful for all of the help in the archives so far.
Coming from the corporate world I am always skeptical of the "open source"
concept, but you guys have done a tremendous job on DJGPP and the CWSDPMI
host.  

Thanks!

- Raw text -