VESA mode

[Dhaann]

Hi,

I've found this code: http://visopsys.org/osdev/sources/vesaModes.php
it finds the right video mode, but how do I actually 'choose' this video mode so I can use it? My goal is to have higher resolutions and better graphics..

Dhaann

[Antti]

Code: Select all

INT 10 - VESA SuperVGA BIOS - SET SuperVGA VIDEO MODE

	AX = 4F02h
	BX = new video mode
	ES:DI -> (VBE 3.0+) CRTC information block, bit mode bit 11 set

Return: AL = 4Fh if function supported
	AH = status
	    00h successful
	    01h failed

Code: Select all

Bitfields for VESA/VBE video mode number:
Bit(s)	Description	)
 15	preserve display memory on mode change
 14	(VBE v2.0+) use linear (flat) frame buffer
 13	(VBE/AF 1.0P) VBE/AF initializes accelerator hardware
 12	reserved for VBE/AF
 11	(VBE v3.0) user user-specified CRTC refresh rate values
 10-9	reserved for future expansion
 8-0	video mode number (0xxh are non-VESA modes, 1xxh are VESA-defined)

Example code:

Code: Select all

	call findGraphicMode
	mov bx, ax
	bts bx, 14     ; Enable Linear framebuffer (check that it is supported)
	mov ax, 0x4F02
	int 0x10

For more information, check this:

http://www.delorie.com/djgpp/doc/rbinter/id/80/2.html

[Brendan]

Hi,

I've found this code: http://visopsys.org/osdev/sources/vesaModes.php
it finds the right video mode, but how do I actually 'choose' this video mode so I can use it? My goal is to have higher resolutions and better graphics..

It finds the first video mode with the requested horizontal resolution, virtual resolution and colour depth, that supports a linear frame buffer. This isn't the same as finding the right video mode. For example, if you ask for "320 * 200 * 256" it will probably fail to find it (as this is a VGA mode and no LFB is required to access it all), and if you ask for "800 * 600 * 16bpp" you won't know if pixels are "RGB" or "BGR" or 65536 shades of grey.

It's also probably the wrong way to approach the problem. Normally you'd want to get a list of all video modes and filter out any modes that the OS doesn't support (and then determine the "best" mode from whatever is left); instead of asking for one specific mode and then giving up if that one mode isn't supported.

To set a video mode, see "Function 0x02 - Set VBE Mode" in the VBE Specification.


Cheers,

Brendan

[Antti]

This is a little bit advanced viewpoint but would it be reasonable to save the list of supported modes (the one that terminates with the value FFFFh) elsewhere before making further VESA calls.

Is it standardized that the list will remain available after next int calls? I know that usually the list is stored inside the same info structure as the pointer itself. Then it remains available as long as you want.

I am quite sure that this is not going to be problem but I am just pedantic when it comes to standards.

[Antti]

I was wrong. At least the VBE3 standard (I did not check the earlier versions) says:

VBE 3.0 BIOS implementations may place this mode list in the Reserved area of the VbeInfoBlock if 'VBE2' is preset in the VbeSignature field on entry to Function 00h, or have it statically stored within the VBE implementation.

"Statically stored" is the keyword here. So it remains available but I am not going to modify my "copy the list to the save place code."

[Dhaann]

thanks for the replies, I also found this on the forum: http://forum.osdev.org/viewtopic.php?t=9700 and this on the wiki: http://wiki.osdev.org/Getting_VBE_Mode_Info
is this the right way to set the video mode? I also want to use the 256 color palette (with resolution 1024x768), but I can't find much practical information about that.. Is 256 the usual color palette for an os (such as windows/mac use)? read also about 32-bpp mode, looks like a lot more colors

it's the first time I am programming graphics for the os. tried vga as well, but I read vesa has got more options.

[Brendan]

Hi,

I also want to use the 256 color palette (with resolution 1024x768), but I can't find much practical information about that..

