Jayeson,
Its a really tough situation for using ks0108 glcd type devices on Arduinos,
particularly with the 168/328 based boards.
It is kind of the convergence of a perfect storm that makes things so difficult.
There are so many pins involved, that it is tough to pick a set of pins
for a default configuration or even a group of configurations.
Also, unlike character type lcds, the glcd software is
having to deal with 8192 bits of pixel data in a low level
interface. This means many thousands of times more i/o operations
to get things done over typical character lcds or intelligent glcds.
(and that is for a 128x64 glcd, with larger displays it is even more data)
The Arduino i/o interface is individual pin oriented.
So at 16mhz having 4us of overhead to deal with each individual pin vs 62.5 ns becomes
very significant, especially when looking at so many i/o operations.
With direct port i/o on the large arduino boards all 8 bits of a data byte
can be written in a single AVR machine cycle.
Another very painful thing is (IMHO) the poor choice of pin assignments Atmel chose for
the mega 8/16/168/328 AVRs. Because of the pin assignments, it is impossible to get
an 8 bit byte in a single AVR register on those processors when using the serial port
on those AVRs.
Even using nibbles across multiple ports can be challenging because of the
alternate port functions and the very limited number of pins on those AVRs.
Now toss in the inability to use a local frame buffer because of SRAM constraints,
(which means you may have to read remote glcd memory before you can write to update a pixel)
you can't really off load any of the processing to an interrupt routine as the glcd update
would make the ISR take too long (potentially several milliseconds),
and wanting to support user defined fonts of any size, and you quickly enter into a world
of having make many painful choices and sacrifices in order to get the functionality
working with reasonable performance across many different AVRs and different sized glcd displays.
The current implementation made many intentional design decisions and sacrifices
along the way to try to make the library easy to use and offer reasonably high performance
across all the arduino boards.
Ease of use was at the top of the list.
One thing that is in the current v3 implementation is that the user can use any arduino pin
for any glcd function. He just has to define these in a config file vs defining them runtime in his sketch.
This has allowed users to easily reconfigure the library to support freeing up pins for alternate functions.
The low level code has many complex macros and inline functions
under the hood that will automagically determine the best/fastest way to use AVR direct port i/o to
access the pins. For 8 bit operations it can reduce that down to a single AVR instruction or
use nibbles, individual pin i/o or any combination depending on the pins selected.
This optimization can't be done if the pin information is not known at compile time by the library
or if multiple instances are used.
Multiple instances was not an initial priority especially given the number of pins involved
for these types of displays.
That said, multiple instances might be something that gets a second look in the future
but in my view, in order to really support multiple instances, the interface needs to be
moved to some form of serial interface, SPI/I2C etc... vs individual control and data lines.
Which could be done very inexpensively using an i/o expander chip.
--- bill