Tektronix TDS744 CRT to LCD color converter FPGA module DIY

[spo256al2]

Hello,
This topic describes LCD color converter FPGA module experience for broken CRT on TDS544 TDS724 TDS744 TDS754 TDS784
 I bought on ebay a TDS744A tektronix oscilloscope as a part. As often this scope as a weak brightness CRT and it is very difficult to find a new CRT. On the net some users have changed the CRT by LCD. They use analog scope VGA output to send signals to a Chinese board which converts analog signals in digital signals to LCD display… Perhaps a more direct solution can be used by taking digital signals directly from the RAMDAC scope. I saw that a company did it. But I thought it was the right time to have my first experience with the FPGA by building my own solution.

It is easy to find service manual and schematic on the web , thanks to kO4BB download - KO4BB. As TDS7XX family as very near hardware as TDS520B, I used the TDS520B schematic for my TDS744 experience.

There are 60 frames per second. Each frame contains (visible) 480 lines of 640 pixels.  A pixel is build by  mixe 3 primary colors: Red, green, and blue. By modifying the intensity of these primary colors, you obtain one the pixel of the color you want. As an artist on his wood palette with watercolor. 
To build the frame, the scope uses a video RAMDAC chip: BT471 or ADV471. The datasheet gives most of the information you need and the TDS 520 schematic gives the rest.

The BT471 use color palette and overlay palette loaded in dedicated RAM and digital to analog converter to output VGA signal.
To display a frame, the scope separates the picture into two types of elements one is curves ( Named overlay palette in BT471 )and all of the other stuff as grid, index, buttons… (named color palette in BT471). The scope displays either the curves or the other stuff.


In the BT471 each color palette or overlay palette uses  3 registers of six bit length: one register for Red, one register for Green, one register for Blue. There are 256 colors palette in the BT471, so 256 registers form a RAM bloc for each primary color and 15 RAM bloc for overlay palette. There is a pixel mask register in BT471 but it is not used in the scope. The scope set all Pixel bit mask register to ‘1’.

So, to display a pixel, the scope sends to the BT471 the address of the color or overlay and the BT471 DAC convert in analog to display the pixel.
At startup, the oscilloscope fills the entire palette with colors and overlays. All this is sent to the BT471's data bus. There is only one pixel mask fill sequence, followed by the address of each pixel with a value for each of the three primary colors, red, green, and blue. BT471 internal logic handles this sequence to load RAM

The scope hardware limits the color palette to 16 colors and 15 colors for the overlay. 
To use an LCD display we roughly need to get the color data from each RAM output, before the DAC. As this possibility is not given by the BT471 RAMDAC, the idea is to sniff the pins RAMDAC and emulate the RAMDAC by a FPGA and send the pixels to the LCD.
To emulate the RAMDAC by a FPGA I reproduce the internal functions of the BT471 : Pixel mask, color address, red, green, blue color registers, RAM blocs, and internal logics. The internal logics was done in Finite State Machine
The FSM is use at the start up to write primary colors into each RAM bloc.
 Function_diagram.pdf (329.56 kB - downloaded 158 times.)
For the FPGA I used an Xilinx Spartan XC3S200 development module (bought in suplus) and I built a PCB to plug the dev board on the BT471.
As the first design PCB was several times modified, it is very dirty and there is colors error intermittently. So, I am drawing a new PCB design.

Here a link for the youtube video https://youtu.be/v6Kjz3UYjVk



At the video starting you can see the yellow LED for the loading RAM from the finite state machine.
I learned VHDL to build this project and I'm sure I didn't respect the state of the art. Bear with me.

Vincent

[nctnico]

That is neat. I like the way to use the QFP socket to connect a chip to an existing board. I never thought of that. I did something similar in the past but using a fixed palette by taking the 5 bit color data that goes into the RAMDAC.

[spo256al2]

Hello,

To nctnico. Yes !!! I built your design and I studied your code and I did a PCB. It ran Thanks.

At the moment I am working on a new PCB with my solution.
Below it is my VHDL source code according to the hand drawing diagram on the last post

RAM_DAC.vhdl is the "main"
FSM.vhdl
MUX_4.vhdl
PIX_MASK.vhdl
RAM_VIDEO.vhdl
REG_8.vhdl
RAM_DAC.ucf is the constraint file for XMF3_g_200 FPGA module with XC3S200 xilinx from PLDkit low cost module compagny.
I know that module is obsolete but with the code source you can use it, on a spartan 7 or other FPGA

The display used is  a 640x480  G065VN01_V1 I bought it on ebay and the inverter to Aliexpress

Vincent

[TERRA Operative]

Ooh, I am interested in this!
I have no programming experience, so I can't help with that bit, but I am interested in replicating it myself once it's working.

Is the LCD you used a good fit, and does the image line up with the side and bottom buttons around the display?

[spo256al2]

Hello Terra,

I just receive the PCB board you did for testing my intermitenly faulty TDS PSU  !!



Yes, the LCD fit all right, I chose its size to fit direcly in place of CRT.
I plan to power the LCD and FPGA PCB module with the 21 volts from the microprocessor board. This 21Volts is used to power the CRT assembly

Vincent

[TERRA Operative]

Nice! I hope it helps you get your PSU working.

[spo256al2]

Hello,

I did the new schematic and PCB drawing for the CRT to LCD converter module. I will order it JLCPB.
I seen that xilinx FPGA is difficult to get on Mouser or Digikey but available at Aliexpress. Palette_LCD_V2_schematic.pdf (96.29 kB - downloaded 185 times.)

Vincent

[Tantratron]

Hello Vincent,

Great initiative where there will more and more need of such LCD-TFT kit, these TDSxxx/A/B/C/D are really incredible Oscope.

You mention a company or person in USA who did such kit (Simmconn Labs - Mr Xu Wang). I did purchase one unit from him and later two of my customers in Europe purchased a total of 1+3 units (two of these units were in my hands to repair the repspective TDS oscilloscope). The product is well designed, astute but expensive plus the LCD-TFT is not of good quality regarding angle of view, brightness.

I understand after discussing with the owner in USA that he was using initially an old TFT-LCD with very good contrast (HITACHI model TX17D02VM2CAA). Later HITACHI stop producing the unit so later Xu decided to use another LCD-TFT ( AUO model G065VN01 V2) but the display contrast, brightness, quality really dropped.

In fact on his eBay publicity, he shows the HITACHI setup but sells AUO setup which can be misleading in my opinion. Technical discussion attempt with Xu was not easy neither productive so my recommendation would be to go after a better LCD-TFT display. The problem is the old form factor 3x4 and the voltage translation required (5V versus 3.3V) but you seem to have done the hardest part, namely the FPGA programing then insertion top of U199 chip.

Anyway glad to see a french (european) initiative, encore bravo pour votre travail.

Albert

[ltarjanyi75]

Hi spo256al2!

"Can you help me how are you driving the LCD display? As I see in its documentation, it has differential inputs. Have you created differential ports on the FPGA or do you have some other circuit between the display and the fpga?"

Update:
I see that I was looking for the document of V2 display, which has different input than V1 which has TTL/RGB inputs.
I guess that the fpga code could be modified to fit this version also. Will try to do that...

Thanks!

[spo256al2]

Hello itarjanyi75,
This adaptator was design for V1 display. As I provide the code, you can modification the code as you want. But I know that a logic chip can change parallel TTL to serial LVDS. On aliexpress you can find this kind of adaptator.
Regards

V.

[ltarjanyi75]

Hi Vincent!

Do you have any progress of your LCD conversion? How the new schematic/PCB does work, if you built it? Could you manage the power supply from J5 connector of the scope board?

In your first schematic you planned to use some signal level shifter, which you changed to serial resistors as I can see. Does this work safely with the FPGA? How did you calculated the necessary resistor value?

Do you power the FPGA in your setup from the RAMDAC? On the schematic I can see that +5V is connected to J6 and also to J8 (which goes to FPGA), so I assume you power the FPGA from RAMDAC pins. Am I right.
What about the 3.3V, do you use external power supply for this?

Thanks,
Laszlo

[TerrySt]

Laszlo,

I am also looking into using the excellent vhdl code from Vincent.  I have a TDS 524A that I want to convert to LCD, so I have been looking into some of those same questions.

