Author Topic: Please recommend a VGA to parallel LCD board or IC  (Read 25448 times)

0 Members and 1 Guest are viewing this topic.

Offline Tantratron

  • Frequent Contributor
  • **
  • Posts: 587
  • Country: fr
  • Radio DSP Plasma
    • Tantratron
Re: Please recommend a VGA to parallel LCD board or IC
« Reply #325 on: December 23, 2024, 04:21:15 pm »
Just out of curiosity. The diagram posted for the output has a cvbs output. Have you tried connecting that ? the picture should be suboptimal, but assuming, this was standard crt inputs, timing should be near a standard 480i (or monochrome ntsc). If the picture is centered correctly on cvbs input, and standard TV timings have nearly fixed atcive areas (ignoring under/overscan), one could extrapolate to the active area position of your signal. These signals are commonly digitized with      720HActive,858 Htotal, 119 or 57 HStart (depending on the referenced hsync edge). Pixel Clock is 13.5MHz. One could then extrapolate from 23.5MHz to 20MHz, and should have a good estimate of the active area.
Hallo avst, I'm not sure to fully understand your question, do you mean if I've connected the rear CVBS output from my R3361 equipment to a real television or CRT screen ?
Otherwise the only thing which I did was to connect this CVBS output into another LCD driver hosting MST703 (MStar) able to more or less display the image on my 640x480 screen.

I think the figures which you estimate and suggest above can make sens when checking my arduino routine probing scalers/registers
Code: [Select]
ISP mode entered - DW8051 reset

HSync type detection auto run         => 101
RGBS input
Measure in analog mode
InputMeasData.HFreq -> 15835
InputMeasData.VFreq -> 61
InputMeasData.HTotal -> 1705
InputMeasData.VTotal -> 258
InputMeasData.HSync -> 176
InputMeasData.VSync -> 0
InputMeasData.HSPolarity -> 1
InputMeasData.VSPolarity -> 1


******** Input Frame Window ***********
Input Horizontal Active Start         => 0/25
Input Horizontal Active Width         => 2/186
Input Vertical Active Start           => 0/4
Input Video Vertical Active Lines     => 0/233
Input VSYNC Delay for Capture         => 17
Input HSYNC Delay for Capture         => 109
Input HS/VS Delay                     => 0H
Input Video Horizontal Porch          => 0/0
***************************************

The measurement in analog mode is expressed for horizontal as RTD clocks (27 MHz) whereas my R3361 generates 20 MHz pixel clock. So the duration of 1705 becomes 1705*20/27 equivalent total pixels per line, namely 1263 pixels which confirms what my logic analyzer found.

As for the active horizontal area width, see Input Frame Window part above, it says 2*256+186 = 698 which cmight be expressed in pixels now even though this is analog signal, maybe i'm wrong.

Anywa you mention 858 Htotal at 13.5 MHz so this would make 20/13.5*858 = 1271 which would concur with 1264 pixels estimated by my logic analyzer or the RTD.

 

Online pcprogrammer

  • Super Contributor
  • ***
  • Posts: 4632
  • Country: nl
Re: Please recommend a VGA to parallel LCD board or IC
« Reply #326 on: December 23, 2024, 04:55:02 pm »
And here is a complete image with colors added for the separate parts generated by the device.
Ouah Peter, this is soooo amazing what you have done in a such short time with your FPGA.
Just out curiosity, when I provided you with 8 seconds recording of my full Advantest signalling outputs (Hsync, Vsync, Trace A, Trace B Grid&text, Markers) through my logic analyzer, does your test bench or proof of concept can actually synthetize or emulate say a few seconds of this recording to observe your LCD display dynamics ?
Albert

If only it was with a FPGA. No it is just software on the PC, but it does spit out an image for every full frame found.

I can test it with my Lichee Nano by loading the bitmap files to the SD card and then play them in sequence on the LCD. Not sure what speed it can obtain this way, frames per second wise. My next step already was to write code for the Lichee Nano to display a single image to see how it looks on an actual LCD that I have, and also play with the scaler inside the F1C100s to see what that can do.

For this to be done I first have to change my code to truncate the image back to 1024 pixels per line.

Offline Postal2

  • Frequent Contributor
  • **
  • !
  • Posts: 791
  • Country: ru
Re: Please recommend a VGA to parallel LCD board or IC
« Reply #327 on: December 23, 2024, 05:03:37 pm »
...l Advantest signalling outputs (Hsync, Vsync, Trace A, Trace B Grid&text, Markers) ...
So, the word "full screen" means "bit plane". Then the displayed image, fonts and window with overlay text are placed in the 1024x1024 plane. However, the datasheet says that the X size should be a multiple of 16, and the Y size should be equal to the number of active lines (counting them progressively).
...This confirms that the output is interlaced and has a total of 527 lines of 1264 pixels. Actively used in the attached image are 475 lines of 973 pixels.
The fact that the horizontal active size is a multiple of 16 is easy to understand from the logic of the serializer.
 

Offline KerJoe

  • Contributor
  • Posts: 21
  • Country: 00
