Page 2 of 3

Re: Getting a list of usable video modes...

Posted: Mon Feb 09, 2009 6:33 pm
by Troy Martin
Brendan wrote:Hehe. That only works if you make assumptions about input devices ... I'm not willing to make those sorts of assumption in my boot code ... and if I built device drivers for all of these into the boot loader then there's still no guarantee that the computer has any input devices at all. :D
That's why you do what windows did (ew ew ew did I just say that?) and do a fresh install that sets up a regular ol' 640x480x4 VGA graphics mode. You can then have the user select their preferred graphics mode and use that from then on.

Makes sense, n'est pas?

Re: Getting a list of usable video modes...

Posted: Sun Mar 29, 2009 9:19 pm
by Brendan
Hi,

Just a quick update on this...

I've added code to allow the EDID from the monitor to be overridden from a file in my Boot Image - either explicitly by the user (e.g. for cases where the video card and/or monitor don't support DDC), or automatically (by using the vendor ID and product ID in the EDID from the monitor to find a corrected file). This mostly means I've done everything possible to ensure the boot code is able to use valid EDID data.
Brendan wrote:For VBE 3.0, Function 0x0B lets you get and set the pixel clock for any VBE video mode. This could be used to check if the video mode can be setup with timings that the monitor supports. This actually does sound like an answer to me (although it's a complex messy answer involving strange calculations and estimates based on other information that may or may not be present).
This is what I'm working on now - deciphering the GTF formulas in an attempt get timing parameters that can be used to detect (and control) minimum and maximum refresh rates, and eventually make sure the monitor supports the video mode. The current problem is that the calculation involves a SQRT, and I can't use the FPU because the OS is meant to be capable of running on embedded systems that may not have an FPU, so I'm about to start implementing a SQRT routine using integer arithmetic.

I found something out too - for VBE 3.0 there's "double scanned" modes that can be used if you pass CRTC parameters while setting the video mode. For some video cards this means almost twice as many video modes can be supported (e.g. 640*240, 800*300, 1024*384, etc) if I can get the GTF stuff worked out....


Cheers,

Brendan

Re: Getting a list of usable video modes...

Posted: Mon Mar 30, 2009 3:25 am
by jal
Brendan wrote:
Brendan wrote:For VBE 3.0
This is what I'm working on now (...) the OS is meant to be capable of running on embedded systems that may not have an FPU
You do realise that embedded systems do not have VBE 3.0, right?


JAL

Re: Getting a list of usable video modes...

Posted: Mon Mar 30, 2009 5:57 am
by Brendan
Hi,
jal wrote:
Brendan wrote:
Brendan wrote:For VBE 3.0
This is what I'm working on now (...) the OS is meant to be capable of running on embedded systems that may not have an FPU
You do realise that embedded systems do not have VBE 3.0, right?
You'd be surprised.

The smallest computer I've got is a eBox-2300SX and that does support VBE 3.0. It uses a "Vortex86" CPU, which is compatible with an 80486SX (there's no FPU). I can imagine a bunch of these things being used in an office or something (e.g. mounted on the backs of LCD screens), with a server humming away in the corner being used for any heavy processing and storage.


Cheers,

Brendan

Re: Getting a list of usable video modes...

Posted: Mon Mar 30, 2009 1:08 pm
by jal
Brendan wrote:You'd be surprised.
I am indeed.
The smallest computer I've got is a eBox-2300SX and that does support VBE 3.0. It uses a "Vortex86" CPU, which is compatible with an 80486SX (there's no FPU). I can imagine a bunch of these things being used in an office or something (e.g. mounted on the backs of LCD screens), with a server humming away in the corner being used for any heavy processing and storage.
Ok, you got me convinced :). That is, I wouldn't want to support such hardware (go use an EeeBox! :)), but in your case it's valid I guess. That said, I bet there are plenty of simple SQRT routines to be found around, and if you know your math, it's easy to write one ('developing' would be an exageration) - I vaguely recall having to do just that in maths class 10 years ago (maths class at the polytechnics where I studied informatics, that is).


JAL

Re: Getting a list of usable video modes...

Posted: Mon Mar 30, 2009 5:20 pm
by Brendan
Hi,
jal wrote:
The smallest computer I've got is a eBox-2300SX and that does support VBE 3.0. It uses a "Vortex86" CPU, which is compatible with an 80486SX (there's no FPU). I can imagine a bunch of these things being used in an office or something (e.g. mounted on the backs of LCD screens), with a server humming away in the corner being used for any heavy processing and storage.
Ok, you got me convinced :). That is, I wouldn't want to support such hardware (go use an EeeBox! :)), but in your case it's valid I guess.
I can't predict what hardware people might want to use my OS for in future, so for me it's best to assume nothing... :)

