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.
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.
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).
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.
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.
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.
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.
Call that scheme B.
---------------------------------------------------------------------
Scheme A:
Input: S Bl bR bG bB fI fR fG fB
nC: Counter to create blink signal BS from refresh signal
out[7] = Bl ? (BS & S) : S
out[6] = Bl ? (BS & bR) : bR
out[5] = Bl ? (BS & bG) : bG
out[4] = Bl ? (BS & bB) : bB
out[3] = fI
out[2] = fR
out[1] = fG
out[0] = fB
FB: S bR bG bB fI fR fG fB _or_ 0 0 0 0 fI fR fG fB (black)
^ !Bl ^ Bl & !BS
Palette: R[7] = in[7] & in[3] & in[6]
R[6..0] = in[7] ? in[2] : in[6]
G[7] = in[7] & in[3] & in[5]
G[6..0] = in[7] ? in[1] : in[5]
B[7] = in[7] & in[3] & in[4]
B[6..0] = in[7] ? in[0] : in[4]
Output: 0 bR bR bR bR bR bR bR
0 bG bG bG bG bG bG bG // !S & (!Bl | BS)
0 bB bB bB bB bB bB bB
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 // Bl & ~BS
0 0 0 0 0 0 0 0
(fI & fR) fR fR fR fR fR fR fR
(fI & fG) fG fG fG fG fG fG fG // S & (!Bl | BS)
(fI & fB) fB fB fB fB fB fB fB
---------------------------------------------------------------------
Scheme B:
input: S Bl bR bG bB fI fR fG fB
nC: Counter to create blink signal BS from refresh signal
@posedge(BS) recalculate palette[16:0]
out[7] = 0
out[6] = 0
out[5] = 0
out[4] = !Bl
out[3] = S ? fI : 0
out[2] = S ? fR : bR
out[1] = S ? fG : bG
out[0] = S ? fB : bB
FB: 0 0 0 !Bl fI fR fG fB _or_ 0 0 0 !Bl 0 bR bG bB
^ S ^ !S
Palette: R[7] = (BS | in[4]) & in[3] & in[2]
R[6..0] = (BS | in[4]) & in[2]
G[7] = (BS | in[4]) & in[3] & in[1]
G[6..0] = (BS | in[4]) & in[1]
B[7] = (BS | in[4]) & in[3] & in[0]
B[6..0] = (BS | in[4]) & in[0]
Output: same as for scheme A
---------------------------------------------------------------------
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?
Lourens
pgp8k72SWpPXY.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)
