From: Harold Roman <harold AT giganet DOT com>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: CWSDPMI Physical Memory Addresses
Date: Sun, 01 Nov 1998 11:36:49 -0500
Organization: GigaNet Inc.
Lines: 29
Message-ID: <363C8E21.BA82A854@giganet.com>
References: <Pine DOT SUN DOT 3 DOT 91 DOT 981101145006 DOT 6846r-100000 AT is>
NNTP-Posting-Host: 207.60.106.223
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 4.04 [en] (X11; U; HP-UX B.10.20 9000/780)
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

Eli Zaretskii wrote:

> One of the methods described in the FAQ, the one which uses the VDS API,
> can handle this, AFAIK.

Thanks for the suggestion. I looked at VDS a while back, and it didn't
really meet my needs. If I remember right, VDS will allocate contiguous
physical pages for your buffer. What I really need is to use an
application's pre-existing buffer, contiguous in virtual memory -- maybe
not contiguous in physical memory. The card's DMA engine is setup with the
virtual to physical mapping of the buffer, then the DMA is started.

Anyway, I figured out my problem with the page tables. I had used the
__djgpp_map_physical_memory() to map all of the 1st Meg into my
application's memory space to make access to that space a bit easier, and
faster(?). Aparentlly, this didn't work so well (I'm still not sure why).
So, when I thought I was reading the global descriptor table (GDT), I
really wasn't. Now I use the following to access the 1st Meg memory:

  assert(  __djgpp_nearptr_enable() != 0  );
  dosBase= __djgpp_conventional_base;
  gdtEntryAddr= dosBase + gdtPhysicalBase + gdtEntryOffset;
  gdtEntry= *gdtEntryAddr;

(Caution: Using __djgpp_nearptr_enable() bypasses some very good protection
mechanisms and may be hazardous to your code's health.)

Harold Roman