For the level shifter, I think it depends on the FPGA you intend to use.  The older versions apparently have clamping diodes on the inputs to prevent the input level from rising more then one diode drop above the VCC for the IO bank of the FPGA.  So the resistor just limits the input current to the pin .  (5V - 3.3V - 0.6V )/ 330 Ohms = 3 mA into the pin, which is a safe current.  But I think the newer FPGAs do not have the clamping diodes.  I can't find any proof of that in the data sheets, but I found a discussion that said they dropped the clamp diodes in favor of having hot swap capability on the inputs.  The resistor value is a compromise between being high enough to limit the input current but not so high that the slew rate of the signal is slowed too much.
I am using a newer FPGA (Spartan 7) so I chose to use a level shifter IC.  Also, I didn't like the idea of loading the o'scope logic signals so heavily on the high levels, nor the slowing of the signals that the resistor would cause.  It probably works fine on an older Spartan, but I prefer a more conservative approach using level shifters (74LCX541D).
I looked at other approaches.  A resistor divider would work (but also loads and slows the signals).  Or the approach used by https://bastelblog.runlevel3.de/en/restore/ds1250-fram-replacement/ uses a red led and a schottky diode on each signal line.  It works well (I built the FRAM board for my scope) and is pretty small and easy to include in the design.
But in the end, I think I will just use the level shifter IC.

For the power supplies, you can probably get away with using the 5V supply from the scope at the RAMDAC chip to power the FPGA board.
But again, I decided to be conservative.  I am planning on using the G065VN01 V2 LCD panel.  It requires 3.3V for the logic at 300mA max (I measured 220mA on mine) and 12V for the LCD backlight at 250mA.  Then you need whatever current the FPGA board you are using will draw.  Mine needs 5V.  The current is probably 200 to 300mA or so, but I haven't checked it while running the full vhdl code yet.
Since I needed 12V for the lcd panel anyway, I decided to use a small smps powered from the 25V at the connector on the oscope that was used to drive the CRT power supply.  That gives me 12V in a small package (OKI-78SR-12/1.0-W36H-C, DigiKey 811-3294-ND).  Then I used the 5V version (OKI-78SR-5/1.5-W36H-C, DigiKey 811-2692-ND) also powered from the 25V o'scope supply for the FPGA board  The FPGA board converts the 5V to the 3.3V and 1.8V for the Spartan 7.  I added a 3.3V linear regulator (TLV76133DCYR) driven from the 5V switcher to supply the LCD logic and the level shifters.   This is a bunch of overkill, but it doesn't add much expense.
The nice thing about the new version of the LCD panel is that it uses LEDs for the backlight running off 12V.  The older version required a high voltage inverter.
Unfortunately it changes from a parallel data input to a four channel lvds serial input.  I had planned to use the FPGA to drive the lvds signals, but I could not find a cheap FPGA board that allowed the power supplies to the FPGA to be set so that lvds signaling could be used.  So instead I an using SN65LVDS1DBVR chips to convert the 3.3V logic from the FPGA to lvds.

I bread-boarded the FPGA and lvds interface and it works fine.  I have now made a pcb with all of the circuitry and am working on trying to make it work. 
One problem I've found is that I haven't been able to find a PLCC socket that fits down over the RAMDAC chip well enough to make good electrical contact and stay mechanically attached.  I have purchased several through-hole and smt versions of the 44 pin PLCC socket and none of them work well.  I can see from the photos that Vincent sanded the top of the socket down.  That helps some.  Also, you have to remove some small standoff posts from the inside of the socket so that the RAMDAC chip fits deeper into the socket.  Those changes barely work, but there isn't a really solid fit.  I have been working on re-shaping the contacts in the through-hole socket and am able to get what looks like a reasonably good connection.

Another problem I'm having is due to needing a 175MHz clock for the lvds outputs to the lcd.  My plan was to use the 25MHz clock to the RAMDAC and use the MMC module in the Spartan 7 to generate a phase locked 175MHz clock.  When I tried it on the breadboard,  it worked great.  But when I try it in the o'scope, the 24MHz clock is too jittery to get a good phase lock.  It may be specific to the TDS 524A.  The clock distribution on other models is different.  I'm able to get a fairly decent display, but there is some noise and jitter in the display that shouldn't be there.  If I use the 100Mhz clock on the FPGA board instead, it has a good clean 175MHz signal, but since it isn't synced to the 24MHz pixel clock in the 0'scope, there is some ripple in the display.  I'm still trying to come up with a good solution.  It wouldn't be an issue if you use the older version of the LCD that doesn't use lvds (if you can still find one).  And it may be OK with a different model o'scope.  There is something about the clock routing on my o'scope that makes it pick up jitter in the 24MHz clock signal between the oscillator and the RAMDAC.

The vhdl code from Vincent seems to work, although I think the jitter in the clock signal makes it act up every now and then.  I think I will be able to tweak it to make it stable with my o'scope, and if yours doesn't have the excessive jitter in the 24MHz clock, it will probably be fine.

Terry

[ltarjanyi75]

Hi Terry,

Thanks for the information about your project, it is very valuable, since I'm trying to do the same.

I also have a G065VN01 V2, which I could drive by a Spartan 6 devboard. I have not tried to attach it to RAMDAC yet, so you are ahead of me. This jitter issue does not sound promising, but will see what it will be in my case (744A scope). I don't know how, but maybe the HSYNC/VSYNC signals of RAMDAC can be used to provide synchronization on the FPGA.

Regarding FPGA code, Vincent's code is a great help, I more or less understand how it works now, though I have plenty to learn, since it is my first FPGA project.

I also only tried to attach one version of PLCC socket onto the RAMDAC and I agree, that it does not fit correctly. I did not have time to play with it more and to look for other types, because I'm currently focusing on the power board and FPGA board design.

If I'm correct you also plan to build your own FPGA board, which you can directly plug with the socket to the RAMDAC. (And not a ready made FPGA devboard which you fit on a PCB with socket, like Vincent did so far.)

Now I work on the power board, which can be attached to J5 socket of the scope board. It has 5V pins beside the 25V, so you don't need to convert the 12V down to 5V.

Bye,
Laszlo

[TerrySt]

