[Open-graphics] bootstrapping the video mode

[Lourens Veen]

On Friday 04 August 2006 16:04, Timothy Miller wrote:
> On 8/3/06, Diego Sáenz <diego.saenz at aulir.com> wrote:
> > I think that vga controler must wait before other parts so it can
> > use that parts. For example:
> > It can use bitblt to copy font characters and emulate text modes at
> > boot.
>
> This may or may not be helpful.  The font will natively be in a
> format that the GPU can't understand, so we'd have to convert that
> too. There might be some advantages to using the GPU to stretch, but
> we could just as well do that in the nanocontroller.  Remember that
> for VGA, performance is a non-issue.  If we get 10Hz on the text
> console, we'll consider ourselves spoiled.

VGA text mode specifies characters as an 8-bit character code, and an 8 
bit attribute. The character code is an index into a table with 
character definitions. IIRC, the character definitions are 16 8-bit 
bytes, where a 0 bit specifies the background colour and a 1 bit the 
foreground colour. The attribute byte has three bits (red, green and 
blue) for the foreground colour, three (again RGB) for the background 
colour, one bit for high-intensity foreground, and one bit for 
blinking. So it looks like BL bR bG bB fI fR fG fB (I'm not quite sure 
about the bit order here, but for this discussion it's irrelevant).

Now, let's say the nanocontroller is in charge of looking up characters 
and writing pixels into an intermediate frame buffer, and let's say 
that that frame buffer has a special format: S bR bG bB fI fR fG fB (8 
bits per pixel). The S(elect) bit is copied from the character 
definition, the rest comes from the attribute byte. Effectively all the 
nanocontroller needs to do for text mode is calculating addresses and 
reorganising data accordingly. Oh, and it needs to write zeros instead 
of data periodically if we want blinking. Of course, our video 
controller won't be able to read this framebuffer format.

Enter the overlay scaler. It needs to support format conversions anyway, 
and one more won't make much of a difference. Especially since this 
format is extremely cheap compared to say the matrix multiply for a YUV 
format. To get to 24-bit RGB, all you need is a 4-bit mux and a bunch 
of wires:

i = S ? I : 0  // equivalent with S & I
r = S ? fR : bR
g = S ? fG : bG
b = S ? fB : bB

R = i r 0 0 0 0 0 0
G = i g 0 0 0 0 0 0
B = i b 0 0 0 0 0 0

The scaling part of the overlay scaler scales the whole thing to the 
desired resolution, the video controller turns the resulting frame 
buffer into a signal and presto, full-screen VGA text mode.

This way we don't duplicate hardware, we don't need the 3D engine (the 
overlay scaler is a lot simpler than the 3D engine I'd say), and our 
BIOSes and boot logos will display nicely even on fixed-frequency 
monitors.

> > 3 Accelerated framebuffer, VGA cappable, botable
> >   (VGA controller using implemmented fearures, BIOS, ...)
>
> I was thinking that VGA might come before acceleration.  In part
> because it's simpler.

We need both anyway. We can develop a nanocontroller first, and then 
when we've got the 3D acceleration stuff done we could create a new VGA 
module based on that, and see which is cheaper/better.

Lourens
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
Url : http://kayan.duskglow.com/pipermail/open-graphics/attachments/20060805/5bc4f564/attachment-0001.bin