Note: An EeeBox is around 4 times the price of the eBox-2300SX. Not a big deal if you're only buying one, but if a company is making some sort of embedded device and they're planning on using 20 thousand of them...
jal wrote:That said, I bet there are plenty of simple SQRT routines to be found around, and if you know your math, it's easy to write one ('developing' would be an exageration) - I vaguely recall having to do just that in maths class 10 years ago (maths class at the polytechnics where I studied informatics, that is).
The SQRT was a lot easier than I was expecting - took me about 20 minutes:

Code: Select all

;'*T Integer Square Root Calculation
;;_______________________________________________________________________________

;Input
; eax		Value
;
;Output
; eax		Square root of value * 65536 (or "16.16" fixed point)

findSquareRoot:
	pushes ebx,ecx,edx,ebp
	mov ebx,eax				;ebx = target value
	clr ebp				;ebp = initial test value (in "16.16" fixed point)
	mov ecx,0x80000000		;ecx = initial test bit (in "16.16" fixed point)

.l1:	or ebp,ecx				;Set the test bit
	mov eax,ebp				;eax = test value (in "16.16" fixed point)
	mul ebp				;edx:eax = result (in "32.32" fixed point)
	shl eax,1				;carry = rounding bit
	adc edx,0				;edx = result, rounded to nearest integer
	cmp edx,ebx				;Is the test value too high?
	je .found				; no, the test value is perfect
	jb .l2				; no, the test value is closer to perfect
	xor ebp,ecx				; yes, clear the test bit
.l2:
	shr ecx,1				;ecx = next test bit
	test ecx,ecx			;Have all bits been tested?
	jne .l1				; no, keep going

.found:
	mov eax,ebp
	pops ebx,ecx,edx,ebp
	ret
It's probably not the best possible method, but it's good enough for now.

My trouble now is the GTF formulas, and trying to make sure my 32-bit integer calculations are accurate enough. Yesterday I wrote code to find the refresh rate from the pixel clock, but it needs some improvement, and there's a few other calculations needed, and I still need to figure out a few things (like the horizontal and vertical sync start and end in VBE's CRTC information block).

I'm guessing it'll take me a week or 2, but by the time I'm done my boot code will have have the best video support possible. :)


Cheers,

Brendan

Re: Getting a list of usable video modes...

Posted: Tue Mar 31, 2009 4:53 am
by jal
Brendan wrote:Note: An EeeBox is around 4 times the price of the eBox-2300SX. Not a big deal if you're only buying one, but if a company is making some sort of embedded device and they're planning on using 20 thousand of them...
Mmm, it's that cheap (the eBox)? The EeeBox is doing around 250 euros at the moment I think...
I'm guessing it'll take me a week or 2, but by the time I'm done my boot code will have have the best video support possible. :)
Well, let us know if you succeed :).


JAL

Re: Getting a list of usable video modes...

Posted: Tue Mar 31, 2009 5:59 am
by Brendan
Hi,
jal wrote:
Brendan wrote:Note: An EeeBox is around 4 times the price of the eBox-2300SX. Not a big deal if you're only buying one, but if a company is making some sort of embedded device and they're planning on using 20 thousand of them...
Mmm, it's that cheap (the eBox)? The EeeBox is doing around 250 euros at the moment I think...
I paid around $120 (Aust) for mine, and EeeBox (single-core Atom) is around $450 (Aust).
jal wrote:
I'm guessing it'll take me a week or 2, but by the time I'm done my boot code will have have the best video support possible. :)
Well, let us know if you succeed :).
If I'm happy with it, I'll release it in the "Announcements, Test Requests, & Job openings" forum. ;)


Cheers,

Brendan

Re: Getting a list of usable video modes...

Posted: Thu Apr 02, 2009 11:05 am
by Brendan
Hi,

This is for my own reference, and in case anyone is wondering what they look like... The GTF formulas.

There's actually 3 separate calculations here - finding all timing parameters from X & Y resolution and desired refresh rate, finding all timing parameters from X & Y resolution and desired horizontal frequency, and finding all timing parameters from X & Y resolution and desired pixel clock frequency.

GTF Formulas For Using Desired Refresh Rate

Code: Select all

H_PIXELS_RND = ( ROUND ( H_PIXELS / CELL_GRAN_RND ) ) * CELL_GRAN_RND

