On 8/4/06, Diego Sáenz <[EMAIL PROTECTED]> wrote:
> 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. It is usually a bitmap with a byte per row(8x8, 8x14 or 8x16 bits/pixels), but we can convert to GPU pixel format in the set mode or load font call with the OGC VGA ROM BIOS code
I know, but when do you convert it? I suppose what the program could do is begin by converting the font to GPU-compatible images, then converting the screen by sending lots of bitblts to the GPU.
> 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. I do not argue about the nanocontroller, i only suggest to reuse hardware blocks and because that wait to the design of those blocks. The nanocontroller can be used to program the rest of the hardware.
No. The nanocontroller doesn't have any ROM. Its program memory will have to be programmed by the BIOS. The BIOS is, therefore, responsible for setting up everything else.
> > > The set mode BIOS rutine must load font on mem and prepare other things(mem zones for char cache 4kb, real framebuffer, etc), every time a char is writed to the card a bitblt copy the right char bitmap to the real framebuffer(it can be easy if we chose the right address for the mem zones) >
You could do that, but given that the font can change, you might as well just update the whole display in a loop. Doing what you're suggesting, the character would be updated perhaps with less latency, but the datapath between the host CPU and graphics memory would be slowed. What works best is to give the host CPU the fast path to memory and have the conversion done in parallel. This way, virtual updates are fast, even if the physical updates are choppy.
> We need to be able to handle font changes that cause every instance of > the glyphs on the screen to change. I anticipate no problem with the > nanocontroller just dumbly regenerating the whole framebuffer every > loop. If the font change is a software one the screen regenerate can be in the font change call, but surelly we will need that feature in a more hardware part.
There's just a part of the VGA address space that contains the font. We don't necessarily want to intercept that. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
