I’m always on the lookout for a quality addition to my lab that would respect my strict budget. Recently, I’ve found myself pushing the Hertz barrier with every other project I do and thus desperately desired a high bandwidth scope. Unfortunately, only recently have 70 MHz to 100 MHz become really affordable, whilst a new quad channel oscilloscope in the 500 MHz to 1 GHz range still costs a fortune to acquire. My only option was to find an absolute miracle in the form of an old high bandwidth scope.

It seemed the Gods of Hand Me Down electronics were smiling upon me when I found this dumpster destined HP 54542C. It appeared to be in fairy good shape and was the top canine in its day. but something had to be broken right? sure enough, the screen was clearly faulty and illegible. want to know how I fixed it? four letters: FPGA.

Problemet
Some shallow research on this scope revealed some interesting history. This was supposedly HP’s first high end  scope with an LCD and was also the precursor to the Infiniium series of scopes that would go on to guideline the market. The LCD did feel like an afterthought though. The scope had an otherwise similar variant with a CRT display, and the version I acquired simply had the CRT digestive tracts eliminated and a colour LCD installed by HP. I hoped the LCD was at fault and not the ASIC’s driving it, this seemed like a good bet as a gentle tap would in some cases bring the screen back to life!

I began investigating the root cause, and started by taking apart the LCD. I found some liquid had been spilt all over it; nothing had corroded, but cleaning and reinstalling did not make any difference. Reuniting the scope with the dumpster wasn’t an option, because aside from the LCD, the scope felt like an absolute treasure trove. even though the LCD’s chauffeur board was completely useless now, it came from a time when the industry had not yet moved onto subatomic pin pitch on wire-to-board connectors. This implied I could conveniently solder on a conventional 26 pin ribbon cable television to tap off all the required signals and begin the process of reverse engineering the protocol in use.

Reverse engineering the LCD Protocols

Ribbon cable television soldered on top of the existing connector
The first step of the process was to identify the signals on the connector. I was on the look-out for the most generic set of signals required to drive any LCD. This should include a few strictly periodic signals, a couple somewhat random signals and ofcourse the typical power and ground. The periodic signals would many likely be the pixel clock and the synchronisation signals which would mark the start of a new line and frame; on the other hand the random looking signals would be the actual pixel data to be displayed. Judging by its age, a fairly easy protocol was expected. Guided by this intuition I began probing the connector and soon enough I had all 25 signals figured out.

I only found two perfectly periodic signals: one, a relatively low 31.25 kHz signal gated at a suspicious 60 Hz, and the other a 25 MHz square wave. The former had to be a integrated synchronisation signal. The 60 Hz was a dead giveaway as it corresponded to the nominal frame rate. The 31.25 kHz underlying signal should then correspond to the horizontal line rate within a frame. Finally, the 25 MHz signal had to be the clock for the whole system, in fact it was the pixel clock.

Next, I had to make sense of the random-looking signals which were evidently the pixel data. Firstly, the need for a 25 pin connector was clearly alluding to some kind of parallel RGB configuration. In total I found nine such signals which perfectly divides by three and wrapped up that the LCD was using nine bits per pixel and three bits per colour channel R,G and B respectively.

Example: VGA patio scheme
Figuring out the scheme and pin-out was part of the challenge. possibly much more essential was figuring out the the timings of the signals in use.  Almost always, raw display signals have what are called “porches”. These can be thought of as regions within each frame where data cannot be written. These originated in the days of CRT where the physical beam of electrons took time to sweep from the end of a line back to the start of the other, or even from the bottom of the screen to the top. Although less pronounced in modern electronic screens, these regions still exist because the LCD controller takes time processing and shuffling incoming data.

Determining the timings

To extract the timings I tried to correlate the pixel data with the synchronisation signals. I was searching for any regions where the pixels were consistently unasserted.

Horizontal Timings
After staring at the data for a while, it was clear the LCD was using a simple, single patio scheme on both the horizontal and vertical portion of the integrated sync signal. This was easy to identify because the pixels were set toenten alle høje eller alle lave i denne periode. Når jeg havde fastslået disse regioner, brugte jeg markørerne til at måle deres varighed og oversatte den tid til et tilsvarende antal pixels.

Dette var et vigtigt stykke information, der ville sikre en stabil og passende reproduktion på VGA-skærmen. Planen var at fodre disse værdier som konstanter i Verilog, og bruge tællere til at “tur” den tilsvarende logik for at nå de nødvendige bølgeformer.

Lodrette timings.
Endelig skulle LCD’ens beslutning identificeres, da jeg skulle køre erstatningsskærmen på de samme indstillinger. Dette blev gjort ved blot at måle de forskellige aktive perioder og sammenligne dem med andre signaler, såsom pixeluret, der havde en periode 40 ns. Den vandrette aktive tid blev bestemt til at være omkring 25,7 US, der således udgør i alt 642,5 pixel, og tilsvarende var den vertikale aktive periode 15,42 ms og med en vandret periode på 30 US, som svarer til 481 linjer. Det var klart, at dette var en konventionel 640 x 480 display med en genoplivning af 60 Hz.

Find en stand erstatning

Den 8 tommer frelser
Så det eksisterende display [viste sig at være] temmelig almindelig i sidste ende, og en erstatning syntes helt plausibel. Desværre var størrelsen lidt mærkelig; Det er nemt at finde syv-tommers skærme, men otte? Selvom jeg ikke kunne finde noget rimeligt prissatfald i udskiftning på nettet, er størrelsen lige tilfældet det samme som den, der blev brugt af mange moderne efter markedsledende LCD-installationer på biler. Disse er gode billige “eyoyo” topkvalitetsskærme (£ 50) og accepterer bogstaveligt talt alle udviklet af videoindgang fra alle analog til VGA og endda HDMI. De støtter også en meget højere opløsning på 1024 * 768. Jeg er forbløffet over, at denne skærm ikke er massivt populært inden for Raspberry Pi-samfundet.

