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 :-). For 16 bit, you can have 565 or 555. Expanding to 888 is just a matter of adding zeroes, or again, just wiring. 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. 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? 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. 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? Last, there's a bug in my earlier description, c_tb is not updated correctly in the loop stage. There are several easy ways to fix it. I'll leave them as an exercise to the reader :-). > Here is the design target: 30Hz screen updates. More is better, but not > at the expense of more gates. Sounds good. Lourens
pgpPSgqPIa9kV.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)
