In previous log I described my findings regarding monitor handling of Vsinc pulse of different widths. It turned out that locking on frame rate is seemingly done on the pulse start, and the pulse polarity is irrelevant. The pulse itself is whatever phase of PWM signal is shorter.

Now, I will do similar investigation on Hsync pulse, for the standard VGA 640*480@60Hz.

The line duration is 31.75 microseconds (us) for this mode, and the Hsync pulse is LOW with duration of 3.8125 us. These are approximations from the standard using base clock of 16MHz - the frequency at which the atmega168 microcontroller chip of my Arduino Nano knock-off board operates.

I started to make this pulse narrower, and the monitor consumed it ok. The smallest pulse duration was just 2 clock cycles, or 125 nanoseconds - looks like in this vicinity the RTD2660H chip locks to start of the line. Only pulse length of 1 clock cycle, i.e. 62.5 ns, is not recognized. Looks like the minimum length is some 100 nanoseconds.

On the other side, there is also a tolerance to bigger horisontal synchronization pulse widths. There is one side-effect visible - during blanking interval which is triggered by sync pulse end, there is dark calibration on part of the line performed. And when pulse width becomes so long that it ends during active image area, the line is sampled at non-zero values, which throws colors off. Otherwise the image itself is stable.

The vertical grey line in the middle of image is probably that dark level sampling area.

When further increasing Hsync pulse length, the lock flips the same way as it was with Vsync -- when LOW pulse becomes longer than HIGH, then the latter starts being used as the synchronization signal, and image now tears apart. 

Even further increase of LOW hsync signal duration makes image move left, and when the HIGH part becomes similar in length as standard LOW pulse, the image becomes centered again. This way, the signal polarity is completely flipped, without any consequences on locking onto line.

One fun thing that might be done, is make Hsync and Vsync pulses slightly bigger that half of line / frame respectively -- this way image tears both horisontally and vertically:

------------------------------------

Concluding sync pulse investigations, I can say now that this monitor is very tolerant to synchronization pulse widths and polarities, as long as timings are stable (at start I had jitter and that was preventing lock). One is not required to make these pulses strictly adhere to standard, but only to provide correct periods (line lengths and line numbers per frame) for stable image to be able to be displayed on this screen.