[Open-graphics] bootstrapping the video mode

[Timothy Miller]

On 8/4/06, Diego Sáenz <diego.saenz at aulir.com> 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.