Re: Please recommend a VGA to parallel LCD board or IC
« Reply #328 on: December 23, 2024, 05:07:15 pm »
Try using SetFIFOWindow:
Code: [Select]
hact = 1024; vact = 768;
SetFIFOWindow(PANEL_H_ACTIVE < hact ? PANEL_H_ACTIVE : hact, PANEL_V_ACTIVE < vact ? PANEL_V_ACTIVE : vact); // For 1024x768 input, 640x480 output -> SetFIFOWindow(640, 480);

If that doesn't work experiment with SetCaptureWindow:
Code: [Select]
hact = 1024; vact = 768;
SetCaptureWindow(/* 0 - 100 some hstart*/, /* 0 - 100 some vstart*/, hact, vact, /* 0 - 100 some hdelay*/, /* 0 - 100 some vdelay*/);
 

Offline avst

  • Contributor
  • Posts: 27
  • Country: de
Re: Please recommend a VGA to parallel LCD board or IC
« Reply #329 on: December 23, 2024, 05:49:28 pm »
Just out of curiosity. The diagram posted for the output has a cvbs output. Have you tried connecting that ? the picture should be suboptimal, but assuming, this was standard crt inputs, timing should be near a standard 480i (or monochrome ntsc). If the picture is centered correctly on cvbs input, and standard TV timings have nearly fixed atcive areas (ignoring under/overscan), one could extrapolate to the active area position of your signal. These signals are commonly digitized with      720HActive,858 Htotal, 119 or 57 HStart (depending on the referenced hsync edge). Pixel Clock is 13.5MHz. One could then extrapolate from 23.5MHz to 20MHz, and should have a good estimate of the active area.
Hallo avst, I'm not sure to fully understand your question, do you mean if I've connected the rear CVBS output from my R3361 equipment to a real television or CRT screen ?
Otherwise the only thing which I did was to connect this CVBS output into another LCD driver hosting MST703 (MStar) able to more or less display the image on my 640x480 screen.

I think the figures which you estimate and suggest above can make sens when checking my arduino routine probing scalers/registers
Code: [Select]
ISP mode entered - DW8051 reset

HSync type detection auto run         => 101
RGBS input
Measure in analog mode
InputMeasData.HFreq -> 15835
InputMeasData.VFreq -> 61
InputMeasData.HTotal -> 1705
InputMeasData.VTotal -> 258
InputMeasData.HSync -> 176
InputMeasData.VSync -> 0
InputMeasData.HSPolarity -> 1
InputMeasData.VSPolarity -> 1


******** Input Frame Window ***********
Input Horizontal Active Start         => 0/25
Input Horizontal Active Width         => 2/186
Input Vertical Active Start           => 0/4
Input Video Vertical Active Lines     => 0/233
Input VSYNC Delay for Capture         => 17
Input HSYNC Delay for Capture         => 109
Input HS/VS Delay                     => 0H
Input Video Horizontal Porch          => 0/0
***************************************

The measurement in analog mode is expressed for horizontal as RTD clocks (27 MHz) whereas my R3361 generates 20 MHz pixel clock. So the duration of 1705 becomes 1705*20/27 equivalent total pixels per line, namely 1263 pixels which confirms what my logic analyzer found.

As for the active horizontal area width, see Input Frame Window part above, it says 2*256+186 = 698 which cmight be expressed in pixels now even though this is analog signal, maybe i'm wrong.

Anywa you mention 858 Htotal at 13.5 MHz so this would make 20/13.5*858 = 1271 which would concur with 1264 pixels estimated by my logic analyzer or the RTD.

From the pictures of the realtek boards on the web, these seemed to have a cvbs input. I was thinking about that one. 27MHz is normally used to digitize cvbs signals, but these are 422 YUV, so two bytes per clock. Yours doesn't have color, so 13.5Mhz is sufficient ( as a side note 27MHz or 13.5Mhz and 720 pixel don't produce square pixels, and the aspect ratio isn't exactly 4:3. But i think it was easier to take a 27MHz crystal, and use that for both 480i and 576i systems ).
Even though you have an analog signal, it is created by a digital circuit, so don't have a 100% analog signal, in the sense it is continuous. It still has discrete pixels at a fixed sample rate. Thats why you should also sample the signal at exact that sample rate for best results.
 

Offline Tantratron

  • Frequent Contributor
  • **
  • Posts: 587
  • Country: fr
  • Radio DSP Plasma
    • Tantratron
Re: Please recommend a VGA to parallel LCD board or IC
« Reply #330 on: December 23, 2024, 05:56:34 pm »
Try using SetFIFOWindow:
Code: [Select]
hact = 1024; vact = 768;
SetFIFOWindow(PANEL_H_ACTIVE < hact ? PANEL_H_ACTIVE : hact, PANEL_V_ACTIVE < vact ? PANEL_V_ACTIVE : vact); // For 1024x768 input, 640x480 output -> SetFIFOWindow(640, 480);

