INTRO:
First and foremost:
NO You Will Not Be Able To Drive Your Laptop Display At Its Full Resolution, 60Hz Refresh-Rate, And Full Motion Video Directly From An 8-bit AVR Using This Technique.
If you want to do that, look into a Raspberry Pi, or something... Run linux, or something... I hear there are even Mini-ITX boards that have LVDS-output. Look into GPUs with 8-bit interfaces (yes, they exist... Epson has some, I have 'em in my collection)... Or think about making your own with an FPGA... There may even be some ideas floating around this site, regarding these ideas, though I'm certain others, elsewhere, have more thorough explanations.
Another Project of mine, can implement fast refresh-rates and full-resolution, full-color (but not full-motion video) by little more than the addition of an SDRAM DIMM... (see SDRAMThing - "Free-Running").
This project is about seeing what *is* possible with basically little more than an 8-bit AVR and an old laptop display... using as LITTLE hardware as necessary.
This means pushing *quite a few* limits...
Overclock that AVR
Use PWM (and dead-timers) to simulate FPD-Link
Use (ancient) TTL chips to simulate LVDS drivers
Use the PLL timer (only available on some AVRs)
Run at *really low* refresh rates, taking advantage of TFT displays' inherent memory
Run at *really low* FPD-Link bit-rates
Stretch that TINY memory! (512Bytes is barely enough for 22pixels by 22pixels!)
Q: Will this work with XYZ-display?
Plausibly.
So far, each display I've tested (excluding one, which died a mechanical death early in the process) has been ultimately made-to-work with this system, with varying results...
The PROCESS of testing out/calibrating a new display is not easy... I know what I'm doing, I wrote the code... and it still takes roughly two full days' work to get an untested display working with this system. We're pushing *all* the limits.
Q: What's the maximum Refresh-Rate I can expect?
let's just do some *really quick* napkin-math, here...
LVDS uses 7 data-bits in each packet...
The "pseudo-LVDS" method, implemented here, uses the AVR's PLL-timer, which *at best* can run at roughly 128Mbps (it's spec'd for 85MHz).
With a 1024x768 display, *disregarding horizontal/vertical blanks, for math-simplification* that means Roughly 1million pixels... 1 million *LVDS Data Packets* must be sent for each screen-refresh.
At 128Mbps/7bitsPerPixel ~= 18 million pixels/second = 18 frames per second.
AT BEST: You'll get 18 screen-refreshes per second, if everything overclocks well, etc.
NOTE: Of Course: the AVR isn't running *nearly* fast-enough to actually *load* new pixel-data for each pixel...
Let's say we're working with this 18million pixels/second... but the AVR's running at only 16MHz... If, somehow, you think of a way to load each pixel with nothing more than ONE CPU instruction, (and that's a TREMENDOUS stretch), that means, at-best, 16/18 of the original 1024 (horizontal) pixels could be individually-controlled...
(910 "AVR pixels" would be stretched across the 1024 screen-pixels)
THIS IS A STRETCH.
Also, doing-so might interfere with the LVDS data-packets themselves, as the packets do not align with the CPU cycles.
Q: What's the maximum Resolution I can expect?
This question is a bit... complicated.
First of all: Are we talking about the display's native-resolution, or the AVR's resolution? See the corresponding questions...
Q: What's the maximum LCD Display (Native) Resolution this will work with?
There's no real limit, here... My displays happen to be 1024x768... they just happen to be the ones I've acquired.
But, keep in mind the type of napkin-math used in "What's the maximum Refresh Rate?"...
In General: Each LCD pixel *must* be sent as an individual LVDS packet, so increased screen-resolutions obviously mean decreased refresh-rates, and so-on. Some displays flat-out *will not work* at extremely-low refresh-rates. This is part of the fun of experimenting.
Note, also, that high-resolution displays generally have two LVDS "channels"... They send Even and Odd pixels on separate but otherwise nearly-identical channels. For these so-called "dual-pixel" displays, it might actually *reduce* CPU overhead, by connecting these two channels *in parallel*. E.G. my laptop's dual-pixel 1440x1050 display could appear, to this system, if wired properly, as a 720x1050 display...
Q: What's the maximum Resolution I can achieve?
This is the more-complicated question... This isn't about the DISPLAY's (native) resolution. It's about what's the highest resolution we can *draw* using the AVR. And, this question is further complicated by the fact that it depends on your goals.
The *simple* answer is that you can only achieve as much resolution as the AVR has memory for... You've an AVR with 512Bytes of RAM, then there's no way you can possibly achieve a higher resolution than sqrt(512)=22x22 pixels... right?
(Note, many of the experiments, here, have been 16x16, which also allows for the RAM to be used for other purposes!)
But, why should we limit ourselves to the memory...? What if we simply wanted to draw alternating pixels of black and white...? We don't need a frame-buffer for that... Or the frame-buffer could be bitwise instead of byte-wise, etc. Or any number of other things...?
This is where you can get clever.
I've come up with a few different methods to stretch the drawing-resolution way beyond the memory-limitations:
frame-buffer (uses 8-bits per pixel... 16pixels by 16pixels = 128Bytes, 22x22~=512B... exponential!)
row-buffer (loads each row before drawing... 128Bytes = 128 pixels horizontal, unlimited vertical)
row-seg-buffer (loads each row before drawing... each "row-segment" consists of a color-value and a number-of-horizontal-pixels.)
Q: What's the maximum color-depth?
The "pseudo-FPD-Link"/"psuedo-LVDS" technique I've come up with--using the PLL timer and dead-timers with PWM--limits the color-depth to 2 bits per R/G/B... that's 6bits per pixel or 64 colors, spanning the standard scheme... each step in R/G/B is roughly 1/4th of the brightness.
There are several ways to switch this up, creating entirely different color-palettes, some with as many as 216 colors. These haven't been experimented-with to too much extent, as the palettes don't cover the standard range.
Other color-depth improvements also exist, such as "row-dithering" which alternates colors on each row, for e.g. low-resolution images.
Note that: e.g. the ATtiny85 only has enough PLL-Timer outputs to handle the FPD-Link TIMING signals, and therefore Red and Green shades are handled *exclusively* by row-dithering, while still simulating the 64-colors.
Q: What 8-bit AVRs can be used?
The "pseudo-FPD-Link/LVDS" method *requires* a PLL-timer and "dead-time-generators"... These are only available on certain AVR devices, including the ATtiny85, ATtiny861, and AT90PWMxxx-series.
This software has also been modified for interfacing with *parallel*-interfaced displays... These *most likely* will *not* come out of an old laptop, but maybe an old desktop LCD monitor... In this case, any AVR can be used, with appropriate software modification.