Project Logs

Collapse

• Extra pixels AS outputs, or display doubling?

  Eric Hertz • 05/19/2021 at 04:06 • 0 comments

  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...

  Read more »

• Random + TODOs?

  Eric Hertz • 02/15/2019 at 08:05 • 1 comment

  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 

• the end of LCD-hacks?

  Eric Hertz • 10/31/2016 at 22:52 • 0 comments

  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
  

  so thought I'd try those Print* functions... and the whole thing rebooted.

  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...

  Read more »

• "DE-Only" displays, no hsync/vsync!

  Eric Hertz • 10/16/2016 at 14:23 • 0 comments

  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.)
  

  (LG Electronics LP121X04)
  

  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"...
  

  (SHARP LQ121S1DG81, 800x600. Has H/V-sync inputs, but apparently ignores them.)

  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...

  Read more »

• Upscaling for TFTs

  Eric Hertz • 10/14/2016 at 15:23 • 0 comments

  (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...

  Read more »

• Ridiculous TV-Board Venture Revisited, potentially

  Eric Hertz • 10/06/2016 at 00:03 • 0 comments

  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...

  Read more »

• Random

  Eric Hertz • 06/05/2016 at 21:23 • 1 comment

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

  And now it does! WOOT!

• Ridiculous TV Board venture FAIL: The Prequel

  Eric Hertz • 11/05/2015 at 04:56 • 0 comments

  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...

  Read more »

• Ridiculous TV board venture FAIL

  Eric Hertz • 11/05/2015 at 04:32 • 0 comments

  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...

  Read more »

View all 9 project logs