Entering mode 640x480x32-bit color in VESA

[~]

The snippet to formulate will be useful to test graphics function in a fairly standard screen size (640x480).

We need a very simple, tiny snippet interface to enter this particular graphics mode whenever we just have any graphics task to try out.

We want a 32-bit color VESA mode because we can easily scale it down to other color resolutions and palettes using RGB conversions, and we also want it because we can test several basic algorithms with full color.

This particular snippet needs to set the video mode without testing whether it exists or if it corresponds to the video number for the present VESA version. We will make such detection and selective calling of modes for a VESA version in another layer of compatibility modules.

[glauxosdever]

Hi,


There are plenty of snippets that show how to setup a 640x480x32 mode with VBE. There is also documentation that gives more information on how to use VBE.

If you feel there is lacking information on some topic, then you can contribute to the wiki.

Edit: Don't contribute to the wiki.


Regards,
glauxosdever

[~]

I got some source code here. I won't type it here because it will become outdated from its source. With the function presented here we can set mode 640x480 32-bit color with Linear Frame Buffer enabled, or report if graphics mode setting failed:

00000000_VESA_Set_Mode_112h_640x480x32bit_LFB.asm


>> Click here if you want to replay a recording of how the code was typed (drag around the directory tree window with the mouse if it blocks the "Play" button) <<


Here is a ZIP with HTML pages and text files I used for references. I am archiving their original URLs and the pages/files in case they disappear. You get among other things a nice basic list of VESA mode numbers in a table with 32-bit modes in bold font:
web_resources-2016-08-25.zip



_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________
Now I need to know how to locate the LFB base address for the case where I don't need to detect anything (it's an initial test case to get going).

I also need to see how to write a generic skeleton application to embed any test snippet, such as this.

[Brendan]

Hi,

I got some source code here. I won't type it here because it will become outdated from its source. With the function presented here we can set mode 640x480 32-bit color with Linear Frame Buffer enabled, or report if graphics mode setting failed:

That code is bad - e.g. it uses the "fixed mode numbers" that were deprecated 20+ years ago (VBE 2.0, 1994) instead of searching the list of available modes for something that matches the resolution and pixel format. Note: a perfectly legal 32-bpp pixel format can be "2 bits of cyan, 3 bits of magenta, 4 bits of yellow, 23 reserved bits" - "bits per pixel" alone is not enough to adequately determine pixel format.

Also note that even just requiring a specific resolution, or a specific pixel format, is also bad. For example, there are lots of (older) video cards that don't support 32-bpp at all and only support 24-bpp (and also lots of cards that only support 32-bpp and don't support 24-bpp). Well written software works with almost any resolution and a wide variety of pixel formats; and finds the most suitable video mode that it supports. This is mostly done via. "filter then score" - filter out the video modes that VBE lists but can't be supported (by OS, or by OS and monitor), then give them a score representing how good they are (e.g. how much the mode matches end user's preferences), and choose the mode with the best score.


Cheers,

Brendan

[~]

Hi,

That code is bad - e.g. it uses the "fixed mode numbers" that were deprecated 20+ years ago (VBE 2.0, 1994) instead of searching the list of available modes for something that matches the resolution and pixel format. Note: a perfectly legal 32-bpp pixel format can be "2 bits of cyan, 3 bits of magenta, 4 bits of yellow, 23 reserved bits" - "bits per pixel" alone is not enough to adequately determine pixel format.

Also note that even just requiring a specific resolution, or a specific pixel format, is also bad. For example, there are lots of (older) video cards that don't support 32-bpp at all and only support 24-bpp (and also lots of cards that only support 32-bpp and don't support 24-bpp). Well written software works with almost any resolution and a wide variety of pixel formats; and finds the most suitable video mode that it supports. This is mostly done via. "filter then score" - filter out the video modes that VBE lists but can't be supported (by OS, or by OS and monitor), then give them a score representing how good they are (e.g. how much the mode matches end user's preferences), and choose the mode with the best score.


Cheers,

Brendan

I am using the logic of:
- Specific raw functional modules (like specific, fully-defined tricks for a particular individual case, useful only for a case with a fixed set of static details).
- Module-selecting subsystem.
- Usable-module-detection subsystem.


I'm only implementing the lowest and easiest level here. It's just for a quick enable.

When I get enough graphics tests going, and when this code alone fails in too many cards, I will already be able to easily plug it through those other detection layers, because it's already thought to be called as one among several low-level functions.

At least it returns TRUE (1), FALSE (0) or "VESA_NOT_AVAILABLE" (-1) values in EAX/RAX using the BIOS mechanism, so at that level it should notify if it failed, to terminate the application and, if urgent enough, write some of the detection layers and detection-dependent VESA code.

But as is, it's clean code that can be used if its system function is available available and only if this is available in a machine (I want to support all of my old hardware, so I am starting from the most basic but still library-level functions, capable to be added to a big compatible layer that can support all VESA implementations as needed by the tests I'm creating).

I will run a visual test by creating a simple obvious pattern. If it looks good, then we know that it's the right mode. If not, we can later write code to simply select available modes and software write modes with +/- keys, and then ENTER to report the exact combination used that we want to use and that looks right, to cache it and then re-apply it, no longer needing to scan manually with +/-.

[Brendan]

Hi,

At least it returns TRUE (1), FALSE (0) or "VESA_NOT_AVAILABLE" (-1) values in EAX/RAX using the BIOS mechanism, so at that level it should notify if it failed, to terminate the application and, if urgent enough, write some of the detection layers and detection-dependent VESA code.

If it returns TRUE (1), then it successfully set mode 0x112, which could be a 123*456 mode that uses 64 bit-per-pixel and the "CMY" colour space.


Cheers,

Brendan

[freecrac]

Hi,

Some usefull, public and costfree documents from vesa.org(register/login) are:
vbe3.pdf

For to get the monitor information of an analog CRT-monitor:
EEDIDguideV1.pdf
EEDIDverifGuideRa.pdf

Dirk

[Kazinsal]

Your broken code hung my graphics card.