Please recommend a VGA to parallel LCD board or IC

[avst]

It is clear that I need to put much more effort and focus to learn porch, APLL and DPPL modification programming

The steps these firmwares take are more or less:

• Detect the signal (activity on sync signals)
• Measure availabe data: Vtotal, Hor. frequency, Ver. frequency, sync polarity and sync width
• Lookup or calculate missing values, Htotal, Hstart and Vstart. Mostly done with a large lookup table. If there is not perfect match, take something similar
• With the Htotal value, the sampling clock can be determined to setup the source pll.
• From the values obtained, the input capture area (position and size) can be setup
• With the horizontal and vertical active, the scaling can be calculated
• From the scaling the pixel clock for the output can be calculated to setup the output pll
• Now the output interface can be setup and the LCD enabled. Note that the output timing varies depending on the input timing, and there are cases, where the output timing would be outside the LCD specs.
• Most often, the table or calculated values will not be perfect, so some fine tuning has to be done (HTotal, sampling phase and position).This is the auto adjust most firmwares offer. These differ from chip to chip, but all are image dependent, which is not 100% bulletproof. E.g. horizontal/vertical position may be deduced from the first non black pixel.
• Sometimes the ADC range can be auto adjusted, provided a suitable image is displayed.
• After everything is finished, the firmware monitors the input timing, to start the whole cycle again, if a significant change occurs

[Tantratron]

Regarding 15kHz operation, the chip is definitely capable of decoding video in that form, but no available firmware does it, as far as I know. The only example I know of is a 5 inch screen labeled Eyoyo, which at least supports 480i operation.

Hello @ahrlad, I've found this first thread discussing Eyoyo with interesting pictures and comments. But are you really sure this RTD2660H firmware does 480i or have you tried yourself ?
No where in the thread I clearly see this product to eat as an input an interlaced 15 KHz RGBS. It does mention YPbPr which is of your interest but that is only three signal input where the synchronization is embedded inside Y signal.
I've found recent details from Eyoyo in this page but I do not see clearly its capacity to deal with 480i or something close from my RGBs interlaced.

[Tantratron]

Here is an update regarding the same vendor from which I've ordered two PCB800099-V9 boards (one 5 december then another 20 december). I note one board has the RTD2660H chip sanded or hidden whereas the other is clearly marked. As a reminder from an old post and discussion, I put in the attached picture the 3 board which I had over-heating problems and no stable firmware execution. I'll see one of these days if that board can be fixed, I start to think the problem is one of its local power supply unless one PCB traces is at fault but comparing side by side some volatge shows a clear difference. One issue is the LDO in charge to generate the 1.8 V from the 3.3 V where if no power, my DMM will read very low value to GND on its 2 output pins. However when power on, it will make separate 1.8 V and 3.3 V on both output pins so this is really wierd. I suspect the switch buttons could be affected by this problem because their voltage result does control what the RTD2660 will do. I'll make later a specific thread to see if my 3rd board can be fixed but I'm attaching local view of this LDO.

Anyway i'm very happy with this model purchased here on AliExpress where the connectors are stronger, firmware stable, PCB neat soldering and price low. It is still not clear all the different jumpers possibilities versus which LCD display (attached two datasheet) but I have enough choice to inspect registers/scalers via my arduino sketch to consolidate my understanding on how to program the RTD2260H.

[ahrlad]

Regarding 15kHz operation, the chip is definitely capable of decoding video in that form, but no available firmware does it, as far as I know. The only example I know of is a 5 inch screen labeled Eyoyo, which at least supports 480i operation.

Hello @ahrlad, I've found this first thread discussing Eyoyo with interesting pictures and comments. But are you really sure this RTD2660H firmware does 480i or have you tried yourself ?
No where in the thread I clearly see this product to eat as an input an interlaced 15 KHz RGBS. It does mention YPbPr which is of your interest but that is only three signal input where the synchronization is embedded inside Y signal.
I've found recent details from Eyoyo in this page but I do not see clearly its capacity to deal with 480i or something close from my RGBs interlaced.

Hello!