If that doesn't work experiment with SetCaptureWindow:
Code: [Select]
hact = 1024; vact = 768;
SetCaptureWindow(/* 0 - 100 some hstart*/, /* 0 - 100 some vstart*/, hact, vact, /* 0 - 100 some hdelay*/, /* 0 - 100 some vdelay*/);
Ok now that I set hact = 1024 and vact = 768 prior calling both your scaling up and down routines, it works fine and stay same as when OpenRTD firmware runs. I can either choose 640x480 or 800x480 as active panel values, it will always work having in mind my LCD is 640x480 but initially OpenRTD is set for !00x480. If I leave 800x480 then of course, right image is truncated since my display is not enough large in resolution but the image is very good.

Note that if call SetFIFOWindow(640, 480) then image is super scrambled whereas no call, it will work just fine.

My problem is to experiment reducing the vertical image shown on my LCD but reducing the horizontal image works fine with no need to call SetFIFOWindow or SetCaptureWindow
 

Online pcprogrammer

  • Super Contributor
  • ***
  • Posts: 4632
  • Country: nl
Re: Please recommend a VGA to parallel LCD board or IC
« Reply #331 on: December 23, 2024, 06:01:54 pm »
Even though you have an analog signal, it is created by a digital circuit, so don't have a 100% analog signal, in the sense it is continuous. It still has discrete pixels at a fixed sample rate. Thats why you should also sample the signal at exact that sample rate for best results.

That is why I suggested using a FPGA to sample the digital signals from the device and use tmds lanes to (HDMI) feed the de-interlaced signal into the RTD2660 to let that one handle the scaling.

Offline Tantratron

  • Frequent Contributor
  • **
  • Posts: 587
  • Country: fr
  • Radio DSP Plasma
    • Tantratron
Re: Please recommend a VGA to parallel LCD board or IC
« Reply #332 on: December 23, 2024, 06:04:19 pm »
From the pictures of the realtek boards on the web, these seemed to have a cvbs input. I was thinking about that one. 27MHz is normally used to digitize cvbs signals, but these are 422 YUV, so two bytes per clock. Yours doesn't have color, so 13.5Mhz is sufficient ( as a side note 27MHz or 13.5Mhz and 720 pixel don't produce square pixels, and the aspect ratio isn't exactly 4:3. But i think it was easier to take a 27MHz crystal, and use that for both 480i and 576i systems ).
OK now I understand so yes, all my boards do have CVBS input connector but only the MST703 based board does work with my CBVS signal as input.

None of my three RTD2660 boards work with CVBS, not saying they cannot work since they have the CVBS jack but probably the firmware was not developped when CVBS is interlaced, no idea.

N.B. I've ordered another spare PCB800099-V9 from AliExpress which should arrive end of december or early january so we will see.

Ironically the OpenRTD firmware which I've flashed on my PCB800099-V9 shows by menu AV1 or AV2 choice but again when connecting my specific CBVS signal, it will not support.
 

Offline avst

  • Contributor
  • Posts: 27
  • Country: de
Re: Please recommend a VGA to parallel LCD board or IC
« Reply #333 on: December 23, 2024, 06:18:20 pm »
Even though you have an analog signal, it is created by a digital circuit, so don't have a 100% analog signal, in the sense it is continuous. It still has discrete pixels at a fixed sample rate. Thats why you should also sample the signal at exact that sample rate for best results.

That is why I suggested using a FPGA to sample the digital signals from the device and use tmds lanes to (HDMI) feed the de-interlaced signal into the RTD2660 to let that one handle the scaling.
That is also of what i was thinking of. I would probably take it a step further, and also do the scaling in the fpga (if i was smart enough for it). Probably not as easy, but doable. The big plus here is, you have a well (more or less) defined source. You don't need universal scaling, which makes life so much harder. No input measurement, no frame rate conversion etc.
I probably would start generating a pseudo VGA signal with some resistor, just to avoid dealing with dvi/hdmi stuff, but its true DVI would be the better chioce afterwards. But even better if you could direct drive the LCD.
 

Offline KerJoe

  • Contributor
  • Posts: 21
  • Country: 00
Re: Please recommend a VGA to parallel LCD board or IC
« Reply #334 on: December 23, 2024, 06:22:22 pm »
Note that if call SetFIFOWindow(640, 480) then image is super scrambled whereas no call, it will work just fine.

If you have the same scrambling as portrayed here:
You may need to adjust the panel pixel clock frequency so that input and output horizontal frequencies match and there is no overrun/underrun in the FIFO:
Code: [Select]
SetDPLLFrequncy((PANEL_H_SYNC_WIDTH + PANEL_H_BACK_PORCH + PANEL_H_ACTIVE + PANEL_H_FRONT_PORCH) * inputMeasData.HFreq / vact * PANEL_V_ACTIVE)

If that fails you can try modifying the output timings via port registers 0x2A and 0x2B to match your 640x480 panel.
 

Online pcprogrammer

  • Super Contributor
  • ***
  • Posts: 4632
  • Country: nl
