Xref:	news-dnh.mv.net comp.os.msdos.djgpp:3125
Path:	news-dnh.mv.net!mv!news.sprintlink.net!news.inc.net!news.sol.net!daily-planet.execpc.com!news.moneng.mei.com!news.ecn.bgu.edu!vixen.cso.uiuc.edu!uwm.edu!chi-news.cic.net!newsfeed.internetmci.com!news.msfc.nasa.gov!bcm.tmc.edu!newsfeed.rice.edu!rice!news!sandmann
From:	Charles Sandmann <sandmann AT clio DOT rice DOT edu>
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: HOHow to access VBE2.0 linear frame buffer?
Date:	Wed, 08 Nov 1995 11:54:52 CST
Organization:	Rice University, Houston, Texas
Lines:	19
References:	<plippone DOT 815788630 AT snakemail DOT hut DOT fi>
Reply-To:	sandmann AT clio DOT rice DOT edu
Nntp-Posting-Host:	clio.rice.edu
To:	djgpp AT sun DOT soe DOT clarkson DOT edu
Dj-Gateway:	from newsgroup comp.os.msdos.djgpp

> So far I've been able to do get_VESA_mode_info call and (using UniVBE2.0)
> found out that the linear frame buffer is at 0xf0000000. 
> tried ... to find out what the 0xf0000000 physical is in linear address 
> (__dpmi_get_physical_mapping() gave 0 ) 

What dpmi provider are you using?  Under CWSDPMI this should return as
linear = physical.  Other DPMI providers may choose to fail this call, but
I think most shouldn't.  Check your call for correct arguments.

With the virtual address of the buffer, you should then either:
1) allocate a selector, set it's base to be the value returned from the 
   mapping call, set it's length to be the size of your frame memory and
   then use fartpr functions, or
2) use the nearptr functions and compute a pointer to the memory

Messing with mprotect is wrong, as is messing with the address 0xf0000000
directly in any manner.  Under CWSDPMI your nearptr address would turn
out to be 0xe0000000 since the typical base of memory is 0x10000000.
This base will be different (and change) under different DPMI providers.

- Raw text -