Lourens Veen wrote:
On Tuesday 31 May 2005 18:35, Patrick McNamara wrote:
I will update the wiki this evening with the conversion regquirements. For
example we need to be able to convert 4,8, and 16 bpp color to 32bpp RGBA.
We need to be able to convert 8x16, 8x14, and 8x8 fonts to 32bpp bitmaps in
80x25, 80x43, and 80x50 line text modes.
Well, 4 and 16 bit colour are pretty much trivial. For 4 bit there are two
options, either it is I(ntensity)RGB, or it is Bl(ink)RGB. In the first case,
the 32-bit xRGB value is 00000000IRRRRRRRIGGGGGGGIBBBBBBB. That's just wiring
(maybe a few buffers if the signal doesn't have a fan-out of 7 :-)). In the
second case, it is 000000000rrrrrrr0ggggggg0bbbbbbb, where r = (((~Bl) | (Bl
& BlS)) & R) and so on, with BlS some kind of oscillating signal. Takes three
of those 4-to-1 function cells these FPGAs are rumoured to consist of :-).
The 4bpp modes allow the 16 colors to be selected from the full
palette. In fact if you look at the stock VGA palette, the first 16
colors are the same colors used for the 4bpp modes. Properly set up, I
think we can get away with a single color conversion routine (whether
hardware or software) for both 16 and 256 color modes. In fact, from
what I can determine that is what is done for most (ALL?) VGA cards.
For 16 bit, you can have 565 or 555. Expanding to 888 is just a matter of
adding zeroes, or again, just wiring.
It's actually a multiply by 8 scaling factor for 555 mode, but are
correct, you can simply move all the bits over in the hardware.
8 bit is a palette lookup, which with a block ram (in 512x36 mode so we can
get the RGB values in one lookup) is trivial as well. The problem may be
loading the palette with the RAM in 512x36 mode, since that is done bytewise
IIRC. Maybe we could fetch the 36-bit line when the address register is
written, and then write back the line with the new value in it when the data
register is written after that. I don't think that that should be a
performance problem.
The host interface is bytewise, but all the docs I have read lead me two
believe the internals aren't. When you read the palette, you set the
starting index and then read a byte, red. If you do nothing but read
again, you get green. And again blue. And again, red, for the next
palette entry.
So you take the 8 bits for the palette entry and dump it into a
counter/buffer. This selects your palette row. A separate div by 3
counter selects which byte is mux 'd to the host interface. The div3
counter is clocked by host reads/writes and when it overflows, it
increments the row counter/buffer.
Along those lines, I definitely think we should expend one of the BRAMs
for the VGA registers. I was originally proposing putting them in card
memory, but I'm pretty certain that the random memory io latency of the
memory controller nixes that idea.
Last, I seem to recall (but it's probably been a decade since I worked with
this) there was some very funky business with palettes in 4-bit modes.
Something like a double lookup. Does anyone know?
Dunno about this. The references I have treat the 16 color modes the
same as the 256 color modes, just using the first 16 palette entries.
Then, about the fonts, can we not simply use the 8x8 font in 640x350 mode for
the 80x43 text mode? 640x350 is standard EGA, so old fixed-frequency monitors
should support it, and 43*8=344 so it will almost fill the screen as well.
That way we only need logic for 8x8 and 8x16 fonts. Having font heights that
are a power of two makes it trivial to calculate the position of the glyph in
the block RAM, which makes for easy lookups.
All VGA fonts are stored on a 32 byte boundary regardless of whether
they are 8, 14, or 16 lines high. In fact the font can be anywhere from
1 to 16 lines high and is the height programmable by a register value.
Maybe we could create a diagram with the five stages (read VGA data, convert
to pixel data, translate colour, write, loop) and what we need for each of
them for each mode?
More on this later, I have "real" work I have to do now. :)
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
