From: Fabrice ILPONSE Newsgroups: comp.os.msdos.djgpp Subject: Re: Allocate physical memory? Date: Mon, 23 Mar 1998 18:49:23 +0100 Organization: Universites Paris VI/Paris VII - France Lines: 106 Message-ID: <3516A0A2.661AEA74@asim.lip6.fr> References: NNTP-Posting-Host: asim.lip6.fr Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------43519FDBD7F66C4E5D38D5AA" To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Precedence: bulk --------------43519FDBD7F66C4E5D38D5AA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Shawn Hargreaves wrote: > I'm in the process of writing a VBE/AF (the SciTech hardware > accelerator API) driver for Allegro, which had already managed > to roughly double the speed of the demo game when running in > page flipping mode on my Matrox card. At present this supports > a range of hardware drawing functions (area fills and blits), > but only when they are operating entirely within the video > memory. VBE/AF also provides the ability to use a bus mastering > transfer mode on some high end cards, which in theory has the > potential to speed up blitting from system memory to the screen, > but I'm unsure if/how I will be able to use this. > > To initiate a bus master copy, I need to program the graphics > controller with the physical memory address of the source data, > but as far as I can see there is no way for me obtain this > information! I need some way to allocate a block of contiguous > physical memory locations, but unless I've missed something, > there are no DPMI functions to do this (using conventional > memory will break under Windows). Before I totally give up on > this idea, does anyone know a way that I could obtain such > a memory buffer? Even if it is only possible in a few specific > environments, the potential benefits of this are so great that > I really want to make it work if that is at all possible... > Are you sure there's no function? I remember of one that do "allocate unmapped memory" or something like that. You can allocate memory and then lock it so it stay in physical memory but i don't know if you'll find a function (of DPMI) to give you this physical adress. :| > Shawn Hargreaves. -- ^ ^ ^ | | | +-+-+ Fabrice ILPONSE | email: fabrice AT asim DOT lip6 DOT fr | | - --------------43519FDBD7F66C4E5D38D5AA Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Shawn Hargreaves wrote:

I'm in the process of writing a VBE/AF (the SciTech hardware
accelerator API) driver for Allegro, which had already managed
to roughly double the speed of the demo game when running in
page flipping mode on my Matrox card. At present this supports
a range of hardware drawing functions (area fills and blits),
but only when they are operating entirely within the video
memory. VBE/AF also provides the ability to use a bus mastering
transfer mode on some high end cards, which in theory has the
potential to speed up blitting from system memory to the screen,
but I'm unsure if/how I will be able to use this.
To initiate a bus master copy, I need to program the graphics
controller with the physical memory address of the source data,
but as far as I can see there is no way for me obtain this
information! I need some way to allocate a block of contiguous
physical memory locations, but unless I've missed something,
there are no DPMI functions to do this (using conventional
memory will break under Windows). Before I totally give up on
this idea, does anyone know a way that I could obtain such
a memory buffer? Even if it is only possible in a few specific
environments, the potential benefits of this are so great that
I really want to make it work if that is at all possible...

Are you sure there's no function? I remember of one that do "allocate unmapped memory" or something like that.

You can allocate memory and then lock it so it stay in physical memory but i don't know if you'll find a function (of DPMI) to give you this physical adress. :|

Shawn Hargreaves.

-- 
        ^ ^ ^
        | | |
        +-+-+   Fabrice ILPONSE
          |     email: fabrice AT asim DOT lip6 DOT fr
          |
          |
          -

--------------43519FDBD7F66C4E5D38D5AA--