VGA Hires Text (8x12 font) with the 512x384 driver?
PatM
Posts: 72
I have the 512x384 driver running a nice 4 color 320x200 three series line graph but the vector font really looks shabby when enlarged in VGA (great on TV or not scaled in VGA). I'd like to shoehorn the 8x12 font from the hires text demo into the mix but I'm really confused as to how to go about it. At first I was thinking the cog code for video had to be modified but then I realized that wasn't at all necessary. What I need to do is copy the font bitmaps into the display ram area at the appropriate location and the video code would display it as a matter of course. Thats about as far as I've gotten though. I can't figure out if using spin to copy the bitmaps is fast enough or if another cog has to be brought in to do fast copying.
My own code is not at all time sensitive - I gather and display data once every five minutes or so and have a PS2 keyboard hooked up to issue infrequent commands (minutes if not days or weeks apart).
Then of course, the hires text driver has the font data split up into thirds for effeciency and is written in assembly. Works like a hot damn but makes my brain overheat trying to figure out how it works
Anybody out there feel up to providing some guidance? Don't need the whole thing written for me (though if that exists, great!) but some idea on how to get started would be wonderful.
P.S. Since this is a tiled driver and the tiles are a different size than the fonts, I know have each letter a different colour just isn't going to work. I'll leave the colouring system alone.
·
My own code is not at all time sensitive - I gather and display data once every five minutes or so and have a PS2 keyboard hooked up to issue infrequent commands (minutes if not days or weeks apart).
Then of course, the hires text driver has the font data split up into thirds for effeciency and is written in assembly. Works like a hot damn but makes my brain overheat trying to figure out how it works
Anybody out there feel up to providing some guidance? Don't need the whole thing written for me (though if that exists, great!) but some idea on how to get started would be wonderful.
P.S. Since this is a tiled driver and the tiles are a different size than the fonts, I know have each letter a different colour just isn't going to work. I'll leave the colouring system alone.
·
Comments
I think SPIN's speed will suffice
With a little bit of chuzpe you can also call it anti-aliasing
·
I've figured out that the screen memory is actually striped vertically with longs. Long #1 is at the top left, Long #2 is directly below long #1. This makes it hell to place characters! In a four letter word like "byte" if its placed at the top left the "By" would·start in long #1 while "te" would·start in long #81 (4 colours - each character scanline needs 16 bits).
Why would the driver use memory in this way? It seems more counter productive than anything else as even·just drawing a line across the screen is going to take lots of math. There must be some sort of advantage to this?
The idea behind it is to display square "chunks" by just stating one single address. So theses chunks have to be allocated just as you describe it. When you display text this is a most clever scheme!
For black&white that is!
Enter colours...
The best idea here is to use planes, but this would take to many (or at least: many) memory accesses when generating the video line. The second best idea is to include the color information in "fat" bits, i.e. one pixel corresponds to TWO consecutive bits (not four as Pat insinuates).
But this is total nonsens for a character generator, as why for heavens sake should it store color information in its glyphs? Well, it could for a real "color font", but the usage is more often the user selects glyph and color independently!
To avoid this redundancy the ROM glyphs are interleaved as circumstantially described in the manual and in the datasheet.
The user can select a background color and a glyph color per tile.
Both schemes, tiling and glyoh interleaving are not well suited for "true graphics". Thus a graphics driver ignores it totally! It sets up the tiling to point into some linear memory and works there only. It does not mind that the pixel driver fetches it as if they were tiles.
The interleaved glyphs from ROM can bve overlayed, but have to be processed before - remove each other bit!
Post Edited (deSilva) : 9/1/2007 11:47:33 PM GMT
The layout makes sense now though, thanks! If you want to do 16 bit ·(4 colour) or 32 bit (2 colour)·wide tiles then yes, this makes total sense as like you say - calculate the start location then just squirt the linear bitmap in there and it works. No messing about trying to line up scanlines.
I'll just figure how how to line up my fonts the brute force way [noparse];)[/noparse] All I have to do is figure out which column of longs it belongs in then figure out if its the even (+0 byte) or odd (+2 bytes) word.
·
In fact GRAPHICS.SPIN has done that for you already.
What you have to do is inserting the glyphs into the "linear" memory according to as it is (line-) structured by GRAPHICS.
The only thing you have to consider when using the ROM font is its interleaving. ORing the glyph will not work as ach second bit does not at all belong to it.
In other words: you have 4 possible values per bitpair
0: bg
1: fg
2: gb
3: fg
So it should be best to map only "fg" to either 1,2, or 3 depending on your color setting
When you use your own glyphs you can "spread" a compact representation or use a already spreaded templates.
This'll be easy now. I'm only going to place the text in columns and rows with no arbitrary placement so I just write a routine to do x*8 and y*10 (decided to use an 8x10 font for small text) to get the linear X and Y positions, extract the character codes one at a time and convert to my data array position (11 words per font) then toss all that at pix() to get it placed. In fact, I think its easier done than said 8)
Its kind of tough understanding you sometimes but hey, your second language skill is a lot better than my second language skill (which is none).
One good thing, I wrote a routine that extracts each digit and determines its position and I kept that for use with the vector font. Since graphics driver only has text printing and not numbers, I swiped itoa() from someplace to convert the numbers to text but it has leading zeros. So I modified itoa() to accept single digits and return single letters. So now I step through the number one digit at a time and print that before moving on to the next digit. At the appropriate time I insert a decimal point (I dont actually use FP, I just make the numbers 10 times larger then manually insert the decimal point)
The big problem for me is that I don't really want to learn assembler (thats what basic compilers are for) and I don't really want to have to hand-make fonts and figure out formulas to convert tile based graphic methods into linear coordinates . I just want to be able to load up the spin tool, tell it which font to use then be able to have it print letters and numbers where I tell it to. In other words, I'm a lazy arsed amateur programmer that has some ideas he wants to implement but doesn't want (nor really knows how) to re-invent the wheel to get it done.
I think the prop is great and the grognards are having a field-day with it. Some day there will be a big enough body of work sitting in the object exchange that non-experts like myself can wade in and have a blast too. For now though, its just frustrating me to the point where I keep finding myself doing things other than work on my project. I think I'm just going to shelve this version and start over with an Atmel chip and an EZLCD. I still have my hydra though, so I can keep trying out the different things people add to the object exchange and see the really cool things people come up with (like the 80mHz scope dealy, that is a real jaw dropper).
That's what we others ar just crazy about to do
And there are MANY wheels already invented. I think the best solution for you is a "Linux board"; they come in the same price range as Propeller boards (AVR32, AXIS Fox-Board with ETRAX100, many more with ARM7 and ARM9 Chips) Those boards generally are extremely small!
Astonishingly, there is already much of what you want, but the catalogueing has been done along the rule user contributions follow "You take what you get". And the community is not yet large enough, or is still struggling with basics like you.
What is certainly needed is a "Guide to the Library", including a merciless re-write of non-confoming items. But even the first task takes time. Don't ask me why my "How the Video Drivers work" has not yet been posted.... It has become lengthier and lengthier... Explainations become a chalenge when the underlying facts are work-arounds (COG space, HUB space, VIDEO logic..)
Post Edited (deSilva) : 9/4/2007 6:44:49 AM GMT