No, I haven't used the screen myself and I couldn't say confidently that it'd support your signal. With both VGA and YpBpR the different firmwares compare the input to a list of known video formats, and yours probably wouldn't find a match.

[timeandfrequency]

Regarding my specific test to learn how to program different registers/scalers, as mentioned I've used now the VGA output signal from one of my TDS500/700 oscilloscopes. These were designed by tektronix in the early or mid 90's. When reading their theory of operation service manual, it is not clear where does the 800x480 resolution comes but it is a variant situation as with the Advantest SA of end of 80's, namely inside their video is digital generated then they down-size or degrade through digital to analog so drive either color or mono-CRT.
[...]
I'm attaching an extract from tektronix TDS500/700 regarding video part

The tektronix TDS500/70 SM excerpt provides some faint clues why the 800 x 480 resolution was chosen.
At least for the Ypixel value : the reason is probably to limit the amount of the expensive (usually dual port) VRAM.

page 1-24 : The waveform planes are 512 by 512 bit maps. Only the upper 480 lines are
displayed

480 Ypixels fit inside a 512 bit plane, so 640 x 480 (standard VGA) was probably the first goal, as stated by the second sentence below (about the text plane).

page 1-25 : Each text plane is a 1024 x 512 bit map with one bit per pixel. The upper
left-hand corner of the bit map, a 640 x 480 section, is sent to the RAMDAC.

I would say that after that first attempt, the Tek guys noticed that the text wasn't that readable, and to improve the situation, as no RT video processor was available inside the scope to do some digital sharpening, the only options left were using bigger fonts (meaning less contents displayed) or improve resolution.
With a 1024 x 512 bit map for the text plane they could push the Xpixel value to 800, but were stuck to 480 Ypixels.
A standard SVGA format of 800 x 600 required a 1024 x 1024 bit map, hence doubling the amount of VRAM to be put on the motherboard.
And perhaps, one boss said No.

With a 1024 x 1024 bit map, even XGA (1024 x 768i) and XGA-2 (1024 x 768p) that showed up in 1990 would have been possible.

The same Wiki page tells us that the 800 x 480 resolution has actually it's own acronym : it is WVGA (or WGA) and a dedicated name : 'Wide VGA' and that is was used for LCD projectors and later portable and hand-held internet-enabled devices.

[Tantratron]

It is clear that I need to put much more effort and focus to learn porch, APLL and DPPL modification programming

The steps these firmwares take are more or less:

• Detect the signal (activity on sync signals)
• Measure availabe data: Vtotal, Hor. frequency, Ver. frequency, sync polarity and sync width
• Lookup or calculate missing values, Htotal, Hstart and Vstart. Mostly done with a large lookup table. If there is not perfect match, take something similar
• With the Htotal value, the sampling clock can be determined to setup the source pll.
• From the values obtained, the input capture area (position and size) can be setup
• With the horizontal and vertical active, the scaling can be calculated
• From the scaling the pixel clock for the output can be calculated to setup the output pll
• Now the output interface can be setup and the LCD enabled. Note that the output timing varies depending on the input timing, and there are cases, where the output timing would be outside the LCD specs.
• Most often, the table or calculated values will not be perfect, so some fine tuning has to be done (HTotal, sampling phase and position).This is the auto adjust most firmwares offer. These differ from chip to chip, but all are image dependent, which is not 100% bulletproof. E.g. horizontal/vertical position may be deduced from the first non black pixel.
• Sometimes the ADC range can be auto adjusted, provided a suitable image is displayed.
• After everything is finished, the firmware monitors the input timing, to start the whole cycle again, if a significant change occurs

I've been following these different steps but for a few days, i'm stuck near going nuts regarding the first step detect the signal. As i've posted back, I thought to have easily found the instruction to identify if there is signal, what type of signal by reading the specific register/scaler 0x4C (see page 46 of the RTD2660) datasheet.