IF ( INTERLACE_REQUIRED == "y") {
    V_LINES_RND = ROUND ( V_LINES / 2 )
    V_FIELD_RATE_REQUIRED = REFRESH_RATE_REQUIRED * 2
    INTERLACE = 0.5
  } else {
    V_LINES_RND = ROUND ( V_LINES) )
    V_FIELD_RATE_REQUIRED = REFRESH_RATE_REQUIRED
    INTERLACE = 0
  }

IF ( MARGINS_REQUIRED == "y" ) {
    TOP_MARGIN_LINES = ROUND ( MARGIN_PRECENT / 100 * V_LINES_RND )
    BOTTOM_MARGIN_LINES = ROUND ( MARGIN_PRECENT / 100 * V_LINES_RND )
    LEFT_MARGIN_PIXELS = ( ROUND ( ( H_PIXELS_RND * MARGIN_PRECENT / 100 / CELL_GRAN_RND ) , 0 ) ) * CELL_GRAN_RND
    RIGHT_MARGIN_PIXELS = ( ROUND ( ( H_PIXELS_RND * MARGIN_PRECENT / 100 / CELL_GRAN_RND ) , 0 ) ) * CELL_GRAN_RND
  } else {
    TOP_MARGIN_LINES = 0
    BOTTOM_MARGIN_LINES = 0
    LEFT_MARGIN_PIXELS = 0
    RIGHT_MARGIN_PIXELS = 0
  }

H_PERIOD_ESTIMATE = ( 1 / V_FIELD_RATE_REQUIRED - MIN_V_SYNC_AND_BACK_PORCH / 1000000 ) / ( V_LINES_RND + 2 * TOP_MARGIN_LINES + MIN_PORCH_RND + INTERLACE ) * 1000000

V_SYNC_AND_BACK_PORCH = ROUND ( MIN_V_SYNC_AND_BACK_PORCH / H_PERIOD_ESTIMATE )

V_BACK_PORCH = V_SYNC_AND_BACK_PORCH - V_SYNC_RND

TOTAL_V_LINES = V_LINES_RND + TOP_MARGIN_LINES + BOTTOM_MARGIN_LINES + V_SYNC_AND_BACK_PORCH + INTERLACE + MIN_PORCH_RND

V_FIELD_RATE_ESTIMATE = 1000000 / H_PERIOD_ESTIMATE / TOTAL_V_LINES

H_PERIOD = H_PERIOD_ESTIMATE * V_FIELD_RATE_ESTIMATE / V_FIELD_RATE_REQUIRED

V_FIELD_RATE = 1000000 / H_PERIOD / TOTAL_V_LINES

IF ( INTERLACE_REQUIRED == "y") {
    V_FRAME_RATE = V_FIELD_RATE / 2
  } else {
    V_FRAME_RATE = V_FIELD_RATE
  }

TOTAL_ACTIVE_PIXELS = H_PIXELS_RND + LEFT_MARGIN_PIXELS + RIGHT_MARGIN_PIXELS

IDEAL_DUTY_CYCLE = C_PRIME - M_PRIME * H_PERIOD / 1000

H_BLANK_PIXELS = ( ROUND ( ( TOTAL_ACTIVE_PIXELS * IDEAL_DUTY_CYCLE / ( 100 - IDEAL_DUTY_CYCLE ) / ( 2 * CELL_GRAN_RND ) ) ) ) * 2 * CELL_GRAN_RND

TOTAL_PIXELS = TOTAL_ACTIVE_PIXELS + H_BLANK_PIXELS

PIXEL_FREQ = TOTAL_PIXELS / H_PERIOD * 1000000

H_FREQ = 1 / H_PERIOD
GTF Formulas For Using Horizontal Frequency

Code: Select all

H_PIXELS_RND = ( ROUND ( H_PIXELS / CELL_GRAN_RND ) ) * CELL_GRAN_RND

IF ( INTERLACE_REQUIRED == "y") {
    V_LINES_RND = ROUND ( V_LINES / 2 )
    INTERLACE = 0.5
  } else {
    V_LINES_RND = ROUND ( V_LINES) )
    INTERLACE = 0
  }

