OSDev.org

Hi,

In the last few months, I've not had any problems with my OS. However, now I have. So, I'm back, to trouble you all..

Well, I've been recently working on my bootloader, and have progressed quite a lot. I seem to find GRUB a little bit lacking, and thus have implemented my own bootloader. My second last step, to finish it, is video mode handling.

Thus, I got a basic overview of what I need to do. I'll use VBE (for a start), get a list of video modes, get EDID, combine both, and find the best possible video mode. Did I mention how inexperienced I'm in this area (didn't get enough years, now, did I)?

I ended up finishing the part of getting video modes and EDID information easily. However, after seeing the bucket load of information provided by VBE and EDID, I'm a lot confused. The point is, I'm totally inexperienced with graphics, and don't know what to do.

A short summary of my problem: I just don't know what I need to know for this. I ended up scanning the compilation of Book Recommendations by L4B, and downloading 'Black Book of Graphics Programming'. However, that exactly didn't seem like what I wanted. I did a lot of googling, but on the overall, I'm very confused on where to begin, with what.

Regards,
Shikhin

P.S. The post may not exactly define what my problem is. That's because, nor do I clearly know. This *might* look like an attempt to troll, but I'm seriously confused.

P.P.S. Since I don't know what I want to be knowing here, I don't know whether BBoGP is the right book or not. I'm currently re-reading through it, but if someone feels that that is EXACTLY what I want, please say so, so I may give two more serious looks to it.

P.P.P.S. Not sure I got the right subforum. This could be moved to somewhere more appropriate.

Shikhin wrote:I ended up scanning the compilation of Book Recommendations by L4B, and downloading 'Black Book of Graphics Programming'. However, that exactly didn't seem like what I wanted.

Aww, shucks. But yeah, that book only covers VGA and some assemby optimizations for old x86 CPUs.

What exactly are you having trouble with? Did you read the VBE/Core and ((E-)E)DID standards? Which parts did you find confusing?

Since I don't know what I want to be knowing here, I don't know whether BBoGP is the right book or not. I'm currently re-reading through it, but if someone feels that that is EXACTLY what I want, please say so, so I may give two more serious looks to it.

Graphics Black Book teaches you how to write graphics-heavy applications on primitive systems. Every concept and hardware detail mentioned is basically still valid. It even tells you how to do 3D rendering with Z-buffering.

The thing is that VBE is often used in ignorance of what monitor is attached, and some implementations take care of that by not allowing bad modes. You don't need to care about EDID intially to actually set a mode. Otherwise you will need to calculate a mode's horizontal and vertical sync rate and check if they fall within the monitor's specs. On really old stuff, the monitor will simply give you a list of supported modes from a limited selection of standard modes.

By the time you can grog that, Video_Signals_And_Timing would be a good next step.

Hi,

Love4Boobies wrote:

Shikhin wrote:I ended up scanning the compilation of Book Recommendations by L4B, and downloading 'Black Book of Graphics Programming'. However, that exactly didn't seem like what I wanted.

Aww, shucks. But yeah, that book only covers VGA and some assemby optimizations for old x86 CPUs.

Well, yeah. I did read those. Didn't entirely seem like a waste of time - and so I ended up reading major parts of the beginning of the book (which covered optimizations for old x86 CPUs).

Love4Boobies wrote:What exactly are you having trouble with? Did you read the VBE/Core and ((E-)E)DID standards? Which parts did you find confusing?

I just knew I was clear enough. I'm rather poor at describing my problems. Well, I'll try to explain what parts I find confusing by telling what I am unable to figure out:

• In cases of VBE below version 1.2, the resolution, and the other information isn't provided. In these cases, do I use VGA? Or is there something I'm missing?
• In cases where the address of the LFB isn't provided (< VBE 2.0), or isn't supported (checked via the attributes), do I simple assume 0xB8000 or 0xA0000, depending on "text" or "graphics" mode? Or am I again missing something here?
• After I determine a mode, how do I go on actually plotting pixels in the right way? How do I support multiple resolutions (with fonts - do I duplicate them for each resolution, or perhaps make them in a resolution independant way). How about colors? I find this one the most confusing topic, and can't figure out where to begin. I'd be happy if I even get a RTFM response with a slight hint as to which one (though I assume a manual wouldn't help - perhaps some specific search I haven't thought of).

Regards,
Shikhin

EDIT: Congratulations to me on the 100.

Hi,

Combuster wrote:The thing is that VBE is often used in ignorance of what monitor is attached, and some implementations take care of that by not allowing bad modes. You don't need to care about EDID intially to actually set a mode. Otherwise you will need to calculate a mode's horizontal and vertical sync rate and check if they fall within the monitor's specs. On really old stuff, the monitor will simply give you a list of supported modes from a limited selection of standard modes.

By the time you can grog that, Video_Signals_And_Timing would be a good next step.

As a matter of fact, I read that article this morning on recommendation by Brendan (yeah, was hunting for help). I do know that I don't need to care about EDID initially, and I plan on handling it after I get enough motivation by filling the screen with weird looking fonts.

EDIT: I got a weird bug. On QEMU, the list of video modes look valid. However, on Bochs, the last 5-10 entries are of resolution 65,535*65,535. I do check for the call for get mode information failing, however, they don't fail. On VirtualBox, the last 2 entries are 65,535*65,535. Is this valid, or some bug?

Regards,
Shikhin

Hi,

Shikhin wrote:A short summary of my problem: I just don't know what I need to know for this. I ended up scanning the compilation of Book Recommendations by L4B, and downloading 'Black Book of Graphics Programming'. However, that exactly didn't seem like what I wanted. I did a lot of googling, but on the overall, I'm very confused on where to begin, with what.

The general approach depends on the level of complexity and capabilities you want from it. However, it can be easier to start simple and then build on that (rather than starting from "complex" and being confused ).

The simplest possible way would be to use the old "VGA" BIOS functions to set a mode like 640 * 480 * 16 colours, and just use that. No EDID, no VBE and no list/s of video modes. This should allow you to write code that generates graphics data for all 16 colour modes (e.g. just use variables for "address of display memory", horizontal resolution, vertical resolution and "bytes between lines" so that it's easy to support all other 16 colour modes later).

If you're planning to support other colour depths later, then I'd recommend that you generate the graphics data in a specific format (e.g. 32-bit per pixel format) in a buffer in RAM, and then (after everything is drawn in the buffer) convert from that format into what the video mode needs. This means that eventually (e.g. when you support 4-bpp, 8-bpp, 15-bpp, 16-bpp, 24-bpp and 32-bpp) you only need to write more conversion routines and don't need new versions of all the different functions that do the drawing.

The next step might be to add support for other "16 colour" VGA modes (640 * 350, 640 * 200 and 320 * 200). For this you could just use conditional compilation - e.g. "#if USE_320_240_4BPP_MODE ....". This should be very easy to do, and it lets you make sure that the code to generate the graphics data does handle other resolutions properly.

Next, add support for 320 * 240 * 256 colour mode (and modify your "drawing" code to support all 256 colour modes).

After that you could generate a list containing the details for all of the VGA modes that you support (mode number, resolution, colour depth, address of display memory, etc); and write code to choose a video mode from your list. How your code decides which mode to choose depends on your OS. It could be a complex thing that takes into account various ratings (e.g. user's preference, OS's preference, monitor's preference, etc), or it could be something simple like "always choose the highest resolution video mode", or it could be some sort of menu that the user uses to choose one. It should also be easy to make it simple to begin with, and then replace it with something more complex later on. Once you've chosen a mode, you should use the mode number from the list to set that video mode - e.g. write your own "set_video_mode(mode_number);" function that calls the BIOS function and then does things like setup the palette if/when necessary).

The next step would be the beginning of VBE support. Get the list of video modes from VBE then have a loop to check each mode. To begin with, for each video mode:

• Check if the OS supports it (e.g. make sure it doesn't require bank switching, and that it's either a 4-bpp/16 colour mode or a 8-bpp/256 colour mode).
• Add the details for the video mode to your list of modes.

You'd also modify your "set_video_mode(mode_number);" function to accept and handle VBE modes.

Now you should be able to support and 4-bpp/16 colour mode and any 8-bpp/256 colour mode (e.g. including 1920 * 1600 * 256 colour, etc). After that, you'd add support for more colour depths (15-bpp, 16-bpp, 24-bpp, 32-bpp); so that your code is able to handle (almost) every possible video mode.

Then comes EDID. Start by just getting the raw EDID data and putting it into a buffer in RAM.

Then you'd want to write code to parse the EDID data. Unfortunately EDID is messy (it uses a bunch of different ways to represent video modes). The end result of parsing should be that some generic variables are set (e.g. physical size of screen in millimetres, etc) and a sane list of supported video mode timings (including some sort of "monitor preference" rating for each of them). After parsing you'd just display the details to make sure it works like it should.

The next step would be to loop through the video modes you got from the video card. For each video mode, use the data you got from EDID to determine the probability that the monitor supports it and also set a "monitor preference" for that video mode. Now modify the routine that chooses a video mode from a list to take into account the probability that the monitor supports the mode and the "monitor preference".

The final step would be to add support for the "CRTC info" structure that VBE 3.0 introduced, to force the video card to generate timings that the monitor wants. This means creating new versions of VBE video modes, so that (in your list of video modes) you'd end up with the original VBE mode (without CRTC info) and none or more new versions of the same video mode (with CRTC info). This allows you to make sure the monitor supports the timing (rather than guessing at the chance of the monitor supporting the mode); and also allows you to support different refresh rates (e.g. "800 * 600 @ 60 Hz", "800 * 600 @ 75 Hz", etc). There's also a "double scanned" flag in the CRTC info which allows you to halve the vertical resolution and create even more video modes (e.g. create "800 * 300" modes from an "800 * 600" mode).

For example, if the video card supports 4 different "800 * 600" video modes (at different colour depths, e.g. 4-bpp, 8-bpp, 16-bpp and 32-bpp), then you'd have 4 "base modes". If you can use CRTC info to set timing then you might expand that list of 4 modes to 3 different refresh rates (e.g. 60 Hz, 75 Hz, 80 Hz) and end up with the 4 original modes plus 12 new modes (e.g. "800 * 600 * 4-bpp @ 60 Hz", "800 * 600 * 4-bpp @ 75 Hz", etc); and then use the "double scanned" flag to get 12 more variations (e.g. "800 * 300 * 4-bpp @ 60 Hz", "800 * 600 * 4-bpp @ 75 Hz", etc). The end result may be a total of 28 different modes (including the original 4 modes). I've done this before - from around 22 modes reported by VBE, I ended up with a list of around 150 different video modes.

That's about as complex as things can get, so after all that you're done (but you may be done sooner if you don't want all of that)!


Cheers,

Brendan

Hi,

Shikhin wrote:EDIT: I got a weird bug. On QEMU, the list of video modes look valid. However, on Bochs, the last 5-10 entries are of resolution 65,535*65,535. I do check for the call for get mode information failing, however, they don't fail. On VirtualBox, the last 2 entries are 65,535*65,535. Is this valid, or some bug?

It's not a bug, it's the end of the list of video modes. The video list returned by VBE is meant to be terminated with a -1 (or 0xFFFF).


Cheers,

Brendan

Hi,

Brendan wrote:Hi,

<insert-well-written-explanation-here>

Cheers,

Brendan

Thanks for all that. Really helped me, so now it's time to get started.

Brendan wrote:Hi,

Shikhin wrote:EDIT: I got a weird bug. On QEMU, the list of video modes look valid. However, on Bochs, the last 5-10 entries are of resolution 65,535*65,535. I do check for the call for get mode information failing, however, they don't fail. On VirtualBox, the last 2 entries are 65,535*65,535. Is this valid, or some bug?

It's not a bug, it's the end of the list of video modes. The video list returned by VBE is meant to be terminated with a -1 (or 0xFFFF).


Cheers,

Brendan

Well, actually, it was a bug. I was saying that there are multiple entries, without the mode being -1, but the entries reported were 65,535 (x-resolution) * 65,5353 (y-resolution). I found out that my segmentation calculation were incorrect. Instead of going on to the next segment when I crossed segment boundaries, I was just incrementing the segment. Heh.

Regards,
Shikhin