Sender:	nate AT cartsys DOT com
Message-ID:	<3588831E.1F6044A5@cartsys.com>
Date:	Wed, 17 Jun 1998 20:01:50 -0700
From:	Nate Eldredge <nate AT cartsys DOT com>
MIME-Version:	1.0
To:	Jerry Lawrence <jerry AT eteklabs DOT nospam DOT com>
CC:	djgpp AT delorie DOT com
Subject:	Re: far pointers using djgpp
References:	<Pine DOT SOL DOT 3 DOT 95 DOT 980617000723 DOT 17603A-100000 AT tiger DOT vut DOT edu DOT au> <35881d34 DOT 2869157 AT news DOT unisys DOT com DOT br> <MPG DOT ff1ff203d4e5e319896ce AT gateway>

Jerry Lawrence wrote:

> 
> Or, you could do this: (can't remember where i got the info from)

It may have been FAQ section 18.6; this hack is described there.
 
> 1) store a local ram buffer of the screen buffer; do all screen
>    operations to this buffer.
> 2) in your graphics init function, use this right after you change
>    screen mode:
>         __djgpp_nearptr_enable();
> 3) in your graphics deinit function, use this:
>         __djgpp_nearptr_disable();
> 
> 4) when a full screen buffer is ready to be displayed:
> 
>         memcpy( (unsigned char *) (0xa0000+__djgpp_conventional_base),
>                         (buff),320*200);
> 
> where "buff" is a 64k buffer (assuming 320x200x256 color)

That's all well and good, but note that it's also dangerous.  When
nearptrs are enabled, you lose much of the protection normally given by
DJGPP's 32-bit environment.  It is now possible for an overrun pointer
to smash the OS, corrupt buffers, damage data, etc, etc.  (Back to the
bad old days of Real Mode!)  Use with extreme caution!!

IMHO, this scheme should only be used if you *absolutely* *must* have
every last bit of speed, and if you've tested your program well already.
-- 

Nate Eldredge
nate AT cartsys DOT com

- Raw text -