I would seriously look at the scroll rate that you really need. You probably do not really need updates faster than about 20Hz. That would give you about 200 msec to update the display. Here are some things to consider:

1) I have demonstrated, on stuff I have built, that a 128x64 display can be updated from an in-XRAM buffer in about 8-9 msec with a SiLabs C8051F124 or 'F020 running at 22.1184 MHz.

2) Trying to implement a graphics display using read-modify write to the memory on-board the gLCD is at least 5 times slower to perform than the screen update from memory buffer scheme I have used and shown in the code examples at: http://www.8052.com/users/mkaras/GraphLCD.phtml

3) It is my experience that the access ease and speed to the display memory on gLCD modules with the T6963C controller is slower and a pain in the butt compared to displays with say the Samsung types that have the vertical raster bytes. This is especially true when you try to work out a merging graphics driver using the storage on the display controller.

4) It is very easy to attach a 32K x 8 SRAM on the EMIF (External Memory InterFace) of the SiLabs processors that are in the 100 pin packages. It can be done with NO extra parts and using the 8-port parts you still end up with very good memory bandwidth because you can setup the EMIF for non-multiplexed address bus operation.

5) Lastly there is a common scheme used on "wave form scanning" type displays that may be suitable for you to consider. I have implemented this several times on products and it works surprisingly well. The idea is to sweep the display update point across the display using a sweeping cursor scheme wherein the bulk of the display waveform stays static on the screen and only the most recent column of pixels gets updated. In the screen graphis below I attempt to show how this works.



The sweeping cursor moves left to right and newst data is painted to the left of the cursor and a blank space is kept to the right of the cursor. A cursor could be 3 or 4 pixels wide. At one update time only three columns need to be drawn...the newest data column overlays the left most cursor pixels. A new column of pixels is added to the right of the cursor bar. And one additional column of pixels are blanked on the right side of the leading blank area. When the update columns get to the right side of the screen they simply wrap back to the left side. The blank area is very important and should be about a pixel wider than the cursor bar.

Michael Karas