When the RTD board boots, no problem it will either work with RGBS 1264x525 15 KHz or VGA 1024x768 48 KHz or VGA 800x480 31 KHz so I enter into ISP mode via arduino I2C command, still no problem where I can read register 0x4C to extract the 3 bits (6:4) after checking bit 7 states Type Detection auto Run ready. The problem which i'm bumping my head, if I do stay in ISP mode (8051 is halted) then if I do change live the signal input type (i.e. VGA becomes RGBS or vice-versa) or no signal then the register 0x4C is never updated. It will keep the last former values found when 8051 did boot prior being halted by ISP mode.

I initially thought that register 0x4C is kind of always detecting HSYNC input type (co-processor or scaler slave) but unless I miss some additional programming, I was wrong. Before asking help here, maybe @KerJoe knows the answer, I've read different github repo (KerJoe     danyaPostfactum  and  specadmin). It seems more complex than what I thought, do you know a simple sequence of commands to update and detect type of input signal, what is necessary to do prior accessing valid detection from register 0x4C. Something similar to RestoreVGA() subroutine provided by KerJoe a while ago except here is to say restart steps described by avst.

The positive side of things, my reading many source files from these 3 repo kind of help me now clearly understand some concept, the key steps like once you capture some input frame info then you look for a database table to match close the values then find typical missing value. Of course my problem wether with the Advantest or the tektronix, bad luck where the resolution is not so standard but that is OK.

[avst]

The positive side of things, my reading many source files from these 3 repo kind of help me now clearly understand some concept, the key steps like once you capture some input frame info then you look for a database table to match close the values then find typical missing value. Of course my problem wether with the Advantest or the tektronix, bad luck where the resolution is not so standard but that is OK.

Maybe you could patch the mode into the modetable (modetable.h) in flash, the mode is prersent in YPbPr.h, but probably that is not enabled in your firmware. The values in that table are not used, if YPbPr is not enabled.

In YPbBr.h:

Code: [Select]

    	{   // Mode 1 : 720 x 480i x 60 Hz
        	0 | _SYNC_HN_VN | _SYNC_HP_VN | _SYNC_HN_VP | _SYNC_HP_VP,          // Polarity Flags,
        	704-20, 224+8,                                                      // InputWidth, InputHeight,
        	157, 600,                                                           // HFreq in kHz, VFreq in Hz,
        	_HFREQ_TOLERANCE, _VFREQ_TOLERANCE,                                 // HFreqTolerance in kHz, VFreqTolerance in Hz,
        	858, 262,                                                           // HTotal, VTotal,
        	129+20, 22,//27,                                                    // HStartPos, VStartPos,
   	 },

Locating the table in the binary and patching the values shouldn't be to difficult. But you should not used the first few modes, because these get a special treatment in the firmware, as there are multiple valid resolutions for the same measurements (old legacy stuff). Maybe use the _MODE_640x480_66HZ entry, as this is another not very common resolution.

Code: [Select]