Endelig syntes alt at være at klikke sammen. Ikke alene kunne jeg erstatte LCD’et med denne VGA-skærm, det ville passe perfekt, da omfanget selv havde nok plads til en CRT!

Så præcis, hvordan udfører man LCD’et til VGA-konvertering? Med en FPGA selvfølgelig!

Signalkonvertering.

På dette tidspunkt blev det eneste, der står mellem mig og et fungerende 500 MHz-scope, med succes konverterede de tidligere nævnte LCD-signaler til VGA. Det var klart, at sådan relativt hurtig behandling kun kunne udføres på en FPGA, men hvilken? Mit mål var på et tidspunkt at forlade FPGA inde i omfanget med skærmen, så jeg havde brug for noget lille og billigt. Heldigvis synes eBay at have et ton af disse gamle Altera Cyclone II-baserede udviklingsbrædder for en Mind Boggling £ 10! Disse er temmelig dygtige FPGA’er, der holder omkring 4K logiske elementer og optimalt til et lille projekt som dette.

En fælles måde, som disse skærmkonverteringer er færdige, bruger rammebuffere. Tanken er at buffer en hel ramme, udføre omdannelsen og spytte den ud i den anden ende. Desværre kræver dette en respektabel størrelse ekstern RAM på FPGA. Disse FPGA-bestyrelser er berygtede for ikke at have nogen ekstern RAM, således at denne ordning var ude af spørgsmålet. Efter lidt tænkning vedrørte jeg den erkendelse, at LCD-signalerne og VGA ikke var så uklar. Hvad hvis jeg kunne konvertere fra den ene til den anden på en line-for-line basis og omgå behovet for en rammebuffer overhovedet?

Carrasion: VGA VS LCD. Dette diagram gælder både de vandrette og lodrette segmenter
Sammenfattende:

LCD har:

Et pixel ur.

Kombinerede synkroniseringssignaler

Kun forreste terrasse

VGA har:

Ingen pixel ur.

Separate synkroniseringssignaler

Front og tilbage gårdhave med en synkroniseringsperiode

Det integrerede synkroniseringssignal
Går i detaljer om, hvordan VGA virker, er uden for denne artikels anvendelsesområde, men jeg vil rette det senere. For nu, hvis vi simpelthen undersøger timingskitsen, ser vi, at den eneste forskel mellem de to signaler er antallet af forekomster og placeringer af verandaerne og placeringen af ​​gyldige data.

Skissen gør konverteringen let, men er kun gyldig, hvis de to rammer er i fuldkvindelige synkronisering. To tell the FPGA to start produce a corresponding LCD frame over VGA, we should first identify the start of a new frame coming from the LCD connector so that we could sync to it. This is possibly the trickiest part of the process, because merely examining the edges of the integrated synchronisation signal from the LCD is not sufficient.

We should instead measure the time between two edges and flag the occurrence of a new frame. The rest is a relatively straightforward set of logic gates that produces the above timing diagram. Lastly, as the LCD does not have a back patio or sync pulse, the incoming RGB data should be balance out in time using a tiny FIFO so that it aligns up perfectly where the VGA monitor expects it. once equating the above into Verilog was completed, I proceeded to deal with the hardware.

Hardware setup

The Hardware Setup
The hardware configuration was fortunately very minimalistic. HP was not quite utilising the LCD to its fullest potential. Inspecting the individual bits of eACH-kanalen afslørede en masse redundans: De forskellige bits var praktisk taget altid identiske, hvilket indikerer en meget overfladisk udnyttelse af den fulde ni-bit farvepalette. Dette var ikke chokerende, da HP for det meste genbruger firmware fra CRT-versionen af ​​omfanget. Alt dette indebar, at jeg kom væk med bare at tilslutte MSB’en af ​​hver farvekanal med stort set intet tab i det endelige billede. Dette reddede mig endnu meget mere dyrebar hukommelse på FPGA.

Det væsentligste problem var, at LCD’et brugte 5 V TTL signaler. FPGA kan acceptere i bedste fald 3,3 V signaler, så niveau konvertering skulle udføres. Jeg valgte at udnytte indgangsspændingsdioderne i nogle af de 74HC-serie logikbuffere for at udføre denne konvertering. Dette har tendens til at ødelægge stigningen / faldetiderne betydeligt dog. For eksempel har 74HC4050 selv polysilicon modstande i serie med diode i matricen, der forskyder behovet for en ekstern seriemodstand. Jeg spillede det sikkert og tilføjede 1 kΩ serie modstande til input af denne buffer og udgangen af ​​blev fodret ind i FPGA. Udgangen af ​​FPGAs HSYNC- og VSync-udgange blev tilsluttet direkte til skærmen, mens RGB-linjerne blev bundet gennem 330 Ω modstande.

Succes

Succes!
Efter at have tæmmet 25 MHz pixeluret for at opføre sig på et brødbræt og tilslutte FPGA til den nye ekstern

Monitorens VGA-port, omfanget blev bragt tilbage til sin formelle herlighed! Selvom alt fungerede perfekt, var denne opsætning ret støj-tilbøjelig. Alt jeg behøver at gøre nu er at lave en PCB og give VGA-skærmen en permanent bopæl inden for omfanget.

Så hvad er der næste du spørger? Nå, i øjeblikket er den eneste måde at gemme screenshots på på, gennem en dateret floppy-drev. Men fordi vi nu har LCD-data, der går gennem en FPGA, hvorfor ikke skrive det til et SD-kort?