Laszlo,
I started out planning to use an FPGA board (S7 mini) (https://shop.trenz-electronic.de/en/TE0890-01-P1C-5-A-S7-Mini-Fully-Open-Source-Module-with-AMD-Spartan-7-7S25-64-Mbit-HyperRAM).  but I may try doing an FPGA on my own board.  I have been itching to try my hand at some bga soldering.

I'm attaching pictures of what I currently have.  I went with a fairly large board because I wanted to use the two nearby support points in addition to the RAMDAC socket.  This meant using an extra board for the socket that let me adjust the height to match the supports.

[TerrySt]

Back side with  the socket board.

[ltarjanyi75]

Wow, nice design and work! Clever idea with the supports!
What do you plug into that big connector with the strip cable? Is it connected to J5 connector pins?

[Tantratron]

I bread-boarded the FPGA and lvds interface and it works fine.  I have now made a pcb with all of the circuitry and am working on trying to make it work. 
One problem I've found is that I haven't been able to find a PLCC socket that fits down over the RAMDAC chip well enough to make good electrical contact and stay mechanically attached.  I have purchased several through-hole and smt versions of the 44 pin PLCC socket and none of them work well.  I can see from the photos that Vincent sanded the top of the socket down.  That helps some.  Also, you have to remove some small standoff posts from the inside of the socket so that the RAMDAC chip fits deeper into the socket.  Those changes barely work, but there isn't a really solid fit.  I have been working on re-shaping the contacts in the through-hole socket and am able to get what looks like a reasonably good connection.

Hello Terry,

It is great to see first Vincent from France then Lazlo from Hungary and now yourself in USA trying to come up with another open source variant for this very topic.

As I've mentionned earlier this year here https://www.eevblog.com/forum/testgear/tektronix-tds744-crt-to-color-converter-fpga-module-diy/msg4639096/#msg4639096, I initially bought in 2021 one kit from Simmcomm labs for my TDS794D. Later french university test center asked me to repair and hack their failed TDS540C then one year later, their mono-CRT failed so I recommended they order same kit to Simmcomm labs. I did made the all repair and installation for them. Then later in 2022 a german customer asked my company for two reconditionned and hacked (one TDS580C and one TDS784C). Same story where I suggested them to order 2 kits from Simmcomm labs but they ordered 3 kits, they offered me as an extra payment one kit which I've later installed in my TDS784D.

Personnaly I'm more a radio guy and digital signal processing guy so digital video processing, I do not know very much but find interesting. Anyway, I still use two Simcomm Labs LCD-TFT kits, they work fine except in my opinion the low contrast quality of the G065VN01 V2 LCD panel. Ideally going after OLED or another brand would be a plus but again, the commercial kit works. The onwer of Simmconn lbas told me it is impossible to beat the contrast of NuColor tektronix technology so it is a choice of lower consumption, lighter weight, less failure to go with LCD-TFT medium visual quality.

Reading part of your post suddenly brings some explanation why it was hard for me to install the QFP socket onto the U199 chip. It is very tricky installation, can get loose in no time depending how you press it. No idea what part number Simmconn labs is using but I wonder if they did not sand it partially but for sure, I'm not trying to remove it to install later unless really needed (i.e. main PSU repair). The removal from J5 is no problem of course, the PLCC-44 reverse socket paradigm really is very wierd.

Now legally I'm wondering what this sentence means, namely in my invoice slip which I've paid to Simmcon labs. It is written The Xilinx FPGA design in the NewScope-5/6/7/8/9 kit is released under GPL 2.0 licence, which means that you have written offer to receive the source code of the FPGA design. The source code is available upon request. The schematics, PCB layout and firmware remain proprietary

The kits came with 4 electronic parts: LCD panel, the power plug connected to J5, the FPGA plug connected into U199 chip and respective cables. Does the previous sentence voids or makes it illegal to check and communicate the voltage values (i.e. power rails), to reuse the concept of receive power from J5 connector, the paradigm to PLLC-44 connect the U199 chip ?

N.B. I think it will be very hard to beat the price of the kit in USA even though it is quite expensive, my question is really about how far legally some of us can really say redo or improve say a prototype or commercialize ?

Albert

[TERRA Operative]

That GPL 2.0 statement is probably because Simmconn Labs is using a library or code that is also GPL 2.0, so their code needs to be released under the same license.

I wonder if is worth getting the source and checking it for any hints or tricks for us here?

[TerrySt]

Wow, nice design and work! Clever idea with the supports!
What do you plug into that big connector with the strip cable? Is it connected to J5 connector pins?

Yes, it plugs into the connector that was used to connect to the crt power supply before it was removed.  I am just using the 25 volt supply voltage from it, but I’m sure also using the 5v supply would work. 

Terry

[ltarjanyi75]

I wonder if is worth getting the source and checking it for any hints or tricks for us here?

It would be interesting how they handled the sync issue Terry mentioned. However it will be questionable what really they would share with anyone, if something at all.

[TerrySt]

I think the issue I am having with syncing is due to power supply noise or ground bounce on my new board.  I’m still working on it but it looks like the clock jitter is way worse after the level shifters I am using.  Once I fix that, it is easy enough to just use the pll or Mmc module in the Fpga to lock onto the 25 MHz click and generate the 275Mhz clock needed for the lvds signals to the new lcd panel.   

Terry

[TerrySt]

I've been working on tracking down the cause of the clock jitter that is causing noise in the display.  Unfortunately, it looks like it is caused by my decision to use the level shifter ICs to convert from the 5V logic levels in the o'scope to the 3.3V signals needed by the FPGA (Spartan 7).  The chip I was using is the 74LCX541D octal non-inverting buffer.  It was a bad idea for a couple of reasons.  First, I completely ignored the fact that the data bus signals get tri-stated.  That leaves the input to the buffer floating, which is a bad idea.  They will draw excessive current and even oscillate.  I could see signs of that and it caused a lot of noise on the power and grounds.  The other reason is the simultaneous switching of several signals on the same chip.  This would probably be OK for most of the signals, but when the clock is fed through the same chip that has seven other signals all switching at the same time, the clock gets noise introduced onto it that causes jitter.
I'm not sure what I'm going to do instead.  I checked the two methods I mentioned earlier (resistor divider on each line or red LED and Schotky diode in parallel on each line.
The resistor divider slows the rise time as expected.  I used 330 Ohms serial and 680 Ohms shunt.  That degrades the rise/fall times, but would probably work OK.  Those values load each signal line by about 5mA.  Lower values would improve the slew rates, but at the expense of extra loading.
The LED/Schottky approach works better. 
Here are o'scope shots of each approach.  Either would probably work.  Maybe I could use the level shifters for most of the signals and use the LED/Schottky for the 8 data bus signals and the clock.

Terry

[Tantratron]

Hello Terry,

I do not have knowledge on FPGA for digital video neither do I know well the operation of the RAMDAC. However I'm using two LCD Kit from Simmconn labs so I took pictures of the board and quick voltage measurements which I can share later if you need.

The more I think about what is written in his invoice The Xilinx FPGA design in the NewScope-5/6/7/8/9 kit is released under GPL 2.0 licence, which means that you have written offer to receive the source code of the FPGA design. The source code is available upon request. The schematics, PCB layout and firmware remain proprietary. This seems to only concern the FPGA firmware, the FPGA plug or board and probably not the power plug board.

After all, the power plug is not real brain, just board re-using the +5Vdc and +25Vdc rails from J5 connector then generating via LDO and buck regulator 3.3Vdc and +12Vdc. Note that I happen to have pictures of this power plug version 0 from 2014 which obviously was revised version 1 in 2018 so the power generation or conversion from J5 rails could be not obvious unless he was obliged to redesign due to lack of components. Wether using a LDO or buck regulator, all these schematics and pins out are standard and found in many datasheets.

First thing, his FPGA is SPARTAN XC3S50A and the board has a secondary LDO generating 1.2Vdc from the incoming 3.3Vdc (why 1.2 Vdc is needed, no idea).

Second thing, I recommend from a local EMI and EMC point of view to rather generate the 3.3Vdc from 5Vdc instead from 25Vdc -> 12 Vdc -> 3.3Vdc because deep down conversion can sometimes generate lot of interference depending on the PCB layout. Maybe these are some noise corruption affecting your jitter, no idea but there must be serious reason Simmcon labs used both 5Vdc and 25Vdc from J5 connector.

Last thing, in the initial version, both HSYNC and VSYNC were routed from J5 to FPGA, later revision only routes HSYNC but I'm really not certain this signal is important because the key thing is the 24 MHz quartz near U199 chip (ADV471 RAMDAC) receiving the FPGA plug.

Attached some pictures if they can help anybody, just my 2 cents

Albert

[TerrySt]

Albert,
Thanks for the pictures.  Their solution is nice and small.  Very well done.  Mine is much larger since I am using an FPGA dev board instead of an FPGA.  I wanted to use the Spartan 7 and it is only available as BGA.  So at least for my first try, I'm sticking with a dev board so I don't have to solder bga.  I may try to make my own fpga board later.
I don't know why they need to route either hsync or vsync from the J5 connector to the fpga.  I just use the /BLANK signal from the RAMDAC.  It seems to work great.
The socket is interesting.  I purchased what I think is that same socket (Methode p/n 213044601) and it is very difficult to get it to fit over the ramdac and stay in place.  Might work with a very small board like they have but not a larger one like mine.  It would keep popping off.  I've purchased several other brands of socket, and none seem to work well without modification.  The Methode one is probably the best I've tried.

Terry

[TerrySt]

I managed to add the red LED and Schottky diode level shifters in place of the I.C. level shifter on the 8 data bus and the clock lines.  The noise issue is gone and the display is nice and clean.   
I'll play around with it and see if it is stable while I start working on a re-spin of the board.

Terry

[ltarjanyi75]

Hello Terry,

Good to hear, that your solution finally works. Did you manage somehow to solder the LED/diode to the same board you made the photo of before, or did you designe another board?

I have a Spartan 6 and it also does not contain clamp diodes. Unfortunately I have not checked it before and I designed my "plug in board" like yours for my Spartan 6 devboard with only serial resistors. And of course it is already in production...
Now I'm thinking how I would replace the resistors for the LED/Diode combo at the same place, without redesigning and producing a modified PCB.
Btw, would the LED/diode combo work for all signals? Why it is only important for data lines and clock? (because of 3-state data lines and importance of clear clock?)

[TerrySt]

Yes, I managed to add the led/diode to my existing board.  It wasn't easy, and it isn't pretty, but it let me test it.  I did it only on the data and clock lines because it was so difficult to do that I didn't want to do it on all the lines.  It is most important on the data lines because they are not just high/low.  They also go tri-state.  This left the inputs to the level shifter ICs floating, which is bad because it causes high currents in the IC and even oscillations.  This was causing a lot of noise on my board.  I also wanted to remove the clock from the level converter IC since there was noise from the other signals on that IC getting coupled into the clock.  Changing just the data and clock signals reduced the clock jitter enough to allow the PLL in the Spartan to give a good phase locked 175MHz clock for the lvds lcd.
I did a re-spin of the pcb which will use the led/diodes on all of the lines.  The parts I used are very small:
LED:  DigiKey p/n 732-12015-1 (0603 package)
Schottky diode:  DigiKey 641-1784 (SOD523 package)
You need good eyes (I have a microscope) and patience to solder them by hand.

Another way that would work for your case is to use your series resistor but add the schottky diodes from the input of the FPGA to the 3.3V supply.  That should work, but will slow the rise/fall times to the signals slightly depending on the resistor value.  The value is a trade-off between speed and how how current is drawn from the signal lines when the diode conducts.  I the case of 330 Ohm resistors, that would be (5v - 3.3v - 0.2v)/330 = 4.5mA.
The led/diode method doesn't slow the signals and doesn't draw any extra current from the signal lines.

Terry

[TerrySt]

The lcd looks great.  The colors and contrast look really good to me.  It is hard to take a picture that looks as good as it does live.  I've just got it taped in place in the scope and still have the protective plastic cover on the screen so the reflections are bad in the photo.  I will make a mounting bezel for it and try to find some sort of anti-reflective plastic or glass protection cover for it.
This is the G065VN01 V2.  The backlight brightness is set to about 50%, which seems plenty bright.

[Tantratron]

All my congratulations Terry, bravo.

Regarding the intensity control, namely the selected Waveform % with the selected text % and how your FPGA code generating the PWM duty cycle for LED back light signal, how did you set the specifoc algorithm fusing each % request ?

Albert

[ltarjanyi75]

I agree with Albert, nice work Terry! The LCD screen looks great!

If I'm not mistaken, the brightness can be set by the dip switches on the board.

[TerrySt]

Yes, the backlight intensity is just set by the DIP switch on the board I made.  I had planned on using a potentiometer to set it, but unfortunately the FPGA board I am using did not route out the input pin for the ADC channel to the low density pins.  So instead I just convert the DIP switch setting to a PWM value.

Terry

[TerrySt]

Just to be clear, the DIP switches just set the backlight level.  The intensity of the traces, text and graticules is still set by the o'scope using the RGB values written to the overlay and palette registers.  I checked that the intensity adjustments from the scope work and they do.

Terry

[TERRA Operative]

Nice work! How do the side and bottom menus line up with the soft-buttons?

Will you open-source the design, or provide gerbers or a kit? I have a TDS784D and a TDS794D that could both get an upgrade....
I wonder if making a board to do away with the dev board, if the backlight brightness could be tied in with the intensity adjustment from the scope controls?


Also, is the difference between V1 and V2 LCD panels just the interface type?

[TerrySt]

I'm happy to share the design files.  I'll post the KiCad schematic and pcb files here once I check out the latest board spin.  But the pcb files might not be of use to anyone unless they also have a TDS524A since the way I made the pcb it mechanically fits the mounting points on scope and lines up with the RAMDAC chip.  I doubt any other models would share the same dimensions.
I will also post the vhdl code I that I used to convert from Vincent's code for the old version of the lcd to the new serial interface version.  And since I was doing this project mainly as a reason to learn vhdl, I re-wrote the entire code starting from scratch.  I did not use the State Machine approach that Vincent used.  I found it easier to understand that way.  I'll post that version after a bit more testing.
I don't know if there is any difference in the lcd panels between V1 and V2 other than the interface and the backlight.  The size is the same.  It fits the scope really well. Ill add a picture with the menus active.
The intensity adjustments from the scope controls are still active.  The scope adjusts the intensity of the traces and text and grid by changing the values in the palette and overlay registers.  There is no analog intensity adjustment in the scope.  So it works with the lcd just as it did with the crt.  I tested the trace and Text/Graticule intensity adjustments and they work perfectly.

The colors on the lcd are much better live.  The camera in my phone makes them look splotchy.  They are actually very solid and bright.

Terry

[TERRA Operative]

Schematics would be awesome, I can lay out a version to fit my scopes, although the processor boards are reused between multiple models so it's likely your design would fit a number of different scope models.

This would mean that only a few different PCB designs would be needed to cover all models.

[Tantratron]

I'm happy to share the design files.  I'll post the KiCad schematic and pcb files here once I check out the latest board spin.  But the pcb files might not be of use to anyone unless they also have a TDS524A since the way I made the pcb it mechanically fits the mounting points on scope and lines up with the RAMDAC chip.  I doubt any other models would share the same dimensions.

I never had older TDSxxx versions except one TDS510A, other 8 models I've reconditionned were C or D serie. The TDS510A even 68020 engine based instead of later 68040 for A11 board do use the same layout for video section than any C or D serie, probably same for TDS7x4A. However I've found one picture of your TDS524A board from internet (see attached with YELLOW arrow) where now I see the mechanical problem or say the U199 chip (RAMDAC) being quite close from fan unit whereas later models position U199 much further away mechanically.

Saying this, I really doubt from a firmware or electrical video signal (analog, digital) any difference, tektronix kept for all versions the same video concept wether mono-CRT or color-CRT hence your work is very valuable for TDSxxx community.

[TERRA Operative]

I just ordered a couple LCD panels for my TDS784D and TDS794D, another fun project to add to the list.

Once they arrive, I'll have a go at designing a bezel/mount. Maybe sheet metal, maybe 3D printable?
Sheet metal has more strength and 'permanence', 3D printable is easier for anyone to make.

Or, "Why not both?" Choice is good. Let's see what way will work best when the panels arrive.

[Tantratron]

I just ordered a couple LCD panels for my TDS784D and TDS794D, another fun project to add to the list.

Where did you order them ?
Are there new or used ?

[TERRA Operative]

I just grabbed these ones.
https://www.ebay.com/itm/314600953560
Not sure if they are new, but the images suggest so (for little that it's worth).

I'll know if they are any good when they arrive....

[TerrySt]

The new board works.  Here are PDFs of the schematics.  There are two boards.  The main board and a board that has just the socket for the RAMDAC.  This is so the height of the main board can be set to allow the mechanical mounting points in the o'scope to be used.

Terry

[TerrySt]

Here are the KiCad design files.  The socket I am using is the Methode p/n 213044401 through hole.  I modified it by milling away the raised areas on the bottom of the socket so that it would sit down further onto the RamDAC chip.  I also re-shaped the contacts in the socket to allow them to grip the RamDAC chip better.  It seems to work OK after those changes.  I never found a socket that worked really well without modifications.  The closest one I could find is the Methode p/n 213044601 surface mount socket.  It can be made to make contact (with a bit of a struggle), but will pop off a little too easily for my taste.  Another socket that can be modified to work is the ASSMAN A-CCS-044-G-T (DigiKey p/n AE10064-ND).  It requires less milling of the bottom (just four small posts that can be cut off with a sharp exact-o knife), but the contacts must be removed individually and re-shaped one by one.   The design of the Methode through hole socket allows all of the contacts in a row to be shaped at once, which yields more consistent results.  I made a small bar out of aluminum that allowed me to bend the contacts around it to get the desired shape.
You also need to source the various cables to connect the board to the o'scope and lcd.  No cables came with the lcd I purchased.  For the backlight cable, I ordered a DigiKey WM15267-ND.  But I had to swap the pins at one end to reverse the order of the pins.  The board is laid out for a 1:1 cable, but the cable as supplied by DigiKey reverses the order of the pins.
For the LCD connector, I ordered several from various places on eBay and AliExpress.  I was looking for one a little longer than 250mm but could never find one.  250mm works in my o'scope, but not much to spare.  I think I ended up using this one:  https://www.ebay.com/itm/202290058359, but I'm not sure. 
For the connection from the o'scope to the board, I used DigiKey p/n H3CCH-1606G-N.  It is a little long, but not too much.
I used a Spartan 7 dev board from Trenz.  It was the smallest dev board I could find for a reasonable cost.  Others would work (with a new pcb layout of course).  The Spartan 7 is much larger than needed.  The design I ended up using only uses 49 FFs and 81 LUTs.  Just be sure what you choose supports a PLL or MMC module that can provide the 175MHz clock for the lvds interface to the lcd panel.  It needs to be phase locked to the 25MHz clock from the o'scope.  The CMOD S7 from Digilent would certainly work, but is a little larger.  I am already thinking about a new version with an FPGA instead of an FPGA dev board.  That might allow me to use the lvds outputs of the FPGA instead of having to use the lvds converter chips.

Terry

[TerrySt]

Here is the VHDL code that is based on Vincent's code but with modifications for the serial interface on the V2 version of the LCD panel, and the backlight and reset changes that go with the new design.  It works OK, but will occasionally display the wrong colors as settings are changed that affect the palette or overlays.  Such as when the colors are changed, or the intensity settings are changed.  It works 99% of the time, but occasionally glitches.  It is 100% stable when the color, palette or intensity settings aren't being changed.
I was trying to debug the glitches, but I decided to just start over with my own code from scratch so that I understood it better.  That version seems to be simpler (to me anyway) and is 100% stable.  I'll post it also.
First, the version based on Vincent's code is attached.

Terry

[ltarjanyi75]

Hi Terry,

Why can't you use the LVDS of the FPGA with the devboard? Isn't its LVDS outputs available on your devboard?

Btw I am now planning a small board with a Spartan 3. The board will be small (44*41mm) which is ok from the point of fitting on top of the RAMDAC, but I don't know if I will be able to solder it...

Thanks,
Laszlo

[TerrySt]

And here is the version I created from scratch.  This is my first attempt at VHDL coding, so no guarantees.  I'm not sure how to attach the automatically generated clock wizard files, so if you need some other files you will have to let me know or just generate them yourself (easy using the clocking wizard in Vivado). 

Terry

[TerrySt]

Hi Terry,

Why can't you use the LVDS of the FPGA with the devboard? Isn't its LVDS outputs available on your devboard?

Btw I am now planning a small board with a Spartan 3. The board will be small (44*41mm) which is ok from the point of fitting on top of the RAMDAC, but I don't know if I will be able to solder it...

Thanks,
Laszlo

None of the dev boards that I could find (at least the reasonably priced ones) allow you to set the voltages on the FPGA to the voltage required by the LVDS interface.  They all seem to be set to 3.3V, and for LVDS you must set the domain voltage to 2.5V.

I don't know anything about the Spartan 3, but it should be fine as long as it can generate the phase locked 17MHz clock.

Terry

[Tantratron]

I used a Spartan 7 dev board from Trenz.  It was the smallest dev board I could find for a reasonable cost.  Others would work (with a new pcb layout of course).  The Spartan 7 is much larger than needed.  The design I ended up using only uses 49 FFs and 81 LUTs.  Just be sure what you choose supports a PLL or MMC module that can provide the 175MHz clock for the lvds interface to the lcd panel.  It needs to be phase locked to the 25MHz clock from the o'scope.

The owner of Simmcon labs has used a Spartan 3 (model XC3S50A), do you know if this is enough to implement 49 FFs (Flip-Flop) and 81 LUTs (Look Up Table) or he was super experimented to optimize its code with much lesser CLBs (Configurable Logic Blocks) ?

None of the dev boards that I could find (at least the reasonably priced ones) allow you to set the voltages on the FPGA to the voltage required by the LVDS interface.  They all seem to be set to 3.3V, and for LVDS you must set the domain voltage to 2.5V

Interesting which explains now why Simmconn labs uses a local 1.2 Vdc regulator because when we see the G065VN01 V2 datasheet (page 11/24), it mesntions for LVDS the differential input common voltage VCM to be between 1.1V and 1.45V (typical 1.2 V) for best threshold detection.

Albert

[TerrySt]

I used a Spartan 7 dev board from Trenz.  It was the smallest dev board I could find for a reasonable cost.  Others would work (with a new pcb layout of course).  The Spartan 7 is much larger than needed.  The design I ended up using only uses 49 FFs and 81 LUTs.  Just be sure what you choose supports a PLL or MMC module that can provide the 175MHz clock for the lvds interface to the lcd panel.  It needs to be phase locked to the 25MHz clock from the o'scope.

The owner of Simmcon labs has used a Spartan 3 (model XC3S50A), do you know if this is enough to implement 49 FFs (Flip-Flop) and 81 LUTs (Look Up Table) or he was super experimented to optimize its code with much lesser CLBs (Configurable Logic Blocks) ?

None of the dev boards that I could find (at least the reasonably priced ones) allow you to set the voltages on the FPGA to the voltage required by the LVDS interface.  They all seem to be set to 3.3V, and for LVDS you must set the domain voltage to 2.5V

Interesting which explains now why Simmconn labs uses a local 1.2 Vdc regulator because when we see the G065VN01 V2 datasheet (page 11/24), it mesntions for LVDS the differential input common voltage VCM to be between 1.1V and 1.45V (typical 1.2 V) for best threshold detection.

Albert

I don't know anything about Spartan 3 but I bet even the smallest Spartan 3 has enough resources for this job.  You just need to make sure the version you choose has enough I/O.  Watch out for the way the I/O banks are defined.  You can't mix voltages in a bank.  So if you decide a bank is 3.3V for the I/O, then all of that bank is 3.3V.  I don't know if the Spartan 3 supports lvds in all of the devices or on all banks or what other restrictions there might be. 
The 1.2V is probably the core voltage.  It looks like the lvds requires 2.5 or 3.3V on the Spartan 3.
I would use the Spartan 3 except it looks like the only tools available are the ISE that only works on Win7 or Linux.  I'm not sure I want to mess with setting up a VM to run either Win7 or Linux.  What tool are you using?

Terry

[Tantratron]

I would use the Spartan 3 except it looks like the only tools available are the ISE that only works on Win7 or Linux.  I'm not sure I want to mess with setting up a VM to run either Win7 or Linux.  What tool are you using?

I'm using MacOS being quite faithfull to Apple since 1986

[TerrySt]

I would use the Spartan 3 except it looks like the only tools available are the ISE that only works on Win7 or Linux.  I'm not sure I want to mess with setting up a VM to run either Win7 or Linux.  What tool are you using?

I'm using MacOS being quite faithfull to Apple since 1986

Is ISE supported on MacOS?

[ltarjanyi75]

Hi,

Spartan 3 (model XC3S50A) should be fine, since SimmconnLabs use it in their design with LVDS also. They have an onboard 1.2V converter and 3.3V as input. 1.2V is used as internal supply voltage in Spartan 3.

I tested the G065VN01 V2 display with a Spartan 6 devboard bought from Aliexpress (Xilinx spartan6 XC6SLX16). It's VCCO and VCCAUX pins are connected to 3.3V and VCCINT (internal supply voltage) to 1.2V, no sign of any 2.5V either... I measured the voltage levels on LVDS output clock signal and it changes approx between 1.1V and 1.45V. What is strange that it is the same even if I set the LVDS output pins IOSTANDARD to LVDS_33 or LVDS_25... (Or I do something wrong...)

ISE can be installed and run on Windows 10 (there are other topics on the net), the issue for me is the IMPACT tool to download the compiled code to the FPGA. It does not work with my Xilinx platform cable (chinese clone) only trough Virtual Machine setup. At least I can develop in Windows 10 and to use the files from same project folder under VM to download the compiled code to FPGA.

Bye,
Laszlo

[TerrySt]

It looks like the Spartan 6 supports LVDS_33 and LVDS_25.  But the Spartan 7 supports LVDS_18 and LVDS_25, but not LVDS_33.  So the Spartan 7 dev boards that have 3.3V applied to VCCO (all of them that I found) cannot support LVDS.

Terry

[ltarjanyi75]

I have checked the Spartan 3 and 6 datasheet. LVDS_33 and LVDS_25 use the same DC charasteristics of user I/Os (e.g. same output common mode voltage). The difference is the necessary output driver supply voltage level, VCCO (2.5V for LVDS_25 and 3.3 for LVDS_33).

So I think Terry, you could also use directly the LVDS I/Os of your Spartan 7 devboard (I assume it works the same way, though I have not checked the Spartan 7 documentation).

[ltarjanyi75]

It looks like the Spartan 6 supports LVDS_33 and LVDS_25.  But the Spartan 7 supports LVDS_18 and LVDS_25, but not LVDS_33.  So the Spartan 7 dev boards that have 3.3V applied to VCCO (all of them that I found) cannot support LVDS.

I see, then it is different for Spartan 7...

[Tantratron]

Just found that article regarding the 1.2V center offset, the topic of LVDS_25 LVDS_33 and other
https://www.diodes.com/assets/App-Note-Files/AN041-P.pdf

Note that sentence from page 1... It has an offset voltage of 1.2V above ground. Because its operating voltage is centered around 1.2V with respect to the driver􏰀s ground, LVDS does not depend on a specific power supply such as 5V or 3.3V making it easy for LVDS to migrate to new low supply voltage technology. Since it is centered around 1.2V, it is also less susceptible to noise since noise often occurs at Vcc or Ground.

[TerrySt]

Just found that article regarding the 1.2V center offset, the topic of LVDS_25 LVDS_33 and other
https://www.diodes.com/assets/App-Note-Files/AN041-P.pdf

Note that sentence from page 1... It has an offset voltage of 1.2V above ground. Because its operating voltage is centered around 1.2V with respect to the driver􏰀s ground, LVDS does not depend on a specific power supply such as 5V or 3.3V making it easy for LVDS to migrate to new low supply voltage technology. Since it is centered around 1.2V, it is also less susceptible to noise since noise often occurs at Vcc or Ground.

But unfortunately the Spartan 7 will not allow me to use the LVDS outputs unless the bank voltage (VCCO) is set to 2.5V.
From the I/O User Guide:  https://docs.xilinx.com/v/u/en-US/ug471_7Series_SelectIO   Page 91.

The LVDS I/O standard is only available in the HP I/O banks. It requires a VCCO to be
powered at 1.8V for outputs and for inputs when the optional internal differential
termination is implemented (DIFF_TERM = TRUE).
The LVDS_25 I/O standard is only available in the HR I/O banks. It requires a VCCO to be
powered at 2.5V for outputs and for inputs

The Spartan 3 and Spartan 6 allow LVDS on Banks powered by 3.3V, but the Spartan 7 does not.
The Spartan 3 would be a better choice for this project, but I have decided to use the Spartan 7 mainly because the new version of the tools (Vivado) does not support the older chips.  I am doing this mainly as a learning exercise, so want to use the latest tools.  Also, I want to try my hand at working with BGA parts (layout and assembly).  I don't know if I'll be successful, but this is a hobby for me now (I'm retired).  If I was doing this to make a product for the marketplace, I would probably use the Spartan 3N, which is non-volatile, so doesn't need the serial EEPROM for configuration.

Terry

[TERRA Operative]

I just had a bit of fun in CAD tonight, whipped up a v1.0 mounting bracket and front bezel.
I can't help with the software side of things, but CAD and PCB layout is where I'm able to lend a hand.

The front bezel should be no thicker than 1.0mm, and the mounting bracket should be 1.2mm thick (To match the thicknesses used by Tektronix)
The LCD panel is screwed to the mounting bracket with 6mm long M2.5mm screws and washers, passing through 2mm tall standoffs that are located between the mounting bracket and LCD.
This should result in a perfectly centered display with minimal fuss.

[ltarjanyi75]

I also re-shaped the contacts in the socket to allow them to grip the RamDAC chip better. 

So far I was not able to get good contacts with my PLCC socket. I just get signals on the pins when I push the socket down.
Will try the smd version, if I will be able to solder it, which looks quite challenging to me...

[TerrySt]

I also re-shaped the contacts in the socket to allow them to grip the RamDAC chip better. 

So far I was not able to get good contacts with my PLCC socket. I just get signals on the pins when I push the socket down.
Will try the smd version, if I will be able to solder it, which looks quite challenging to me...

Which socket did you try?

Terry

[Tantratron]

So far I was not able to get good contacts with my PLCC socket. I just get signals on the pins when I push the socket down.
Will try the smd version, if I will be able to solder it, which looks quite challenging to me...

How many pins from U199 one needs to electrically access and routed to the FPGA ?

There are total of 4x11 so 44 pins but what is the layout (position), which pins are actually necessary ?

Maybe quick picture or local layout to help visualize the density to be managed ?

[TerrySt]

So far I was not able to get good contacts with my PLCC socket. I just get signals on the pins when I push the socket down.
Will try the smd version, if I will be able to solder it, which looks quite challenging to me...

How many pins from U199 one needs to electrically access and routed to the FPGA ?

There are total of 4x11 so 44 pins but what is the layout (position), which pins are actually necessary ?

Maybe quick picture or local layout to help visualize the density to be managed ?

You need 22 signals (plus ground although you could get that elsewhere). 
The SMT socket from Methode (p/n 213044601) is the only socket I found that works without modification, although it just barely works.  It will lock down onto the ramdac chip with a bit of fiddling with it, and contacts all the pins, but it pops back off rather easily in my opinion.
No other SMT socket I tried even came close to working.
Of the several through-hole sockets I tried, none worked without modification.  They would not make contact with all the pins unless you pressed on them.  The modifications involved removing some of the plastic at the bottom of the socket so that it would fit down onto the ramdac chip further. 
The easiest one to modify is the ASSMAN A-CCS 044-G-T (DigiKey pp/n AE10064).  On it, you can just use a sharp knife to cut away four little posts on the bottom of the socket.  That let it fit onto the chip and make contact, but again, just barely.  So I also removed each individual contact (pretty easy to do) and re-shaped the contacts so that it made better contact at the top of the socket.  Sanding the top edge of the socket off a little also helps.  I'm attaching a picture of before/after.  It works well after the mods.
I prefer the Methode p/n 213044401 through hole socket although it is harder to modify.  You need a milling machine or at least a dremel with steady hands to remove the plastic from the bottom of the socket.  But the contacts can be removed all at once and re-shaped in a row.  I found that easier than the one at a time ASSMAN contacts. 
Either one might work with just removing the plastic at the bottom (without re-shaping the contacts), but definitely better after re-shaping the contacts.

Edit:  On my TDS524A, there are a few small SMD resistors that sit very close to the ramdac so that I also needed to file a little plastic on one edge of the sockets to avoid hitting them.

[ltarjanyi75]

Which socket did you try?

I ordered my sockets from Ali:https://www.aliexpress.com/item/1005003506048098.html?gps-id=pcStoreJustForYou&scm=1007.23125.137358.0&scm_id=1007.23125.137358.0&scm-url=1007.23125.137358.0&pvid=7ec44edf-75ce-4692-916c-282a1ee4d143&_t=gps-id:pcStoreJustForYou,scm-url:1007.23125.137358.0,pvid:7ec44edf-75ce-4692-916c-282a1ee4d143,tpp_buckets:668%232846%238107%231934&pdp_npi=4%40dis%21HUF%21178.56%21178.56%21%21%210.50%21%21%402101cff817034629856118168ecfc4%2112000026094301457%21rec%21HU%211629207339%21&spm=a2g0o.store_pc_home.smartJustForYou_6001943031111.1005003506048098

It has 4 stand offs at the bottom, which I milled off. I will try to sand the top of the socket, will see how much it helps.
I could not remove the contacts, it seems to be moulded into the plastic case.

And I also will order the Method and Assman version you recommend...

[ltarjanyi75]

How many pins from U199 one needs to electrically access and routed to the FPGA ?

As Terry wrote, 22 pins + GND has to be accessed, he also included a schematic.
If it helps I can also make a picture of the RAMDAC area of the scope...

[TerrySt]

All of the through hole sockets I’ve looked at have a removable bottom that allows you to get to the contacts to re-shape them.  The SMT sockets don’t however.

[Tantratron]

Merry Christmas All,

As Terry wrote, 22 pins + GND has to be accessed, he also included a schematic.
If it helps I can also make a picture of the RAMDAC area of the scope...

Yes please, picture would help me to vizualize.

All of the through hole sockets I’ve looked at have a removable bottom that allows you to get to the contacts to re-shape them.  The SMT sockets don’t however.

Attached again picture I've grabbed from an italian eBay seller few years ago which as re-selling the first version based on Hitachi LCD-TFT unit. We can guess printed a M on brown socket (top left), do you know if this means the brand is METHODE ?

Are you really sure there is not Methode socket which does not not require any milling or grinding ?

Later Simmcon Labs made FPGA board to work with AUO LCD-TFT but there is no reason why socket would change since U199 chip has always been the same on any TDSxxx lofic board.

[ltarjanyi75]

All of the through hole sockets I’ve looked at have a removable bottom that allows you to get to the contacts to re-shape them.

You are right again. I could remove the bottom of the socket. But for sure, you must be very patient!
I already succeeded to break some pins, and I don't know that the ones I didn't will be ok at the end. Finishing with 44 pins is a real puzzle.
 

[ltarjanyi75]

Yes please, picture would help me to vizualize.

Here is a picture about the RAMDAC area.


And to share the progress of my project, a picture about my power board. This will generate the 12V and 3.3V to LCD and 3.3V to my FPGA board (which is still under design). For sure this was the easier part and so far only could test in the scope and with a separate Spartan 6 devboard.

[ltarjanyi75]

My best solution so far: soldered the smd version of the socket I have, then after soldering I cut off the plastic base from the bottom of the socket. It was quite easy. Now the socket grabs the RAMDAC correctly.

[TerrySt]

My best solution so far: soldered the smd version of the socket I have, then after soldering I cut off the plastic base from the bottom of the socket. It was quite easy. Now the socket grabs the RAMDAC correctly.

Great!  I'll have to try that also.

Terry

[ltarjanyi75]

First results with my board in the scope. I reused Vincent's great code and Xilinx's xapp486 7:1 Serializer example code.

I still have some issues with the result (some random pixel noise, strange color changes and some issues with graph colors), but at least I see something on the LCD.

Also the contact of the PLCC socket is still not the best. At first attempt my image on the screen had some red pixel noise (can be seen on one of the pictures) which somehow disappeared after I pushed the board a bit more to RAMDAC.

I also have a soldering issue with my flash memory chip on the board (short on one of the SPI pins), so I have to reload the code to FPGA after every restart. But since it does not impact the other part of the FPGA, I have not yet tried to resolder the chip. First I wanted to make sure that my design could work at all...

Attached a short video also...



Video: https://1drv.ms/v/s!Am44vwFO-Vr3grcEEeiL6_0ZZbcnnQ

[TerrySt]

Nice work.  Great board design.  Very compact.
I also had issues with random colors sometimes with Vincent's VHDL code.  I couldn't get my head around some of the stuff he was doing in it, so I re-wrote it.  I think my version (posted up above) is simpler and seems 100% stable.

Terry

[ltarjanyi75]

Thanks! The board could be made even more compact by removing the reset button, oscillator and JTAG/config pins in the final design. I could have also thought of including some debug pins/leds at the beginning. These would come handy now...

I have compiled your code also with some necessary modifications because of the difference of Spartan 3 (or the lack of my fpga development knowledge) and tested it. Now the background is perfect, but I still have issues with the singal traces: these move slow, have "ghost image", change color and also disappear sometimes from the screen. I don't now if it could be because of the difference between Spartan 3 and 7 versions...

If anyone with more experience in VHDL/FPGA development could help what could be the problem, that would be great!

[TerrySt]

I can't imagine what would cause slow moving or ghost image traces in the LCD.  Are you sure it is not just a setting on the o'scope?  Like variable persistence or similar?

Terry

[Tantratron]

I still have some issues with the result (some random pixel noise, strange color changes and some issues with graph colors), but at least I see something on the LCD.

Also the contact of the PLCC socket is still not the best. At first attempt my image on the screen had some red pixel noise (can be seen on one of the pictures) which somehow disappeared after I pushed the board a bit more to RAMDAC.

I have compiled your code also with some necessary modifications because of the difference of Spartan 3 (or the lack of my fpga development knowledge) and tested it. Now the background is perfect, but I still have issues with the singal traces: these move slow, have "ghost image", change color and also disappear sometimes from the screen.

Great work and progress Lazlo,

As for the strange persistence or signal issues which you mentioned in this post and previous one. Please check but I think you are using InstaVu or later DPO mode so undo this mode which might solve the issue.

Albert

[ltarjanyi75]

Yes, the InstaVu was turned on, which also can be seen on my pictures. I must have been tired when I tried it yesterday...
Now the traces are ok, no slowness or ghost image.
 
The only remaining issue I have, that changing the display setting does not always work correctly: waveform colors are changing even if for example I select the same display color scheme multiple times + sometimes the waveforms totally disappear (which appear again after I change a few times the display settings again). Maybe the waveform disappear is also the result of color change.

Terry, does your display setting change work correctly?
 

[TerrySt]

I had that problem a lot when I was having noise issues on my first revision of the board.  I also had it some when using Vincent's VHDL code.  But with my new board and my new VHDL code, it is 100% stable.
It sounds like there is noise or ringing on the /WR signal or possible the data (D0-D7)  or Register Select (RS0-RS2) signals.  The register selects are latched in on the falling edge of /WR.  Then the data is latched in on the rising edge of /WR.  The /WR signal is only active when a color change is sent from the o'scope.   The 25MHz read clock is not used during the color changes.  Take a look at all of the signals and see if they look noisy or have bad ringing on the edges.  You may find that just putting the o'scope probe on one of the signals improves the situation. 
Look to see that the RS signals are stable when the /WR goes low, and that the Data signals are stable when the /WR goes back high.

Terry

[TerrySt]

I finished the new design using a Spartan 7 FPGA instead of using a development board.  I was able to solder the FPGA and the other small components using a hot plate and  a hot air gun.  The FPGA uses the FTGB196 package (196 balls in a 1mm grid).  I was pretty pleased at how well the FPGA balls looked after soldering (looking in under the edges).  I still used a larger pcb than required so that it can reach the mounts on the o'scope.
I also printed a bracket and bezel for the display.  I started with the files that TERRA provided earlier, and modified them for the 3D printer.  I added standoffs instead of using spacers and also added stiffeners to the bracket since it was a bit flimsy in plastic (would be fine in aluminum).  I added an extra layer to the bezel to keep it centered in the frame.
Lastly, I added an anti-glare screen protector (https://www.amazon.com/dp/B01MQYZBX9?psc=1&ref=ppx_yo2ov_dt_b_product_details).  It can be cut to size and works great.  It cuts down on reflections pretty well.  I'll attach a picture with the bezel and screen protector in place.

Terry

[TerrySt]

Here is the Spartan 7 FPGA board I made.  Like I said earlier, this was just a learning exercise.  The Spartan 7 is probably not the best choice for this project.  The project uses a small percentage of the FPGA resources and it requires extra power supplies (3.3V, 1.8V, 1.0V and 2.5V) just for the FPGA.  Then you still need 3.3V and 12V for the LCD panel.  Also, it requires level shifters on each of the lines from the o'scope.  So it ends up being a more complicated design that it would if you used a Spartan 3 or something similar. 
It also doesn't save any money over using a development board.  The Mini S7 dev board I used in my first version was about $80 after shipping to the US, but the FPGA is $20 and the extra pcb costs to go to a 4 layer board with smaller vias and ENIG finishing for the FPGA easily costed more than the dev board.  But now I know I can design and solder using BGA chips (at least the 1mm pitch ones).

Terry

[TERRA Operative]

How did my parts fit? I can make changes and adjustments if needed

[TerrySt]

How did my parts fit? I can make changes and adjustments if needed

They were perfect except for the cutouts for the connectors on the bracket.  They didn't match up with the connectors on my LCD panel.  They were close enough that the cables still could exit through the cutouts.  Other than that, the changes I made were just to reinforce it for printing with plastic (PLA).

I will attach what I ended up with and you can compare to what you made.  Thanks for providing them.  They save me lots of time.

Terry

[TERRA Operative]

Hmm, I can't download. Seems the forum attachment bug has struck again.
Can you reupload but ignore the first attachment upload slot and use the second slot to get around the bug?

[Tantratron]

Me too, I cannot upload the last 2 attachements of Terry (message #75 and #78)

[TerrySt]

I wasn't aware of the forum upload bug.  I'll try again.
First, the step files for the bezel and bracket.

[TerrySt]

The LCD with the bezel and the screen protector:

[TerrySt]

...and the FPGA board.

[Tantratron]

Many thanks Terry for the new uploads, it works fine.
All my congrats for your BGA soldering skill and work, I could never do this myself.
Happy New Year, Albert

[TerrySt]

Here is the latest version of my VHDL code that uses the LVDS transmitters in the FPGA instead of using external LVDS converter chips.

Terry

[ltarjanyi75]

Terry, your code works wonderfully on my Spartan 3 board also!

I just had to make one modification: I reverted back to the process in your previous version, where you examined the CLK_175 and CLK_25 in the same process. After that everything works correctly: changing colors, intensity, etc. 
Without this modification I just had some blue and black pixel "noise" on the LCD. Don't know why exactly...

But anyway it is super cool!!! Thanks for your help!

[TERRA Operative]

Just made some modified mounting plates, adjusted as per TerrySt's modifications (I derped the design somehow... )

I included STEP files for a thicker 3D printable mounting plate that doesn't need standoffs, and the original that can be cut from aluminium plate with the use of 2mm tall standoffs.

[TERRA Operative]

Hey, ltarjanyi75, would you mind releasing your schematics/PCB files if it is all working perfectly?



Also, how hard would it be, or would it even be possible  to get something like the Lattice LCMXO2-256HC-4TG100C working? (I have practically no programming experience however...)
I can get them in Akihabara for cheap.
https://www.latticesemi.com/view_document?document_id=38834

Where is everyone buying their Spartan 3 chips?

[ltarjanyi75]

Yes, I can share the details, I just need some more time to fix my design errors and test before that.

I quickly checked the datasheet of the family of PLD you sent and I think it could work with one of those also. Here is the brief resource usage summary of the code for Spartan 3 and these fit into the specs:
- Number of Slice Flip Flops: 51
- Total Number of 4 input LUTs: 172
- Number of bonded IOBs: 31
- Number of DCMs: 1
These devices also have on-chip flash for configuration, so no external flash would be required if I'm correct.
Maybe I will give a try later to check the development tool for this device and try to compile the code...

I bought my Spartan 3 chips from Aliexpress, about 8 USD each (+ shippping). Bought 2 of them and they work perfectly.

[TERRA Operative]

Great. If you find that you can compile code, I can draw up a PCB to test on.

Having another look at the datasheet, it seems I need to use the XO2-640U (not the XO2-256 that I can get off the shelf here) Lattice FPGA if I want dedicated LVDS output buffers and a PLL. Are these needed for this application?

[ltarjanyi75]

Yes, that is what I have just found also, because I could not add PLL to the 256 type.
640U is the smallest with 1 PLL, which is required for 25MHz to 175MHz clock multiplication. The smallest package of this is 144 pin TQFP.
(Compared to Spartan 3, which has 100 pin package)

Otherwise I could modify the VHDL code to synthesize without the pin/IO constraints... I don't know yet know how this can be compiled to a programmable binary on this platform and also do not have cable/programmer etc. to test it.
But at least it still seems to be doable even if not with the smallest chip.

[TERRA Operative]

Well, I can only get the non-PLL 256 type locally, so if I have to order chips, I may as well stick with the Spartan 3.

Do you have a link to the seller you bought from? If they are selling known good chips, I'll buy from them too.

(I just found Spartan XC3195A-3PQ208C for about 4000yen per 4 units being sold locally if they would work?)

[ltarjanyi75]

Do you have a link to the seller you bought from? If they are selling known good chips, I'll buy from them too.

This is where I bought from:
https://www.aliexpress.com/store/1102598538/pages/all-items.html?sortType=bestmatch_sort&SearchText=XC3S50A

[ltarjanyi75]

I had some time lately to further enhance my LCD solution. It was more a fun to build than it will be a frequently used feature.
The idea was to solve the brightness setting of the LCD (without opening the scope and changing DIP switch setting) which is possible by varying the duty cycle of the LCD PWM signal.

What I did:
- placed a resistive touch panel in front of LCD
- moved the PWM signal generation from FPGA to an atmega4809 chip/board (installed behind LCD) and program written with Arduino IDE
- Brightness can be set by (controlled by Atmega):
   - touching the upper right corner of screen for around 3 seconds
   - then you can set the value on the left of screen with the y value
   - you can save the value permanently by pressing save button (lower right)
   - if not saved the setting is only stored temporarily till the next restart
   - setting will disappear after not touching the screen for about 5 seconds
- FPGA code modified:
   - removed PWM signal generation
   - accept commands and brightness values from Atmega
   - necessary logic for brightness setting UI elements to overlay the pixel info received from scope during setting

The code could be further enhanced, but probably I will stop here.
(The resistive touch coordinate reading is not perfect, it has some false readings, but most of the time it works fine. And the UI is a bit ugly...)


https://1drv.ms/v/s!Am44vwFO-Vr3gsB13GQrtzPChORk2w?e=a98BJh

[TERRA Operative]

Nice!

I wonder how much of a project it would be to communicate back and forth via GPIB to actually control the scope like a modern touchscreen scope?  

[ZGoode]

This project is awesome!  I was looking at the simmcomm options, but since I have a whole array of stuff I want to eventually swap to LCD I can't justify their cost of $400+ per board.  How difficult do y'all think it would be to adapt this Tektronix adapter to something like an HP 3563A?

[Tantratron]

Hello, I do have a question for the members who did succeed writing the FPGA firmware.

Besides tektronix TDS500/770 oscilloscope for which I still have not tried to replicate your FPGA design, I've spent some time on another LCD retrofit about Advantest spectrum analyzer (R3x61, R3x65 and RX71). The thread found on another part of the forum is quite long but is about using a scaler chip RTD2660 and it finally worked as a proof of concept. The Advantest video pixel signal is very unusual (1264x525 interlaced 15 KHz) then I thought to verify if my firmware would succeed as well on the TDS500/700 VGA output, maybe read this first post then very astute response from another member here.

Again here I'm discussing the VGA signal definition in the TDS500/700 so not the root digital version hacked from the RAMDAC. From the VGA point of view, the signal is 800x600 pixel at 60 Hz and 32 KHz so my 2 questions. When you connect to the RAMDAC, what is the active pixel resolution you decode then does your firmware applies a rescaling to generate 640x480 instead 800x480 ?

Since I have two SimConn labs kit running respectively is my TDS784D and TDS794D, I knew after installing the LCD is 640x480 LVDS so I'm curious to understand why in the first place nobody kept the 800x480 or rescaled to 800x600 ?

On a side note, using the RTD2660 scaler video chip does succeed to generate 640x480 from the 800x480 but requires to modify part of its firmware because 800x480 seems not very common plus does respect the 4:3 aspect ration of 90's.

Thank you in advance, Albert

[nctnico]

A long time ago I did an TFT conversion on an Advantest spectrum analyser as well. I translated 2 horizontal pixels into one using a CPLD and some external memory. IIRC I did the translation based on adjacent intensities to decide what to put on the display. I added an extra connector on the display board to output the image as digital signals. It worked quite well.

This was the result:

[Tantratron]

A long time ago I did an TFT conversion on an Advantest spectrum analyser as well. I translated 2 horizontal pixels into one using a CPLD and some external memory. IIRC I did the translation based on adjacent intensities to decide what to put on the display. I added an extra connector on the display board to output the image as digital signals. It worked quite well.

This was the result:

Amazing what you have done, actually the other thread I did mention in this forum as well as on yahoo advantest forum discusses the retrofit of R3261/R3361. The rendering of your display is super good compared to what i'm obtaining so far because the RTD2660 scaler chip does not have a framebuffer to properly deinterlace (see my video proof of concept).

Would you have kept the schematics or the mathematics on how you did implement, in particular due to the unusual digital video format of these Advantest then how you did enhance pitch resolution ?

[TerrySt]

My TDS-524A RAMDAC uses 640 x 480 resolution.  I believe the VGA output on the back is also 640x480.
This actually made it difficult to find a display, since most have moved to 800x600.
But the one I found is 640x480 so no conversion was required.  The only change I had to make was to the clocking to the LCD, which was a serial (LVDS) instead of the older parallel TTL interface.

Terry

[Tantratron]

Thank you Terry for your return of practice regarding the 640x480 at RAMDAC level.

What is strange with my TDS784D, when connecting its VGA port to a multi-resolution LCD driver with RTD2660 scaler chip standard board (PCB800099-V9), part of my TDS image is lost (see attachements) when I choose 640x480 resolution. I only have 640x480 display to try (either TTL or LVDS) but the RTD2660 chip declares 800x480 for some reason (see again attachments).
Of course, the internal TDS board chip in charge to translate or transcode the RMADAC signals into VGA could be the culprit, no idea.

See below camera picture of my TDS784D with SimConn Labs kit then its VGA output result feeding the RTD2660 chinese driver.

P.S. One reason this caught my attention is that a TDS754A on eBay told me to have installed a 800x600 LCD-display and driver connected to J88 (VGA link).

Albert

[TerrySt]

I don’t know what would be causing the display to lose pixels on the ends like that.  Post 33 shows what I got with my scope. 

Terry

[Tantratron]

Ok Terry, now I verify what you said earlier with your TDS524A. Indeed wether at RAMDAC level or VGA output, same 640x480 resolution with my TDS784D where an external DELL display indicates input to be 640x480. So this means the LCD table allocation of the RTD2660 cheap chinese LCD driver has either a firmware bug or the Sync, the Porches values chosen by tektronix back then in 90's are not so standard fooling the rescaler.

[Tantratron]

Thanks to Terry in this thread and another one, so the native pixel resolution 640x480 at RAMDAC level is indeed 25 MHz. I wanted to push the exercice to compare FPGA approach versus VGA on image quality but for some reason most LCD driver from AliExpress or eBay cannot self-adjust to TDS500/700 resolution neither auto-position the TDSxxx video format. However with an arduino DUE hack (proof of concept) controlling the scaler video chip RTD2660H from this 10 € driver board, it is doable as shown in my quick video this morning.



I'm still interested to go after FPGA wether TDSxxx or another project with Advantest which is more complex because again the RGBs format is not conventional plus frames are interlaced. However it is still an open question which FPGA chip and designing tool to choose, some mention Gowin Tang Nano. Would you have some return of experience or suggestions ?