Re: Please recommend a VGA to parallel LCD board or IC
« Reply #335 on: December 23, 2024, 06:28:35 pm »
That is also of what i was thinking of. I would probably take it a step further, and also do the scaling in the fpga (if i was smart enough for it). Probably not as easy, but doable. The big plus here is, you have a well (more or less) defined source. You don't need universal scaling, which makes life so much harder. No input measurement, no frame rate conversion etc.
I probably would start generating a pseudo VGA signal with some resistor, just to avoid dealing with dvi/hdmi stuff, but its true DVI would be the better chioce afterwards. But even better if you could direct drive the LCD.

That is my problem with the scaling too. No idea how to do 2D dithering and filtering. The source of the video is very well defined in this case. You even get the 20MHz clock to load the pixels into the memory.

Directly driving the LCD from the FPGA is indeed the best and the Tang Nano 9K even has a connector for it on board. Same does the 20K, which I ordered a couple of days ago. Lost of fun projects that it can be used for.

Offline avst

  • Contributor
  • Posts: 27
  • Country: de
Re: Please recommend a VGA to parallel LCD board or IC
« Reply #336 on: December 23, 2024, 06:45:51 pm »
That is also of what i was thinking of. I would probably take it a step further, and also do the scaling in the fpga (if i was smart enough for it). Probably not as easy, but doable. The big plus here is, you have a well (more or less) defined source. You don't need universal scaling, which makes life so much harder. No input measurement, no frame rate conversion etc.
I probably would start generating a pseudo VGA signal with some resistor, just to avoid dealing with dvi/hdmi stuff, but its true DVI would be the better chioce afterwards. But even better if you could direct drive the LCD.

That is my problem with the scaling too. No idea how to do 2D dithering and filtering. The source of the video is very well defined in this case. You even get the 20MHz clock to load the pixels into the memory.

Directly driving the LCD from the FPGA is indeed the best and the Tang Nano 9K even has a connector for it on board. Same does the 20K, which I ordered a couple of days ago. Lost of fun projects that it can be used for.
If you stick to panel of 640 or 800 by 480, no vertical scaling would be required, which i assume is the harder part. Horizontal scaling should be somewhat easier. Basically this should just be some kind of digital filter (never done that before in a fpga, but there is lots of info available).
To avoid frame tear, you could just read the frame buffer at the double rate of the input, outputing two lines for every input line. Add a small delay to start reading the output, and then the output would never catch the input. This way you avoid multiple frame buffers.
 

Online pcprogrammer

  • Super Contributor
  • ***
  • Posts: 4632
  • Country: nl
Re: Please recommend a VGA to parallel LCD board or IC
« Reply #337 on: December 23, 2024, 06:53:28 pm »
If you stick to panel of 640 or 800 by 480, no vertical scaling would be required, which i assume is the harder part. Horizontal scaling should be somewhat easier. Basically this should just be some kind of digital filter (never done that before in a fpga, but there is lots of info available).
To avoid frame tear, you could just read the frame buffer at the double rate of the input, outputing two lines for every input line. Add a small delay to start reading the output, and then the output would never catch the input. This way you avoid multiple frame buffers.

I have done some filtering in code, but never in hardware, but a low pass filter should be doable. On the other hand if a 1024*600 display is used there is no need for any of it, because the used number of horizontal pictures is less than the 1024. The aspect ratio is different, but my images posted before show that it is not to bad. The one clue that things are wrong is the fact that the raster on the screen does not have square boxes.

Here is one trimmed and expanded to fit 1024*600.

Edit: Come to think of it, the CRT in the spectrum analyzer does this in the analog domain. In some way it squeezes the pixels in a shorter space.
« Last Edit: December 23, 2024, 07:10:02 pm by pcprogrammer »
 

Online pcprogrammer

  • Super Contributor
  • ***
  • Posts: 4632
  • Country: nl
Re: Please recommend a VGA to parallel LCD board or IC
« Reply #338 on: December 23, 2024, 07:58:00 pm »
Here is a picture of the image I outputted from the capture data on the 1024*600 screen connected to my Lichee Nano.

It looks a bit better in real life, but it is not as bright as a CRT. There is also a packed in plastic touch panel in front of it. It is a prototype after all.  :-DD

I have to check the backlight driver and specifications of the LCD panel to see if it can be improved.

Also need to load my program and the images onto a faster SD card. This 128MB card I'm testing with to startup in FEL mode is slow, and after loading the program I could see the image being written to the display from top to bottom. No way it can do multiple frames a second with that card.  :palm:

Ah well, tomorrow is another day.

Offline Tantratron

  • Frequent Contributor
  • **
  • Posts: 587
  • Country: fr
  • Radio DSP Plasma
    • Tantratron
Re: Please recommend a VGA to parallel LCD board or IC
« Reply #339 on: December 23, 2024, 08:20:05 pm »
Note that if call SetFIFOWindow(640, 480) then image is super scrambled whereas no call, it will work just fine.

If you have the same scrambling as portrayed here...
You may need to adjust the panel pixel clock frequency so that input and output horizontal frequencies match and there is no overrun/underrun in the FIFO:
Code: [Select]
SetDPLLFrequncy((PANEL_H_SYNC_WIDTH + PANEL_H_BACK_PORCH + PANEL_H_ACTIVE + PANEL_H_FRONT_PORCH) * inputMeasData.HFreq / vact * PANEL_V_ACTIVE)

