OSDev.org

Eventually I'd like my kernel to support a graphics subsystem that drives a nice-looking console, with a high resolution (I'm going to require a video card capable of at least SVGA) and minimum 64K colours. What I'd like to do is develop a frame buffer type of device that Linux supports. Essentially it gives a nice console with good looking fonts and colours, instead of a boring 80x25 console with ugly fonts.

My console is going to have a white background with black fonts instead of the other way around, and the fonts will be anti-aliased. I wonder how I can achieve this? My main development machine has an on-board graphics card (an S3 Trio 3D with a Virge chipset to be precise) which conforms to the VESA 1.2 standard. So I expect I'll need some old VESA docs, since I believe VESA is now at revision 2 or 3 level.

How is this kind of thing done? Does the graphics card memory get mapped the same as 0xB8000 (or whatever it is) and simply go further, so there is x bytes for each pixel on the screen? Or is it mapped somewhere else? Does it need a driver which shoots the graphics in DMA mode (e.g. the DMA chip grabs the buffer from memory and sends it out over the AGP bus)? And are fonts simply bitmaps indexed in an array by the ASCII integer code, so you can access them easily and retrieve the bitmap of the font to draw in the video memory?

I am slightly confused by VESA and SVGA. What is the relationship between these two standards? Which one will give me some information to go on to implement my frame buffer console with high resolution anti-aliased fonts?

Hmm... has anyone else implemented a graphics subsystem in their OS? How'd you do it, what docs did you read?

Targetting VESA 1.2 is a pain, because it doesn't have any pmode entry points. Later VESA versions give you pmode code for switching banks in non-LFB mode, but VESA 1.2 requires you to switch to V86 or real mode for this. You should expect to switch banks frequently when drawing (imagine clearing the screen or scrolling), so bank switching needs to be fast; switching processor modes isn't.

By way of a shortcut, I've written/ported an S3 driver. It targets an S3 Trio64, but it might work for your Trio 3D. See here, but note that the source to the original driver has probably disappeared from the Internet.

If you use anti-aliasing on fonts, please make them at least around 30 pixels tall, since with small fonts anti-aliasing causes stress on eyes, and generally makes the text hard to read on the long run..

True, they look a little nicer when you first look at them, but try reading small anti-aliased text for an hour or two, and it gets really painful.

Tim Robinson wrote: Targetting VESA 1.2 is a pain, because it doesn't have any pmode entry points.

Thanks so much for the info and the stunningly readable source code! I'm afraid the Trio64 code doesn't work with the Trio3D, but heck, I can read the Xfree sources for the S3 Virge server (that works, I've tried all possible servers that may work) and get some ideas. In fact, I might just disable the onboard Trio3D and plug in my Matrox Millenium PCI card instead, since there's lots of code for that card lying around. I hope I don't need to be expert on PCI for this however... the basics like the PCI BIOS and memory mapped areas should be suficient, along with how the Matrox card uses it...

Hmm, looks like I'll have to download your O/S code and do some more extensive reading! You've got your system to quite an advanced state with video drivers and such... a good reference work!

So it looks like to avoid the old VESA BIOS rmode (?) thing I will have to read up on the AGP thing and its memory ports (I'm only guessing here), since the latest VESA BIOS extensions won't be around for my S3 or Matrox card... darn. If it only works in rmode however (VESA 1.2) I wonder how the XFree people made it work? There must be different ways of doing it - old style VESA BIOS calls in 16-bit real mode (?) and in 32-bit pmode using PCI/AGP memory mapped I/O.

mystran wrote: If you use anti-aliasing on fonts, please make them at least around 30 pixels tall, since with small fonts anti-aliasing causes stress on eyes, and generally makes the text hard to read on the long run..

True, they look a little nicer when you first look at them, but try reading small anti-aliased text for an hour or two, and it gets really painful.

Thanks for this tip! I certainly will make them big enough to be nice. Actually, I want fonts that appear on a 17-inch monitor as 12-point fonts, I think these are at least 30-pixels tall. But having a console with limited GUI stuff means I can make the fonts rather like 14- or 16- point fonts, which will probably be better and less of a strain on the eyes. I will have a configuration tool however to change the font and font size. I might port Knuth's Computer Modern Fonts actually... or even the fonts in the XFree package. (Saves me re-inventing too many wheels.)

James Buchanan wrote:If it only works in rmode however (VESA 1.2) I wonder how the XFree people made it work? There must be different ways of doing it - old style VESA BIOS calls in 16-bit real mode (?) and in 32-bit pmode using PCI/AGP memory mapped I/O.

It will be possible to program the Trio 3D outside of the BIOS, but don't expect it to be documented anywhere. Certainly XFree will do it, and I recall that Svgalib claims support for various S3 cards. I've found Svgalib source to be more readable and generic than XFree, so that's where I would start.

Another reference material would be s3.txt, which I later found is available as part of VGADOC. This doesn't tell you how to program the various cards, but it does contain a full register reference (so you can go one better than VESA and add acceleration).