I've had a chance to look closer at the st920 chip interface.
It is very different from a ks0108 style type of display.
It has some higher level commands, ,built in fonts, user definable
fonts plus bitmap graphics capability.
It also has 3 interfaces: 8 bit, 4 bit, & serial.
The ks0108 type of device is a very "dumb" interface.
It is just a big bit mapped memory display with an 8 bit interface.
While it looks like a nice feature superset compared to a ks0108,
there will be some challenges trying to get this type of device
integrated into the glcd library (the ks0108 library really isn't a good option).
Because the ks0108 is a dumb bit mapped interface, the ks0108 type of device requires doing everything yourself. Which includes rendering fonts from font data stored in the user code (sketch).
The ks0108 on board graphic memory is based on 8 bit display pages that when the display panel is viewed with a wide aspect ratio (vs tall), the 8 bit pages draw 8 vertical pixels on the screen with bit 0, being the the top most pixel. Every time a page is written the address counter advances to the right.
In my initial look at the st920, it appears that it uses a 16 bit page split across 2 writes and also advances the address counter to the right. The real challenge with respect to a "ks0108" style library is that it appears that the 16 bit page draws 16 pixels horizontally when the display panel is viewed horizontally with the left
most pixel being bit 15.
This is a fundamental difference between it and the ks0108 style glcd pages.
The difference between vertical and horizontal pixel page display mapping is potentially a big deal depending on how the code is written.
Currently the ks0108 & glcd library code does not use a frame buffer.
This was very intentional to allow it run on smaller MCUs and not consume extra RAM memory regardless of the display panel geometry.
Because the ks0108/glcd code does not use a frame buffer, there are several places in the code that "understand" the page to pixel mapping direction and do pixel to page mappings on the fly, the biggest being the character rendering code.
Also, the font data created is currently generated for 8 bit vertical pages.
It is still possible to slide in support for a horizontally page mapped device, but it won't be a drop in. And there will have to be some design design decisions made as how to best fit it in.
Things like having different font data that maps to this style of device or map the font data from 8 bit vertical pages, to 16 bit horizontal pages on the fly as characters are rendered.
There is also a potential issue of how to handle the st920 built in fonts vs custom graphic rendered fonts. The built in fonts have some limitations on them that the glcd library fonts do not. Like pixel location and size. The glcd library can render any sized font on any x,y pixel value. The st790 has very limited number of internal fonts and has distinct boundaries where fonts must be drawn.
The glcd library also provides some options like inverse video mode and reverse (top to bottom) scrolling within user defined text areas that isn't supported by the st920 built in fonts.
But the st790 is not alone in these types of compatibility issues with the current ks0108/glcd library code. There are several other displays that have these capabilities including some that do not have read capability so it may be that adding support for this type of device is tied in with a bigger picture view of how to add support for this class of device and devices that do not provide read capability, rather than looking at it from the viewpoint simply getting support for the st790.
--- bill