If that fails you can try modifying the output timings via port registers 0x2A and 0x2B to match your 640x480 panel.
OK the scrambling I refer to is when I explicitly call your routine SetFIFOWindow() after having called both your ScaleUp() and ScaleDown() routines which work fine now if and only if horizontal scaling.

See attached good picture without calling SetFIFOWindow() then when calling SetFIFOWindow()
 

Offline Tantratron

  • Frequent Contributor
  • **
  • Posts: 587
  • Country: fr
  • Radio DSP Plasma
    • Tantratron
Re: Please recommend a VGA to parallel LCD board or IC
« Reply #340 on: December 24, 2024, 07:07:01 am »
Hello KerJoe,

I think to have partially understood the issue with SetFIFOWindow routine, now my arduino sketch will read the content of FIFO via this specific code
Code: [Select]
// FIFO Window parameters
  ScalerWriteByte(0x30,0x00);
  FIFO_MSB = ScalerReadByte(0x31); // read FIFO 31-00
  Serial.print("FIFO: Display window read width before scaling up        => ");Serial.println(((FIFO_MSB & 0x30) << 4) + ScalerReadByte(0x31),DEC); // width from FIFO 31-01
  Serial.print("FIFO: Display window read length before scaling up       => ");Serial.println(((FIFO_MSB & 0x3) << 8) + ScalerReadByte(0x31),DEC); // length from FIFO 31-02
  Serial.println();

OpenRTD firmware considers always the display to 800x480 wether VGA or RGBS, it is normal because JagDroid requested that specification. Here are the values of FIFO content parameters prior any rescaling attempt.

VGA case
Code: [Select]
FIFO: Display window read width before scaling up        => 800
FIFO: Display window read length before scaling up       => 480

RGBS case
Code: [Select]
FIFO: Display window read width before scaling up        => 698
FIFO: Display window read length before scaling up       => 233

When VGA case, if I call your SetFIFOWindow(800, 480), everything stays the same, no scrambling which is normal. However if I call SetFIFOWindow(640, 480) then image is scrambled as shown before so recalling SetFIFOWindow(800, 480) resumes correct image.

I still do not understand the FIFO values when RGBS.

As a synthesis which could make sense for you, here are more complete parameters tracking or debugging.

VGA case
Code: [Select]
ISP mode entered - DW8051 reset

HSync type detection auto run         => 110
VGA input
Measure in analog mode
InputMeasData.HFreq -> 48387
InputMeasData.VFreq -> 60
InputMeasData.HTotal -> 558
InputMeasData.VTotal -> 805
InputMeasData.HSync -> 60
InputMeasData.VSync -> 799
InputMeasData.HSPolarity -> 1
InputMeasData.VSPolarity -> 0

Measure in digital mode
InputMeasData.HTotal -> 1343
InputMeasData.VTotal -> 805
InputMeasData.HSync -> 143
InputMeasData.VSync -> 799
InputMeasData.HSPolarity -> 1
InputMeasData.VSPolarity -> 0


******** Input Frame Window ***********
Input Horizontal Active Start         => 179
Input Horizontal Active Width         => 1024
Input Vertical Active Start           => 17
Input Video Vertical Active Lines     => 768
Input VSYNC Delay for Capture         => 18
Input HSYNC Delay for Capture         => 109
Input HS/VS Delay                     => 0H
Input Video Horizontal Porch          => 0
***************************************

FIFO: Display window read width before scaling up        => 800
FIFO: Display window read length before scaling up       => 480

Inside ScaleUP
scaling factors computed by OPENRTD2662 with 800x480 display
F/FF/FF
F/FF/FF
scaling factors computed by KERJOE with 640x480 display
9/99/99
9/99/99

Inside ScaleDown
scaling factors computed by OPENRTD2662 with 800x480 display
14/7A/E2
19/99/99
scaling factors computed by KERJOE with 640x480 display
19/99/99
19/99/99

RGBS case
Code: [Select]
ISP mode entered - DW8051 reset

HSync type detection auto run         => 101
RGBS input
Measure in analog mode
InputMeasData.HFreq -> 15835
InputMeasData.VFreq -> 61
InputMeasData.HTotal -> 1705
InputMeasData.VTotal -> 258
InputMeasData.HSync -> 176
InputMeasData.VSync -> 0
InputMeasData.HSPolarity -> 1
InputMeasData.VSPolarity -> 1


******** Input Frame Window ***********
Input Horizontal Active Start         => 25
Input Horizontal Active Width         => 698
Input Vertical Active Start           => 4
Input Video Vertical Active Lines     => 233
Input VSYNC Delay for Capture         => 17
Input HSYNC Delay for Capture         => 109
Input HS/VS Delay                     => 0H
Input Video Horizontal Porch          => 0
***************************************

FIFO: Display window read width before scaling up        => 698
FIFO: Display window read length before scaling up       => 233

