On 8/8/06, Lourens Veen <[EMAIL PROTECTED]> wrote:
On Saturday 05 August 2006 16:51, Timothy Miller wrote:
> 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 have a feeling that I'm not entirely up to speed and we're getting
terminology mixed up here. When I say "overlay scaler" I
mean "that-which-implements-Xv". "Video controller" makes me think
about the part that scans a frame buffer and creates a video signal. Do
I understand correctly that the overlay scaler functionality will be
implemented in the video controller eventually? In that case we seem to
be at least somewhat on the same page, and if so, please read "video
controller" for "overlay scaler" in the following.
Definitely mixing up terminology. I'm not planning on a mechanism
that will arbitrarily composite two framebuffers into one image.
However, there will be a means to have an 8-bit overlay by using the
upper 8 bits of the 32-bit pixels on the screen as a paletted image.
Moreover, there will be a way to make that look to the host like a
packed 8-bit framebuffer.
But if you want scaling, you'll have to use the drawing engine.
I hadn't thought of using the palette, because the conversion is so
trivial (I still managed to mess it up though, the one shown below is
the right one). It's a good idea, because we have the palette anyway.
I'm not sure about using it for blinking though.
Haven't you done palette animation before? :)
The problem is that we have 9 bits per pixel: 8 bits for the attribute,
and one for foreground/background select (from the character glyph).
I think you don't need the fg/bg select. Just pick the right one when writing.
With my scheme, the idea is to interpret the blink bit in the attribute
byte in the nanocontroller, and write the rest to the frame buffer,
which is 8 bits per pixel.
Initially, I had planned on having the nanocontroller just do all the
conversion work, straight from glyphs, attributes, and font, right to
32-bit pixels in the framebuffer. Blinking would involve it deciding
if that frame should have the blinking characters on or off. Having
the palette just makes things slightly more convenient.
The nanocontroller takes care of blinking by, for half of its refreshes,
writing [black] to the frame buffer instead of the normal data, for any
pixels that have the blink bit set. The blink bit itself does not end
up in the frame buffer, and we don't rewrite the screen more often than
usual.
IIRC, blinking "off" means making the whole block the background
color, not black.
I thought of using the overlay scaler to convert from this 8-bit format
into RGB because it is the main pixel format converting part. So it
seemed an obvious choice. I hadn't thought of using the palette, but we
can. After all, it's just a fixed 8-bit to RGB function that we need,
and that is exactly what the palette is.
Well, unfortunately, I don't think we have an overlay scaler like
you're thinking of. However, we may be able to get the drawing engine
to do some sort of conversion that helps.
Call the above scheme A.
Alternatively, if we want to use the palette to do the blinking, then
the blink bit needs to be present in the frame buffer. We can do that
if we interpret the f/b select bit in the nanocontroller and write a
byte 000Birgb into the frame buffer. We then use a 32-entry palette,
and rewrite 16 entries periodically to do the blinking.
That's what I'd initially thought of, but that would make blinking
characters blink to back, rather than the background. Mind you, that
is probably acceptable, since we're trying to do a half-assed
implementation anyhow! :)
[snip diagrams]
I tried to make sense of what you wrote, but I think I'm too
distracted. In any case, we're just going to write code to do this.
How expensive is reprogramming that palette logic-wise? And in terms of
code complexity? Does it weigh up to the extra complexity in the
palette equations?
I think the only advantage to using the palette is perhaps some code
savings. We'll rewrite the whole fb and palette every frame. The
difference is that, with the palette, there are fewer datapaths in the
conversion code, making it smaller and more likely to fit into the
program memory. But it may be tiny anyhow, so maybe we don't care.
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
