From:	Persona <mailto:wribak AT usa DOT net>
Newsgroups:	comp.os.msdos.djgpp
Subject:	a small pmode question
Date:	Sun, 17 Aug 1997 02:31:40 -0700
Organization:	Spamless Society
Lines:	30
Message-ID:	<33F6C4FC.44F@usa.net>
NNTP-Posting-Host:	lap-ca5-47.ix.netcom.com
Mime-Version:	1.0
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp

I have been a real mode programmer for a long time, and I am just
beginning to grasp the strong and easy concepts of pmode.  Just starting
out learning VESA, I found a piece of text talking about __tb.  Please
bare with me, thanks... :)

------------
The VESA detection routine requires a memory buffer in conventional
memory where it will return all the information about the
card. We could use __dpmi_allocate_dos_memory() with the size of
sizeof(VBE_VgaInfo) although there is an easier way.
DJGPP uses a globally available transfer buffer which typically 4KB in
size. We can use this buffer as our conventional memory
buffer. After the call to VESA function 0x4F00 we will just copy the
transfer buffer to our VBE_VgaInfo structure. The buffer
is called __tb and in defined in go32.h. However, for us to use it we
need a segment and offset pair, even though we're in
protected mode, because VESA functions (with the exception of version
2.0 which I'll discuss later) go back to real mode to
acomplish their tasks. T he offset is equal to __tb & 0x0F and the
segment is equal to (__tb >> 4) & 0xFFFF.
------------

From my understanding, (__tb >> 4) & 0xFFFF is redundant; the "& 0xFFFF"
is not necessary since it's up to 64k limit anyways.  The __tb & 0x0F is
the part I am a bit curious.  Why would __tb be AND 0x0F, in the range
of 0 ~ 15 dec.  Why is it assumed that it won't be starting from 0, if
that's not the case, why not __tb & 0xFF, or __tb & 0xFFF, etc.

Please feed my curious mind.  And guide me if I am wrong somewhere. 
Thank you!

- Raw text -