View Full Version : VGA Hires Text (8x12 font) with the 512x384 driver?
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 http://forums.parallax.com/images/smilies/smhair.gif
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.
09-01-2007, 01:07 AM
Pat, you gave all the clues - now just do it!
I think SPIN's speed will suffice
09-01-2007, 02:38 AM
I didn't like the big fonts of the VGA examples either. But, I found a 1024x768 tile driver while digging through this forum that works nicely and gives 64 columns by 24 rows of characters. This example also includes a graphics window you can use for your graph, although it will undoubtedly occupy a smaller area of the screen...
09-01-2007, 02:57 AM
Many things depend on the physical resolution of your monitor... It makes not much sense to generate pixels that cannot be displayed. But mybe it is sometomes the easiest solution
With a little bit of chuzpe you can also call it anti-aliasing http://forums.parallax.com/images/smilies/smile.gif
Yeah, I've seen that 1024x768 driver, problem is that I need four colours and the whole screen for the graphs. 320x240 works great it's just the font that looks icky. Of course, on TV the same font looks nice and smooth with round holes instead of square etc. But then, thats what the font was meant for I would assume.
Well, I've been working on this and I've got the basics figured out. At first I was getting completely wonky results which was mostly because I didn't understand how memory is used for video. I thought the bytes would simply be sequential and correspond to horizontal scan lines. For a 320x240x4 screen Byte #1 would be the 4 pixels at the top left and byte #80 would be the four pixels on the top right. Boy, was I wrong.
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?
09-02-2007, 07:36 AM
That's what tiles are all about! Tiles are NOT linear bitmaps.
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!
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
So really what you're saying is that I need to find a linear VGA driver if I don't want to do the math to calculate the positions for bitmapped fonts? And no, don't say "write one yourself" because I'm an assembly luddite. Not only do I not know assembly, traumatic experiences back in my apple ][ days have made me loath the idea of ever learning http://forums.parallax.com/images/smilies/freaked.gif
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 ;) 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.
09-02-2007, 08:59 AM
So really what you're saying is that I need to find a linear VGA driver if I don't want to do the math to calculate the positions for bitmapped fonts?
No, I think not. The "tile" pixel drivers are fine. You just set-up what they think are tiles and then forget all about it!
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
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.
Ah, I think I figured out what you're trying to say. I've been thinking of the bitmap font as a font and forgetting that its simply a picture. I looked in the graphics driver and there was a pixel sprite function so i added the setup data to one of the font data sections and voila, it appears right where I wanted it. It even appears in the same orientation as the bitmap instead of reversed (well, my number looks reversed now since I reversed it to work with the reversal of the manual copying method). That'll make it easier on my brain when making the numbers and letters.
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).
Well, I've come to the conclusion that I'm just not ready for the prop. I tried using the graphics driver spite routines and it took my font graphic and doubled up the pixels, making it look all chunky. No problem I thought, I'll just go back to the (easier) byte wide graphic. Then I realized I can't do that - pix() requires word sized data. So, I went back to the initial method of using bytemove with word wide graphics. Then it hit me... to have three different colours of the same font, I have to either have three copies of each character or figure out how to swap the bits around on a copy of the character. So, I finally gave up and decided to stick with the vector font.
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).
09-04-2007, 02:36 PM
Then it hit me... to have three different colours of the same font, I have to either have three copies of each character or figure out how to swap the bits around on a copy of the character.
And I had been so happy to have explained all this to you some days ago ... But you see: There is no thing like own experience http://forums.parallax.com/images/smilies/wink.gif
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 .
That's what we others ar just crazy about to do http://forums.parallax.com/images/smilies/devil.gif
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.
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!
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.
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