Hi,
tera4d wrote:I finally did the switch to vesa 1024x768 thanks to Dex !
tera4d wrote:I can only draw on the top 30 pixels or something but i can draw over the WHOLE WIDTH.
Does that has anything to do with my video mode or?
I'm guessing that you're using "15 bits per pixel" or "16 bits per pixel", and that you're writing pixels to the area at 0x000A0000. The only reason I have for this guess is that "1024 pixels per line * 32 lines * 2 bytes per pixel" works out to 64 KiB, which is exactly how large the area at 0x000A0000 is.
If this guess is right, then to access more pixels you need to use bank switching (where different parts of display memory are mapped into the area at 0x000A0000 where you can access them); or setup a linear frame buffer (where you can access all of the display memory without bank switching at a different address, like from 0xE0000000 to 0xE8000000, but the address depends on a lot of things).
For bank switching there's VBE functions to change banks, which can be a problem when your OS is in protected mode and can't switch banks. To get around that there's 2 protected mode interfaces, one for VBE 2 and a different one for VBE 3. For setting up a linear frame buffer you need to check that the video card supports it for the mode you're using (there's a flag in the mode information data that "VBE FUNCTION 01H - RETURN VBE MODE INFORMATION" returns) and you need to set the corresponding flag (bit 14 in BX) when you set the video mode.
There's probably other things I should mention.
First, old versions of VBE had fixed mode numbers (for e.g. where you can assume that video mode number 0x104 is "1024 * 768 * 16 bits per pixel"). For VBE2 and later, this became optional and you can't rely on it anymore (e.g. video mode number 0x104 might be anything, and "1024 * 768 * 16 bits per pixel" could be a different video mode number).
Some video cards don't support "16 bits per pixel" formats - instead they might support "15 bits per pixel". Most cards support 15 bpp or 16 bpp but not both. The same is true for 24 bpp and 32 bpp. Also, for most video cards pixels are RGB but a few older video cards use BGR instead. To complicate things more, for some video cards, in 15 bpp modes the highest bit is actually used for something (e.g. to select a colour from the palette that's normally only used in 8 bpp modes). If you don't check, then you could end up getting all the colours wrong.
Also, what are you going to do if the video card doesn't support any 1024 * 768 video modes?
For reasonably reliable code, you
must:
- Support a wide variety of resolutions and pixel formats (e.g. 8 bpp, 15 bpp, 16 bpp, 24 bpp and 32 bpp)
- Use "VBE FUNCTION 00H - RETURN VBE CONTROLLER INFORMATION" to get a list of all video mode numbers
- Check the details for each video mode (returned by "VBE FUNCTION 01H - RETURN VBE MODE INFORMATION") to see if your code will support it or not (and find out what resolution and pixel format/colour depth, and if LFB is supported, etc).
- Decide which video mode you want to use (based on the details for each video mode, and what your code can support)
- Never set any video mode with a resolution that's higher than 640 * 480 without the user's permission
Also, just because a video card supports a certain video mode doesn't mean that the monitor also supports that video mode. If you use a high resolution video mode like 1024 * 768 then it might work, but the monitor might not support it and you might get a black screen, a black screen with some sort of message on it (e.g. "Horizontal sync out of range"), or a strange flickering screen; and in some cases (usually old "VGA only" monitors) you can blow the monitor up. To make this worse it does depend on timing signals, and it's possible (for e.g.) to have a video card that generate signals for 1024 * 768 @ 75 Hz and a monitor that only supports 1024 * 768 @ 60 Hz; where both the video card and the monitor support the resolution but it still doesn't work. In all of these cases, VBE will tell you that it set the video mode correctly (no error messages or anything) and you won't know if it's actually working or not (for all you know, the monitor may have exploded and set the user's desk on fire, but VBE will say it worked fine).
It is possible (for most video cards and most monitors) to find out which video modes the monitor does support. This is called EDID (Extended Display Information Data), where you ask the video card to get the EDID and the video card returns one or more blocks of data that you need to parse to find out what the monitor does/doesn't support. It's complicated, but it's the only way to make sure that the monitor supports the video mode you intend to use. Unfortunately VBE normally doesn't give you enough information to be entirely sure that a video mode will work (VBE won't tell you timing information), but you can use EDID to estimate how likely it is that a video mode will work, and on some video cards it's also possible to use "CRTC Info" when setting the video mode to force the video card into using timings that you know the monitor definitely does support.
For extremely reliable code, you could:
- Support a wide variety of resolutions and pixel formats (e.g. 8 bpp, 15 bpp, 16 bpp, 24 bpp and 32 bpp)
- Use "VBE FUNCTION 15H SUBFUNCTION 01H - GET EDID" to get the EDID for the monitor
- Parse the EDID and set variables, etc that indicate the monitors capabilities (and, if EDID wasn't supported just set these variables, etc to "standard VGA" values)
- Use "VBE FUNCTION 00H - RETURN VBE CONTROLLER INFORMATION" to get a list of all video mode numbers
- Check the details for each video mode (returned by "VBE FUNCTION 01H - RETURN VBE MODE INFORMATION") to see if your code will support it or not *and* estimate the chance that the monitor will support it or not
- Decide which video mode you want to use (based on the details for each video mode, and what your code and the monitor supports)
- Never set any video mode with a resolution that's higher than 640 * 480 without the user's permission *unless* the EDID information has allowed you to be very confident that the monitor does support the video mode
Almost all good programmers use the first method (without EDID), because it's a lot easier. I implemented the second method in my boot code (partly because I don't want to ask the user anything if it's possible to avoid it).
Cheers,
Brendan