Inside ScaleUP
scaling factors computed by OPENRTD2662 with 800x480 display
D/F5/C3
7/C4/44
scaling factors computed by KERJOE with 640x480 display
9/99/99
9/99/99

Inside ScaleDown
scaling factors computed by OPENRTD2662 with 800x480 display
0/0/0
0/0/0
scaling factors computed by KERJOE with 640x480 display
19/99/99
19/99/99

Note that now in VGA, calling your ScalingUp and ScalingDown routines works fine, I just need to provide active values instead of total values.

However I still do not understand how I could modify the rescaling of OpenRTD with RGBS case (the image is both truncated at the bottom and on the right) where I leave aside the topic of blurry or flickering.
 

Offline Postal2

  • Frequent Contributor
  • **
  • !
  • Posts: 791
  • Country: ru
Re: Please recommend a VGA to parallel LCD board or IC
« Reply #341 on: December 24, 2024, 07:11:19 am »
Most likely I made a mistake and Am95C60 draws lines in one pixel. The simplest command "line" will draw a line 1 pixel thick. To draw a line 2 pixels thick, you need to program a brush. And although the brush is programmed for a marker, in 1991 no one would have thought to complicate the standard line drawing. Therefore, RTD2660 and any other LCD controller that does not have a frame buffer will output horizontal dot-lines with 30 Hz flickering.

TV chips always have a frame buffer.
The photo shows the installation of a panel for MSD3663. You can set 1024x600. Unfortunately, I could not check all available panels, there are many, but switching occurs immediately, and I simply do not see the result.
I will also put the firmware from it if someone wants to unpack and read the list of available panels.
« Last Edit: December 24, 2024, 07:50:57 am by Postal2 »
 

Offline Tantratron

  • Frequent Contributor
  • **
  • Posts: 587
  • Country: fr
  • Radio DSP Plasma
    • Tantratron
Re: Please recommend a VGA to parallel LCD board or IC
« Reply #342 on: December 24, 2024, 09:50:33 am »
To avoid frame tear, you could just read the frame buffer at the double rate of the input, outputing two lines for every input line. Add a small delay to start reading the output, and then the output would never catch the input. This way you avoid multiple frame buffers.
Do you know any specific chip or assembly of known logic gates 74xx which could do this stacking serializing without the need to go after a FPGA development ?
This re-framing construction seems quite deterministic since we have already DOTCLK, HSYNC and VSYNC separate signals.
 

Offline KerJoe

  • Contributor
  • Posts: 21
  • Country: 00
Re: Please recommend a VGA to parallel LCD board or IC
« Reply #343 on: December 24, 2024, 11:25:09 am »
The FIFO value is set to the minimum width/height of input/output. So for your RGBS signal it should be 640x233. Please also try to change the display clock, display output timings and the capture window value.
 

Offline avst

  • Contributor
  • Posts: 27
  • Country: de
Re: Please recommend a VGA to parallel LCD board or IC
« Reply #344 on: December 24, 2024, 12:04:50 pm »
To avoid frame tear, you could just read the frame buffer at the double rate of the input, outputing two lines for every input line. Add a small delay to start reading the output, and then the output would never catch the input. This way you avoid multiple frame buffers.
Do you know any specific chip or assembly of known logic gates 74xx which could do this stacking serializing without the need to go after a FPGA development ?
This re-framing construction seems quite deterministic since we have already DOTCLK, HSYNC and VSYNC separate signals.
Probably could be done with a dual ported ram and some counters, glue logic and a pll or clock doubler.  Chip count would be quite high, and the details could be tricky, as when to generate the syncs for the output, determining the even/odd frames, etc. A PLD lets much more room for tweaking everything until its right.
 

Offline avst

  • Contributor
  • Posts: 27
  • Country: de
Re: Please recommend a VGA to parallel LCD board or IC
« Reply #345 on: December 24, 2024, 12:18:22 pm »
TV chips always have a frame buffer.
Not quite true. At the time the RTD2660 came to the market, incorporating memory was expensive, and LCD resolutions for affordable panels was low. Chips like the RTD2660 where made for the lower end of TV sets or monitors, where every cent possible counted. There where solutions with frame buffers, but at more than the double price. Even today there are scaler chips for analog cvbs signals, e.g. TW8847, which are used mainly for stuff like security cameras, rearview cameras etc., which don't have frame buffers. With small low resolution LCDs and real world images, this is ok, just not for digitaly created images.
 

Offline Tantratron

  • Frequent Contributor
  • **
  • Posts: 587
  • Country: fr
  • Radio DSP Plasma
    • Tantratron
Re: Please recommend a VGA to parallel LCD board or IC
« Reply #346 on: December 24, 2024, 12:24:25 pm »
The FIFO value is set to the minimum width/height of input/output. So for your RGBS signal it should be 640x233. Please also try to change the display clock, display output timings and the capture window value.
Ok thanks where I'm trying progressively through reading the datasheet, your source file to really understand the key parameters. Some aspects are still not clear for me like how to mathematically link the analog or digital mode measurements versus input frame window and now the LCD display format.

