Yes, you have the right idea. But in practice the sync rates will never be exactly the same.
So you will need to treat them as asynchronous. You'll need at least 3 framebuffer slots to do rate conversion. Then add some very simple logic to increment ecah domain's FB ptr at each frame completion.
Yes, you have the right idea. But in practice the sync rates will never be exactly the same.
So you will need to treat them as asynchronous. You'll need at least 3 framebuffer slots to do rate conversion. Then add some very simple logic to increment ecah domain's FB ptr at each frame completion.
Why three frame buffers? How would you work with them?
The pixel clock (ie time per pixel) etc for VGA is at a different rate to the incoming video signal. Therefore my incoming signal is not synchronised in any way with my outgoing video signal except that they are both 60Hz.
Or.... you can go the other way. Try getting a cheap flat-panel VGA input and lower it's crystal clock at the same ratio 31.5:25. Feeding the video in now, the monitor will think it's actually 31.5Khz by 75Hz.
Also, any old Comodore Multisync screens which supported 15Khz through 36KHz on the horizontal will work directly with this logic analyser output.
A stupid dumb FPGA based line doubler, using an Analog Devices VGA ADC, with a bottom end 15$ Altera FPGA using 2k x 8bit dual-port ram for double each line coming out to a resistor ladder video dac will make a 50Khz X 60Hz video mode of 500xYYY(double your source) (horizontal res is meaningless here, you can call this 640 pixels or 1024 pixels) which is supported by any flat panel today.
With that ADC, you will need a long period PLL clock generating circuit tied to the H-Sync. But if you don't want to deal with an ADC with I2C controls, I understand.
I would wire this to a FPGA which has at least enough internal ram for 5 lines of video, since you are using monochrome, that makes 1kx8 per line x 5, or 6kx8 to be safe. The FPGA will need 1 pll to 2x the clock since you will be making a simple dumb line doubler. IE, 24Khz video in, 50Khz out, the vertical 60hz will remain the same. You will need an 8 bit DAC (unless you are feeding a panel digitally), or resistor DAC with a video opamp to feed the RGB analog in of an LCD screen and a logic buffer to convert the 3.3v sync out of the FPGA to 5v ttl as not all LCD screens like 3.3v.
I would wire this to a FPGA which has at least enough internal ram for 5 lines of video, since you are using monochrome, that makes 1kx8 per line x 5, or 6kx8 to be safe. The FPGA will need 1 pll to 2x the clock since you will be making a simple dumb line doubler. IE, 24Khz video in, 50Khz out, the vertical 60hz will remain the same. You will need an 8 bit DAC (unless you are feeding a panel digitally), or resistor DAC with a video opamp to feed the RGB analog in of an LCD screen and a logic buffer to convert the 3.3v sync out of the FPGA to 5v ttl as not all LCD screens like 3.3v.How would that work?
I'm assuming when he says "CRT scope", he means a traditional scope with arbitrary X-Y-Luma vector drive (where a lissajous circle is drawn by moving the CRT beam in a circle, not by a progressive scan of the screen in Luma-H-V style).
Ok, we got a problem here: After writing and deleting all those posts I made which were correct, and are now gone!
@sokoloff, did you even look at the OT's scope in his thread:
https://keepdevelopingprojects.wordpress.com/2016/01/25/project-crt-oscilloscope-lcd-mod-motivation/
If you want to make a video scan doubler for your 'logic-analyser', (it's not really a scope as it says 'logic analyser' right on the top left of the device)
If you want to make a video scan doubler for your 'logic-analyser', (it's not really a scope as it says 'logic analyser' right on the top left of the device)
If you already have FPGA, it might be easier to build your own logic-analyzer front-end than to interface analog video signal.
Hi,
I am aiming to convert a CRT oscilloscope into an LCD oscilloscope by converting the video signal to VGA using an FPGA. The incoming video format is similar to VGA but uses different timing and voltages.
The pixel clock (ie time per pixel) etc for VGA is at a different rate to the incoming video signal. Therefore my incoming signal is not synchronised in any way with my outgoing video signal except that they are both 60Hz. I'm trying to figure out the best way to deal with this situation.
I was thinking what I could do is have two banks of memory. The incoming frame writes to the banks alternately, and the outgoing frame reads from the banks alternately, such that we never read from a bank at the same time as writing to it. But this assumes that I can keep both displays completely in sync (they are both operating at 60hz). I would then have two different pixel clocks (outgoing and incoming) and the banks of memory would switch between the two clocks and I don't know if this is a good idea?
You can keep both displays in sync. TFT screens allow a wide range of their clocks and synchronisation signals. I have done these kind of conversions several times already. I prefer to use a Xilinx 9500XL series CPLD because these don't need an external config storage and have 5V tolerance. If the incoming and outgoing rate can be made synchronous (no form of interlacing) you don't need any storage.
You can keep both displays in sync. TFT screens allow a wide range of their clocks and synchronisation signals. I have done these kind of conversions several times already. I prefer to use a Xilinx 9500XL series CPLD because these don't need an external config storage and have 5V tolerance. If the incoming and outgoing rate can be made synchronous (no form of interlacing) you don't need any storage.What do you use for memory?
If needed I use an external SRAM. This is a board I made to convert an STN dot matrix LCD into TFT: