Sender: nate AT cartsys DOT com
Message-ID: <3791484A.885F939D@cartsys.com>
Date: Sat, 17 Jul 1999 20:21:46 -0700
From: Nate Eldredge <nate AT cartsys DOT com>
X-Mailer: Mozilla 4.08 [en] (X11; I; Linux 2.2.10 i586)
MIME-Version: 1.0
To: djgpp AT delorie DOT com
Subject: Re: 0xA000 plot pixels questions in 13h mode
References: <3 DOT 0 DOT 1 DOT 32 DOT 19990717221010 DOT 00698cd8 AT apiitkl DOT edu DOT my>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp AT delorie DOT com

Mark wrote:
> 
> Hello all,
> 
> I am just a beginner, so bear with me.
> 
> I am reading several tutorials on game programming using DJGPP to gain some
> basic game programming skills in 13h mode. After hours of trying out
> snippets and reading the DJGPP FAQ and browsing the info.exe, I found out
> that I couldn't access 0xA000 directly. "use the so-called "farptr"
> functions like _farpeekb and _farpokew" is stated in the FAQ. I tried a lot
> and I finally got a pixel plotted on the screen using the <go32.h> and its
> functions:
> 
>    _farsetsel(_dos_ds);
>    _farnspokeb(0xA0000 + y*320 + x, color);
> 
> - What is the "farptr" for ? And what is a poke and a peek ?

[Very simplified explanation]

The Intel x86 architecture is "segmented", which means memory is divided
into pieces.  Things in the current segment are referred to as "near",
while stuff outside it is "far".  The segment used for DJGPP programs
contains the program and nothing else.  So, to get to stuff outside your
segment, like the video buffer, you need a far pointer.

Peek = read (examine), poke = write (change).  Makes sense when you
think about it.

> - I noticed that there are lots of functions that look so much like the above:
>         _farpokeb
>         _farpokew
>         _farnspokew
>         etc.
>   which is now the best or easiest way for me to use for this plotting
> pixel stuff.

The suffixes b, w, l indicate the size of what is poked.  "b" for byte,
"w" for word (16 bits, like a `short'), "l" for long (32 bits, like a
`long').

You'll notice that the ones with "ns" in the middle don't require the
segment as one of their args ("ns" = "no segment").  You must select the
segment first with `_farsetsel' for these.  This is a performance
advantage but probably not useful when getting started.  The others pass
the segment each time.
 
> - Why are there so many functions that look like they are far or near types
> ? The compiler is 32bit and in the FAQ stated that DJGPP doesn't even
> recognise the far and near types ?!?!

Some compilers allow you to specify near and far as part of the pointer,
like `char far *p'.  GCC (DJGPP's compiler) doesn't-- all pointers are
effectively near.  These functions are provided to let you access memory
outside your segment anyway.
 
> - Also a tutorial mentioned that I could disable/enable the protected mode
> using __djgpp_nearptr_enable();
>  and __djgpp_nearptr_disable() for pixel plotting. But it also stated that
> it could damage the DOS area and block the system ?! How much damage can it
> do? Would it be permanent ?

It would be possible to overwrite anything that's in memory, which would
probably crash the system.  There are also disk caches in memory
(usually), so nothing on the hard drive would really be safe either. 
Note that there is nothing inherently dangerous about these functions;
it's just that they allow any other bugs in your program to do a lot
more damage.

-- 

Nate Eldredge
nate AT cartsys DOT com