P18F4550:
@bperrybap by setdot do you mean drawing pixel by pixel, because talking to these displays at low level 1 byte draws 8 pixels at once virtically which is 8x quicker than 1 pixel at a time
I'm very aware of the glcd page memory layout.
The glcd library goes through great pains to really limit the accesses to glcd memory
by doing page accesses whenever possible.
It gets very complicated depending on the format of the data and
the alignment of the image/glyph and the alignment of glcd memory which
is why the character rendering code is so large and complex.
(Some glcds us vertical pages, and some use horizontal pages)
The XBM drawing routine I posted is very simple, it renders 1 bit at a time which is why I said
it isn't as fast as when things are done in native glcd format.
But in some cases the rendering and the updates to the physical display are
not done at the same time. In that case the pixel updates don't hurt very much
and in some cases can actually be faster because you can have really small
and fast code to render, and then simple but fast code to take the rendered data and slam
it to the physical display. ug8glib kind of works this way.
bikeboy,
the glcd library does not support the ST7565, you should have a look at Oliver's ug8glib library:
http://code.google.com/p/u8glib/
http://arduino.cc/forum/index.php/topic,91395.0.html
It uses a very different model for talking to the glcd display than the glcd library
but it supports your display as well as XBM bitmap format.
--- bill