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.
Problema
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 toeither all high or all low during this period. once I had pinpointed these regions, I used the cursors to measure their duration and translated that time to an equivalent number of pixels.
This was a vital piece of information that would guarantee a stable and appropriate reproduction on the VGA monitor. The plan was to feed these values as constants into Verilog, and use counters to “trip” the corresponding logic to achieve the required waveforms.
Vertical Timings
Lastly, the LCDs’s resolution had to be identified as I would have to run the replacement monitor at the same settings. This was done by simply measuring the various active periods and comparing them to other signals such as the pixel clock that had a period 40 ns. The horizontal active time was determined to be around 25.7 us, thus constituting of a total of 642.5 pixels and similarly the vertical active period was 15.42 ms and with a horizontal period of 30 us, that corresponds to 481 lines. clearly this was a conventional 640 x 480 display with a revitalize rate of 60 Hz.
Finding an able substitute
The 8 inch Saviour
So the existing display [turned out to be] pretty common in the end, and a replacement seemed entirely plausible. Unfortunately, the size was a bit odd; it’s easy to find seven-inch screens but eight? even though I could not find any fairly priced drop in replacement on the web, the size just happened to be the same as that used by numerous modern after market LCD installations on cars. These are good low-cost “EYOYO” top quality screens (£50) and accept literally all develops of video input from all Analog to VGA and even HDMI. They also support a much higher resolution of 1024 * 768. I’m amazed this screen is not massively popular within the Raspberry Pi community.
Finally, everything seemed to be clicking together. Not only could I replace the LCD with this VGA monitor, it would fit in perfectly as the scope even had enough room for a CRT!
So exactly, how does one carry out the LCD to VGA conversion? With an FPGA of course!
Signal conversion
At this point the only thing standing between me and a functioning 500 MHz scope was successfully convert the previously mentioned LCD signals to VGA. It was clear such relatively fast processing could only be done on an FPGA, but which one? My objective was to, at some point, leave the FPGA inside the scope with the screen, so I needed something small and cheap. Luckily, eBay seems to have a ton of these old Altera Cyclone II based development boards for a mind boggling £10! These are rather capable FPGA’s, holding about 4K logic elements and optimal for a small scale project like this.
A common way these display conversions are done are using frame buffers. The idea is to buffer a whole frame, carry out the conversion and spit it out at the other end. sadly this calls for a respectable sized external RAM on the FPGA. These FPGA boards are notorious for not having any external RAM, thus this scheme was out of the question. After a bit of thinking, I pertained to the realisation that the LCD signals and VGA were not that dissimilar after all. What if I could convert from one to the other on a line-by-line basis, and circumvent the need for a frame buffer at all?
Comparasion: VGA vs LCD. This diagram applies to both the horizontal and vertical segments
În concluzie:
LCD has:
A Pixel clock
Combined synchronisation signals
Front patio only
whereas VGA has:
No Pixel clock
Separate synchronisation signals
Front and Back patio with a Synchronisation period
The integrated synchronisation signal
Going into detail of how VGA works is beyond the scope of this article, but I’ll fix that later. For now, if we simply examine the timing sketch, we see that the only difference between the two signals is the number of occurrences and locations of the porches and the placement of valid data.
The sketch makes the conversion look easy but is only valid if the two frames are in complete sync. 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 eCanalul ACH a evidențiat o mulțime de redundanță: diferitele biți au fost practic identice, indicând o utilizare foarte superficială a paletei de culori complete de nouă biți. Acest lucru nu a fost șocant, deoarece HP a reutilizat în cea mai mare parte firmware-ul din versiunea CRT a domeniului de aplicare. Toate acestea au implicit că am scăpat doar că am atins MSB-ul fiecărui canal de culoare, fără practic nici o pierdere în imaginea finală. Acest lucru ma salvat chiar și mult mai prețios memorie pe FPGA.
Cea mai importantă problemă a fost că ecranul LCD utilizează semnale de 5 V TTL. FPGA poate accepta la cel mai bun semnale de 3.3 V, astfel încât conversia nivelului a trebuit să fie efectuată. Am ales să folosesc diodele de prindere de intrare în unele dintre tampoanele logice din seria 74HC pentru a efectua această conversie. Acest lucru tinde să distrugă timpul de creștere / cădere considerabil. De exemplu, 74HC4050 are chiar rezistori polisilicon în serie cu dioda în matriță, deplasând nevoia unui rezistor de serie externă. Am jucat-o în siguranță și am adăugat 1 rezistoare de serie KΩ la intrarea acestor tampoane și ieșirea a fost alimentată în FPGA. Ieșirea ieșirilor HSync și VSync a FPGA au fost conectate direct la monitor, în timp ce liniile RGB au fost legate prin rezistențe de 330 Ω.
Succes
Succes!
După îmbinarea ceasului de pixeli de 25 MHz pentru a se comporta pe un panou de panificație și pentru a găti FPGA la noua externă
Monitorul VGA portului, domeniul de aplicare a fost adus înapoi la gloria sa formală! Deși totul a funcționat perfect, această configurație a fost destul de predispusă la zgomot. Tot ce trebuie să fac acum este să fac un PCB și să acordăm VGA să monitorizeze o reședință permanentă în cadrul domeniului de aplicare.
Deci, ce se întâmplă în continuare? Ei bine, în prezent singura modalitate de a salva capturile de ecran este printr-o unitate de floppy datată. Dar pentru că acum avem datele LCD care trec printr-un FPGA, de ce nu scriem asta pe un card SD?