delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1996/10/15/14:49:43

From: "Salvador Eduardo Tropea (SET)" <salvador AT inti DOT edu DOT ar>
To: Emil0 AT aol DOT com, djgpp AT delorie DOT com
Subject: Another way to access VGA memory
Date: Tue, 15 Oct 1996 15:16:42 +0300 (GMT)
Message-ID: <9610151516.aa12417@ailin.inti.edu.ar>

Hi Richard, here SET from Argentina:

Richard wrote:
>I have a neat way to access video memory which I haven't seen done anywhere
>else. Maybe I'm wrong - maybe everyone does it - but here it is:
  I'm using this technique from 5/96 that was my second approach to access 
video memory with DJGPP, the first was use the ..._map_physical_... but that's 
incompatible with Loose 3.1 (:-) so I switched to this methode.

>Get a descriptor by calling the (badly named) __dpmi_segment_to_descriptor()
>to segment 0xA000. Whack this into a global variable. You can now use this in
>any assembler module - you can put it in a segreg in one instruction, ie.
>movw _vga_ram_descriptor, %es. There is no overhead of calling a library
>function. You don't even need to trash another register!
Wait!!!, you don't need to use %es, you can use a less used selector like %gs 
or %fs.

>At first this method might seem to be a "hack" - the documentation says this
Not a hack, see the farpoke/peek family.

>function should be "used sparingly". It is however in the DPMI specs, and so
>is guaranteed to be in all future DPMI versions (I think...). It's worked on
Eli explained well the situation, the fact is that some DPMI server have 
allready allocated descriptors for the 0xA000 and 0x40 segments and when you 
need one can offer to you your copy (not with a DPMI service) to avoid the 
generation of hundreds of descriptors.

>every host I've tried it on. Also, there is still full memory protection as
>the segment limit will default to 64k. Therefore you can only access video
>memory which can't do any harm.
Yeap! that's the good part, you can't destroy DOS or Losse with a wrong 
calculus, and (at least for my program) is equally fast than the nearptr 
methode (that's a really HACK :-), and I don't need to make strange arithmetic 
adding the __djgpp_base... so from my point of view the load of the selector 
isn't a problem (at least isn't worst than the base addition). Even more: if 
your program have a really fast part where you don't call any of the library 
functions you can load the selector only one time and reload it only when you 
suspect that the value was loosed, I'm doing this and works OK. In the other 
hand if I use nearptrs I must add the base in tons of parts so is worst.
  That's my opinion, I know that Eli thinks that the nearptrs are faster than 
this methode.

>Any comments? Maybe someone knows how Carmack-Abrash do it?
  As you can see a lot of comments!

>Richard.  :)  Please reply to emil0 AT aol DOT com as I only get the weekly digest.
>Thanks!

SET

********************************************************************************
Salvador Eduardo Tropea (SET) - salvador AT inti DOT edu DOT ar
Work: INTI (National Institute of Industrial Technology) Sector: ICE 
(Electronic Control & Instrumentation)
Post (Home): Curapaligue 2124 - Caseros (1678)- Buenos Aires - Argentina 

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019