Arrgh! That's where a scope would have really helped.
Thanks Chip. I'll check mine tonite.
Yeah, the vertical sync's serration pulses' duty cycles were too mild for some monitors. They are to spec, now, though.
A normal HSYNC pulse is 4.7us. For the high VSYNC serration pulses, HSYNC is 2.35us, while for the low VSYNC serration pulses, HSYNC is half a normal scanline minus 4.7us. My original low VSYNC pulses were not low for long enough, causing the low-pass/schmitt trigger VSYNC sensor in some monitors to not toggle.
Ah... I see that now, and it totally explains the erratic behavior I was chasing!
Yes, and by the way, it's been surprising to me, but the NCO works beautifully for timing, without the need for a PLL or tricky programming. And with the colorspace converter feeding from the NCO, instead of rigid lock-stepping through 16 states, like on Prop2-Hot, we've got baseband video that's as good as anyone could ask for.
Glad we got that all sorted out. Could be useful to play with TV output in the car, while waiting for kids...
BTW: Can anybody explain what #1 and #2 do in the following?
xcont m_hs,#2
xcont m_hl,#1
#2 makes a low sync pulse
#1 makes the black level (SETCI value [7:0])
If the two LSBs are 0 (#0), SETCY value [7:0] is used as a base and the luma is added to it. I need to document all this.
Yes, and by the way, it's been surprising to me, but the NCO works beautifully for timing, without the need for a PLL or tricky programming. And with the colorspace converter feeding from the NCO, instead of rigid lock-stepping through 16 states, like on Prop2-Hot, we've got baseband video that's as good as anyone could ask for.
Indeed. honestly, it was all pretty easy. The TV rattling around drove me nuts!
If we want, matching the pixels to the colorburst pretty much did what HOT did anyway.
This came up 5 years ago during the development of the Fignition. The designer had used that site to code their PAL output routines, which didn't work on all monitors. This is a copy of a post I made...
The text quoted is wrong.
For PAL it is *always* 5 + 5 + 5 (source: Specification of Television Standards for 625-line System I Transmissions)
As far as the first field goes - it doesn't really matter as it will sort itself out next time around. Although if you wanted to be absolutely spot-on you'd start on Line 1 which is the start of the Broad Pulses (aka long sync pulses).
And yes, the delay is a high level for 30us. The '5 + 5 + 5' vertical sync sequence runs at twice the normal sync rate so that you get a falling edge every 32us. Note that it's the falling edge which is used as the timing reference point.
A quick web search brings up an amazing number of pages where the information on video sync is just plain wrong.
From: fignition@googlegroups.com [mailto:fignition@googlegroups.com] On Behalf Of craig
Sent: 15 December 2011 21:06
To: fignition@googlegroups.com
Subject: Re: PAL Video
Thanks for the explanations guys I understand it much better now.
Just another quick question on the vertical syncs, the martin.hinner.info website from my first post states that:
The format for field 1 (starting at line 623.. ends at line 5 inclusive):
o 6 Pre-equalizing pulses.. 5 long sync pulses... 5 Post-equalizing pulses.
The format for field 2 (starting at line 311.. ends at line 317 inclusive):
o 5 Pre-equalizing pulses.. 5 long sync pulses... 4 Post-equalizing pulses.
equalizing pulses are "short syncs" (active low as usual) of 2 microseconds followed by a delay of 30 microseconds.
Would the very first field 1 generated have vertical syncs of 6-5-5 (8 scan lines) or just 5-5 (5 scan lines) and when he says 'delay of 30 microseconds' does he mean a voltage of 0.3V for 30 microseconds?
I've been running various timings with the goal of understanding how we can optimize higher resolution TV signals.
Turns out, the small frequency beats seen on high contrast, detail image elements can be near completely eliminated by a selective reset of the NCO phase. If it's free running, those artifacts cycle across a few frames. This is seen as shimmer and or perhaps variations in the color of thin, bright objects, and a bit of noise, for an image pattern, like a crosshatch.
After some trial and error, I've learned we can reset the NCO phase right at the vsync point, and again at the beginning of the visible scan line to make the errors small and consistent. The result is a pretty darn good image! A newer HDTV, or even SD digital display should just correct for these. An older analog set will simply display a more consistent signal with no moving artifacts.
Should be a net improvement on any display. Maybe this technique can work for a PAL display too.
If you have a moment, please run these and report your results back, with display type and what you saw the two drivers do.
I've included two 640 pixel drivers, the A driver has a free running NCO phase, and should display shimmer and other artifacts on the detail patterns I've hacked into the pretty bird bitmap. This should be the worse looking one.
The B driver has the NCO phase reset at the vsync point, and again right at the beginning of each visible scanline. Most of those artifacts should be gone, and depending on your TV, the patterns may resolve better too. This should be the better looking one.
My CRT TVs displayed much better on the B driver. So far, I've only been able to test a Samsung HDTV, and it did better on the A driver. If you have an HDTV to test on, I would appreciate the results.
I wonder if it would help to preserve NCO phase on Burst, ( not visible, and usually feeds a Xtal PLL ) but re-align phase on line-start so the visible effects are reduced, but the burst average is correct ?
I tried that, and the CRT sets hate it, (at least the two I have do) but the HDTV sets might not. I'll let a few test results come in and think on it some more. It may be worth exploring some more.
Good news is using the same clock for pixels and color yields 320 pixel resolution, and that works great on all sets I've tried.
This is about pushing it...
And we've got component to fall back on for many use cases.
I tried that, and the CRT sets hate it, (at least the two I have do) but the HDTV sets might not. I'll let a few test results come in and think on it some more. It may be worth exploring some more.
Hmm, that does seem counter-intuitive - did you check the burst on a scope ?
Preserve NCO phase has to be a little tricky to do, if you are also non-preserve elsewhere.
potatohead
The bitmap2.bmp appears to be the wrong bitmap format.
I get same result for A&B versions on all monitors (Analog & Digital)
Screen is almost all white with assorted colors weaved thru image matching bird colors.
@Ozpropdev, The bitmap is sized for interlace. You should only see half of it. I should have explained that. For these tests, I needed some high color areas and some high contrast, detail color and monochrome areas.
Almost all white seems odd though. There should be a black portion with some patterns in it. Those are sized and colored to highlight various things. I've uploaded a picture.
@jmg, it does seem so. Agreed!
What I observed with the analog set, when locking the phase as you describe, is very consistent rainbow artifacts on high contrast image detail. They stand right out. This is true for just the burst, as well as things like burst every other line.
When I did the frame and visible phase lock, those errors averaged consistently, and the color phase shift acted to cancel them out.
The HDTV didn't appear to demonstrate the same behavior, and that's why I'm curious about what others see on their displays.
Potatohead
Fixed my all white screen issue. The download of bitmaps in Windows and Mozilla behaves differently to downloading other files. It seems the original format was ignored/changed. I tried a different way and image is good npw.
Results on Analog screen were Version B had less cyclic artifacts than version A.
On digital monitor the opposite was observed. Version A was a better deal than version B.
I will try it on some other monitots later. Good work!
Does anyone know if we can run the color at 4x colorburst? Right now, it's 2x. I'm asking because running the same clock for both color and pixels seems to marginalize most of these small artifacts.
Comments
So, it works on a monitor that was failing before?
Sorry I didn't make proper serration pulses the first time.
It is totally to spec now.
Is this interlaced, or non interlaced, Sync ?
It is non-interlaced,
Arrgh! That's where a scope would have really helped.
Thanks Chip. I'll check mine tonite.
Yeah, the vertical sync's serration pulses' duty cycles were too mild for some monitors. They are to spec, now, though.
A normal HSYNC pulse is 4.7us. For the high VSYNC serration pulses, HSYNC is 2.35us, while for the low VSYNC serration pulses, HSYNC is half a normal scanline minus 4.7us. My original low VSYNC pulses were not low for long enough, causing the low-pass/schmitt trigger VSYNC sensor in some monitors to not toggle.
Yes, and by the way, it's been surprising to me, but the NCO works beautifully for timing, without the need for a PLL or tricky programming. And with the colorspace converter feeding from the NCO, instead of rigid lock-stepping through 16 states, like on Prop2-Hot, we've got baseband video that's as good as anyone could ask for.
BTW: Can anybody explain what #1 and #2 do in the following?
xcont m_hs,#2 xcont m_hl,#1#2 makes a low sync pulse
#1 makes the black level (SETCI value [7:0])
If the two LSBs are 0 (#0), SETCY value [7:0] is used as a base and the luma is added to it. I need to document all this.
Indeed. honestly, it was all pretty easy. The TV rattling around drove me nuts!
If we want, matching the pixels to the colorburst pretty much did what HOT did anyway.
The PAL diagrams are fine but the text is wrong.
This came up 5 years ago during the development of the Fignition. The designer had used that site to code their PAL output routines, which didn't work on all monitors. This is a copy of a post I made...
Turns out, the small frequency beats seen on high contrast, detail image elements can be near completely eliminated by a selective reset of the NCO phase. If it's free running, those artifacts cycle across a few frames. This is seen as shimmer and or perhaps variations in the color of thin, bright objects, and a bit of noise, for an image pattern, like a crosshatch.
After some trial and error, I've learned we can reset the NCO phase right at the vsync point, and again at the beginning of the visible scan line to make the errors small and consistent. The result is a pretty darn good image! A newer HDTV, or even SD digital display should just correct for these. An older analog set will simply display a more consistent signal with no moving artifacts.
Should be a net improvement on any display. Maybe this technique can work for a PAL display too.
If you have a moment, please run these and report your results back, with display type and what you saw the two drivers do.
I've included two 640 pixel drivers, the A driver has a free running NCO phase, and should display shimmer and other artifacts on the detail patterns I've hacked into the pretty bird bitmap. This should be the worse looking one.
The B driver has the NCO phase reset at the vsync point, and again right at the beginning of each visible scanline. Most of those artifacts should be gone, and depending on your TV, the patterns may resolve better too. This should be the better looking one.
Good news is using the same clock for pixels and color yields 320 pixel resolution, and that works great on all sets I've tried.
This is about pushing it...
And we've got component to fall back on for many use cases.
Preserve NCO phase has to be a little tricky to do, if you are also non-preserve elsewhere.
Always good to see what is possible
I see some more 7" region Car displays offering Video/VGA and HDMI, so the VGA could be compared with video & their chipsets.
The bitmap2.bmp appears to be the wrong bitmap format.
I get same result for A&B versions on all monitors (Analog & Digital)
Screen is almost all white with assorted colors weaved thru image matching bird colors.
Almost all white seems odd though. There should be a black portion with some patterns in it. Those are sized and colored to highlight various things. I've uploaded a picture.
@jmg, it does seem so. Agreed!
What I observed with the analog set, when locking the phase as you describe, is very consistent rainbow artifacts on high contrast image detail. They stand right out. This is true for just the burst, as well as things like burst every other line.
When I did the frame and visible phase lock, those errors averaged consistently, and the color phase shift acted to cancel them out.
The HDTV didn't appear to demonstrate the same behavior, and that's why I'm curious about what others see on their displays.
Fixed my all white screen issue. The download of bitmaps in Windows and Mozilla behaves differently to downloading other files. It seems the original format was ignored/changed. I tried a different way and image is good npw.
Results on Analog screen were Version B had less cyclic artifacts than version A.
On digital monitor the opposite was observed. Version A was a better deal than version B.
I will try it on some other monitots later. Good work!
Thanks a lot.
Tested on two more monitors (1 Analog & 1 Digital).
Same results as my post above.
Digital displays sample at 13.5mhz. This is where the difference is. I tested another digital one too. Same result.
Now we know a bit more about where the work that should pay off nicely is.