IF ( MARGINS_REQUIRED == "y" ) {
    TOP_MARGIN_LINES = ROUND ( MARGIN_PRECENT / 100 * V_LINES_RND )
    BOTTOM_MARGIN_LINES = ROUND ( MARGIN_PRECENT / 100 * V_LINES_RND )
    LEFT_MARGIN_PIXELS = ( ROUND ( ( H_PIXELS_RND * MARGIN_PRECENT / 100 / CELL_GRAN_RND ) , 0 ) ) * CELL_GRAN_RND
    RIGHT_MARGIN_PIXELS = ( ROUND ( ( H_PIXELS_RND * MARGIN_PRECENT / 100 / CELL_GRAN_RND ) , 0 ) ) * CELL_GRAN_RND
  } else {
    TOP_MARGIN_LINES = 0
    BOTTOM_MARGIN_LINES = 0
    LEFT_MARGIN_PIXELS = 0
    RIGHT_MARGIN_PIXELS = 0
  }

H_FREQ = H_FREQ_REQUIRED

V_SYNC_AND_BACK_PORCH = ROUND ( MIN_V_SYNC_AND_BACK_PORCH * H_FREQ / 1000000 )

V_BACK_PORCH = V_SYNC_AND_BACK_PORCH - V_SYNC_RND

TOTAL_V_LINES = V_LINES_RND + TOP_MARGIN_LINES + BOTTOM_MARGIN_LINES + INTERLACE + V_SYNC_AND_BACK_PORCH + MIN_PORCH_RND

V_FIELD_RATE = H_FREQ / TOTAL_V_LINES

IF ( INTERLACE_REQUIRED == "y") {
    V_FRAME_RATE = V_FIELD_RATE / 2
  } else {
    V_FRAME_RATE = V_FIELD_RATE
  }

TOTAL_ACTIVE_PIXELS = H_PIXELS_RND + RIGHT_MARGIN_PIXELS + LEFT_MARGIN_PIXELS

IDEAL_DUTY_CYCLE = C_PRIME - ( M_PRIME / H_FREQ )

H_BLANK_PIXELS = ( ROUND ( TOTAL_ACTIVE_PIXELS * IDEAL_DUTY_CYCLE / ( 100 - IDEAL_DUTY_CYCLE ) / ( 2 * CELL_GRAN_RND ) ) ) * 2 * CELL_GRAN_RND

TOTAL_PIXELS = TOTAL_ACTIVE_PIXELS + H_BLANK_PIXELS

H_PERIOD = 1 / H_FREQ

PIXEL_FREQ = TOTAL_PIXELS * H_FREQ
GTF Formulas For Using Pixel Clock Frequency

Code: Select all

H_PIXELS_RND = ( ROUND ( H_PIXELS / CELL_GRAN_RND ) ) * CELL_GRAN_RND

IF ( INTERLACE_REQUIRED == "y") {
    V_LINES_RND = ROUND ( V_LINES / 2 )
    INTERLACE = 0.5
  } else {
    V_LINES_RND = ROUND ( V_LINES) )
    INTERLACE = 0
  }

PIXEL_FREQ = PIXEL_FREQ_REQUIRED

IF ( MARGINS_REQUIRED == "y" ) {
    TOP_MARGIN_LINES = ROUND ( MARGIN_PRECENT / 100 * V_LINES_RND )
    BOTTOM_MARGIN_LINES = ROUND ( MARGIN_PRECENT / 100 * V_LINES_RND )
    LEFT_MARGIN_PIXELS = ( ROUND ( ( H_PIXELS_RND * MARGIN_PRECENT / 100 / CELL_GRAN_RND ) , 0 ) ) * CELL_GRAN_RND
    RIGHT_MARGIN_PIXELS = ( ROUND ( ( H_PIXELS_RND * MARGIN_PRECENT / 100 / CELL_GRAN_RND ) , 0 ) ) * CELL_GRAN_RND
  } else {
    TOP_MARGIN_LINES = 0
    BOTTOM_MARGIN_LINES = 0
    LEFT_MARGIN_PIXELS = 0
    RIGHT_MARGIN_PIXELS = 0
  }

TOTAL_ACTIVE_PIXELS = H_PIXELS_RND + RIGHT_MARGIN_PIXELS + LEFT_MARGIN_PIXELS

IDEAL_H_PERIOD = ( ( C_PRIME - 100 ) + ( SQRT ( ( ( 100 - C_PRIME ) ^ 2 ) + ( 0.4 * M_PRIME * ( TOTAL_ACTIVE_PIXELS + RIGHT_MARGIN_PIXELS + LEFT_MARGIN_PIXELS ) / PIXEL_FREQ / 1000000 ) ) ) ) / 2 / M_PRIME * 1000

IDEAL_DUTY_CYCLE = C_PRIME - ( M_PRIME * IDEAL_H_PERIOD / 1000 )

