Xref: news2.mv.net comp.os.msdos.djgpp:4087
From: brien AT leland DOT Stanford DOT EDU (brien oberstein)
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Making the nearptr hacks use longs.
Date: 21 May 1996 00:52:44 -0700
Organization: Stanford University
Lines: 29
Message-ID: <4nrsoc$2n3@firebird13.Stanford.EDU>
References: <Pine DOT SUN DOT 3 DOT 91 DOT 960521075640 DOT 13486B AT is>
NNTP-Posting-Host: firebird13.stanford.edu
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp

Eli Zaretskii <eliz AT is DOT elta DOT co DOT il> writes:


>On 20 May 1996, Austin Appleby wrote:

>> it'll be even speedier... Basically, the idea is to set videoptr to a 
>> long pointer instead of a char pointer, so that the thing will optimize 
>> down to some resemblance of a movsd op instead of a movsb, thus a 4x 
>> improvement. But for the life of me I don't know how to get the thing to 
>> work...

>`dosmemputl' (and `movedata') already use 32-bit movsd, so I don't see 
>how you can get any real speed-up here.  The only situation where nearptr 
>is faster is when you operate on single pixels or small groups of 
>pixels.  If you need to move large buffers, `movedata' is as fast as 
>nearptr, but much more safe (as it doesn't disable memory protection), 
>and also works on any DPMI platform.

Right.  I'm using the near pointer method 'cause I like to generate
images directly into the frame buffer (which may be mapped out or whatever).
I'm wondering if there is a simple way to _just_ map the vga frame buffer
into the djgpp address space as opposed to the entirety of conventional
memory.  This would only have to be done once at the beginning of the
program and would be totally safe!  You get speed+safety.  Isn't this
THE solution to graphics under dpmi?

-brien