Depending on the particular controller for a graphic LCD, that might not be
the case... we're presently using a 120x32 unit (turned into 20x4 characters)
where the controller organizes the memory as 4 "pages" (rows) of 120 bytes...
and each byte you send ends up displayed "verticallly" (as a column), with the
pixels turned on or off based on which bits are set in the byte (as you'd
expect). Although you do need to keep a font around (just as, e.g., a big
array if you're using C), the actual code that deals with keeping track of
cursor positions and turning ASCII into bitmaps something like 100 lines of
C -- I wrote and tested it in a couple of hours. While strictly speaking it
does require more uC "oomph" -- you're sending six bytes to the controller for
each character rather than 1 -- it's an utterly trivial amount of CPU time in
either case.
(Granted, if you want to start taking advantage of the graphic LCD and draw
circles or whatever, surve, that's more time and code... but if you're just
looking to use a graphic LCD as a text-output device, the point is that it can
still be very fast and easy to do.)