Please remember my testing and learning methodology, I run the OpenRTD firmware connected to either my VGA or RGBs then try to either read some parameters or modify other parameters via my arduino VGA-i2c channel.  One of my objective wether image is flickering or not would be to live change the scaling result so the RGBS would not be truncated anymore (bottom and right).

In the meantime, I've now added this reading code to understand the different parameters, maybe you can check if i've done something wrong plus help learn how the values are connected.

My extract updated code
Code: [Select]
// reads input frame window parameters
  Serial.println("******** Input Frame Window ************");
  Serial.print("Input Horizontal Active Start         => ");Serial.println((ScalerReadByte(0x14) << 8) + ScalerReadByte(0x15),DEC);
  Serial.print("Input Horizontal Active Width         => ");Serial.println(((ScalerReadByte(0x16) & 0x7) << 8) + ScalerReadByte(0x17),DEC);
  Serial.print("Input Vertical Active Start           => ");Serial.println(((ScalerReadByte(0x18) & 0x7) << 8) + ScalerReadByte(0x19),DEC);
  Serial.print("Input Video Vertical Active Lines     => ");Serial.println(((ScalerReadByte(0x1A) & 0x7) << 8) + ScalerReadByte(0x1B),DEC);
  Serial.print("Input VSYNC Delay for Capture         => ");Serial.println(ScalerReadByte(0x1C),DEC);
  Serial.print("Input HSYNC Delay for Capture         => ");Serial.println(ScalerReadByte(0x1D),DEC);
  Serial.print("Input HS/VS Delay                     => ");Serial.print(ScalerReadByte(0x1E),HEX);Serial.println("H");
  Serial.print("Input Video Horizontal Porch          => ");Serial.println(((ScalerReadByte(0x1F) & 0x7) << 8) + ScalerReadByte(0x20),DEC);
  Serial.println("****************************************");
  Serial.println();

// reads display format parameters (auto-increment is self-activated)
  ScalerWriteByte(0x2A,ScalerReadByte(0x2A) & 0xC0);
  Serial.println("******** Display format     ************");
  Serial.print("Display horizontal total pixels       => ");Serial.println(((ScalerReadByte(0x2B) & 0xF) << 8) + ScalerReadByte(0x2B),DEC);
  Serial.print("Display horizontal sync end           => ");Serial.println(ScalerReadByte(0x2B),DEC);
  Serial.print("Display horizontal background start   => ");Serial.println(((ScalerReadByte(0x2B) & 0xF) << 8) + ScalerReadByte(0x2B),DEC);
  Serial.print("Display horizontal active start       => ");Serial.println(((ScalerReadByte(0x2B) & 0xF) << 8) + ScalerReadByte(0x2B),DEC);
  Serial.print("Display horizontal active end         => ");Serial.println(((ScalerReadByte(0x2B) & 0xF) << 8) + ScalerReadByte(0x2B),DEC);
  Serial.print("Display horizontal background end     => ");Serial.println(((ScalerReadByte(0x2B) & 0xF) << 8) + ScalerReadByte(0x2B),DEC);
  Serial.print("Display vertical total lines          => ");Serial.println(((ScalerReadByte(0x2B) & 0xF) << 8) + ScalerReadByte(0x2B),DEC);
  Serial.print("Display vertical sync end             => ");Serial.println((ScalerReadByte(0x2B) & 0x1F),DEC);
  Serial.print("Display vertical background start     => ");Serial.println(((ScalerReadByte(0x2B) & 0xF) << 8) + ScalerReadByte(0x2B),DEC);
  Serial.print("Display vertical active start         => ");Serial.println(((ScalerReadByte(0x2B) & 0xF) << 8) + ScalerReadByte(0x2B),DEC);
  Serial.print("Display vertical active end           => ");Serial.println(((ScalerReadByte(0x2B) & 0xF) << 8) + ScalerReadByte(0x2B),DEC);
  Serial.print("Display vertical background end       => ");Serial.println(((ScalerReadByte(0x2B) & 0xF) << 8) + ScalerReadByte(0x2B),DEC);
  Serial.println("****************************************");
  Serial.println();
 
// FIFO Window parameters
  ScalerWriteByte(0x30,0x00);
  FIFO_MSB = ScalerReadByte(0x31); // read FIFO 31-00
  Serial.print("FIFO: Display window read width before scaling up        => ");Serial.println(((FIFO_MSB & 0x30) << 4) + ScalerReadByte(0x31),DEC); // width from FIFO 31-01
  Serial.print("FIFO: Display window read length before scaling up       => ");Serial.println(((FIFO_MSB & 0x3) << 8) + ScalerReadByte(0x31),DEC); // length from FIFO 31-02
  Serial.println();

Globally here are the different values read with VGA input
Code: [Select]
ISP mode entered - DW8051 reset

HSync type detection auto run         => 110
VGA input
Measure in analog mode
InputMeasData.HFreq -> 48387
InputMeasData.VFreq -> 60
InputMeasData.HTotal -> 558
InputMeasData.VTotal -> 805
InputMeasData.HSync -> 60
InputMeasData.VSync -> 799
InputMeasData.HSPolarity -> 1
InputMeasData.VSPolarity -> 0

