OSDev.org

Hi,

Combuster wrote:Any problems if I wikify this?

None at all - IMHO this information is required just to use VBE reliably; along with EDID (but you can find version 1.1 of the EDID data structures on Wikipedia) and details for the VBE DDC function (which VESA will let you have for free).

However, I should point out that this information is incomplete - the value of certain constants are missing from my original post. The default values for these constants are: CELL_GRAN_RND = 8, MARGIN_PRECENT = 1.8, MIN_PORCH_RND = 1, MIN_V_SYNC_AND_BACK_PORCH = 550, C_PRIME = 40 and M_PRIME = 600. I'd also mention that for my version of the formulas REFRESH_RATE_REQUIRED, V_FIELD_RATE_REQUIRED, H_FREQ_REQUIRED, PIXEL_FREQ_REQUIRED, V_FIELD_RATE, H_FREQ, PIXEL_FREQ are all in Hz (and not a mixture of Hz, KHz and MHz), which helps to simplify the formulas.

There's also some strange things that can happen with these formulas. For example, if any of the calculations give a negative result then it indicates invalid input (e.g. if the PIXEL_FREQ_REQUIRED input parameter is too low, then you can end up with horizontal blanking that takes "negative N us"). In practice, some of these calculations probably have an allowed range (e.g. things like "horizontal blanking must be >= 20% of the horizontal total") but I've been unable to find anything indicating what the allowed ranges for anything is.


Cheers,

Brendan

I started working on it Here - Still needs a lot of work, but there's a nice introduction for everyone that wonders what this is all about.

Hi,

Combuster wrote:I started working on it Here - Still needs a lot of work, but there's a nice introduction for everyone that wonders what this is all about.

Looks like a very promising beginning!

Just to let you know, I'm not happy with those formulas yet, and plan to continue working on them.

