Timothy Miller wrote:
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.
The big problem with the palette idea is that blinking can be turned on
and off per character. This works ok if you use the blink bit as an
alternate palette select, however then you have the problem of the
background color. Someone had pointed out, the blink changes the
foreground to the background color. If we are going to do a
nanocontroller, I would suggest throwing hardware at this problem.
//vsync counter
always (@posedge vsync) begin
blink_count <= blink_count+1;
end
//blink logic
if(blink_count[6] && text_attr[7]) begin
//just display the background color here
end else begin
//display the character in the foreground color here
end
If the nanocontroller is full featured enough, the blink logic can be
implemented in software, but the counter being in hardware certainly
simplifies some things. Regardless or hardware or software, I would shy
away from using palette magic to do text mode blinking. I think the
resource requirements in terms of scratch RAM for the palette as well as
the logic for working with them and keeping them up to date will not be
worth it.
One other point, on the suggestion of just blinking to black instead of
the foreground color, I would argue against it. If we are going to
bother to put a VGA emulation mode in the card then it really needs to
behave properly (as people expect). Slow is ok, but outputting
different from what is the expected norm will generate lots of "it's
broke" comments. Unfortunately, it's the negative comments that get
posted and spread around.
Patrick M
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
