Ok, so the FPS and iFPS (64x64) got me really curious.
I went and tested the glcd library on a ks0108 just to see how it compared
to the ST7920.
(I wrote a nifty little iFPS sketch that does the calculations)
With glcd on a 128x64 ks0108 using a clearscreen FPS test:
FPS = 79.08
iFPS = 158.16
glcd was using 8 bit direct port i/o driving all the glcd lines
(using nibbles on two ports vs 8 bits on single port slowed it down by 8 FPS)
glcd also uses delays with more accurate timing to match glcd spec timing
like Tas and Tdsw rather than using longer delays using <util/delay.h>
<util/delay.h> has many issues in its delay cycle calculations.
If you don't have the very latest AVRlibC you can get delays
that are many times longer or shorter than you ask for depending
on what you ask for and the F_CPU value.
This effect is worst at the low end like sub 3-5us which is where
these kinds of delays often are.
glcd uses Hans Hendriech's delay_x delay package instead.
So I think getting an FPS of 25.6 using much longer than needed timing delays
for control line setup, data hold times and strobe widths is actually quite good.
If the delays in WriteData() and WriteCommand() were
cut down closer to the spec, the fame rate would go up.
--- bill