OSDev.org

It has been discussed numerous times here how to work with higher resolution graphics. Since I wanted to do some tests I thought I'd write a small sample.

The idea would be to set a suitable graphics mode (through VBE [VESA BIOS Extensions]) and then use that through the linear frame buffer once you are in protected / long-mode etc.

The sample is exactly 512 bytes long (so you can stick it on a bootable floppy) and does the following:

- check for VBE 2.0 or higher
- find a suitable mode (graphics 800 x 600 in either 24 or 32-bits, [direct]color, linear framebuffer, available)
- switch to that mode
- enable A20 and unreal mode to be able to access the frame buffer
- draw a gradient like background
- draw the graphics card manufacturer string on top (with alpha blending) of this background

This should illustrate various things (like font writing, using a builtin 8x8 ROM font) and is hopefully of some use.

There are some restrictions. I've built it with MASM (Microsoft) and it probably won't compile with NASM/FASM etc. Perhaps someone else is willing too look into that. You will also need at least a 486 with a fast A20 enable option.

And of course a VBE 2.0 compliant video card with the proper video mode. For some reason I could not get it to run in QEMU, but it has been verified to run under Bochs, Virtual PC and three actual computers with various graphics cards.

The archive includes the full source (free to use), ISO and floppy image, build options (if you have MASM) and mkisofs to create an ISO file from the floppy image.

Download the whole archive here:

www.visuar.com/projects/VBETest.zip

I've also put two screenshots up anyone just wants to see the end result:

www.visuar.com/projects/VBEBochs.png (Bochs, 24-bit)
www.visuar.com/projects/VBEVirtualPC.png (MS Virtual PC, 32-bit)

This code is far from optimal in performance and perhaps in size (especially since it uses a lot of 32-bit instructions/registers in 16-bit code). However, I think it is quite clear and pretty well documented.

If someone is going to work with VBE do get the latest specification and read it *thoroughly*! There are a lot of minor things to get right. Don't worry, there are still lots of things unclear (that's why the test). Especially on how to write the 24 and 32-bit data (see my code).

Get the version 3 spec here (PDF):

http://www.vesa.org/public/VBE/vbe3.pdf

I hope this is useful to someone and please let me know what everyone thinks!

p.s. in case you are wondering, a lot of optimization can be done in real protected mode or long-mode (this would work great with the 64-bit and extra(!) registers). Pentium U & V pipe optimization, sse / mmx, lookup tables, converting the font bit-table to a true color alpha mask only once, etc. Do keep in mind that if you gonna de optimization you only do it if it is really needed and you PROFILE to make sure it improves!

p.p.s. you definitely want to change at least two things in this source. Get rid of the 64 conditional jumps per character and use at least double buffering (don't draw directly to video memory, except to copy your prepared page [in one fell swoop with mmx / sse / dma])

Hi,

That's very nice work!

One minor suggestion though - technically, you'd wan't to use "ModeBytesPerScanline" (or "LinBytesPerScanLine" for VBE 3.0 LFB).

The reason is that a logical scan line may be longer than it's visible portion. For example:

[tt]XXXXXXXX----
XXXXXXXX----
XXXXXXXX----
XXXXXXXX----[/tt]

Where 'X' is visible, but '-' is not.

For example, on some video cards, in 32 bpp 800*600 mode you might find that "ModeBytesPerScanline" is 4096 bytes, not 3200 bytes, and you'd need to write 3200 bytes and then skip the remaining 896 bytes to get to the beginning of the next screen line.


BTW you also need to add a link to this code in the FAQ! ;D


Cheers,

Brendan

Thanks Brendan. I was actually wondering if I need(ed) BytesPerScanline. Guess I didn't see the LinBytesPerScanline. I'll see if I can work that in tomorrow.

The FAQ might be a good idea, but I guess it would be better if we could embed the code or archive in there instead of on my server.

As a side note, that code only reads the first half of the character set (128 characters), so if the vendor string (or whatever input) contains any characters above ASCII 127 strange things start to happen.

None of the control characters are processed either (carriage return, tab, etc.). Just about drawing stuff

Brendan: I checked the spec, this is what they say:

The BytesPerScanLine field specifies how many full bytes are in each logical scanline in banked modes. The logical scanline could be equal to or larger than the displayed scanline (the number of physical pixels displayed). For linear modes please refer to the LinBytesPerScanLine field.

Which, as usual, is pretty vague. I mean, LinBytesPerScanLine is only supported from VBE 3.0. None of my physical (and two of those are pretty new models) cards I have available have VBE 3.0. Nor do any of the virtual ones.

So if it isn't available should I/we use BytesPerScanLine instead? But they say it is for banked modes. Sigh.

I guess I'll have to fire up another test program and see what the value of that field is on my physical and virtual cards.

You would've thought the spec would be clear in a version 3 of the document. But no, no mention of what the reserved mask does in direct color mode, no mention of how you are supposed to write 24-bit color to memory exactly (the first color part of a pixel gets written twice in my code now in 24-bit mode), etc. etc. ::)

Hi,

Rob wrote:Which, as usual, is pretty vague. I mean, LinBytesPerScanLine is only supported from VBE 3.0. None of my physical (and two of those are pretty new models) cards I have available have VBE 3.0. Nor do any of the virtual ones.

So if it isn't available should I/we use BytesPerScanLine instead? But they say it is for banked modes. Sigh.

I haven't been able to find an official version of "VBE 2.0", but from this document, which looks very similar it says:

"The BytesPerScanLine field specifies how many full bytes are in each
logical scanline. The logical scanline could be equal to or larger
than the displayed scanline."

From this I would assume that everything before VBE 3.0 used BytesPerScanLine, and everything after that should use BytesPerScanLine for banked modes and LinBytesPerScanLine for LFB modes.

I would also assume the same for the primary colour shift and mask values...

Rob wrote:You would've thought the spec would be clear in a version 3 of the document. But no, no mention of what the reserved mask does in direct color mode, no mention of how you are supposed to write 24-bit color to memory exactly (the first color part of a pixel gets written twice in my code now in 24-bit mode), etc. etc. ::)

If life was meant to be easy, we wouldn't need cemeteries.

The reserved mask is used for bits that should be zero. This includes the highest 8 bits of a 32 bpp pixel, and the highest bit of a 15 bpp pixel. Some video cards use these bits for extra features.

For example, I read about one video card (can't remember which) that uses the highest bit in a 15 bpp pixel to select an 8 bpp colour (from the palette, just like in 256 colour mode). For the value 0x8012 it would look up index 0x12 in the palatte and use that colour. For most video cards the palette can be switched into "8 bit per primary colour" mode (rather than the standard "6 bit per primary colour" mode), so this gives up to 256 colours at 24 bpp in a 15 bpp mode.

For 24 bit modes, I use something like:
Where "<colour>" is calculated from the colour shift and colour mask values.

To be honest - I actually check that red is the highest 8 bits, green is the middle 8 bits and blue is the lowest 8 bits, and then refuse to use the video mode if it's not. Bit diddling isn't so good for performance and video cards that don't fit this are rare (but do exist).


Cheers,

Brendan

Brendan wrote: I would also assume the same for the primary colour shift and mask values...

The VBE 3 spec actually says so for the primary colo(u)r shifts and masks. But not for the scanline length. Probably a small oversight on their part.