On Friday 04 August 2006 16:04, Timothy Miller wrote: > On 8/3/06, Diego Sáenz <[EMAIL PROTECTED]> 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
pgpmuLwwfDRZy.pgp
Description: PGP signature
_______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
