OSDev.org

Does anyone know how to initialise VGA video modes once in protected mode (x86 platform).

I can't find any information for setting up video mode without using the BIOS.

Does anyone know how to do this?

I am looking for 1024x768x256 video modes and above.

I am possibly wrong, but I think that most (all?) of the
modes you are looking for are only practical when
using the VESA routines. Otherwise, you'd have to
write code for almost all possible video chipsets...

are you talking about VGA or VESA modes, coz VGA modes can't reach 1024x768x256 !!!

to use VESA modes from Pmode there is three ways :
1 - Using *Optional* VBE3 routines directly from pmode (not all cards support it)

2 - Using real mode (switch back to Rmode, call int 0x10 to choose new video mode, switch back to pmode)

3 - Using VM86 : create a virtual 86 tasks which will switch video modes, IMHO this is the best way to do it, but need the implementation of vm86 which is not easy .

ohhh, and i forgot to say, that there is another way : if your OS will never need text mode, you can choose your VESA videomode before entering Pmode using BIOS calls

Hi,

[quote="[AlAdDiN]are you talking about VGA or VESA modes, coz VGA modes can't reach 1024x768x256 !!![/quote]
VGA is a hardware standard that goes up to 640*480*16 colours, or 320*240*256 colours. VESA is the standards orginization that are responsible for the VESA BIOS Extensions (commonly called VBE), which is a software standard (not a hardware standard). VBE was designed as a standard interface to use video card features that go above and beyond standard VGA. These extensions to VGA are called "Super VGA" (or SVGA). SVGA cards supported 1024*768*256 well before the VESA people wrote the first VBE standard. Therefore I'd say blueice is looking for information on setting up SVGA modes.

[quote="[AlAdDiN]to use VESA modes from Pmode there is three ways :
1 - Using *Optional* VBE3 routines directly from pmode (not all cards support it)

2 - Using real mode (switch back to Rmode, call int 0x10 to choose new video mode, switch back to pmode)

3 - Using VM86 : create a virtual 86 tasks which will switch video modes, IMHO this is the best way to do it, but need the implementation of vm86 which is not easy .[/quote]
4 - Write a different device driver for each video card (for e.g. using IO ports, etc directly).

Options 1 to 3 won't work if you port your OS to 64 bit mode or any other platform that uses PCI, and won't work for 2D and/or 3D hardware acceleration, vertical retrace IRQs, computers with multiple video cards (e.g. dual monitor). Option 4 is also faster and more efficient. Unfortunately option 4 will take you many years just to get some video cards supported.

IMHO the best option is none of them, or more specifically all of them at the same time. Use the BIOS functions during boot to set a "default" video mode, and then have device drivers on top of that. Device drivers would include one for VBE 3, one for standard VGA using direct IO ports, and more for specific video cards using direct IO ports.


Cheers,

Brendan

@Brendan :
- 1 - I know the differences between VGA and VESA
- 2 - I agree with you about using sp?cific drivers, but IMHO when you are developping an OS the first think to do is to get an up and running kernel with all basic OS functions before starting write drivers

I'm new to OS Development, but I do agree with [AlAdDiN] for the simple reason that IT MAKES SENSE.

And the question is... WHERE I can get ANY information 'bout video-cards IO protocols ?! E.g. it would be very interesting to find any info 'bout GeForce chipsets... so I can write 256b accelerated intros

Cards specific features specifications are really hard to find, usually manufacturr keep some secret information about their products, but some of them are publishing parts of their drivers as OpenSource (like nvidia) you can take a look at nvidia driver for linux.

but again : if you are developping an OS, the main think to do is getting an up and running kernel with all needed features (memory manager, process manager, messaging, signals, scheduler ...)

I share the desires to use those modern videomodes and found a lot of documentation about SVGA and AGP. I'm just digging in after I made the first steps AlAdDin mentioned. I finished my own assembler OS, meant to test code, i.e. code, that switches to an other viedeomode than the VGA3-textmode.
Maybe my Program could help You to develop the routines. You could easily add Your own procedures and call them, using an F-key...
Look at my homepage:
http://www.rcfriz.de
As I'm very interested in this subject, I hope, that You will contact me at:
[email protected]
I could send the docs to You, which I found. I think Brendan isn't right (I hope it) - You won't need years to code. There are still some registeradresses and bit-meanings You need to know. In case of AGP You will need documentation about the special mapping of registers and refresh memory ( I found the well done intel-doc: AGP_3.0_Final_R1.0.pdf).
But You need to see, that everything, vendors could have done, needs to act as fast as possible. Thus it needs to be simple!
The well hidden things are special registers and commands for video-purpose (i.e.Ati-All in wonder...), but You could omit it ( or dissassemble the driver-binaries

Hi,

frizzz wrote:I think Brendan isn't right (I hope it) - You won't need years to code. There are still some register adresses and bit-meanings You need to know.

Whether Brendan is right or not depends on what you want the video driver to be capable of. Obviously generic VBE 3.0 support is going to be much easier than creating decent drivers that support all video modes with 2D and 3D acceleration using direct IO. It also depends on how many video cards you support.

Most video manufacturers produce a chipset, and then enhance the original chipset for later versions. Therefore creating a decent device driver for the original video card is going to be much harder than changing that video driver to suit the later versions of the card.

Let's say for the original version it takes you 2 months, and 2 weeks to modify that for each further version of the card. You'd need drivers for:

- ATI
- Chips & Technologies
- Cirrus Logic
- IIT
- Matrox
- NCR
- Nvidea
- Oak
- Paradise
- S3 Incorporated
- SiS
- Trident
- Tseng Labs
- Video7
- Weitek

That's 15 "chipsets" that I can remember, which would be around 30 months. For each of these there's the variations on the original chipset. If you say there's an average of 10 variations per chipset then that works out to another 75 months.

On top of this you'll probably want a generic VGA driver and a generic VBE 3 driver (so people can use something while you're trying to catch up to the manufacturers latest designs). Allow another 2 months for these.

Further, you're going to need to design the software interface to the video drivers and document it well. You're also going to need code to do some things in software for when the video card doesn't do it in hardware (for e.g. if someone wants 3D polygons or something on an old card it will work by doing it in software). Add another 3 months (or more) for this.

Ok, that all adds up to around 120 months, or 10 years. Unfortunately this doesn't really allow time for finding all the documentation you'll need, aquiring video cards to test drivers on or fixing all the bug reports that people will (hopefully) send in.

There's also things that can be done to improve this. If you don't need to work, or attend school or university then you can probably halve this. You could also skip the older video cards which could halve it again.

One possibility would be to write the generic video code (standard VGA and VBE 3) and a few decent video drivers, and then ask for volunteers to write the others. This is where your well documented device driver interface is needed - people would use your documentation and the source code for the decent video drivers that you've done as a guide for figuring out their own drivers.

Another possibility would be to write poor quality code. For example, if you didn't bother with 3D it'd save heaps of time. Unfortunately this would also make it less likely that volunteers will be interested in helping, so I'm not too sure if this would save time in the end or not.

Something that may be a huge help is supporting computers with multiple video cards (ie. dual display). This would let you use one stable video driver/monitor to see debugging information, etc from a video driver you're working on. Otherwise, if the video driver your working on results in a black screen or trashed video it can be very difficult to figure out what's going wrong.

frizzz wrote:But You need to see, that everything, vendors could have done, needs to act as fast as possible. Thus it needs to be simple!
The well hidden things are special registers and commands for video-purpose (i.e.Ati-All in wonder...), but You could omit it ( or dissassemble the driver-binaries

This is obviously wrong!

For example, to make things simple for software (and faster) video cards could have a single IO port that software uses to set a new video mode - for e.g. "out 0x1234, 0x13" could set 320*200*256 mode. This would make the hardware more complicated though, so no manufacturers will ever do it. Instead you need to set around 100 different registers (or more) to set a video mode properly.

Instead of making the software interface simple the manufacturers try to get the best performance for the least cost. This often means doing some things in hardware where performance matters and pushing things back to software where performance doesn't matter so much (or where it's too costly to do it in hardware, or where the card doesn't support the feature at all).

If you're talking about 2D and 3D acceleration (line drawing, hardware mouse cursors, bit-blits, polygons, fog, z-buffers, volumetric smoke, textures, lighting, shadow, bump mapping, etc) then it's probably going to be more complicated than you expect. For example, your video interface might use signed 32 bit integers for x, y and z co-ordinates where (0,0,0) is the centre of the screen, while the video card might expect 64 bit floating point x, y and 1/z where (0,0,0) is the top left corner of the screen. You might have to do hidden surface removal or clipping in software, or perhaps the video card only supports 3D triangles and your video interface uses polygons that need to be split into multiple triangles? Even for something like a 2D line you might need "(x, y), step and length" or "starting (x,y) and ending (x,y)", and there's things like patterns, colour and/or source data, and mixing modes.


Cheers,

Brendan

Thank You Brendan for Your well done overview and introduction to programming of videocards!
It's a mess - and I think, that everybody knows it. I beg for pardon, that my english is not as perfect as my german. Thus You misunderstood, what I wanted to say. As I said, I have no experiance with videocards. But I have a lot of experiance with integrated circuits and gate logic. That was my point of view. I know, that there must be a base adress (the chip-enable-pin) and an adress-space, if more bitsettings are needed to control the state-machines behind the pins than fit into a normal register.
Thus You need to know these adresses, if You want to control the state-machines.
The second thing to know are the values, You need to move to those registers, where every bit is connected to an input of a gate, which is a part of the state-machine. Other registers store the output of that state-machine (a programmer reads the status there).
This is true for ever, because this is the nature of those things.

But imagine, that there are only 32 bit You can set or reset. You will have 4G possibilities to set or reset! ( You can calculate 1 bit = 1 second of Your life
You need to be happy, when a vendor of such a state-machine uses only a subset of his possibilities. Everybody knows, that vendors of videocards did not cooperate as vendors of harddisks, who evaluated a very well done ATA-standard. Vendors of videocards tried the (S)VGA-standard and VESA. But we know, that a lot of vendors ( You listed some of them) play their own games.

Now there is still the question, where to get documentation. I would be satisfied to know how to switch to a certain videomode and where to write data to a certain scanline. And I think, that there are many programmers, who would be satisfied too, if they got such a subset of the possibilities.
I am shure, that these two functions could be done within a week, when the documentation is found already.

I mentioned already, that I found documentation depending on AGP. My first impression is, that this is complete. But Brendan pointed to an other problem: the register-adresses and bit-meanings in these registers are not the same on every video-card. Thus documentation about these things is needed too.
I know, that the X-driver in my linux deals well with my ati-card. It deals well with other chipsets too. The X-driver is open source. You can be shure to find there the needed things.

The most modern high resolution modes are available only on cards, which are AGP-cards. Thus there will be needed additionally documentation of PCI, if You want to know the adress space of a card.
Finally busmaster-DMA is needed (as far as I know).