Ridiculous [LCD] Display Hacks

Most displays I've encountered from STN through TFT use row drivers and column drivers which essentially are little more than shift-registers... 

Imagine building a 24x16 LED matrix, one way to drive it would be to use five 74LS595's. Three daisy-chained for the 24 columns (Anodes) and two separately daisy-chained for the 16 rows (Cathodes, Invert those outputs).

Now you write a driver for this display, and basically you shift 1 active row onto the row-registers, and shift all the pixels in that row onto the column registers. Then shift the next row to be active, and shift in that row's pixels. And so-forth. The row clock is your Hsync, the column clock is your pixel clock. Vsync is accomplished by resetting the row-registers to the first row (reset the outputs to 0, then shift in one 1).

OK...

Now, imagine you shift in more than 24 bits, say 25, on a row, what'd happen? Well, as I recall of the '595, it'd result in your image being shifted to the right, losing your first few columns off-screen...

BUT: 

Display row/column drivers are designed backwards, for the sake of daisy-chaining, and for the sake of puting the first-received pixel at the left.

So, most I've run into (especially older ones. TODO link an OKI Column Driver) handle 64 columns. The first 64 data bits received are shifted to its 64 parallel outputs. Any bits received thereafter are shifted out of that chip and into the next. Once that second chip gets its 64 bits, it shifts any remaining bits to the next, and so-forth.

Thus, say you have a 128x64 STN LCD, you might accidentally try to drive it with a 64x64 input signal, and... in most cases I've run into it'll work. The image will be displayed at the left, and the right 64x64 pixels will display whatever garbage was in those registers from power-on/reset (and if you believe the hype, those liquid crystals might get unhappy with DC... but, I'm not sure about that, since the AC waveform is separate from the shift-register loading).

Now, here's where it suddenly, this evening, got interesting to me:

If you try to drive that with a 192x64 input signal, it will most-likely handle that just fine, as well. The column drivers don't know/care what's daisy-chained off of them. The first two happily receive and store (and display) the first 128 pixels, then spit the remaining out for the third, which just happens to not be attached. But they don't know that.

So, now.... hmmm....

What if we attached a 74LS595 to the output of that last column driver?

Or... maybe even a second display panel's first column driver?

Alright, so maybe that'd be difficult with today's displays, but maybe not. In fact many displays have test-points.

So, what-say your Raspberry Pi is wired to a 640x480 panel, and you configured it for 800x480, and tapped off the daisy-chain with a bunch of '595s? Maybe even 20 of them!

Now you have up to 160 outputs which can be toggled at 28.8kbps! (480x60Hz) or, little bursts of SPI (output only, of course) reaching 4.6Mb/s...

Could be handy.

Also, it shouldn't be too difficult to tap in a second display with a few trace-cuts and wires on the display itself...

The latter is something I'd been trying to figure out for some time, two displays on a lappy from the single display's input. I don't know why, but my brain was stuck this whole time in trying to use the regular input signals, rather than tapping to/from the panels themselves.

Or, heck, say you just want to add a friggin' indicator LED to your lappy's lid... if 60Hz is fast-enough, forgo the 595 altogether... 

Or maybe you dug out a groovy old stencilled LCD from an old lappy with a HD activity indicator, battery indicator, etc. and want to mount it next to the display. Or even a VFD for such things.... oooohhhh....

Heh, though a lot of that could also be done via DDC. Anyhow...

Oh yeah, this came from my escapades with a TI-86 over at #Vintage Z80 palmtop compy hackery ... the whole point was how to add outputs to a system without any.

...

MWAHAHAHA!

https://hackaday.io/project/179772-vintage-z80-palmtop-compy-hackery/log/193466-inside-the-ti-86

I'd forgotten that older displays often load multiple pixels (usually four, sometimes 8 on huge displays where one half and the other refresh simultaneously) side-by-side simultaneously via parallel data bits for each "pixel load" clock... which might well mean that FOUR LEDs or such could be driven this way with little to no extra circuitry. and, of course, more could be done with four parallel shiftregisters.

This project-page is REALLY random...

Here's Something for later avr-lvds-lcd (why didn't I call that avr-fpdlink? And why do I continue to call it the former despite its now handling a slew of LCD interfaces?):

http://www.electricstuff.co.uk/nanohack.html

Apparently Mike has broken the enigma that is MIPI-DSI, at least enough to drive an old iPod display.

That's a nice screen, as I recall, and from my understanding of Mike's work running it with an AVR may actually be possible.

And then...?

Kinda makes yah wonder about other MIPI-DSI displays... Great starting-point, anyhow.

