Look in the last logs for more info on these weird(?) LCD column-drivers which contain an internal framebuffer...

Weird Thought:

This display [most likely] has 120 rows (and 160 cols)... (one row-driver chip, one col-driver chip)

The column-driver chip can handle 160 columns, and its internal framebuffer can handle up to 240 rows (two row driver chips).

OK, since this only drives 120 rows, that means its row-driver chip is not wired for daisy-chaining...

Which very-well *could* mean that if you sent the timing signals for a 160x240 display (instead of the 160x120 it likely actually is), it'd show the first 120 rows, then automatically recycle to the first row, showing rows 240-479 on the original 120 rows...

Essentially getting *two* refreshes for every Vsync.

But Wait!

It'd be *easy* to hack a normal 160x120 driver for this setup (if it's true), by simply putting a divide-by-two counter on the VSync...

So, the graphics-controller doesn't have to do anything special to accomodate this double-refresh-per-vsync "mode".

NOW, IF such were implemented....

let's pretend the graphics controller chip, designed for B/W (on/off) pixels has inbuilt frame-by-frame dithering to acommodate 3 shades of grayscale over two consecutive frames (at 60Hz, maybe 120, up to 240!).

first frame: the pixel can be on or off

second frame, same.

So, off off = 0%

off on (or on off) = 50%

on on = 100%

That's actually pretty common for graphics drivers designed for LCDs at the time...

Now, if I'm right about the automatic cycling of the row-driver at row 120, that means the col driver's internal framebuffer (which can handle twice as many rows as we have) can store the actual grayscale information, and automatically refresh it, when new frame-data isn't being sent!

Coool!!!

If it *wasn't* done that way, I don't think it'd be a huge hack to make it that way...

Maybe a pull-resistor tied to the daisy-chain-in input on the row driver, tied also to its daisy-chain output...

As I understand, it's basically just the "load TRUE" into the row shiftregister for one hsync clock" input.... so daisychaining it *back* to itself would cause it to loop (if it doesn't already) for that second "frame"...

Could be groovy!

(I should clarify that we're talking about STN displays which don't actually call their inputs "hsync" and "vsync", though they're very similar in concept... So I usually just call them such. Especially since different manufacturers call them different things. 

BUT this isn't a great habit, because it implies timings similar to TVs... and LCDs don't *have* to be so strictly-timed since they have shiftregisters to store the pixel data whenever it's available... which is for the next log).