OSDev.org

Posted: **Sat Jun 12, 2004 11:20 am**

I collect informations about Design GUI. I have read that I can use VM86 (I use pmode) to call bios interrupt or VESA. another way use of framebuffer.
I have searched the internet but I don not find a usefull infos.
if someone know a good links or has usefull info about framebuffer, please give it here.

to look at linux framebuffer code or X, it does not give info only code.

at the end I want to write a SVGA driver in kernel, so that application can use it to implement GUI feature like window, buttom etc.

Posted: **Sun Jun 13, 2004 2:21 am**

hi,
It will be better to use Linear Frame buffer. Using LFB you dont need to mess up with bank switching.

First u need to initialize Vesa using Int 0x10,

LFB is an address in memory, IF you write something there will be visible to screen. Same as 0xa00000,

The vesa mode info contains the linear address.
see physbaseptr, in the structure.
Read this info using

just do agoogle.
http://www.google.com/search?hl=en&ie=U ... rogramming

Code: Select all

/* Structure for VESA BIOS EXTENTION mode information as defined by VESA */
typedef struct tagSVGAMODEINFO
{

   /* mandatory information for all VBE verson */
   WORD modeattributes;          /* Mode attributes  */
   BYTE winattributes;           /* Window A attributes */
   BYTE winbattributes;          /* Window B attributes */
   WORD wingranularity;          /* Window granularity */
   WORD winsize;              /* Window size */
   WORD winasegment;           /* Window A start segment */
   WORD winbsegment;           /* Window B segment   */
   DWORD winfuncptr;           /* pointer to window function */
   WORD bytesperscanline;        /* Bytes per scanline   */


   /* Mandatory information for VBE 1.2 and higher */
   WORD xresolution;           /* Horizontal resolution in pixels */
   WORD yresolution;           /* Vertical resolution in pixel */
   BYTE xcharsize;              /* Character cell width in pixels */
   BYTE ycharsize;              /* Character cell height in pixels */
   BYTE numberofplanes;        /* Number of memoryplanes  */
   BYTE bitsperpixel;           /* bits per pixel  */
   BYTE numberofbanks;           /* Number of banks  */
   BYTE numberofimagepages;     /* Number of images  */
   BYTE reserved1;              /* Reserved for page function */

   /* Direct color fields */
   BYTE redmasksize;             /* size of direct color red mask in bits */
   BYTE redfieldposition;        /* Bit position of lsb of red mask */
   BYTE greenmasksize;           /* size of direct color green mask in bits */
   BYTE greenfieldposition;     /* Bit position of lsb of green mask */
   BYTE bluemasksize;            /* size of direct color blue mask in bits */
   BYTE bluefieldposition;        /* Bit position of lsb of blue mask */
   BYTE rsvdmasksize;            /* size of direct color reserved mask in bits */
   BYTE reservedfieldposition;     /* Bit position of lsb of reserved mask */
   BYTE directcolormodeinfo;     /* Direct color mode attributes  */

   /* Mandatory information for VBE 2.0 and above    */
   DWORD physbaseptr;           /* Physical addres for flat frame buffer */
   DWORD offscreenmemoffset;     /* Pointer to start of off screen memory */
   WORD offscreenmemsize;        /* Amount of offscreen memory in 1kb units */
   char reserved2[206];        /* Reserved */
}SVGAMODEINFO;

regards

Posted: **Sun Jun 13, 2004 2:29 am**

out of my ignorance for the state of current graphics chipsets: is it realistic to assume that anything reasonably recent supports VBE2 with linear framebuffer?

Posted: **Sun Jun 13, 2004 3:06 am**

Of cource your hardware needs to support VBE2.

You can check using function 4f00 and 4f01 (int 0x10). I dont know how to do it in pmode. I think you need to initialize in Real Mode and jump to pmode.

I think the latest is VBE3. There are some tutorials in its official site.

http://www.vesa.org/standards_free.html
http://www.vesa.org/tutorials.html

regards

Posted: **Sun Jun 13, 2004 3:20 am**

that mean I should use VM86 mode to access Graphic card.
is there another way, like direct IO access?.

most on web example is suitable for dos program. they use dos services, like ( dpmi.h go32.h ..). I don't use something like those or knowing what is that. I am linux developer not DOS

thanks

Posted: **Sun Jun 13, 2004 3:27 am**

While I can't speak definitively, it is my understanding that most video cards after around 1997 can be expected to support VBE2, while those after 2000 generally support VBE3. These dates are only approximate, of course; you would have to check the docs on the individual cards to see what they support. In any case, you would need to run at least a few real-mode interrupt calls, if only to retrieve to call information for the VBE3 functions.

HTH. C&CW.

Posted: **Sun Jun 13, 2004 3:50 am**

Schol-R-LEA wrote: While I can't speak definitively, it is my understanding that most video cards after around 1997 can be expected to support VBE2, while those after 2000 generally support VBE3.

Ok, that kinda confirmed what I though was the case. Since people probably aren't going to play with cards much older than 1997 in systems I had in mind...

Posted: **Sun Jun 13, 2004 3:50 am**

Is that real, to access Graphic card I should use only real mode or VM86!!!
why using PMode then, when I can not access Graphics Card frame buffer as I in PMode?
most modern Operating System use GUI and I do not thinks they use VM86. X Server or Windows XP is an example.

Posted: **Sun Jun 13, 2004 6:15 am**

okay, let's make things clear: since VBE2, you have a protected-mode interface to functions like Switch Graphic Window of VESA, which means once you have set up the proper video mode, you can do all the other operations safely from protected mode (even if linear framebuffer was unavailable)

Since VBE3, the protected-mode interface also covers mode setting (and the whole VESA api).

