On 5/31/05, Lourens Veen <[EMAIL PROTECTED]> 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 :-).
That's how I did it in the verilog vga text thing I just did. > > 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. It just occurred to me that we might be able to use the palette in the main video controller. I'm going to design it with various modes that allow for lookup of the RGB going out. So all we need to do is give the VGA palette some way to get at that. When the video is translated, we can convert paletted to paletted, just arranged differently and let the video controller to the lookup. > 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? I think Patrick did a diagram of that, where there's an EGA palette. The thing is, you can usually collapse two lookups into one. The trouble there is that you have to have logic to combine the palettes, which may be costlier than just doing the double lookup. When you have software control, it's one thing, but in this case... > > 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. We can do the 8x14 font too. When I did something like this, I found that the BIOS would switch back and forth between 350 and 400 line modes. I pretended they were the same mode, but I had to do funky stuff with the cursor and how character redefinitions were handled. Is there a standard place in the card's VGA BIOS ROM where standard fonts are stored so that they can be reloaded? > > > 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? Patrick did this too, I think. > > 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 > > > _______________________________________________ > Open-graphics mailing list > [email protected] > http://lists.duskglow.com/mailman/listinfo/open-graphics > List service provided by Duskglow Consulting, LLC (www.duskglow.com) > > > _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