I think part of the problem is that the original GTF formulas from VESA are copied from their spreadsheet, so that (for a silly example) instead of doing something like:
They'll do:
And then simplify it to:
And then they'll remove any indication of what they've done:
So that in the end, the formulas from VESA end up being a confusing mess where you're never too sure if there's a hidden scaling factor or not. Another simple example (that isn't made up) is "MARGINS_PERCENT", which is a value that would range from 0 to 50 that's typically divided by 100; and isn't a value that ranges from 0 to 0.5 that doesn't need scaling.

I plan on going through the formulas again, and making sure that all variables are either in pixels, lines, seconds or hertz (with no implied/hidden milliseconds, microseconds, kilohertz, megahertz or "percent" scaling factors).

I've also noticed that some of the calculations are the same in each formula. Rather than having 3 independent/larger pieces of code, it can be split into 3 smaller pieces of code that all use the same subroutines for common things. For example, you'd be able to replace about 10 lines from each formula with "call do_precalculations" to avoid code duplication (triplication?).

Also, I only posted "primary formulas". There's also a "secondary formula" where the results from the first set of calculations are used to find additional parameters; and there's another calculation (called the "blanking formula") for finding the values for "C_PRIME" and "M_PRIME" from some variables called C, M, J and K that's used for "secondary timings". I want to do the same for these formulas as I'm doing for the primary calculations. Then I need to go through all of these parameters and figure out which ones are actually useful (both for setting a video mode using VBE, and for setting a video mode in a "bare metal" video driver), and then work backwards removing redundant calculations (i.e. calculations that are only used to create information that you don't need anyway). After I've done this, I can combine it with the "common subroutines" idea, so that the entire "secondary formula" ends up being part of the "do_postcalculations()" routine, and so that the entire blanking formula becomes part of the "do_precalculations()" routine.

Then I want to find the valid ranges for all variables used in all calculations. This is mostly because of how I'm planning to implement it. For example, if I knew that "H_FREQ" ranges from 50000 to 1000000 then I'd be able to use "20:12" fixed point for this variable to improve the accuracy I get from a 32-bit integer.

Finally, all of these calculations can be simplified a lot if you assume that the "default GTF values" are being used. I want to provide simplified versions of the formulas, because most of the time you can use the default GTF values and can skip a lot of work.


Cheers,

Brendan

I got most of the story laid out the way I wanted it. There's a big bunch of links and notes to fill in but that shouldn't be a problem. So if you have comments, fire away

@Brendan: where does the round ( x , 0 ) come from - is that meant to be truncation?

Hi,

Combuster wrote:@Brendan: where does the round ( x , 0 ) come from - is that meant to be truncation?

That's an editing error - "round ( x , 0 )" is meant to be "round ( x )".

I've attached my current notes, because I'm about to stop working on the full versions of the formulas and start working on stripped-down versions for my own use.

My current notes aren't too tidy, but it includes the blanking calculation and the secondary parameter calculation, all variables and parameters have been converted back to standard units, and I think I've simplified it as much as I can (without taking chunks out or assuming default values). The only other thing I wanted to do was find the maximum and minimum values that each variable can be, but I'd rather do this after I've removed things I don't need from the formulas (like margins and most of the secondary parameter calculations, that aren't needed for VBE 3).


Cheers,

Brendan

Hi,

Brendan wrote:

Combuster wrote:Just to kick in some real life idea (MS is good for something after all)

"The system will now change the resolution. If the monitor does not support the resolution it will be changed back after 15 seconds"

Make from that what you want

Hehe. That only works if you make assumptions about input devices (it's followed by a "Did it work? [OK] [Cancel]" dialog box, where you have to select "OK" within 15 seconds). I'm not willing to make those sorts of assumption in my boot code - there could be just a touch screen and joystick, or maybe a microphone (for speech recognition) or maybe 6 different keyboards; 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.

I think I owe you an apology....

Turns out that this mess has grown a lot more complex than I'd originally hoped; and it seems that I am willing to make some assumptions about input devices after all. I'm going to end up with over 300 video modes on some of these computers, and I don't want to test each video mode on each computer by modifying my boot script, rebuilding and then rebooting.

Here's the beginning of my new *optional* "interactive boot menu" thing (keyboard required - apologies to all tablet users):
Check out the shadows!


Cheers,

Brendan

Brendan wrote:Check out the shadows!

Wicked! :)


JAL

Brendan wrote:Check out the shadows!

They are really cool! I like it a lot when people take care of such details.

Roel

Hi,

Hobbes wrote:

Brendan wrote:Check out the shadows!

They are really cool! I like it a lot when people take care of such details.

Thanks

This was one of those things that seems simple until you start writing it. I couldn't shade a pixel more than once so I had to draw all the shadows after all the windows are drawn, and because the position of the shadows depends on the height of whatever the shadow lands on I had to keep track of the height of everything.

To draw the shadows I use a "height buffer" (one byte per group of 4 pixels, one bit per height), plus a "shadow map" (one bit per group of 4 pixels, for shaded/not shaded); and there's a simplified ray tracer that casts 8 rays of "anti-light" in parallel, that generates the shadow map from the height buffer.


Cheers,

Brendan

Hi,

Ok, just a quick update...

So far I've implemented code to generate a list of video modes and give each video mode a "reliability rating" (which is my software's estimate of how likely it is that the video mode will work on the current hardware, based on all the information it can get). I've also done a full menu system that allows each video mode to be tested (and other things), and a test pattern generator that generates a 96-bit per pixel test pattern that is then displayed (with the video mode being tested) using Floyd-Steinberg dithering.

The video mode testing menu: How the test pattern is meant to look (generated with 640*400, 32-bpp): How the test pattern looks with low resolution and low colour depth (generated with 320*200, 8-bpp): And, how the test pattern looks with low resolution and insanely bad colour depth (generated with 320*200, 4-bpp): The idea here is to generate the best possible picture for the test pattern, so people can get an idea of the "best case" appearance of the video mode, taking into account that the OS itself will eventually be using virtual resolutions and virtual colour depths (where the video driver converts virtual video into actual video, including scaling and dithering).

I've still got a long way to go though - I've almost finished code that uses VBE3.0 CRTC info to force the video card into using established timings that the monitor says it supports, but I still haven't done code to use GTF/CVT to generate other video mode timings that should work.


Cheers,

Brendan

Wicked shadows!
Could you add a penumbra though

Would be wicked x googolplex if you did.

At the moment I'm in 80x25x16 text mode
My only windows are ASCII art.
Looking to graphics in OS version 0.04, but VBE is so patchy on EDID.
I'll probably use the Windows version, with a list from VBE, maybe even ignoring EDID.
Seeing the work you guys do is awe-inspiring.