From: Persona 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 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Precedence: bulk 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!