DPMI and graphics
Neil A Drage
mini FAQ and I now have more Qs than As.
Anyway. If you are compiling using DJGPP with DPMI is
it still possible to write directly to the screen, using
address 0xD0000000 I mean?
If it is still possible is it recommended?
If it is not possible, how does GRX do it?
I belive you have to be in DPMI mode to get the graphics
working in a DOS box in Windows, is this right?
You see I want to write my own fast assembler routines
to access the screen for a game I am writing. I do like
the idea of writing in 32 bit flat memory and DJGPP seems
ideal.
Hope you can help. Thanks.
Neil A. Drage
Charles Sandmann
> 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
> I belive you have to be in DPMI mode to get the graphics
> working in a DOS box in Windows, is this right?
Correct.
Eli Zaretskii
> mini FAQ and I now have more Qs than As.
Indeed, it is. And as such, it is discussed in the DJGPP FAQ list
(vailable as faq102.zip from the same place you get DJGPP),
Chapter 10.
Ron Grunwald
> Anyway. If you are compiling using DJGPP with DPMI is
> it still possible to write directly to the screen, using
> address 0xD0000000 I mean?
>
There is an alternate way to read/write from display memory directly
under DPMI. This requires creating an LDT descriptor first though.
Eg.
Use function 0000h of the DPMI interface API to allocate a
descriptor. In INTEL syntax:
DPMI_INTERFACE equ 31h
mov ax,0000h
mov cx,1 ;allocate one descriptor
int DPMI_INTERFACE
jc error
mov gs,ax ;get segment selector
jmp fill_desc
error:
.
.
.
Once you've created a descriptor you have to initialize it for the
segment that you're trying to access.
mov ax,0007h ;Set segment base address
mov bx,gs ;get segment selector
;Assuming your display segment starts at A000:0000h
mov cx,000Ah ;cx:dx hold the 32-bit linear base addr.
xor dx,dx ;of the segment
int DPMI_INTERFACE
Next, specify the size of the segment. I'm assuming 128Kb for an
super-VGA card.
mov ax,0008h ;Set segment limit
mov cx,0002h ;cx:dx hold the 32-bit segment limit
xor dx,dx
int DPMI_INTERFACE
To read/write directly from display memory all you have to do is to
place the segment selector into a segment register, and specify the
desired offset within the display segment. Eg.
mov gs,display_selector
mov esi,000001F2h
mov al,gs:esi ;read a byte from display memory
Of course what is really handy with this sort of programming is the
DPMI interface programming specification. I'm not sure whether you've
got this, but unfortunately I forgot where I retrieved my copy from.
Regards, Ron.
********************************************************************
| Author.............. Ron Grunwald |
| Internet............ r.gru...@cowan.edu.au |
| Phone............... (09)273 8027 or (09)273 8468 |
|------------------------------------------------------------------|
| Department.......... Computer Operations and Systems Management |
| Division/Faculty.... Information Technology |
| Institute........... Edith Cowan University, Churchlands |
| Location............ Perth, Western Australia |
********************************************************************
"I don't have any solution but I certainly admire the problem!"
Antony Suter
Charles Sandmann <sand...@clio.rice.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?
>
>
>> 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
>
>> 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.
--
- Antony Suter <ant...@werple.mira.net.au> (Rohaan)
- "...in Space, all warriors are Code warriors", Chang, ST6.
Mr A. Walker
: In article <2ffd2e39...@clio.rice.edu>,
: Charles Sandmann <sand...@clio.rice.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
: --