In my experiments with TFT LCDs I did a LOT of taking-advantage of the fact that *by-design* (and by name) Thin-Film-Transistor LCDs have a transistor (and dynamic RAM in the form of a capacitor) at every pixel.

Essentially a write-only DRAM framebuffer, which is why they are so much less prone to flicker than STN LCDs... each pixel *holds* its value until the next time it's refreshed.

Or at most, until the capacitor discharges, which I've found to be on the order of one second... (as low as 1/4, as high as 5!)

Yes, I have several projects whose refresh-rate is about 1/2second per frame, or 2Hz (And you need 120?!). 

(Handy for slow microcontrollers to make use of an old 1024x768 laptop LCD)

....

But, frankly, that wasn't really unexpected. That was the whole reason I started those experiments.

I did, however, run into some *very* unexpected odditities which I really wanted to be able to take advantage of, if they were reliable...

One such oddity occurred when I messed-up the number of Hsyncs; too few hsyncs resulted, as one would expect, in the top portion of the display being refreshed. The unexpected part was that the bottom retained its image, without fading.

Only one of the 4 displays I was working with had this "feature". The others eventually faded where they weren't refreshed.

But it got even weirder, because several times it would refresh in the middle of the display, and as if that wasn't weird enough, both the upper and lower unrefreshed portions retained their images without fading.

Almost like it would be somehow possible to *intentionally* refresh any arbitrary row[s] at-will...

...which, of course, would be perfect for a slow microcontroller...

say one had a graph in the upper half, showing power-usage throughout the day... or maybe a weather-display... It only needs to be updated once a minute. Below that there could be a user-interface, or textual information changing/scrolling regularly.

...

The other day I came across a really cheap source of displays used in PDAs, like the B/W Palm series. These are STN, which I actually like the look of and daylight-readability... I got so excited I completely forgot that TFT is what made all my prior projects possible, and these aren't TFT. Heh!

But I ordered a lot, so I started thinking about how to drive them with my slow microcontroller-of-choice...

Yeah, well, we're not talking 1024x768, nor 18bits per pixel, we're talking 1bpp at maybe 160x160. Even my slow-uC-of-choice could surely handle that and other tasks as well.

So I started looking into the undocumented pinout... trying to derive it from things on-board. Looks like it's a typical dot-matrix STN, row drivers, col drivers... essentially continuously raster-drawn... The row/col drivers are silicon on ribbon cables, no chip numbers I can see. 

But there is a separate chip, which I gather is responsible for the weird voltages LCDs require....

And it, apparently, is somewhat specialized in some way I don't quite understand, but apparently some of that specialty carries-over to the row/col drivers. So, I gather, it's *very* likely the unmarked row/col drivers are the ones recommended in the marked chip's datasheet.

So, I dug up their datasheets, and sure-enough they look pretty typical.

Wait, What did I almost scroll over?!

"160x240bit RAM"

RAM in a column-driver?!

What a read followed thereafter!

This otherwise normal-looking column-driver has a full-on [write-only] framebuffer.

You treat the display like any other, continuously sending raster-info at 60Hz... Timing is important, yahknow... not easy for slow uC's doing other things...

But these column-drivers *remember* the rows you last sent... so if you decide to stop sending, it refreshes automatically from the internal framebuffer!

The idea makes sense... It's advertised for power-savings. The display-driver can go to sleep without affecting the display.

Alright, still, even one frame in 1/60th of a second is a lot to ask from a slow uC...

But, no! It gets better!

These column drivers keep track of which row it's on... so if you decide to wake the display driver at row 16, and only want to refresh rows 16-32.. no problemo!

Weird!

And, yet, makes total sense... PDAs were cutting-edge, power-usage was important.

.....

And, here, we've come full-circle to forgotten features that may well exist in newer technologies...

Maybe (weirdly?) the column-drivers in my 1024x768 color TFT laptop display weren't designed from the ground-up. Maybe "blocks" were taken from an earlier STN device, duplicated countless times for so many more pixels, later for *shades*, eventually modified for output to TFT... and maybe something like that could explain why that laptop display seemed capable of writing any rows arbitrarily while retaining the others...

?

?

?

......

...

Many many hours (and a log) later...

I've found a pretty good document from Hitachi (linked in the next log) about LCDs... And, not being an analog-guy, I'd never really looked into the weird "AC" voltage-timings used for LCD segments/pixels... until now. It shouldn't be as hard to understand as it was for me during that hour, but I [think I] did gather one thing from it... *Unwritten*/*unselected* "segments" get drive-signals at the *same* time as the segment[s] being written. What? It almost seems that all pixels on a "common" driver-output get driven with an AC waveform of *small* amplitude (1/3rd, 1/4th the full drive-voltage) at all times... regardless of whether those particular pixels are on or off, and maybe even regardless of whether the common (row) driver is currently selected(?!). IF I understand this correctly, it seems maybe the pixels/liquid-crystals have some amount of hysteresis... A large voltage-pulse (both positive, followed by negative, to remove DC-bias) might turn the pixel on. Then a small AC waveform holds it...(?!). Whereas if the pixel is *off*, that same small AC waveform does *not* turn it on....(?!) Not even some shade of gray?! 

I could be completely mistaken. I'm pretty-durn-comfortable with binary timing-diagrams, but apparently throwing-in a couple additional levels makes it seem incomprehensible to me. HAH! I'll try again another time. This is a great document (1500+ pages! Albeit mostly datasheets.)

BUT, IF I understand that correctly, then that might explain my experience with some [TFT] displays' holding their images even when those particular rows/cols are *not* refreshed (with new/repeated pixel-data)... 

...because they might just be receiving that tiny AC voltage that seems to hold their hysteresized-value (?!)

But then... how on earth could that "hysteresis" idea work with *analog* values (64-256 shades of gray?!)...

Brain exhausted. Another day, maybe...