Sender: mike AT Home-51 DOT inp DOT nsk DOT su
To: Michael Bukin <bukinm AT inp DOT nsk DOT su>
Cc: djgpp AT delorie DOT com
Subject: Re: Direct Access vs. Far vs. Near
References: <19971101224800 DOT RAA21869 AT ladder01 DOT news DOT aol DOT com>
	<m3lnz6bu2u DOT fsf AT H-Bukin DOT inp DOT nsk DOT su>
From: Michael Bukin <bukinm AT inp DOT nsk DOT su>
Date: 03 Nov 1997 15:08:20 +0600
In-Reply-To: Michael Bukin's message of 03 Nov 1997 08:16:25 +0600
Message-ID: <m3bu02jqez.fsf@H-Bukin.inp.nsk.su>
Lines: 69
Precedence: bulk

Michael Bukin <bukinm AT inp DOT nsk DOT su> writes and corrects himself:

> eggbrains AT aol DOT com (Egg brains) writes:
> 
> > okay, anyway, in my program (a start of a graphics lib -- yes, i know about
> >  Allegro)  i draw pixles to the screen (what else).  when i directly wrote
> >  to the screen ie:
> > 
> > vga = (unsigned char*)MK_FP(0xA000, 0);
> > vga[where]=color;
> > 
> > i can draw about 1.6 million pixels per second, however,
> > when using Farnspoke,
> >  i can draw up to 3+ million pixels per second... why is it so much faster?
> > 
> 
> Try assembler for the first. Or
> *((unsigned char*) MK_FP (0xA000, where)) = color;

DJGPP has no MK_FP, because gcc has no idea about "far" pointers (*).
You can have almost the same result by using _far... functions and loading %fs
segment register with specific selector or by using inline assembly.

--- Trying to explain "far" pointers (correct me if I'm wrong)
(*) "far" pointer in C is a pointer, which on dereferencing will
use address consisting of both selector and offset (segment and offset in
real-mode).  It is an extension to C language for some DOS compilers.

Also, far pointers for real-mode compilers are not very efficient, because
of weird pointer arithmetics. Again, use assembler for maximum speed.
> 
> Make sure you use the same video mode for both methods.

For some video cards memory access speed depends on what video mode you use.
E.g. on mine, it is fast in VBE2.0 modes and slow in 0x13.
> 
> > would using the near access go faster yet?
> 
> Most probably not.

_far... functions add segment override prefix compared to near functions
(and usual accesses to program's data).  If segment override is slower
for your processor, then video access may be slower also.

Also, you can avoid segment override by using inline assembly and
loading selector in default segment register,
i.e.

__asm__ ("pushw %%es; movw %%ax,%%es; movb %%dl,(%%edi,%%ecx); ...popw %%es");

It is not complete example and I'm not sure that %%es
is default segment register for addressing with (%%edi,%%ecx).
> > 
> > anyway, using the Far mode, how would i make selectors to sprites?
> > would i make the sprites by define an array (with malloc/new etc...)
> > and then make a selctor to it?  what about if I change the size/location?
> > i will need to make a new selector right?
> > an since you can't delete selectors if i re-size it
> >  enough will i run out of memmory?
> 
> You need not make selector for memory allocated with malloc/new, I don't
> know where the selector is, but looking into libc references, _my_ds ()
> is a good candidate and alternatively you can get it
> from %%ds with inline assembly.
> 
> BTW, Allegro has selector in BITMAP structure, so it is all there, I think.

I mean you can look there, it is rather clear (I've looked it up, and sure,
it uses `_my_ds ()' for getting selector value for accessing memory bitmaps).