Measure in digital mode
InputMeasData.HTotal -> 1343
InputMeasData.VTotal -> 805
InputMeasData.HSync -> 144
InputMeasData.VSync -> 799
InputMeasData.HSPolarity -> 1
InputMeasData.VSPolarity -> 0


******** Input Frame Window ************
Input Horizontal Active Start         => 179
Input Horizontal Active Width         => 1024
Input Vertical Active Start           => 17
Input Video Vertical Active Lines     => 768
Input VSYNC Delay for Capture         => 18
Input HSYNC Delay for Capture         => 109
Input HS/VS Delay                     => 0H
Input Video Horizontal Porch          => 0
****************************************

******** Display format     ************
Display horizontal total pixels        => 956
Display horizontal sync end            => 16
Display horizontal background start    => 32
Display horizontal active start        => 32
Display horizontal active end          => 832
Display horizontal background end      => 832
Display vertical total lines           => 567
Display vertical sync end              => 3
Display vertical background start      => 12
Display vertical active start          => 12
Display vertical active end            => 492
Display vertical background end        => 492
****************************************

For example, I still do not fully understand the mathematical relations between 956 display horizontal pixels, 832 horizontal active end versus active width 1024, HTotal of 1343, the FIFO sizing... ?

Another question: does the scalingup or scalingdown affects all the brute total line or column sizing ?

Thank you
« Last Edit: December 24, 2024, 03:12:03 pm by Tantratron »
 

Offline Postal2

  • Frequent Contributor
  • **
  • !
  • Posts: 791
  • Country: ru
Re: Please recommend a VGA to parallel LCD board or IC
« Reply #347 on: December 24, 2024, 12:40:26 pm »
.... just not for digitaly created images.
The problem is not with the digital image, but with ensuring compatibility with the built-in CRT. If it weren't for this, then with a couple of commands you can reprogram the Am95C60 to the desired scan rate without affecting the operation of the device.
 

Offline KerJoe

  • Contributor
  • Posts: 21
  • Country: 00
Re: Please recommend a VGA to parallel LCD board or IC
« Reply #348 on: December 24, 2024, 02:14:48 pm »
OK, so I checked how the ScaleDown function works with a mismatched panel (1024x600) and RTD2662 (1366x768) active resolution. Here's how I've done the scale down to native resolution of the panel:
Code: [Select]
ScaleDown(hact, vact, 1024, 600);
SetFIFOWindow(1024, 600);
SetDPLLFrequncy((PANEL_HSYNC_WIDTH + PANEL_HBACK_PORCH + 1366 /*PANEL_HACTIVE*/ + PANEL_HFRONT_PORCH) * inputMeasData.HFreq / vact * 600)
Therefore for your case it should be
Code: [Select]
ScaleDown(hact, vact, 640, 480);
SetFIFOWindow(640, 480);
SetDPLLFrequncy((64 + 26 + 800 + 0) * inputMeasData.HFreq / vact * 480)

To only scale vertically I ran:
Code: [Select]
ScaleDown(hact, vact, 1366, 600)
SetDPLLFrequncy((PANEL_HSYNC_WIDTH + PANEL_HBACK_PORCH + 1366 /*PANEL_HACTIVE*/ + PANEL_HFRONT_PORCH) * InputMeasData.HFreq / vact * 600)
Therefore for your case it should be:
Code: [Select]
ScaleDown(hact, vact, 800, 480)
SetDPLLFrequncy((64 + 26 + 800 + 0) * inputMeasData.HFreq / vact * 480)
 
The following users thanked this post: Tantratron

Offline Tantratron

  • Frequent Contributor
  • **
  • Posts: 587
  • Country: fr
  • Radio DSP Plasma
    • Tantratron
Re: Please recommend a VGA to parallel LCD board or IC
« Reply #349 on: December 24, 2024, 02:28:15 pm »
As most of you know, I'm quite new to video processing but I do have a question regarding YPbPr mode which seems to be found in RTD2660. In fact, the synoptic diagram or chip data flow mentions YPbPr/VGA/HDMI but no RGBs so my question: does YPbPr is always progressive or can it be interlaced ?

Unless I'm wrong, all the CVBS jack input connector found on these LCD driver boards (i.e. PCB800099) would only work for YPbPr or what other composite format then are they interlaced or only progressive ?

One reason I start to have doubts, please check for example this decoder attached datasheet where unless i'm wrong, I do not see YPbPr to be interlaced. Only YUV mode would be interlaced but does the RTD2660 able to decode such signal and what video display quality ?

The RTD2660 datasheet mentions de-interlace function as well as de-composite function but are the operations offering good image quality output at the end ?

Another way to understand my question, are we in a specific twilight zone with my RGBs interlaced 15 KHz signal which was never covered by any firmware except OpenRTD2662 ?
« Last Edit: December 24, 2024, 03:23:20 pm by Tantratron »
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf