Thanks for the idea - I didn't really think of trying that (who knows why, I
think my brain must be broken these days ;), but it is a really good idea.
I'll probably be limited to 1 maybe 2 fonts, but I might be able to make it
work for what I need, especially if I trim out letters I won't be using in
the display.

I was thinking of setting the character bitmaps into eprom and setting it up
to be able to access the eprom for the bits, but I may be asking for too
much trouble...  I just don't know - it will all depend on how many fonts I
will ultimately need - but either way, a method to convert from a text file
layout of the font to hex/binary/arrays would definitly be good.

-Tony


----- Original Message -----
From: "Olin Lathrop" <olin_piclist@EMBEDINC.COM>
To: <PICLIST@MITVMA.MIT.EDU>
Sent: Sunday, March 23, 2003 6:59 PM
Subject: Re: [PIC]: Graphic LCD's & text...?


> I put the font table into the program memory of the 16C66 that was also
> controlling the LEDs directly.  The trick to the flexibility was keeping
the
> original font definition in a text file that is easily modified by humans.
> Per character code, the font file contains an array of characters that are
> either "-" or "*" to indicate which pixels are on for that character.  The
> font "image" is therefore visible in the text editor, and can be modified
> intuitively.  A font compiler reads this file and produces an MPASM
include
> file that is little more than a large pile of RETLW instructions.  Another
> program was written that read the same font definition file and created an
> image of each character font and its associated character code.  In other
> words, the runtime font table and the documentation are both created
> automatically from the same human-understandable font definition file.
This
> scheme has worked out reasonably well.
>

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads