(Update 10-16-16: DE-Only displays, see the next log!)

I've been contacted, recently, about a potential upscaling project... wherein one might wish to display e.g. 640x480 on an 800x600 TFT.

So, the obvious solution is to use some sort of scaling processor... an FPGA, etc. with enough memory for a single input-frame (or maybe even enough for an output-frame?).

Thing is... TFTs are (or can be) pretty simple devices...

You've got a bunch of shift-registers at the top, for horizontal-driving, and a bunch of shift-registers along the side for selecting a row.

You clock-in a row's worth of data, then clock that "Hsync" input, which essentially advances the vertical shift-registers.

Pretty simple.

I've actually run into LCDs where you can *repeat* a row by, as I recall, double-clocking those vertical-shift-registers. (Double-pulsing that Hsync input).

Because, I think: The horizontal shift-registers are... shift-registers. They hold the value last-written to them. So, by pulsing Hsync twice, it ends up just shifting that vertical-shift-register, but NOT reloading a new row to the horizontal-shift-registers.

Cool.

So, if that was *reliable*, if LCD manufacturers documented their displays *to that level*, it would be *easy* to scale from e.g. 640x480 to 800x600, just have a slow (8-bit AVR should be *plenty* fast enough) processor watching the input Hsyncs and for every 600/480 lines, double-pulse the output-Hsync.

Scaling Horizontally...? Equally easy. Drive the LCD panel with a pixel-clock 800/640ths faster than the input pixel-clock. There might be a slight flicker where a physical output pixel is located at a data-transition between two input pixels, but that's not entirely different than most scaling, e.g. on VGA LCD monitors.

MOST bare-LCD panels I've worked with have *no problem* working *way* outside the specifications in their data-sheets. E.G. they usually specify timings for 60Hz refresh-rates... and yet I've driven displays all the way down to 1/5Hz... yeah, that's where the screen is refreshing once every *five seconds*. There you get some oddities, the pixels begin to fade, etc.

But, here's the deal... TFT (Thin Film Transistor) LCDs *inherently* have *memory* at *every single pixel*... It's a bit like having a DRAM-based frame-buffer *built into* the display.

And, there's a built-in line-buffer in the horizontal shift-registers.

And, again, unlike most older display technologies, LCDs' interfaces are *inherently digital*... There's no *need* for timing-generators. Remember, old CRTs had to create "Ramp" functions for the vertical-syncing... But with LCDs there is no ramp-function, there's just a shift-register with a clock-input. One could, plausibly, clock those inputs at any rate one desires... Even, sporadically.

Similar for refresh... There's no reason a TFT LCD *has* to be refreshed at 60Hz... the internal memory at every pixel can usually hold a value for hundreds if not thousands of milliseconds. You *could* refresh at 1Hz, if your application worked that way.

There's no reason these displays *couldn't* be interfaced like that, except that they don't *specify* these sorts of things, because it's a highly unusual use-case.

And, realistically, it wouldn't be *that* much more difficult for displays to have an interface *like* DRAM (row/column addressing).

And yet, we treat these things like CRTs... they're spec'd as though they have to have steady timings. Horizontal and Vertical porches, and more... which, really, are only necessitated by the characteristics of their shift-registers, but *not* by the characteristics of e.g. sync-regenerators, and "ramp" circuitry those specs were originally designed for.

And... what does that mean...? To be within documented-specs, scaling from 640x480 to 800x600 requires a frame-buffer, timing-generators, and more. Basically, an embedded computer is necessary to do something that simple... something that *could* be handled by the hardware *already on* the LCD-panel.

--------------------

Here's one of my old projects... this literally uses an AVR microcontroller and a couple 7400-series XOR gates to directly drive a 12.1in laptop LCD. The refresh-rate is something like 2Hz.

https://sites.google.com/site/geekattempts/home-1/drive-an-old-laptop-display-from-an-avr