enum PresetModeDef
{
	    _MODE_640x350_70HZ = 0,         	// Mode 00: 640x350_70Hz, 720x350_70Hz
	    _MODE_640x400_56HZ,					// Mode 01: 640x400_56Hz
	    _MODE_640x400_70HZ,					// Mode 02: 640x400_70Hz, 720x400_70Hz
	    _MODE_720x400_70HZ,             	// Mode 03: 640x400_70Hz, 720x400_70Hz
	    _MODE_640x400_701HZ,          		// Mode 04: 640x400_70.1Hz
	    _MODE_640x480_60HZ,             		// Mode 05:
	    _MODE_640x480_66HZ,             		// Mode 06:
	    ....

[avst]

I initially thought that register 0x4C is kind of always detecting HSYNC input type (co-processor or scaler slave) but unless I miss some additional programming, I was wrong. Before asking help here, maybe @KerJoe knows the answer, I've read different github repo (KerJoe     danyaPostfactum  and  specadmin). It seems more complex than what I thought, do you know a simple sequence of commands to update and detect type of input signal, what is necessary to do prior accessing valid detection from register 0x4C. Something similar to RestoreVGA() subroutine provided by KerJoe a while ago except here is to say restart steps described by avst.

The firmware seems to do following steps (sync.c):

• Start a stable measurement by setting bit 0 of reg 0x4F and wait 5ms
• Check if hsync is present by looking at hsync counter overflow, reg 0x4E, bit 7
• if no overflow, wait another 60ms, then check if signals are stable in reg 0x4F, bit 7
• if stable, reads the hsync counter, and programs it into reg 0x4C and 0x4D (some special cases are used here)
• Stops a stable measurement by resetting bit 0 of reg 0x4F
• Starts the auto measurement by resetting, and then setting bit 6 of reg 0x47

[Tantratron]

First of all, I wish everybody a Happy New year 2025.

Hello @avst thanks for your last 2 posts, in particular the 2nd one which helps me to clarify and understand the sequence of calling, polling to say self-detect signal presence then detects what type of VGA signal. I'll try later to code your findings and suggestions in my arduino sketch then will share the outcome.

One serious difficulty is how to absorb, understand the different source files. Some are the Realtek leaked files which seems very heavy, lot of cases, lot of lines and not so much comments inline. Then some person mainly from Russia on GitHub have tried to reverse engineer or understand or simplify the leaked source file to go after some autonomous source file. However many times, they offer even less comments or will cover only special case of signal (i.e. HDMI).

I believe you have mainly read the alien files section of KerJoe which seems close from Realtek leaked files.

As for mapping or patching some modes into my OpenRTD2662 running firmware, maybe it could solve the other issue of the RGBs deinterlacing firmware to hopefully solve the image cropping and less clear the more we go to the right of the LCD (i.e. vertical grid lines ddisappearing progressively). If only more projects were known to address specifically the 15 KHz deinterlacing or YPbPr modes versus more project doing VGA input or HDMI input.

Albert

[Tantratron]

I initially thought that register 0x4C is kind of always detecting HSYNC input type (co-processor or scaler slave) but unless I miss some additional programming, I was wrong. Before asking help here, maybe @KerJoe knows the answer, I've read different github repo (KerJoe     danyaPostfactum  and  specadmin). It seems more complex than what I thought, do you know a simple sequence of commands to update and detect type of input signal, what is necessary to do prior accessing valid detection from register 0x4C. Something similar to RestoreVGA() subroutine provided by KerJoe a while ago except here is to say restart steps described by avst.

The firmware seems to do following steps (sync.c):

• Start a stable measurement by setting bit 0 of reg 0x4F and wait 5ms
• Check if hsync is present by looking at hsync counter overflow, reg 0x4E, bit 7
• if no overflow, wait another 60ms, then check if signals are stable in reg 0x4F, bit 7
• if stable, reads the hsync counter, and programs it into reg 0x4C and 0x4D (some special cases are used here)
• Stops a stable measurement by resetting bit 0 of reg 0x4F
• Starts the auto measurement by resetting, and then setting bit 6 of reg 0x47

Ok it works now, many thanks again, see my source code extract (needs to be written more clearly and pro...) but works

Code: [Select]

int8_t AutoDetectInput(void)
{
uint8_t timeout_i, timeout=90;

// Reset auto sync detection
  ScalerWriteBit(0x4F, 0, 0b0);
  ScalerWriteBit(0x4F, 0, 0b1);
  delay(5); // wait 5 ms

//check if Hsync is present looking at hsync counter overflow
  if(ScalerReadBit(0x4E,7))
  {
    Serial.println("No Input");
    return(-1);
  }
  else
  {
    delay(60); // wait another 60 ms
    if(ScalerReadBit(0x4F,7)==0)
    {
      Serial.println("No stable measurement");
      return(-2);
    }
    Serial.println("Signal present");
    ScalerWriteBit(0x4F, 1, 0b1); // pop up stable value
  }
  Serial.print("Stable Hysnc period       => ");Serial.println(((ScalerReadByte(0x50) & 0x7) << 8) + ScalerReadByte(0x51),DEC);
  ScalerWriteByte(0x4C, (ScalerReadByte(0x4C) & 0xF8) | (ScalerReadByte(0x50) & 0x07));
  ScalerWriteByte(0x4D,ScalerReadByte(0x51));
  ScalerWriteBit(0x4F, 0, 0b0);  // stop stable measure
  ScalerWriteBit(0x47, 6, 0b0);
  ScalerWriteBit(0x47, 6, 0b1);  // enable hysnc type detection auto run

// Polling bit 7 of 0x4C
  for (timeout_i = 0; (timeout_i <= timeout) && (ScalerReadBit(0x4C, 7) == 0); timeout_i++)
    if (timeout != timeout_i) delay(1); // wait 1 ms
    else
    {
       Serial.println("Time-out hysnc type detection");
       return -3;
    }

  Serial.print("HSync type detection ready            => ");Serial.println(ScalerReadBit(0x4C,7),BIN);
  Serial.print("HSync type detection auto run         => ");Serial.println((ScalerReadByte(0x4C) & 0x70) >> 4,BIN);
  return(0);
}

Now some Serial monitor testing data log where the RTD2660H board will either have NO INPUT or VGA input or RGBS input disconnected live (code 110 is for VGA and code 101 is for RGBS with XOR hsync-vsync)

Code: [Select]

ISP mode entered - DW8051 reset
Signal present
Stable Hysnc period       => 558
HSync type detection ready            => 1
HSync type detection auto run         => 110

ISP mode entered - DW8051 reset
Signal present
Stable Hysnc period       => 559
HSync type detection ready            => 1
HSync type detection auto run         => 110

ISP mode entered - DW8051 reset
Signal present
Stable Hysnc period       => 559
HSync type detection ready            => 1
HSync type detection auto run         => 110

ISP mode entered - DW8051 reset
No Input

ISP mode entered - DW8051 reset
No Input

ISP mode entered - DW8051 reset
Signal present
Stable Hysnc period       => 1705
HSync type detection ready            => 1
HSync type detection auto run         => 101

ISP mode entered - DW8051 reset
Signal present
Stable Hysnc period       => 1705
HSync type detection ready            => 1
HSync type detection auto run         => 101

ISP mode entered - DW8051 reset
Signal present
Stable Hysnc period       => 1705
HSync type detection ready            => 1
HSync type detection auto run         => 101

ISP mode entered - DW8051 reset
No Input

ISP mode entered - DW8051 reset
No Input

ISP mode entered - DW8051 reset
Signal present
Stable Hysnc period       => 559
HSync type detection ready            => 1
HSync type detection auto run         => 110

ISP mode entered - DW8051 reset
Signal present
Stable Hysnc period       => 558
HSync type detection ready            => 1
HSync type detection auto run         => 110

[Tantratron]

I've found still an incomplete register/scaler initialization required to really have auto detection of VGA or RGBS.

As long as say the OpenRTD russian firmware first initialize and sense either VGA or RGBS input signal then no problem under ISP mode to then always detect either No input, RGBS input or VGA input.

However if the RD2660 board running under OpenRTD firmware was never connected to any valid input (RGBs or VGA), once entering ISP mode via I2C arduino then it is impossible to later auto detect (my previous scketch). So there must be some additional register/scaler setup to really go into a full automatic signal detection.

What i've done after checking some commands in the realtek leaked file (sync.c from KerJoe) is to display these specific register values.

No Signal

Code: [Select]

ISP mode entered - DW8051 reset
********************
Page 0: P0_ADC_POWER_C6   => 38
Common Page register 0x16 => 8
Common Page register 0x32 => 0
Common Page register 0x49 => 6
Page 0: P0_ADC_POWER_D5   => 0
********************
No Input

VGA signal

Code: [Select]

ISP mode entered - DW8051 reset
********************
Page 0: P0_ADC_POWER_C6   => 3F
Common Page register 0x16 => C
Common Page register 0x32 => 30
Common Page register 0x49 => 66
Page 0: P0_ADC_POWER_D5   => 0
********************
Signal present
Stable Hysnc period       => 558
HSync type detection auto run         => 110
VGA input

RGBs signal

Code: [Select]

ISP mode entered - DW8051 reset
********************
Page 0: P0_ADC_POWER_C6   => 3F
Common Page register 0x16 => A
Common Page register 0x32 => 23
Common Page register 0x49 => 66
Page 0: P0_ADC_POWER_D5   => 0
********************
Signal present
Stable Hysnc period       => 1705
HSync type detection auto run         => 101
RGBS input

There might be other register/scaler in need for additional parameters setup so my previous auto detect routine would always work, no idea but that is where i'm now stuck.

[avst]

There might be other register/scaler in need for additional parameters setup so my previous auto detect routine would always work, no idea but that is where i'm now stuck.

In Sync.c:

Code: [Select]