Plotting is always performed by video-memory access and doesn't require the VESA to be called in any way

Now, beware with assumption like "cards since 2000 will support VBE3": There's a bunch of cheap chips that were shipped without the smallest VBE2 even recently, since they manufacturer assume the PC will only be used by Win* and they provided a Win* driver to fit all your assumed needs.

(oh. the shame)

Posted: **Sun Jun 13, 2004 6:31 am**

Hi,

amirsadig wrote: Is that real, to access Graphic card I should use only real mode or VM86!!!
why using PMode then, when I can not access Graphics Card frame buffer as I in PMode?
most modern Operating System use GUI and I do not thinks they use VM86. X Server or Windows XP is an example.

The VBE bios supports 2 protected mode interfaces. Starting with VBE 3.0 all of the VBE functions are optionally acccessible from protected mode. To use this interface you need to copy the video BIOS into RAM and scan the first 32 Kb for a "Protected Mode Information Block". Full details are in the VBE 3.0 standard.

If the card doesn't support the VBE 3.0 protected mode interface (which is possible even if the card supports the rest of the VBE 3.0 standard), then you won't be able to change video modes while in protected mode (unless you do it without VBE, or you use virtual 80x86 or real mode).

For VBE 2.0 there's a different protected mode interface using function 0x4F0A. This interface may or may not be available on any card that supports VBE 2.0 or later. This function returns the size and address of a block of memory that needs to be copied (and some other stuff). This block of memory contains code for bank switching and setting palette data. Again see the VBE 2.0 or 3.0 standard for details.

If none of the protected mode interfaces are available you can set the video mode during boot (in real mode) and use it while in protected mode. To do this get a list of video modes from VBE (if present) or use a static one for VGA (if VBE isn't present). All of the video modes in this list will need to be addressable when in protected mode. For example, 320*200 256 colour mode is addressable, but bank switched 1024*768 * 256 colour mode isn't addressable and can't be used. All video modes that support linear frame buffers are addressable. Then you could offer the user a list of video modes to choose from, set the desired mode (including it's palette if necessary). Now your protected mode code can use the video mode, but can't change video modes or the palette.

Because the VBE 2.0 protected mode interface is "bank switching only" it's probably faster to use LFB's instead (if available). Just remember that you may not have access to the palette without VBE.

It gets a bit confusing with all the options, so I did a summary:

Code: Select all

Method                          VBE3.0      VBE2.0      None
Availability                    Optional    Optional    Always
Can switch modes                Yes         No          No
Can use any mode                Yes         Yes         No
Can use LFB modes               Yes         Yes         Yes
Can use bank switching          Yes         Yes         No
Can access palette              Yes         Yes         If VGA compatible
Can use hardware double-buffer  Yes         Yes         No

Switching back to real mode to use the real mode BIOS is technically possible, but it's extermely difficult to do it without missing IRQ's (IMHO it's best to forget this option). It's also possible to use virtual 80x86 mode, but this isn't as easy as it sounds and it isn't impossible if you intend porting your OS to 64 bit mode.

I don't know which way is the best for your OS. My OS creates a list of accessable video modes and sets the video mode before entering protected mode. This is because I intend writing video card device drivers.

Basically the code used in real mode is for cards that don't have any video driver yet. My OS will (hopefully) have a generic VGA video driver (using direct IO ports), a VBE 3.0 video driver (using VBE 3.0 protected mode interface details scanned for after boot) and video drivers for specific video cards (using direct IO ports).

A video driver designed specifically for a particular card would be best option for an end user to use. If there isn't one the end user might be able to use one of the generic video drivers (VGA or VBE3), depending on the card. If none of the generic video drivers can be used then the user can fall back on the real mode code used during boot.

Cheers,

Brendan

Posted: **Thu Jun 17, 2004 10:24 am**

I will try to check VBE 3.0 protected mode interface first.

I need to know if buchs or VMWare support VBE 3.0?

Posted: **Fri Jun 18, 2004 2:47 am**

Hi,

amirsadig wrote: I need to know if buchs or VMWare support VBE 3.0?

I don't know about VMWare, but Bochs will only support VBE 2.0 (if it's configured for it).

Cheers,

Brendan

Posted: **Fri Jun 18, 2004 2:48 am**

bochs doesn't, afaik. nor does it support VBE2
i can't tell for VMware ...

Posted: **Fri Jun 18, 2004 4:57 am**

VMware supports the both of them, VBE 2.0 & VBE 3.0

Bochs supports VBE 2.0, if you provide it the appropriate vbe bios in bochsrc:

vgaromimage:/root/bochs/VGABIOS-lgpl-latest.bin --> on the plex86 homepage,this image can be obtained.

mark: to my knowledge, this vgabios only supports VBE modes with 8 bpp. Dunno if they 've added more in the meantime, for I don't care for bochs atm as it doesn't work with my floppy driver - any hardware and vmware do! *grmpfl*

hth & stay safe.

Posted: **Sat Jun 19, 2004 3:07 am**

hi
I have readed here that new version of bochs support VBE 3.0.

read this http://osdev.neopages.net/tutorials/bochs/bochs.php

OSDev.org

Using framebuffer to build GUI

Using framebuffer to build GUI

Re:Using framebuffer to build GUI

Re:Using framebuffer to build GUI

Re:Using framebuffer to build GUI

Re:Using framebuffer to build GUI

Re:Using framebuffer to build GUI

Re:Using framebuffer to build GUI

Re:Using framebuffer to build GUI

Re:Using framebuffer to build GUI

Re:Using framebuffer to build GUI

Re:Using framebuffer to build GUI

Re:Using framebuffer to build GUI

Re:Using framebuffer to build GUI

Re:Using framebuffer to build GUI

Re:Using framebuffer to build GUI