delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1997/06/20/22:53:39

From: Shawn Hargreaves <Shawn AT talula DOT demon DOT co DOT uk>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Vesa 2.0 init/detect. Need clarification/help.
Date: Fri, 20 Jun 1997 19:48:41 +0100
Organization: None
Distribution: world
Message-ID: <RoFH+OAJCtqzEw0d@talula.demon.co.uk>
References: <33A8646E DOT 5438F0D0 AT execulink DOT com>
NNTP-Posting-Host: talula.demon.co.uk
MIME-Version: 1.0
Lines: 57
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp

Jeff Weeks writes:
>So, why does everybody place "VBE2" into their VESASignature before
>calling function 0x4F00?  

According to the VESA spec:

   The VbeInfoBlock information block size is 256 bytes for VBE 1.x, 
   and 512 bytes for VBE 2.0.

   Input:    AX   = 4F00h  Return VBE Controller Information
          ES:DI   =        Pointer to buffer in which to place
                           VbeInfoBlock structure
                           (VbeSignature should be set to 'VBE2' when
                           function is called to indicate VBE 2.0
                           information is desired and the information
                           block is 512 bytes in size.)

So, you must pass this string to tell the driver you have allocated
enough space for the info structure, and it can safely return the full
512 bytes of information. It's just to avoid breaking old VBE 1.2 apps
that only provide a 256 byte info buffer...

>How can I detect Vesa 2.0?  Can I only check
>the VESAVersion variable?

VESAVersion is indeed the way to go.

>Do all Vesa 2.0 implementations have a protected mode interface?  I'm
>under the impression that not all have a linear frame buffer interface,
>correct?  But what about pmode interface.

I suspect all do, but I wouldn't rely on it. It would probably be a good
idea to check both for an error return code from 0x4F0A, and also for
NULL function pointers in the returned table. You may never see such
things, but robust code is always a good thing...

The linear framebuffer is indeed not always available: this is a
hardware thing rather than just a software API, and some cards don't
support it.

>Also, if one mode supports a pmode interface or a lfb, does that mean
>all others will as well?  Or is it possible for only some modes to have,
>for example, a lfb?

It is indeed. Check bit 7 in the ModeAttributes field to see if an LFB
is available. Since this is a per-mode structure, there is no reason why
it should be the same for all resolutions.

I suspect if the pmode interface is supported in one mode it will be in
them all, but again it can't hurt to be sure: I'd grab a new copy of the
code every time you change mode, and check for error status at the same
time.


--
Shawn Hargreaves - shawn AT talula DOT demon DOT co DOT uk - http://www.talula.demon.co.uk/
Beauty is a French phonetic corruption of a short cloth neck ornament.

- Raw text -


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