         ....
         CScalerSetBit(_SYNC_SELECT_47, ~(_BIT3 | _BIT2), (_BIT3 | _BIT2));//SOY1 ,2nd HS/VS 
        
        //HS_RAW/SOY,source selection
        CScalerSetBit(_SYNC_SELECT_47, ~_BIT4, ((BYTE)bHsyncSelection << 4));
        synctypetemp    = CSyncSearchSyncTypeVGA();
        break;
        .....

BYTE CSyncGetSyncTypeStepVGA(void)
{
    BYTE flag, cnt = 0;
    
    CScalerPageSelect(_PAGE0);
    CScalerSetByte(_P0_ADC_POWER_AD, 0x18);//DCR  enable,1M
    
    CScalerSetByte(_VGIP_ODD_CTRL_13, 0x00);
    CScalerSetByte(_YUV2RGB_CTRL_9C, 0x00);//disable YUV->RGB
    CScalerSetBit(_IPH_ACT_WID_H_16, ~(_BIT7 | _BIT3), 0x00);
    CScalerSetBit(_SCALE_CTRL_32, ~_BIT7, 0x00); //disable video compensation
    CScalerSetBit(_SYNC_CTRL_49, ~(_BIT2 | _BIT1 | _BIT0), _BIT2 | _BIT1); // SeHS/DeHS ,ADC_HS/ADC/VS
    CScalerSetBit(_SYNC_INVERT_48, ~(_BIT4 | _BIT2), (_BIT4 | _BIT2));// HS_OUT ,clamp output enable
    
    if((bit)CScalerGetBit(_SYNC_SELECT_47, _BIT4)) //V304 modify
    {
        CScalerPageSelect(_PAGE0);
        CScalerSetByte(_P0_ADC_TEST_CTRL_AF, 0x04);
    }
    
    CScalerSetBit(_SYNC_SELECT_47, ~_BIT5, _BIT5);  //Enable De-composite circuit
    
    // Vsync counter level 384 crystal clocks
    CScalerSetBit(_VSYNC_COUNTER_LEVEL_MSB_4C, ~(_BIT2 | _BIT1 | _BIT0), 0x03);//768Hsync
    CScalerSetByte(_VSYNC_COUNTER_LEVEL_LSB_4D, 0x00);
    
    do
    {
        CScalerSetBit(_STABLE_MEASURE_4F, ~_BIT0, 0x00);
        CScalerSetBit(_STABLE_MEASURE_4F, ~_BIT0, _BIT0);//Measure start
        ....

Maybe this helps

[Tantratron]

Hello @avst,

The source file Sync.c from Realtek is very long, very complex or seems to cover many types of sync, many type of input signals.

So far, I was able to understand from your suggestions on january 1st how to auto-detect what type of sync signals through this part of sync.c code

Code: [Select]

#if(_HSYNC_TYPE_DETECTION == _AUTO_RUN)
/**
* CSyncGetSyncTypeAutoRun
* Get VGA sync type by Hsync Type Detection Auto Run
* @param <none>
* @return {sync type}
*
*/
BYTE CSyncGetSyncTypeAutoRun(void)
{

...............................

	CScalerSetBit(_STABLE_MEASURE_4F, ~_BIT0, 0x00);//Measure- Clear
	CScalerSetBit(_STABLE_MEASURE_4F, ~_BIT0, _BIT0);//Measure- Start

	CTimerDelayXms(5);

	if((bit)CScalerGetBit(_HSYNC_TYPE_DETECTION_FLAG_4E, _BIT7))
    {// Hsync overflow
		return _NO_SYNC_STATE;
    }

	//eric 20070523 VGA long time wake up
	CTimerDelayXms(60);

    if(!((bit)CScalerGetBit(_STABLE_MEASURE_4F, _BIT7)))//both polarity and period are stable
        return _NO_SYNC_STATE;
	CScalerSetBit(_STABLE_MEASURE_4F, ~_BIT1, _BIT1);//Pop up result

    // Get stable period
	CScalerRead(_STABLE_PERIOD_H_50, 2, pData, _AUTOINC);
	((WORD *)pData)[1] = ((pData[0] & 0x07) << 8) | pData[1];

...............

	CScalerSetBit(_STABLE_MEASURE_4F, ~_BIT0, 0x00);//stable measure stop

	CScalerSetBit(_SYNC_SELECT_47, ~_BIT6, 0x00);
	CScalerSetBit(_SYNC_SELECT_47, ~_BIT6, _BIT6);	//Enable hsync type detection auto run

	if(CTimerPollingEventProc(90, CMiscHsyncTypeAutoRunFlagPollingEvent)) //auto run ready
	{
		synctemp = (CScalerGetBit(_VSYNC_COUNTER_LEVEL_MSB_4C, 0xff) & 0x70) >> 4;//Measur result

...............................

from which I made below my last code which works detecting if VGA or RGBs or NoInput

Code: [Select]

int8_t AutoDetectInput(void)
{
uint8_t timeout_i, timeout=90, type_input;

// Reset auto sync detection
  ScalerWriteBit(0x4F, 0, 0b0);
  ScalerWriteBit(0x4F, 0, 0b1);
  delay(5); // wait 5 ms

//check if Hsync is present looking at hsync counter overflow
  if(ScalerReadBit(0x4E,7))
  {
    Serial.println("No Input");
    return(-1);
  }
  else
  {
    delay(60); // wait another 60 ms
    if(ScalerReadBit(0x4F,7)==0)
    {
      Serial.println("No stable measurement");
      return(-2);
    }
    Serial.println("Signal present");
    ScalerWriteBit(0x4F, 1, 0b1); // pop up stable value
  }
  Serial.print("Stable Hysnc period       => ");Serial.println(((ScalerReadByte(0x50) & 0x7) << 8) + ScalerReadByte(0x51),DEC);
  ScalerWriteByte(0x4C, (ScalerReadByte(0x4C) & 0xF8) | (ScalerReadByte(0x50) & 0x07));
  ScalerWriteByte(0x4D,ScalerReadByte(0x51));
  ScalerWriteBit(0x4F, 0, 0b0);  // stop stable measure
  ScalerWriteBit(0x47, 6, 0b0);
  ScalerWriteBit(0x47, 6, 0b1);  // enable hysnc type detection auto run

// Polling bit 7 of 0x4C
  for (timeout_i = 0; (timeout_i <= timeout) && (ScalerReadBit(0x4C, 7) == 0); timeout_i++)
    if (timeout != timeout_i) delay(1); // wait 1 ms
    else
    {
       Serial.println("Time-out hysnc type detection");
       return -3;
    }
  type_input = (ScalerReadByte(0x4C) & 0x70) >> 4;
  Serial.print("HSync type detection auto run         => ");Serial.println(type_input,BIN);
  if(type_input == 0) Serial.println("Not support");
  if(type_input == 5) Serial.println("RGBS input");
  if(type_input == 6) Serial.println("VGA input");
  return type_input;
}

However it only works if either RGBs or VGA signal was initially detected by OpenRTD2662 firmware. If no input signal was detected, the OpenRTD2662 will wait and detect any signal with its own unknown loop. Once entering ISP mode, the DW8051 is halted so we need to generate via the arduino as a Kernel the correct detection loop which means other register programming.

[Tantratron]

OK after displaying different registers content, I might have found the issue where the russian firmware seems to random allocate bit 4 of register 0x47 when no signal is present at boot then entering ISP mode. This bit says if SOG/SOY or HS_RAW(SS/CS) input sync selection so now prior reset auto sync function, I do force this specific bit to 0. Same story with ADC RGB power which seems sometimes incomplete so I do force to power on all inputs.

So far now, below updated auto sync source file provides a self-input detection wether RGBs VGA or No input.

Code: [Select]

int8_t AutoDetectInput(void)
{
uint8_t timeout_i, timeout=90, type_input;

  ScalerWriteByte(S_PAGE_SELECT, 0);
  ScalerWriteByte(0xC6, 0x0F);     // set ADC RGB power 
  ScalerWriteBit(0x47, 4, 0b0);    // choose HS_RAW(SS/CS) source selection

// Reset auto sync detection
  ScalerWriteBit(0x4F, 0, 0b0);
  ScalerWriteBit(0x4F, 0, 0b1);
  delay(5); // wait 5 ms

//check if Hsync is present looking at hsync counter overflow
  if(ScalerReadBit(0x4E,7))
  {
    Serial.println("No Input");
    return(-1);
  }
  else
  {
    delay(50); // wait another 50 ms
    if(ScalerReadBit(0x4F,7)==0)
    {
      Serial.println("No stable measurement");
      return(-2);
    }
    Serial.println("Signal present");
    ScalerWriteBit(0x4F, 1, 0b1); // pop up stable value
  }
  Serial.print("Stable Hysnc period       => ");Serial.println(((ScalerReadByte(0x50) & 0x7) << 8) + ScalerReadByte(0x51),DEC);
  ScalerWriteByte(0x4C, (ScalerReadByte(0x4C) & 0xF8) | (ScalerReadByte(0x50) & 0x07));
  ScalerWriteByte(0x4D,ScalerReadByte(0x51));
  ScalerWriteBit(0x4F, 0, 0b0);  // stop stable measure
  ScalerWriteBit(0x47, 6, 0b0);
  ScalerWriteBit(0x47, 6, 0b1);  // enable hysnc type detection auto run

// Polling bit 7 of 0x4C
  for (timeout_i = 0; (timeout_i <= timeout) && (ScalerReadBit(0x4C, 7) == 0); timeout_i++)
    if (timeout != timeout_i) delay(1); // wait 1 ms
    else
    {
       Serial.println("Time-out hysnc type detection");
       return -3;
    }
  type_input = (ScalerReadByte(0x4C) & 0x70) >> 4;
  Serial.print("HSync type detection auto run         => ");Serial.println(type_input,BIN);
  if(type_input == 0) Serial.println("Not support");
  if(type_input == 5) Serial.println("RGBS input");
  if(type_input == 6) Serial.println("VGA input");
  return type_input;
}

I will proceed with next steps suggest while ago by @avst, see below

It is clear that I need to put much more effort and focus to learn porch, APLL and DPPL modification programming

The steps these firmwares take are more or less:

• Detect the signal (activity on sync signals)
• Measure availabe data: Vtotal, Hor. frequency, Ver. frequency, sync polarity and sync width
• Lookup or calculate missing values, Htotal, Hstart and Vstart. Mostly done with a large lookup table. If there is not perfect match, take something similar
• With the Htotal value, the sampling clock can be determined to setup the source pll.
• From the values obtained, the input capture area (position and size) can be setup
• With the horizontal and vertical active, the scaling can be calculated
• From the scaling the pixel clock for the output can be calculated to setup the output pll
• Now the output interface can be setup and the LCD enabled. Note that the output timing varies depending on the input timing, and there are cases, where the output timing would be outside the LCD specs.
• Most often, the table or calculated values will not be perfect, so some fine tuning has to be done (HTotal, sampling phase and position).This is the auto adjust most firmwares offer. These differ from chip to chip, but all are image dependent, which is not 100% bulletproof. E.g. horizontal/vertical position may be deduced from the first non black pixel.
• Sometimes the ADC range can be auto adjusted, provided a suitable image is displayed.
• After everything is finished, the firmware monitors the input timing, to start the whole cycle again, if a significant change occurs