On 8/5/06, Lourens Veen <[EMAIL PROTECTED]> wrote:
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.
I'm not sure, but it looks like you're suggesting an 8-bit pseudocolor approach. I had been planning to add that to the video controller, but I hadn't been thinking about that for the nanocontroller, which is silly, because I should have. I may be repeating what you're trying to say, but basically, we can just use the palette and arrange it so that a set of them are rewitten periodically to make the blinking work. I think we need all 256, because when a character blinks "off", the foreground colors come to be the same as the background of their corresponding characters.
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
I'm not 100% sure what you're doing, but I think we can do this cheaply by using the pseudocolor overlay palette in the video controller. When blinking on of off, 128 of the color cells have to be updated, but that's dirt cheap compared to rewriting the whole framebuffer. ON THE OTHER HAND, we're always rewriting the whole framebuffer anyhow. It just may be that the conversion program is more likely to fit, because we simplify the number of different things the conversion code has to deal with.
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.
Well, like I said before, this video controller design doesn't have the ability to scale. If there's a need for it, I have thought of ways to add it, but in THIS case, we can program the microcontroller to do some integer scaling. (1x, 2x, 4x).
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.
The overlay scaler might be logically simpler, but it's in a performance-critical path. That makes it harder to design. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
