Xref:	news-dnh.mv.net comp.os.msdos.djgpp:1273
Path:	news-dnh.mv.net!mv!news.sprintlink.net!simtel!harbinger.cc.monash.edu.au!silas.cc.monash.edu.au!junaid
From:	junaid AT silas DOT cc DOT monash DOT edu DOT au (Mr A. Walker)
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: DPMI and graphics
Date:	31 Jul 1995 11:41:49 GMT
Organization:	Monash University
Lines:	54
References:	<DBCE25 DOT 5Fq AT bath DOT ac DOT uk> <2ffd2e39 DOT sandmann AT clio DOT rice DOT edu> <DH23mapRCXE6078yn AT werple DOT mira DOT net DOT au>
Nntp-Posting-Host:	silas.cc.monash.edu.au
To:	djgpp AT sun DOT soe DOT clarkson DOT edu
Dj-Gateway:	from newsgroup comp.os.msdos.djgpp

Antony Suter (antony AT werple DOT mira DOT net DOT au) wrote:
: In article <2ffd2e39 DOT sandmann AT clio DOT rice DOT edu>,
: Charles Sandmann <sandmann AT clio DOT rice DOT edu> wrote:
: >> If you are compiling using DJGPP with DPMI is it still possible to write 
: >> directly to the screen, using address 0xD0000000 I mean?
: >
: >No.
: >
: >> If it is not possible, how does GRX do it?
: >
: >GRX V2 uses <sys/farptr.h> type routines (it has it's own internal ones 
: >actually I think).  A hack to do it directly under DJGPP V2 & DPMI is
: >in the works but not finished yet

	Well its all there, see delorie.com/pub/djgpp/contrib/crt0*
.. Amazingly, you can even use gdb on such a program without incident.
However it may not work in all enviornments, either now or in the future.

: >
: >> I belive you have to be in DPMI mode to get the graphics
: >> working in a DOS box in Windows, is this right?
: >
: >Correct.

: After trying the sample code "vram.c" posted early June by Al-Junaid Walker
: in both 32-bit segment wrap hack mode and the djgpp farptr mode, I actually
: found the farptr mode to be the quickest by about 5-10 percent.

: This code copies a ram video buffer to video ram.

	That was some time back. The code has bugs. crt0* doesnt have
blit bugs, but a trivial graphics mode switching bug. When i get time
i may fix it. Send me $10 and i'll fix it now.
	NB there should be no slow down. Run the program several times
and average. The near ptr hack is really only useful in specialized
circumstances where far ptr reloading is frequent.
	In a real machine about the only way it improves your program
is to make it easier to read. Even though segement overides take an extra
clock, modern chipsets tend to 'write-back' to VRAM, so the CPU ends up
waiting for VRAM in either case. This is not true in the new fast video
cards that are faster than system RAM - they can do VRAM bus writes in
a single cycle, so you will effectively halve their blit speed (but if
you are running a clock doubled/trippled CPU, then things are a little
better since the extra clock is internal CPU cycles, not external MB
system cycles).

	Anyway its all a bit academic, concentrate on your algorithms.

Junaid


: --
: - Antony Suter  <antony AT werple DOT mira DOT net DOT au>  (Rohaan)
: - "...in Space, all warriors are Code warriors", Chang, ST6.

- Raw text -