(https://hackaday.com/2019/02/12/putting-an-out-of-work-ipod-display-to-good-use/)

UPDATE May-ish, 202...1:

ahhh, he mentions 'vertical dithering' which is a trick I thought I invented for avr-lvds-lcd to get 64 'colors' from an attiny85, which can only supply two pseudo-lvds channels (blue/timing and lvds-clock, as I recall) of the four, leaving red and green "pixels" to either full-on or full-off, since they were driven by GPIOs rather than the PWM outputs which can toggle much faster than the CPU clock.

[TODO2, thought-of just now, why use a pseudo-lvds channel for the clock, instead of a GPIO? Oh yeah, lvds-clock is 3 ticks high 4 ticks low during ONE AVR instruction cycle... but wait, only at the fastest refresh rate, which is completely unnecessary for MarioThing which only updates at about 2Hz framerate... hmmm...]

That setup displays HUGE blocks for each "pixel", 16x16 stretched onto a 1024x768 display... so each graphical "pixel" consists of numerous lines of physical pixels... so vertical-dithering is nearly invisible at the normal viewing distances. Thing is, the '85 has far too little RAM for something like this, so more than 64 colors isn't really doable as-is. On The Other Hand: I'd developed numerous image-ram-packing methods for various needs... (e.g. higher resolution at the cost of slower refresh rates)... and hadn't considered vertical-dithering in those other cases... so this is a TODO to consider such things. [Key factor from the vid: vertical dithering COMBINED with high vertical resolution allows for subpixels-ish... e.g. black background with yellow-green feathers, transitioning halfway down what would otherwise be a square pixel... and the sorts of images that would lend themselves well to such low-res-horizontal/high-res-vertical]

Above: 16x16 on a 1024x768 display, refreshing at 2Hz with vertical dithering on red and green channels from full-on to full-off gives 4 shades, each. Slow refresh captured partway down the image as the "question block" "shimmers" between different copper-ish hues, making it look like metal...

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

Above: High-res/low-refresh is NYI on attiny85, but I think it could be, with either fewer colors or dithering... this was an attiny861 as i recall. The image is drawn vertically, bottom to top, the white at the top is where the RAM was maxed-out from too many color-transitions. Each vertical pseudo-pixel is represented in memory as a color and number of pixels packed into each byte. Note how text uses a lot of color-changes, so uses far too much memory to rotate the display to landscape. And the three rainbows of blue almost look the same due to gamma, I guess. That can't really be changed, due to the pseudo-lvds implementation limits....(?) Weird, though, as the 4 shades of blue (as well as red and green) are distributed pretty evenly from 0-100%. Hmmm...

(Friggin google sites doesn't allow linking of images?!)

....

TODO: This project-page could use some serious redoing... the original "project" is long defunct, and this has turned into a bit of a catch-all for my LCD-related projects/ideas...

See also #(VFD) Panel-filter and #avr-lvds-lcd binary-clock 

UPDATE: RIDONCULOUS HACKING to obtain EPG-info via an old tuner, scroll down a bit...

Whelp, there's a pretty-durn-good find, if I say so...

Sitting in the laundry room atop the donation-bin...

Apparently the only things wrong with it are:

A) Batteries leaked in the remote... non-functional until a thorough cleaning

B) Stand is extremely wobbly, touching the on-screen buttons has no effect without grabbing the display from behind for support.

C) The Menu interface is funky... but I think I'm getting the gist.

D) NO EPG!!! How the hizeck am I supposed to plan my day?

Hack-Potential: My digital-receiver I use for my CRT has a serial port hidden in the case... and as I recall the thing actually outputs the EPG-info when it's received... hmm...

-----------

So... yeah... That's *way* outta my budget... 22in, no less... biggest non-CRT in my collection by a good 4 inches. Should I replace my 33in TV? Gain some surface-space? Maybe even hang it on the wall?

Crud, do I understand these newfangled resolution-standards correctly? 1080p = 1920 x 1080? Lessee, my 18incher is 1280x1024, my SGI is 1600x1024... dagnabbit, TV or desktop? Maybe both... sheesh...

Financially, I should probably sell the thing... oy, do I understand this correctly, too? You can buy a screen of this size/resolution for less than $150 new?! Man, how times've changed.

Whelp, some thinking to do, I guess... And now I've got HDMI to go with my new Raspberry Pi Zero!

--------

RIDONCULOUS HACKING:

So, Best I Can Tell, from pressing of 'all the buttons' the best you can get with this TV is a listing of the *current* show, and a description about it. But, no info about what shows are coming up in the future...

So, I've got a "Digital-Stream" Digital-Tuner I've been using for my old CRT, and it happens to have a serial port on-board that I, of course, hacked into the day I got the thing. I got some drawings/test-patterns and even text ('sm_printf', no less!) displayed on-screen a while-back. Pretty cool what can be done with this thing via the serial-port!

I wrote down all my experiments... it takes a bit to get 'sm_printf' working, including stopping the video-playback, as I recall, but it does work.

