Sender: nate AT cartsys DOT com
Message-ID: <35DF11C4.427C8FB@cartsys.com>
Date: Sat, 22 Aug 1998 11:45:24 -0700
From: Nate Eldredge <nate AT cartsys DOT com>
MIME-Version: 1.0
To: Steve Carter <shc103 AT york DOT ac DOT uk>
CC: djgpp AT delorie DOT com
Subject: Re: Page Boundaries
References: <Pine DOT SUN DOT 3 DOT 91 DOT 980813105510 DOT 2812N-100000 AT is> <6r1a8p$c7o$4 AT pump1 DOT york DOT ac DOT uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk

Steve Carter wrote:
> 
> Eli Zaretskii (eliz AT is DOT elta DOT co DOT il) wrote:
> 
> : On Thu, 13 Aug 1998, Endlisnis wrote:
> 
> : > I need to know that too.  I want to use __djgpp_map_physical_memory, but it
> : > says I need a page-aligned data-block.  What is page-aligned and how to I
> : > create/calculate a page-aligned address.
> 
> : That's something entirely different.  Page-aligned in this context
> : means aligned on the 4KB pages used by the PC paging and virtual
>                        ^
>                        64k, I think!

We're confusing two different meanings of `page' here.  The 8086 meaning
referred to a 64K aligned 64K block of memory.  But the 386 uses pages
of 4K in its memory management scheme.  I think the second is more
common these days.

> : memory mechanisms.
> 
> : You get such pages either by calling `sbrk' or by allocating a larger
> : block with `malloc' and using a part thereof whose starting address
> : has its lower 12 bits zeroed.
> 
> Thanks.  I was wondering, but I don't think it's possible:  How about
> mallocing a 128K block, to guarantee getting a whole page in there
> somewhere, then free()ing parts of that block that aren't used?  I presume
> this is not possible...

Okay, Eli is thinking of the second meaning.  As far as DMA buffers, you
have to use conventional memory, since it's the only reliable and
commonly available way to ensure the physical address of memory is where
you think.  You can use __dpmi_allocate_dos_memory to get it, and I
think there is a resize function which lets you shrink it.  You can only
shrink the top end, though-- the bottom stays where it is.

You could try something tricky like: allocate a 128K chunk, note its
address, free it, allocate a block < 64K that should end approximately
on a 64K boundary, allocate your DMA buffer, shrink to fit, and free the
first block.  Check it every step of the way, however, since many things
can break this.  Also be aware that a non-contiguous block of less than
64K is of minimal use to DOS, so this may not even be worth the trouble.
-- 

Nate Eldredge
nate AT cartsys DOT com