If you support 1024 * 768 with 256 colours, then it should be very easy to support 800 * 600 with 256 colours, or any other resolution with 256 colours. In this case you'd want to search the list of video modes for any video mode that is 256 colours (that can be accessed without bank switching); and then maybe find the video mode that is closest to 1024 * 768 (which might be 1024 * 600, or 1152 * 768 or something else).

For 256 colour modes, you need to deal with the palette. My advice is to use the VBE function to set the palette to whatever you want (and do *not* use the similar BIOS function or use the VGA registers directly). I tend to just set the palette up as "3 bits of green, 2 bits of red and 2 bits of blue" (e.g. so the colour 0xE3 is cyan). It is possible to calculate the best palette to use for each frame and reconfigure the palette to suit that frame, and get a better end result (but it's hard to avoid shearing effects and the overhead is a lot higher).


Cheers,

Brendan

[Dhaann]

I've put Antii's code example in the stage where we're still running real mode, doesn't give any errors (so I assume it's working). Then it enters protected mode and the kernel loads. But how can I check from here wether the video mode is really selected (there aren't any changes on the screen)?

[Antti]

I've put Antii's code example...

That piece of code should be considered as pseudo code. There is no any error checking and it does not even give any parameters to the 'findGraphicsMode' function. The purpose of it was just to give some basic idea.

If you really checked the error and there were none, then the mode should change.

[freecrac]

Hello maybe i can help too.
At last i have also a question, but later.

This little piece of code shows how to get a vesamode-number(unknow) for a desired resolution and/or other criteria, for that we can get mode informations.

Code: Select all

; The code is for the 16 Bit Realmode
MaxX = 640   ; Horizontal resolution
MaxY = 480   ; Vertical resolution
BpP   = 32     ; Bits per pixel

          mov      ax, DATEN           ; Store relative Segmentadress of the Datasegment
          mov      ds, ax              ;  into DS-Segmentregister
          mov      es, ax              ;  into ES-Segmentregister
          mov      di, OFFSET VINF     ; Buffer(512 Bytes) for VESA-Info
          mov      ax, 4F00h           ; Function 0
          int 10h                      ; Get up to 512 Bytes es:di (Datasegment:VINF)
          cmp      ax, 4Fh             ;  succsesfull ?
          jnz NOVESA                   ;   else error: no Vesabios aviable
          cmp     Byte PTR[di+5], 2    ; Compare major version number of Vesa
          jb  NOVESA2                  ;  lesser than Version 2?
          lfs      si, [di+0Eh]        ; Get pointer of Modelist in FS:SI

MODE:     mov      cx, fs:[si]         ; Get Modenumber
          lea      si, [si+2]          ; Increase Offset of modelist (instead of add si,2)
          cmp      cx, 0FFFFh          ; End of list ?
          jz  NOMODE
          add      cx, 4000h
          mov      ax, 4F01h           ; Get Mode Info
          mov      di, OFFSET MINF     ; Buffer(256 Bytes) for Mode Info
          int 10h
          cmp      ax, 4Fh
          jnz NOVESA
          cmp     Word PTR[di+12h], MaxX
          jnz MODE
          cmp     Word PTR[di+14h], MaxY
          jnz MODE
          cmp     BYTE PTR[di+19h], BpP ; Bits per pixel?
          jnz MODE

;- other compare instructions -

; ------Our DS-SEG-----
VINF   DB 512 dup (0AAh) ; Buffer for Vesa-Info(4F00h)
MINF   DB 256 dup (044h) ; Buffer for Mode Info(4F01h)

Additional we can check other importend bits in the ModeAttributes field.
we can check the FieldPosition and the MaskSizes of each color fleld and if we become a BGR or RGB orientation for the bits of the green, red and blue field
we can check how many BytesPerScanLine exist
we can check if the address of the linear framebuffer exist, or if there only 4 zero bytes
VBE 3:
we can check if we can use hardware triple buffering for flicker free large movements on the screen without to become a tearing of the content
(more usefull in combination with a higher refreshrate)
we can check the MaxPixelClock if we want to use our own CRTC-parameter for a higher refreshrate >60hz

If we want to use a vesamode with our own CRT parameter table (VBE 3 only with modenumber+800h ),
then we can try to get some informations of our CRT-monitor before to make sure that we do not exeed the capacity of it.
(Note: Older 5 pol BNC(bayonet connector) cable have no DDC(Display data channel) for to transmit the EDID(extended dispay information data))

Code: Select all

 
	  mov      ax, 4F15h           ; DDC - INSTALLATION CHECK
	  xor      bl, bl
	  int    10h
	  cmp      ax, 4Fh
	  jnz NODDC

	  mov      ax, 4F15h           ; DDC - READ EDID
	  mov      bl, 1
	  xor      cx, cx
	  xor      dx, dx
	  mov      di, OFFSET EDID     ; es:di 128 byte
	  int    10h
	  cmp      ax, 4Fh
	  jnz short NODDC
	  mov      eax, 0FD000000h     ; Text-identifier V/H range
	  mov      bx, 36h
	  cmp      eax, [di+bx]        ; di+36h detailed timing #1
	  jz  short RANGE
	  lea      bx, [bx+12h]
	  cmp      eax, [di+bx]        ; di+48h detailed timing #2
	  jz  short RANGE
	  lea      bx, [bx+12h]
	  cmp      eax, [di+bx]        ; di+5Ah detailed timing #3
	  jz  short RANGE
	  lea      bx, [bx+12h]
	  cmp      eax, [di+bx]        ; di+6Ch detailed timing #4
	  jnz short NODDC

RANGE:    mov      cl, [USERHZ]
	  mov      al, [di+bx+6]       ; MAXHZ
	  mov      dl, [di+bx+8]       ; MAXKHZ


    MAXHZ        =        160          ; CRT-Monitor: HZ
    MAXKHZ       =         96          ; KHZ

;-------
EDID   DB 80h dup (55h)

But before we can set a mode with a higher refreshrate, we have to get a pixelclock from our card and we have to recalculate our refreshrate before.

Code: Select all

Input: bp = vesa modenumber

DDCOK:    mov      ecx, DWORD PTR[di+0Dh]
	  mov      ax, 4F0Bh             ; get/set Pixel-Clock
	  xor      bl, bl                ; 0=get
	  mov      dx, bp                ; Video-Mode
	  int    10h
	  cmp      ax, 4Fh
	  jnz NOVESA                     ; ERROR function not aviable
	  mov     DWORD PTR[di+0Dh], ecx ; pixelclock

	  xor      eax, eax            ; calculate RefreshRate
	  mov      ax, [di]            ; horizontal Total
	  xor      ebx, ebx
	  mov      bx, [di+6]          ; vertical Total
	  mul      ebx
	  mov      ebx, eax
	  mov      eax, ecx            ; Pixelclock
	  mov      esi, 10
	  xor      edx, edx
	  div      esi
	  xor      edx, edx
	  div      ebx
	  mov      [di+11h], ax        ; RefreshRate=Pixelclock/(HTotal*Vtotal)

;--------------------------------------
; example of a CRTC parameter table for the resolution of 1024 x 768 @100 hz refreshrate
;--------------------------------------
CRTC    DW 1456                        ; Horizontal Total       in Pixel
HORIANF DW 1122                        ; Horizontal  Sync-Start in Pixel
HORIEND DW 216                         ; Horizontal  Sync-End   in Pixel
VERTOTA DW 814                         ; Vertical   Total       in Lines
VERTANF DW 768                         ; Vertical    Sync-Start in Lines
VERTEND DW 42                          ; Vertical    Sync-End   in Lines
DOIFLAG DB 04h                         ; Flag (interlaced,doubleScan,polarity)
PIXCLOC DD 118309000                   ; Pixel clock in hz
REFRATE DW 10000                       ; Refresh-Rate in 0.01 hz
;---------------------
        DB 40 dup (0)
;--------------------------------------

Tested with a geforce 4 ti 4200 from msi(vbe3 AGP 4MB) and two 19" CRTs from SAMSUNG and SAMTRON with a capacity of 96 khz/160 hz.
A little DOS-Demo (source is written for MASM 5) can be download from my homepage:
http://www.alice-dsl.net/freecracmaps/Tool/Neutrip.zip

public documents from vesa.org
EEDIDguideV1.pdf
EEDIDverifGuideRa.pdf
vbe3.pdf
..
Little helpfull tool for calculating the CRTC parameter:
http://home.arcor.de/g.s/vbehz.htm

;-------------------

Now it is time for my personal question, maybe somebody knows an answer.
Most of modern videocards comes with a primary and additional with a secondary display device.
If they are two monitors pluged in and we start our PC, then we can see that they are in a "cloned mode" and they both are showing the same content.
If we switch to a vesa graphic mode, then the secondary device switch to the same resolution too and shows also the same content that we can see on the primary device.

But how we can stop those "clone mode", for to let show the content of the secondary linear framebuffer on our secondary monitor maybe in a different resolution/mode?

Dirk

[Brendan]

Hi,

If they are two monitors pluged in and we start our PC, then we can see that they are in a "cloned mode" and they both are showing the same content.
If we switch to a vesa graphic mode, then the secondary device switch to the same resolution too and shows also the same content that we can see on the primary device.

But how we can stop those "clone mode", for to let show the content of the secondary linear framebuffer on our secondary monitor maybe in a different resolution/mode?

Normally (e.g. with a "dual head" video card or separate video cards) there is no "clone mode" (and you'd have to emulate it manually by copying data to both framebuffers or something).

For some "dual head" video cards there is support for "clone mode" (e.g. where both video controllers use the same data from the same framebuffer) but I'm not too sure how that works or how to configure it - it certainly isn't something that would be enabled by firmware during boot.

For some laptops there's only one "single head" video card, and they just split the video signal. In this case there's probably no option at all (or maybe just the option of turning one of the monitors off). It just doesn't have the hardware needed to generate 2 different video signals.

Of course there may be a bunch of different variations I've overlooked - I don't know. Mostly what I'm saying is that it's impossible to answer the question without knowing exactly what sort of video hardware is involved.


Cheers,

Brendan

[freecrac]

Hello Brendan, many thanks for your fast answer.

Hi,

Normally (e.g. with a "dual head" video card or separate video cards) there is no "clone mode"...

Oh. Is the secondary monitor only black if there is no "clone mode", or wich content is shown in this situation if the POST-Process is done and we starts with booting?

For some "dual head" video cards there is support for "clone mode" (e.g. where both video controllers use the same data from the same framebuffer) but I'm not too sure how that works or how to configure it - it certainly isn't something that would be enabled by firmware during boot.

For some laptops there's only one "single head" video card, and they just split the video signal. In this case there's probably no option at all (or maybe just the option of turning one of the monitors off). It just doesn't have the hardware needed to generate 2 different video signals.

Of course there may be a bunch of different variations I've overlooked - I don't know. Mostly what I'm saying is that it's impossible to answer the question without knowing exactly what sort of video hardware is involved.

Cheers,

Brendan

I think if there is no firmware for to enable that the secondary device shows the content of the secondary framebuffer
and for to switch to a seperate videomode in a other resolution on the secondary device, then we have to know how we can use a port acess for this instead.
But i am not familar with memory maped io access, or if there is a standard way for to controll a secondary display device for popular extern video cards for the PC from ATI/AMD and from NVIDIA.
Do you think those cards are far differrent in this case also with other modells of a manufacturer, so every generation of cards need an other handling therefor?

Dirk

[Brendan]

Hi,

Normally (e.g. with a "dual head" video card or separate video cards) there is no "clone mode"...

Oh. Is the secondary monitor only black if there is no "clone mode", or wich content is shown in this situation if the POST-Process is done and we starts with booting?

That's what happens on all my systems - the "primary" monitor shows the firmware POST, boot, etc; and any other monitors remain black until the OS starts video driver/s for their video controllers. These are all computers with multiple video controllers though (rather than multiple monitors sharing the same video controller/video signal).

I think if there is no firmware for to enable that the secondary device shows the content of the secondary framebuffer
and for to switch to a seperate videomode in a other resolution on the secondary device, then we have to know how we can use a port acess for this instead.
But i am not familar with memory maped io access, or if there is a standard way for to controll a secondary display device for popular extern video cards for the PC from ATI/AMD and from NVIDIA.
Do you think those cards are far differrent in this case also with other modells of a manufacturer, so every generation of cards need an other handling therefor?

Writing native video drivers is a nightmare - best to leave that for "version 2" of your OS...


Cheers,

Brendan

[freecrac]

Hi,

Normally (e.g. with a "dual head" video card or separate video cards) there is no "clone mode"...

Oh. Is the secondary monitor only black if there is no "clone mode", or wich content is shown in this situation if the POST-Process is done and we starts with booting?

That's what happens on all my systems - the "primary" monitor shows the firmware POST, boot, etc; and any other monitors remain black until the OS starts video driver/s for their video controllers. These are all computers with multiple video controllers though (rather than multiple monitors sharing the same video controller/video signal).

Ok.

I think if there is no firmware for to enable that the secondary device shows the content of the secondary framebuffer
and for to switch to a seperate videomode in a other resolution on the secondary device, then we have to know how we can use a port acess for this instead.
But i am not familar with memory maped io access, or if there is a standard way for to controll a secondary display device for popular extern video cards for the PC from ATI/AMD and from NVIDIA.
Do you think those cards are far differrent in this case also with other modells of a manufacturer, so every generation of cards need an other handling therefor?

Writing native video drivers is a nightmare - best to leave that for "version 2" of your OS...

Yes, specally if there is no documentation about how we can do it.
Samples for a nacked skeleton of a sourcecode for a future driver for DOS exist and can be found in the web.

But where we can find more deeeper informations about our hardware and how we can use all function of it without to involve a (close source) driver?
And why those old informations about bare 2D-functions are not exist for public usement, how can anybody be a problem with this for those big manufacturers if they publish these informations?
And if the manufacturers do not longer want to provide all those old RealMode stuff, why do they put a vbe-bios on their modern cards?

Edit: I search for the vbe modelist inside of the bios starting at C000:0, but i could not find it there. Maybe the modelist is stored in a different form.

Dirk

[Brendan]

Hi,

Writing native video drivers is a nightmare - best to leave that for "version 2" of your OS...

Yes, specally if there is no documentation about how we can do it.
Samples for a nacked skeleton of a sourcecode for a future driver for DOS exist and can be found in the web.

But where we can find more deeeper informations about our hardware and how we can use all function of it without to involve a (close source) driver?

You can find some information for some cards (mostly Intel and AMD), and Linux does have some source code for almost every video card (e.g. based on reverse engineering where information isn't available).

However, if you're considering this then you probably fail to grasp the complexities involved. For example, implementing a modern video driver typically includes implementing some sort of "shader language" compiler for that video card.

And why those old informations about bare 2D-functions are not exist for public usement, how can anybody be a problem with this for those big manufacturers if they publish these informations?

I honestly don't know why companies like NVidia fail to provide any information. They say "trade secrets" but I don't believe them, and it's more likely that they're just too lazy to spend ages documenting things properly (and handling mistakes in the documentation, updates/revisions, etc).

And if the manufacturers do not longer want to provide all those old RealMode stuff, why do they put a vbe-bios on their modern cards?

For backward compatibility; and because the BIOS requires something it can use during POST to display errors, etc to the user. Eventually the BIOS will die, and video card manufacturers will put "UEFI byte-code drivers" in their card's ROM instead.

Edit: I search for the vbe modelist inside of the bios starting at C000:0, but i could not find it there. Maybe the modelist is stored in a different form.

I have no idea why you'd want to do that in the first place - just use the correct VBE function correctly.


Cheers,

Brendan