(Apparently, someone else came up with a pretty in-depth analysis and an awe-inspiring level of hackery, but not the info I'm currently looking for)

There's lots of debug-data, and also a Mini-Shell... typing '?' causes a listing of a bunch of functions which can be called... Debug-wise, whenever new EPG info is downloaded, it shows an update, but does *not* show the info. It's taken a bit of experimenting with a bunch of the functions... but there is, in fact, a way to dump that info to the serial port... The *obvious* one would be 'epg_list', but executing that causes a listing of basically only the channel numbers and whether or not the EPG-data has been downloaded.

So I went through the list of 232 functions, looking for others... There're a couple really obvious looking ones such as 'PrintEit' and 'PrintEtt'... I dunno what an Eit or Ett is, but whenever there's an EPG-table update, it mentions Eit[#]:

[APP tEpgSca 49] 0142 ******** epgEventEitReceived, Eit[6], 8/8 tables
[APP tEpgSca 49] 0142 ******** epgEventEitComplete, rf 39, subch [2] source id 3
[APP tEpgSca 49] 0143 ******** epgEventEttReceived, Ett[0][1], 1/43 tables
[APP tEpgSca 49] 0144 ******** epgEventEttReceived, Ett[0][2], 2/43 tables

Interestingly, it actually shows an disassembly-listing of where it crashed... pretty cool, but beyond me at the moment, and not particularly necessary. Here's a sample, 'cause I think it's cool anyhow:

>[DATA ABORT:4] at 0x0ed2a0(Task tcb:0x2423c4, miniShe ), uptime 1737769 ms <<
>> Program counter at Exception       : 0x000ed2a0
....
        000ed294  ebffbe1a  BL       0xdcb04 == OS_DbgPrintf()+0x0000
        000ed298  e5953004  LDR      r3,[r5,#4]
        000ed29c  e1a04286  MOV      r4,r6,LSL #5
     ** 000ed2a0  e19410b3  LDRH     r1,[r4,r3]
        000ed2a4  e59f00c4  LDR      r0,0xed370
        000ed2a8  ebffbe15  BL       0xdcb04 == OS_DbgPrintf()+0x0000
        000ed2ac  e5953004  LDR      r3,[r5,#4]

Anyways, I went through *all* the other functions one-by-one looking for other such things... Found a few that looked promising, but nothing did the job.

So finally went back to that *most-obvious* 'epg_list' and tried a bunch of arguments... getting exactly the same listing of merely the channel numbers and whether the EPG's been downloaded.

Shell> epg_list <various arguments, e.g. '0', '0 0'>
MiniShell: [epg_list]
call function of '0x0008cf8c'
Dmc_EpgPrintAllTables (id 0, source_id 0)
==== Summary List of all EPG ====
 (0) id 9, num subch 3, 7 sec
     [0] source id 1, 9-1 [K***-HD], #3,  active, 7 sec, Incomplete!!
     [1] source id 2, 9-2 [Vme], #4,  active, 0 sec, Incomplete!!
     [2] source id 3, 9-3 [Create], #5,  active, 0 sec, Incomplete!!
 (1) id 39, num subch 3, 105 sec
     [0] source id 1, 7-1 [K***-DT], #1,  active, 38 sec, Completed
     [1] source id 2, 7-2 [K***-SD], #2,  active, 28 sec, Completed
     [2] source id 3, 7-3 [K*** 3], #3,  active, 37 sec, Completed

call 0x8cf8c result = 0x0 (0)
[BASIC TASK] cmd(25), subCmd( 0)
[MW EA] Monitor Start

Looking more closely, I realized I wasn't using the *right* arguments. Right... Obvious... "(id 0, source_id 0)" shoulda been enough to get it...

Shell> epg_list 39 3
MiniShell: [epg_list 39 3]
call function of '0x0008cf8c'
Dmc_EpgPrintAllTables (id 39, source_id 3)

Print EPG Tables of Ch 39, Subch 0..

 [2] source id 3, 7-3 [K*** 3], #3, active, 37 sec, Completed
   MGT     : 0x32dad4, ver 17
   preMGT  : 0x328c54, ver 17
   TVCT    : 0x328bd4, ver 0
   STT time: 0x4542c3c1, (2016/11/1 Tue 11:43:00 [tz+9])
   EIT-array : 0x43aca4

...ETT-v : 0x32a054
      ETT ETM_id 00030000, event 0, ver 17
         (eng) Address

...EIT-0 : 0x2f93b4 (pid 0x1d00)  ETT-array: 0x2f92c0
      EIT source_id 3, ver 17, 6 events
         event[0]: id: 0x0039, 11/1  9:00:03 ~  9:30:03, ETM 1 (ThisPTC)
            (eng) Roseanne
             (eng) To celebrate Halloween, their favorite holiday, the Conners invite friends and family members over to help them transform their home into the scariest house on the street; Dan and Roseanne become engaged in an escalating prank war.
         event[1]: id: 0x003A, 11/1  9:30:03 ~ 10:00:03, ETM 1 (ThisPTC)
            (eng) Roseanne
             (eng) Roseanne learns a lot about the opposite sex when her lumberjack costume for a Halloween party turns out to be a little too convincing; Dan grows upset when he learns that D.J. wants to dress up as a witch for Halloween.

Cool!

So, am-thinkink: I can have a script running that tests 'epg_list' until it says "Complete". Then, flip to the next station, and do the same... It'll continuously cycle through the channels downloading the lists... Then I could e.g. connect it to my computer and make a little script that'll show a listing of only the times and show-names, but then can get more info about the particular show if I want to... yahknow, kinda like a "TV-Guide"... and... wait, doesn't that exist on the internet?

WEEE!

So that was the first step of ridonculosity-realized.

The next step was... "Well, I'd really rather see it *on* the (new) TV... how can I do that?"

(I'll need a remote to browse the list... we'll come back to that once I've figured out this other stuff...).

So then I'm thinking... well, I could either A) see whether there's a serial port in the TV with such an open UI as this one, maybe so sophisticated I could actually "printf" straight to the screen... But, the level of openness of this guy is *shocking* to me, so I doubt the TV would, as well...

So, other options...?

Spose I could connect something like a PiZero to the HDMI input, or even composite....

Oh Snap. Composite.

Right...? The friggin' Digital-Tuner has all this functionality built-in with a composite output and a remote.

Ridonculosity-2-realized.

---------

Only annoyance, then, is that I'll have to use two different remotes, and change channels twice, but yahknow... (OTOH, now I have two DTV tuners... I could record one show and watch another at the same time!)

Ridonculosity-3-realized: Yeah, I could just look up TV-Guide.com or whatever... But that's not the same. Using the remote is much more comfortable.

The last log got me thinking a bit more about my old display projects (e.g. https://sites.google.com/site/geekattempts/home-1/drive-an-old-laptop-display-from-an-avr and #my very first binary-clock, which I just got working again).

And, I remembered... wait a minute... some displays don't actually USE Hsync... INCLUDING some of the displays where I've actually encountered repeated-rows!

So, some overview...

Some (many?) TFT's these days are "DE-Only"... wherein they don't actually make use of the Hsync and Vsync signals, but base the entirety of their timing on the Data-Enable input. WTF. So, basically, what that means is:

Data-Enable is used to indicate when pixel-data is being written. Unlike CRTs (or VGA-interfaced LCDs) which have to guess the location of the pixels based on the horizontal-porch-timings, most bare LCD panels (like found inside your laptop/TV/monitor) have a Data-Enable input which *tells it* when pixel-data is coming-through. Thus, basically, the rising-edge of DE indicates the first pixel in the row, and the falling edge indicates when the last pixel in the row has been drawn.

(Oh, by the way, also unlike CRTs, LCDs *usually* have a pixel-clock... CRTs usually *don't*... look at the VGA pinout, no pixel-clock! If you've got a VGA-interfaced LCD, then it most-likely has circuitry inside to recreate a pixel-clock for the LCD panel.)

You can guess, then, that Hsync (and specific-duration H-porches) are unnecessary, when using DE... Instead of paying attention to Hsync, just look for DE going inactive, then reactivating... that indicates a new row.

And some displays do just that, completely ignoring the Hsync input. ("DE-Only" displays).

The interesting bit is that Those Displays (usually) actually ignore the Vsync input, as well.

Wait, what? How does DE indicate that...?

So, my guess is that somewhere in the display's circuitry there's basically something like a counter... That counter says "OK, I've received X number of pixel-clocks but no pixel-data, so we must be doing a new frame"...

Arighty-then... It's not *that* complicated... A *really* simple implementation might be to say something like... Say we've got a 1024x768 display... normal 1024x768 timings (e.g. sent to a VGA monitor) may have an h-porch of up to 1000 pixels, so if there are, say, more than 3000 pixel-clocks between Data-Enables, then consider it a new frame.

Of course, every display is going to implement that differently... One might be 3000 pixel clocks, another might be 30,000 (v-porches may be in the hundreds of rows, and rows may be thousands of pixel-clocks).

Or, another way it might be implemented is simply by the DE-detection circuit's knowing exactly how many rows are on the panel... Simply count 768 DE-actives, then restart at the top. (That could get complicated if the LCD-panel is turned on *after* the signal starts... (or if the PLL in the LVDS-receiver doesn't sync until after a few rows of data) how would it know where the top is...? Again back to the counting inactive pixel-clocks).

....

But the oddity discussed in the last log... an oddity that I've seen (and kinda want to take advantage of), the repeating of rows... I've seen it on DE-Only displays... How's that work?

Again, with a Hsync/Vsync display, it would make sense that e.g. strobing Hsync Twice might not allow for the column latches to load a new row of image-data, so they probably still store the previous row's data... So two Hsyncs would advance the row twice, but no new data would be loaded, so two rows would display the same data. (see the last log).

But, with a DE-Only display...? Who knows... That display ONLY looks at the DE-signal, ignoring Hsync, completely. One possibility, maybe... Say DE is usually active for 1024 columns (1024 pixels in a row), then say it's only active for *1* pixel the next time around...

Another possibility, now that I've written/revised this a few times, I think I remember seeing this: What happens when DE is active for *far too long*... For *longer* than one row's worth of pixels...? Somewhere in there, again, there's a counter. So when the DE signal is active for too long, eventually the DE-detection circuit's counter might overflow, causing a row-advance, but the column-latches themselves still contain the data from before, causing a repeated-row. Unfortunately, this "method" wouldn't lend itself well to my most-recent plan of doing real-time framebuffer-less resolution-upscaling :/

I haven't experimented with it to the extent to make it repeatable. But I have *definitely* seen repeated rows, and I'm certain I've seen it occur on DE-Only displays, as well. So... The question becomes... is that something that can be characterized to the extent that it can be made use of?

This is where it gets complicated... Because different DE-Only displays *probably* implement their DE->row-advance->frame-advance detection-schemes differently. Atop that, the manufacturers have very little (if any) reason to *document* that scheme, since the important thing in the *vast majority* of cases is that it works with a single "native" signal-timing that happens to match-up with a typical VGA-timing-scheme... Long LONG horizontal porches, Long LONG vertical porches... ("long" when compared to what's necessary for a digital circuit such as the horizontal/vertical shift-registers in an LCD).

So, it may be possible to figure out how to repeat a row on one display, but that scheme may not work for another.

FYI, here's one of the most-detailed diagrams of a display's internal-workings I've seen documented in a display's datasheet:

(LG Electronics LP121X04)

Not much to go by, there, for hack's sake... guess you've just gotta experiment :)

(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

a snippet from a log at #sdramThingZero - 133MS/s 32-bit Logic Analyzer...

Wherein, I've ordered a Raspberry Pi Zero, and realized I don't actually have a functional display with an HDMI/DVI input...

As you may recall from the previous log-entries at this project, I went a bit crazy in trying to turn an old 15in VGA-input LCD computer-monitor into a multi-input display, by attaching an old plasma-screen's TV-Tuner/Video-processing board...

It worked, sorta, I'll leave the details to the previous logs. But the gist of it is that A) That screen doesn't have speakers, and more-importantly B) The color-bits output by the TV-Tuner board aren't aligned with FPD-Link (the monitor's input to the panel), so, as I recall, where FPD-Link expects the highest bits, the TV-Tuner is outputting its lowest bits. No, that doesn't quite make sense, does it...? Something like that, anyhow. The end-result was that by adjusting the brightness (on the TV-tuner) to 0, the image is about right, but not quite.

-------

kden.

-------

Further, I've got a project coming up which needs the circuit (poorly-) converting between the TV-Tuner's single-pixel output and the dual-pixel FPD-Link... Those chips are spendy, so I'd rather not build another, especially since that circuit was designed for the purpose it will be re-re-purposed back to, and only *barely* works with the project it's currently being (re-)purposed for.

Oy, describing these ridiculous display-conversion "adventures" usually seems to be quite difficult.

Anyways here's what I wrote at the log:

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

One realization re: PiZero: Yeahp, I don't have a screen with DVI/HDMI input... I think I can hack something together, but it'll definitely be a hack. At one point a couple years back I did a DVI -> FPD-Link converter, it should probably work, but then I need some adapters from Micro-HDMI->DVI, or something... And the micro->HDMI converters were cheap at that place, but not in stock (figures). We'll see where this goes. Oh, and I finally managed to dig out the fluorescent-tube used in #my very first binary-clock (and many other projects, prior)... turns out the ground-wire got ripped from the tube, but luckily the tube is in-tact as well as the solder-point. FHWEW! So, DVI->FPD-Link may be "the path." Alternatively, I have another LCD display to which I once attached an old Plasma's TV-Tuner board... (which also happens to have HDMI inputs). #Ridiculous [LCD] Display Hacks It's a bit hokey (some of the color-bits are misaligned), but pseudo-functional, and maybe worth fixing-right. Oh, and I might be acquiring a "new" PowerBook G4, from a generous (and extremely patient) donor, to replace the old one, whose motherboard died... which means I'll be needing the Single-Pixel-to-Dual-Pixel converter I'd repurposed for the Plasma->LCD converter, to install that 1400x1050 display back in the new PBG4 (1024x768 is painful!)... So, maybe I'll be needing another of those converters. Those chips ain't cheap. Oy. Oh yeah, and I'd need to redesign it slightly to remap those color-bits... if I wanted to do it right for the Plasma->LCD converter. Weee!

no... dagnabbit... if I'm already building a new circuit, rather'n just soldering up a prebuilt PCB... then the logical-conclusion would be to work it for the *other* LCD display, which just happens to have speakers. So, I'd need... Well, that display is dual-pixel, as well, but dual-pixel *parallel*... the TV-tuner board is single-pixel LVDS-output, with, again, a weird color-bit-mapping. So... I gotsta get an LVDS->Parallel converter (which, actually, I think I have a few, just not the ones the *other* board was designed for, savings: $8). But, then, I need to convert the single-pixel parallel-data into dual-pixel *parallel* data... which would need... a couple 8-bit D-Q latches... No, wait... a couple *for each color* (so six) (and I just happened to invest in a bunch of 574's), and... Hmm, something to divide the pixel-clock in half... another D-Q latch should do... Maybe an inverter or some other glue-logic... I might actually already own all the parts I need, only major problem is the tiny pin-spacing of the LVDS-receivers... Don't *really* feel like designing a PCB for this one-off ridonculosity. (we'll call it "art"). Oh, maybe I can get away with only 3 8-bit DQ latches... Why didn't I invest in some 50+pin TSSOP breakouts...? Ah, but there's a TQFP-100 breakout I could cut in half, and only have a few pins hanging on each side to be dead-bugged... Only thing is, how do I assure that it always picks up the *first* pixel on the latch...? (how many pixel-clocks does the receiver take to sync its PLL?). Guess I could throw in a button to inject a pixel-clock (or a few dozen, with bouncing and all) if it's not synced properly...

So, if I've got this straight, I should be able to take an old 15in VGA-input LCD monitor with built-in speakers, and cludge-together a converter to connect an old (dead) plasma-TV's TV-Tuner board... 15in 1024x768 with two HDMI inputs, TV-tuner, VGA (via RCA-jacks!), a couple composite inputs, and a few other doodads. And... then I'll have something I can connect to the $5 PiZero.

So, how do I determine the color-bit mapping...? I *know* it's non-standard, as I spent quite a bit of effort fiddling with the brightness-settings (really low) to get it working with a standard FPD-Link display... So those high-bits are mis-located, is the logical conclusion. I suppose I could drive it with an HDMI source, 'scope the outputs of the LVDS->Parallel chip when driving it with, say, specific RGB-values (plausibly via GIMP?)... But, then, do I need to worry about whether there's color-correction going on via the OS...? Oh, and... I don't actually have a video-card with DVI/HDMI... Though, the "new" PBG4 does... so, hmmm.... But, then, the TV-Tuner has its own color-"correction" via brightness/contrast, as well as temperature, and more... so, realistically, quite unlikely I'll find a 1:1 mapping from in to out...

HTML-editing doesn't exist on a hacker-site?!

And now it does! WOOT!

Crazy ramblings written prior to the decision to take on the Ridiculous TV-Board Venture [FAIL] in the previous log...

Yesterday: pulled apart three LCD displays in an attempt to fight through brain-mush, didn't work, and ended up with a bunch of precariously-placed piles of parts that needed to be put back together before the cat got to 'em. Though, discovered that the one 15inch VGA display that had parallel signals was, in fact, dual-pixel. Which I should've remembered, since I designed an AVR circuit for it a couple/few years back that ended up being the basis for one of my longer-running and most highly-developed projects.

Thought maybe that display's housing could house the dual-pixel LVDS display's screen; since this housing has speakers, it'd be better-suited for the TV-board... But the screens' mountings were not at all the same dimensions, and the LVDS screen was actually larger than the spacing of the speakers. So, nogo.

So, now... Decided it was a sure-sign I should make use of my old Single-To-Dual-Pixel-Converter project... the one I had hanging on the wall. Traced out the display's pinouts (CCFL inverter, as well as the LVDS signals/power)... Went to grab the converter off the wall... and sure-enough two rather important wires are dangling, pins ripped from the chip. Alright, that was the prototype, I had another on a PCB that was functional at one point... couldn't remember why I went-about making the third circuit (second PCB) except that I did a better job of it and managed to squeeze out a couple more MHz for a higher refresh. So, that first PCB may be an option... And there it is dangling off the original deadbugged prototype (how'd I miss that?). And despite being soldered on a PCB, somehow it seems I managed to rip a couple pins out of the TQFP... Again, a couple *important* pins. So that one's a nogo, as well. Just art, at this point.

So, where're we at...?

Dug through all my (relatively-recently-acquired) parts supplies, don't have any more of either of those chips (though I do have a couple bare boards, I think). I do have *other* chips, which... well, no, they wouldn't work on that PCB at all... And switching from single-pixel to two single-pixel transmitters in dual-pixel mode, well, it may not really be that conceptually-difficult... What, maybe just a clock-divider and inverter? Oddly, the LVDS-display's VGA-converter circuitry uses a bunch of 74x574's (latches)... maybe that's necessary... A conceptual challenge that might be interesting, anyhow. But I don't have any... what're those chips, they're TQFP spacing, but two rows, rather'n square... SOIC? Anyways, no breakout boards for 'em, and while I might be willing to cut up one TQFP breakout board for One of these chips, I don't, currently anyhow, have the patience to do *three* of them. So, there's that.

Then... Well, it occurred to me...

That video-card I'd been fighting with, to get multimonitors... The ridiculous endeavor that was... wherein a year ago I made an adapter to make that special monitor work with a regular video card... and then this year decided to use this specialized video-card (made to work with that monitor) work with a regular-old monitor... Yeah, that video card...

Well, now that *that* video card has been hacked-apart for that monitor's adapter, there's... low-and-behold... a single-pixel-parallel-input to dual-pixel-LVDS-output daughter-board sitting 'round doing nothing... Nicely, it's made of standard parts I can easily figure out the 24-bit input pinout... So now all's I need is a single LVDS->Parallel adapter chip, preferably on a board... could use one of those cut-TQFP breakouts...

And then...

Wait, lest I forget again, part of this was leading to... Duh, there's the single-to-dual converter that I was using in my old laptop, which... well, I'll come back to that.

So, there's the old specialized video card's uber-special daughter-board that does basically what one chip on my single-to-dual-conveter did, which I could rebuild if I just had the chips (and I could probably order samples, after all). But then...

What if I want to use this specialized daughter-board with something else...? Maybe I'll put it *back* in the specialized-video-card so I can drive my old/dead laptop's screen with the wacom attached behind it, so I can finally get to some gimping...

So, spent a bit trying to figure out if this specialized video card I fought for days getting working alongside my built-in video card could handle dual-head configuration, separate images on the VGA and LVDS outputs... (and, if it does, does it support other resolutions on the LVDS-output than the one it was designed for?)...

Anyways, no dual-head. But in the process of trying to find that out, was reminded of my Matrox card which I tried to do multimonitors with first, which didn't work, but wasn't *really* tried before I remembered this one... so then had the brilliant idea of trying to put the "specialized" video-card's daughter-board into a normal-old Matrox card which just happens to have a daughter-board upgrade option (which I don't have) for DVI. Which, most-likely, takes 24bit parallel RGB, which is the input of this daughter-board.

Whew... So... At this point, we've got:

Video Card A was designed to work with Monitor A
Monitor A has been adapted to work with Video Card X (any with VGA) at the expense of Video Card A's specialized circuitry which enabled it to work with Monitor A in the first place.

Video Card A has been repurposed as a regular-ol' (VGA) video card, and is now connected to Monitor B (a regular ol VGA monitor).

Video Card B is a regular old video card (VGA) that could potentially be wired-up with Video Card A's parts to become.... a lesser version of Video Card A's original specialty.

Do I have this right?

Wait, and where's this leave us...?

Oh, so then Video Card B, which is now basically just like Video Card A was, could be used to drive my old laptop's display as a graphics-tablet. OK. Whwew.

"Why don't you just..." OMG WHY. DON'T. I. JUST.

Alright, I think I could wrap my head around readapting Video Card A back to its original purpose *IF* it can drive my graphics-tablet... BUT it might be specially-designed for 1600x1024, whereas the graphics tablet's screen is 1440x1050... MAYBE it reads the EDID, but maybe not... because, what makes it special, is that it has a BIOS-hack to allow for the screen's native resolution (1600x1024 is the only screen that ever used that connector) in various modes (e.g. text mode, or scaling for lower resolutions). So, there's that.

Where's this leaving us...

I went to tremendous effort to get that specialized 1600x1024 (ONLY) display working via a custom adapter with regular-ol'-VGA, so it'll work in text-mode, etc... and, more importantly, not be limited to just one computer (could, now, work with any computer with VGA, through a KVM, etc.). But, now, I have a regular-ol display that could do the same (only slightly smaller resolution, 1280x1024), so I guess, really, I needn't *keep* this special display generic... could put back together the specialized video card, and everything'd be back to normal, right...?

Wait, there's the graphics tablet, which still needs... bah, the VGA converter I hacked for the 1600x1024 display would probably work just great with 1440x1050, huh.

Yeah, I just can't wrap my head around taking that thing apart. But, again, I could buy a new one for not too much money... and it wouldn't even need to be hacked... but I don't have "not too much money" so there's that.

Alright. Where are we...?

I ain't changing Monitor A, nor its converter, dammit! If nothing else, it'll still be usable when Video Card A is no longer supported (which it already appears to be being phased out, judging by how much effort I had to go through to get it to work on my system). OK, that's settled.

That leaves us with:

I don't have a vid-card with DVI, so I can't use my already-built DVI->dual-pixel-LVDS converter...

(but that *does* have a single-pixel parallel to dual-pixel LVDS chip in it, and it's not *difficult* to remove... but I have this single-pixel-parallel to dual-pixel LVDS daughter-board which isn't being used... oy.)

Where are we now?

Graphics tablet...

Why don't I just fix my old friggin' laptop...? It'd be nice to sit on the couch again. Sheesh.

Graphics tablet...

If I went that route... The friggin' screen ALREADY HAS the Latest Functional Single-To-Dual LVDS converter attached to it, that was the whole reason I built the dang thing.

But, if I connect the "dang thing" to my desktop... I need to make a friggin' list, or a chart, or something... this is getting ridiculous. No, it was ridiculous when I started, it's ridiculously ridiculous. "Ridonkulous"

Alright, to connect the graphics tablet to the desktop: Either the desktop needs to output LVDS (single or dual-pixel, depending on whether I use the converter), or the display needs a VGA converter (which is currently hacked to drive Monitor A). Or I need a video card with DVI and use my DVI->LVDS converter...

The LVDS method can be accomplished with Video Card A's original daughter-board, plausibly attached to Video Card A. If not there, then in Video Card B, with a nice ol' hack-job. OK.

The VGA method I can't afford. (I ain't scrapping Monitor A's converter!)

The DVI method I can't afford.

That leaves...

Why don't I just fix up my old laptop...?

OK, the LVDS method...

If I use Video Card A's daughter-board (or take apart my DVI->LVDS converter), AND [[Video Card A works with different resolutions] OR [Video Card B can be gotten working with it and multimonitor support]]. Then, I have dual-pixel-LVDS output, which will work directly with the graphics tablet's display... no need for the single-to-dual LVDS converter I originally built for it.

THAT LEAVES the single-to-dual LVDS converter for my TV-board to drive my dual-pixel 15inch LVDS desktop monitor.

Right.

OR if I fix up my laptop, then I'll *definitely* want to keep the single-to-dual-pixel converter in it...

The graphics-tablet idea would be nogo, but I could implement that *in* the laptop, as was the original plan (and mostly accomplished), and could probably even use something like VLC, VPN, no, what was that thing... whatever, could probably use a remote-desktop type protocol to use the laptop as a graphics tablet for my desktop, if I wanted. (VNC!) So there's that.

I'd *certainly* be more comfortable writing something like this if I had my feet up on the coffee table, instead of sitting at a desk.

So, then, the "TV-board" idea still requires single-to-dual conversion...

Oh, and the graphics-tablet idea *not* being driven via the desktop with LVDS makes for no need for ... ugh.

Or I could put the graphics tablet's digitizer behind a 1024x768 display, instead... those're single-pixel LVDS, which could easily be driven by one of those cheap ol' VGA-LVDS converters. But if I'm putting money into this (which I don't have) then I might as well up it a few bucks and get another 1440x1050 display (nevermind all this ordeal would be unnecessary). But, anyways, that'd otherwise require LVDS output from my desktop, which could necessitate either single or dual-pixel depending on the display, which my DVI->LVDS converter could handle switching between...

AND HERE is where we come to one of my project-ideas of a while-back, the whole point of standardizing on a couple "IDE-Cable" pinouts for LVDS and parallel-RGB, the idea of easily-swappable and adaptable converters between various video-formats... even have half-finished PCB designs laid-out.

Anyways, my old laptop *does* have DVI, which is why I built the DVI-to-LVDS adapter... and having the graphics-tablet screen be *separate* from the main screen is kinda nice (penning on a laptop's hinge is kinda wonkey).

Wherein I'm completely exhausted, and didn't come to any conclusions about which path to take.

Kinda just want to put my feet up... but feel like I need to see *something* working, or I won't really be able to relax.

Hope it's as funny to read as it was to write, anyhow.

Oh right! I've got a fully-functional Single-to-dual LVDS converter in my dead laptop... No reason I couldn't repurpose it "temporarily"... hmm... Could even attempt laptop-repairs with an old screen that doesn't require the converter...

Spent several days' efforts on adding my TV-board to one of my old 15in monitors...

Long-story short (actually wrote a long lead-up, but didn't post it yet). NEW: It's Posted: https://hackaday.io/project/8146-ridiculous-lcd-display-hacks/log/27559-ridiculous-tv-board-venture-fail-the-prequel

Long-story short, ended up installing it in (more like *on*) the one that has a dual-pixel LVDS display (as opposed to the other, which has parallel-RGB-input).

The TV-board outputs single-pixel LVDS, so I made use of my single-to-dual converter... Finally another use! And (once I found one that didn't have a pin ripped out of the TQFP) it worked right off the bat, AWESOME.

So, that was the first day or so...

Then, I don't know how many days it's been since, but I mounted the board, rewired all the power, got it all closed up. It's not *completely* finished; there's still the buttons and the IR-detector which need to be mounted somehow... (Well, and something about speakers... but that's another venture). But, basically it's darn-near finished... and all that hardware-hacking was a bit of an ordeal. (Oh, I blew out a mosfet I added to switch the power to the display by rewiring the display's power backwards WHOOPS, but the failure certainly could've been much worse, blowing the display rather'n a mosfet!)

So after days of hardware hacking was finally near completion I plugged it in, thought I'd kick back and veg out in front of it for a while, let my accomplishments soak in...

And noticing some strange brightly-colored pixels in the menus. What's that?

OHHHH YEAH.....

I had this connected to an old single-pixel laptop display, previously... same resolution, so basically the only non-cosmetic changes are mounting-hardware and some connectors.

And.... Yeah...

I fought this bright-pixel issue on that display, too... and I didn't exactly *forget*, because when I planned to use the *other* monitor (the one with parallel RGB), I actually considered this "ohhh-yeah" factor in initial design-contemplations...

So what is this "ohhh yeah..." factor?

Well, the TV-board apparently outputs the bits in a different order than the de-facto FPD-Link bit-ordering...

The de-facto FPD-Link/LVDS standard has the first three LVDS channels dedicated to the 6 (highest) bits of each color. That accounts for 18bits per pixel, which is pretty common. A fourth (and possibly fifth?) channel can be added that usually carries two lower bits for each color. That way, if you connect an 18bpp display to a source that outputs 24bpp, all you have to do is leave the fourth channel unwired. The lower two bits, then, are just ignored... same as val_6bit=val_8bit*64/256 (in integer-math). Pretty smart, really. And they make connectors with that in mind.

However, FPD-Link, as I recall, doesn't exactly *define* the actual bit-ordering for the colors, it's more of a suggestion.

And, here, it seems, the TV-board outputs it differently... I haven't actually broken out the signals to determine for certain, but my old experiments had me turning the "brightness" (not the brightness of the backlight, but the brightness of the RGB-data) down to some small percentage. Having done-so, the image from most video sources looked fine. However, the menus always apparently displayed at the normal brightness, which resulted in gradients that suddenly jump from, e.g. black to dark-blue, then suddenly jumping to bright-blue. Looks *awesome* in anti-aliased fonts (i.e. completely unreadable)! And then, when there's a gradient that's not a single color it's even weirder, e.g. black to dark-gray-blue and suddenly jumping to bright red, or something.

Anyways, it looks awful.

The "brightness" fix worked pretty well for video-sources, but the contrast has to be just-right, as well. And even then there'd be an odd "bright" pixel where it should've been dark, and low-contrast... And then there's the On-Screen-Display stuff, like the volume adjustment indicator, and stuff that were barely readable. It was a cludge, and barely usable at the time of the old display; in fact I used the Composite output on the TV-board to feed into my regular CRT TV and used the attached LCD only for navigating menus (as they aren't displayed on the composite output).

So, the failure, I guess, is a weird one... I knew this was a problem, I even considered it in early planning of this project... Not sure why I even went with the dual-pixel LVDS display and my adapter, rather'n making a different adapter for the parallel-display (where I could've rewired the bits, appropriately). Nevermind the fact that display has speakers built-in. Dumb. And all that friggin' time modifying the housing, rewiring all the power-circuitry, and plenty more... and still no speakers anyhow! But for whatever reason that's the path I took, and spent *days* at it, thinking I was only a few minor steps from totally-complete, before the fail I'd already predicted and somehow forgotten made its appearance.

And now... I dunno, it'd be a bit of effort just to get that display functioning like it used to (VGA input); have to resolder some wires I cut, and a few other things. Also a little bit of work to get the single-to-dual adapter back to functional for its old use... (Oh, and, apparently the Tuner aspect is a lot weaker than I remembered, as in non-functional, WTF? That's what I used it for with the last display. Heck, before the old LCD was added, I'd used it as a digital-tuner for my CRT long enough to have memorized the menus I couldn't see... Weird.)

Suffice to say, it's all been shelved for a while. Three previously-useful/functional systems now basically unusable in their current franken-state.

Realistically, it shoulda been installed in (on) the other display from the start, what's a TV without speakers?