H_BLANK_PIXELS = ( ROUND ( TOTAL_ACTIVE_PIXELS * IDEAL_DUTY_CYCLE / ( 100 - IDEAL_DUTY_CYCLE ) / ( 2 * CELL_GRAN_RND ) ) ) * 2 * CELL_GRAN_RND

TOTAL_PIXELS = TOTAL_ACTIVE_PIXELS + H_BLANK_PIXELS

H_FREQ = PIXEL_FREQ / TOTAL_PIXELS

H_PERIOD = 1 / H_FREQ

V_SYNC_AND_BACK_PORCH = ROUND ( MIN_V_SYNC_AND_BACK_PORCH * H_FREQ / 1000000 )

V_BACK_PORCH = V_SYNC_AND_BACK_PORCH - V_SYNC_RND

TOTAL_V_LINES = V_LINES_RND + TOP_MARGIN_LINES + BOTTOM_MARGIN_LINES + INTERLACE + V_SYNC_AND_BACK_PORCH + MIN_PORCH_RND

V_FIELD_RATE = H_FREQ / TOTAL_V_LINES

IF ( INTERLACE_REQUIRED == "y") {
    V_FRAME_RATE = V_FIELD_RATE / 2
  } else {
    V_FRAME_RATE = V_FIELD_RATE
  }
Note: The "round()" function here rounds to the nearest integer (it doesn't round down or round up).

Cheers,

Brendan

Re: Getting a list of usable video modes...

Posted: Fri Apr 03, 2009 12:51 am
by djmauretto
OK ,I add the copyright for the above formulas:
* Copyright (c) 2001, Andy Ritger [email protected]
* All rights reserved. :P

Re: Getting a list of usable video modes...

Posted: Fri Apr 03, 2009 3:38 am
by Brendan
Hi,
djmauretto wrote:OK ,I add the copyright for the above formulas:
Um?

Those formulas are my personal formulas, that were based on the formulas in VESA's GTF specification (it'd be impossible to have any "GTF formulas" that aren't). This makes them a "derived work" (and subject to VESA's original copyright).

However, the purpose of my derived work is education, research and study; the amount of VESA's document used was not substantial; and the effect on VESA's potential market is zero (it could even improve the profits of VESA's members). Therefore I'm within my rights providing this derived work under "fair use".

I'm not too sure if there's a legal obligation to provide attribution or not. It's obvious (from context) where these formulas are derived from, and if they were a direct copy (rather than a derivative) I would've included explicit attribution (in the same way I've done in the past for pieces of Intel's documentation). In this specific case I didn't, partly because it's not a direct copy (and partly because VESA are incompetent blood sucking vampires who should never have been involved in industry standards for interoperability to begin with 8) ).


Cheers,

Brendan

Re: Getting a list of usable video modes...

Posted: Fri Apr 03, 2009 4:03 am
by djmauretto
that were based on the formulas in VESA's GTF specification
:?: :?:
Did you mean GTF.XLS CVT.XLS spreadsheet ?
Did you have some other Spec about GTF ?

Re: Getting a list of usable video modes...

Posted: Fri Apr 03, 2009 4:32 am
by Brendan
Hi,
djmauretto wrote:
that were based on the formulas in VESA's GTF specification
Did you mean GTF.XLS CVT.XLS spreadsheet ?
Did you have some other Spec about GTF ?
There's the specifications themselves, plus some spreadsheets that go with them. Ask VESA for a copy of a PDF called "Generalized Timing Formula Standard, Version: 1.1, September 2, 1999", but don't be surprised if they want to charge voluntary/open source developers $$$ for this 10-year-old obsolete standard.


Cheers,

Brendan

Re: Getting a list of usable video modes...

Posted: Fri Apr 03, 2009 4:45 am
by Combuster
Any problems if I wikify this?

@djmauretto: I have a GTF spreadsheet by a different author... And mathematical formula's don't fall under copyright law here.

Re: Getting a list of usable video modes...

Posted: Fri Apr 03, 2009 4:51 am
by djmauretto
Brendan wrote:There's the specifications themselves, plus some spreadsheets that go with them. Ask VESA for a copy of a PDF called "Generalized Timing Formula Standard, Version: 1.1, September 2, 1999", but don't be surprised if they want to charge voluntary/open source developers $$$ for this 10-year-old obsolete standard.
Have you purchased this standard?
I did not understand where you have taken the information
regarding formulas, I own only 2 spreadsheet
longer a source in 'C'