You should not need any additional buffering. There should not be a loading issue.
The glcd will place very little load on the AVR pins and the AVR pins have quite a bit of "oomph".
This is a wiring issue or possibly a library code issue as I haven't specifically tested your exact configuration.
The main reason that I say it might be a library code issue is that currently the library
uses 8 bit values for x/y coordinates for speed. Because of this, the maximum
pixel value can be is 255.
There are some funny things that happen in the code as the display size gets to 256 pixels wide.
The code will actually not be able to address all 256 pixels across.
You will for sure lose the right most pixel all the way down.
There well may be some issues with the code as I have never tested the code with a 256 pixel wide
configuration and currently a pixel value of 255 is "magic" to the code internally.
We didn't put much effort into testing 256 pixel wide displays as we hadn't seen any panels this large
and this dual display mode is not something that many people will hook up.
You are off pioneering into some new territory.
Also keep in mind that incorrect wiring could potentially damage the glcds.
(unconnected wires are essentially the same as miswired wires)
On reason there can be issues is that if both glcds are not wired correctly, more than 1 glcd
or even more than 1 chip on a single glcd module
can attempt to drive the data bus at a time so you end up with bus collisions.
The way these modules work is that depending on the control line logic levels,
the ks0108 chips will do various things to the data bus.
The data bus is bi-directional. It must be shared between input and output so
all entities that are hooked up to the data bus must all be in agreement with
who should be using the data bus and in which direction.
In this setup, there are 5 entities (6 if you count the buffer chip)
that are potentially driving/accessing the data bus. The AVR, and four ks0108 chips (2 per glcd).
(Also the buffer chip if that is hooked up)
If a chip is selected, then it looks at the other control lines to see what to do
with the data bus. If the chip is not selected it floats its data bus pins to allow
something else to drive the bus. That could be another ks0108 chip on a glcd module
or it could be the host (AVR) depending on what is going on.
When selected, the chip will then look at the read/write line to see if the data bus
should be listened to (write rw=low) or driven (read rw=high).
The EN signal determines when the chip will drive the bus. If the rw pin is high,
the chip will drive the data bus pins as soon as EN goes high and will continue
to drive the bus as long as it remains selected, EN remains high and rw remains high.
When the data lines of both glcd modules were originally tied together, it sounds like none of the control lines
of the second glcd were hooked up. Because of this, the second glcd has floating control
lines. Floating inputs are not good. More than likely many if not all of the control lines float up to high.
If they all float high, then you would end up with the both ks0108 chips on the second glcd module
being selected (cs1+cs2 high) in read mode (r/w high) and EN high.
In this condition, both ks0108 chips on the second module
would attempt to drive the data bus all the time and that would
crash with the other module or even the AVR trying to drive the data bus.
Adding an external chip to drive the data bus for the AVR will not solve this.
Also, I'm not sure how the library code could work with that buffer chip.
(I'm betting that diags was failing).
I'm not sure how the buffer chip was hooked up but
since that buffer chip is not bi-directional and does not seem to have any output enables, it
will drive the bus all the time. Because of this, the AVR would not be able
to properly read data from the glcd memory as the buffer chip would be
driving the data bus at the same time as the ks0108 chips during read
operations.
========================
My suggestion is to remove the buffer chip and wire up the glcds directly
to the AVR pins.
Since these two glcd are being treated as a single glcd module to the software,
they both must be fully hooked up before either will work properly. It is just
like with a single glcd. If you left any wires not hooked up, the glcd will not work
properly. In this case if any wires on either glcd are not hooked up correctly,
it makes both fail.
Hook up d0-d7 lines together, hook the rw, en, di, lines together.
Then hook up each modules contrast and backlight pins separately.
All the CS lines must be hooked up and none can be shared.
(I can't see your mega pin configuration file but I'm assuming you didn't change it)
CS1 & CS2 from first module would pins 33,34
and CS1 & CS2 from second module would be pins 32,31
It should then work.
If not, run the diags sketch and capture the serial output
and past it here and we can diagnose from there.
If things are not working, then the serial output is a great tool
as it shows everything that the library is using to configure its low level
i/o code.
I'll work with you until we get this up and working to make sure that there is not
any issues in the actual library code, especially when the display
size is 256 pixels wide.
--- bill