The P1 PAL driver is correctly written and works, but it just doesn't produce a very good quality image due to P1 hardware problems (it really depends on TV, too, it works as good as anything else on my little portable PAL TV, I've attached an image I've taken yesterday, because why not?).
Hardware capture devices didn't like the P1 PAL driver much. Pretty sure that came down to jitter. PAL requires more precision and consistency than NTSC does. Those things do matter on an NTSC signal, and can be seen too. It's just that NTSC will allow a lower grade signal, and variations in color tend to blend in the human eye across frames and fields. (Hello VHS!)
I would imagine newer TV's, sampling at 13.5Mhz may have issues with the P1 driver.
But, more analog displays, basically older ones, displayed it very reasonably.
Hardware capture devices didn't like the P1 PAL driver much.
I've actually never had an issue with that. Chip's driver (and all its derivatives) always captures great (well, as great as my cheap video capture thing gets), both NTSC and PAL. Whereas on my big ol' CRT TV, PAL always has diagonal stripes of hue-shift moving across the screen. Certainly viewable, but not very nice.
It looks like red is coming out green, and green is coming out red. Yellow is close but not perfect. Blue is right but that was set to 0 in the colour bursts so didn't play a part in its calculation. Magenta and cyan look pretty ugly too. Of course black and white work as they don't need to send the colour signal.
Am I mistaken or does that sound like the burst color has it's V component inverted?
Rogloh, I accidentally messed up your post! I'm sorry. I thought I was quoting and responding, but I was editing it. It got pretty much wiped down to nothing. I'm sorry.
I noticed in some of your NTSC code for P2 you were shrinking the sync tips and black/blank levels when your SAT parameter reduces Chip. Was there a specific reason for that?
I guess the math got applied to everything. Not exactly intended.
Rogloh, I accidentally messed up your post! I'm sorry. I thought I was quoting and responding, but I was editing it. It got pretty much wiped down to nothing. I'm sorry.
So I have found some colour values that can setup the right colour burst levels (or at least close enough for now) for creating a 150mV amplitude colour burst, with the original attenuation settings for SAT=70.
GREEN = 255 ($FF)
RED = 77 ($4D)
r=SAT * 1280/1646 <<--- this is also adjusted from 1000/1646 to boost the level sufficiently.
However even with this the colours are still wrong. To me it roughly looks like red/green might be phase shifted by 45 degrees. I believe this makes sense as only the Q (V) component is being used to modulate the colour output not U.sin(wt) + V.cos(wt). The order of the colour bars from left to right is meant to be white, yellow, cyan, green, magenta, red, blue, black but the image shows something else.
Notice how the TV seems to adapt part way down from the top and how the colours started out even uglier there. The colour bar change at the bottom is because my software intentionally shifts these bars to prove it is my video output not the TV displaying its own thing.
I think the way to make it work for PAL might be to adjust both U and V signals per line, such that the colour bursts are situated along -U,0 and 0,-V axes instead of at -U, -V and -U, +V, i.e. introduce another 45 degree rotation. This may mean that I need to keep both cq and ci as well as the two xor flips for them unless there is a way to setup the co-efficients differently to achieve the same rotation thing but only flipping either U or V by itself during each scanline. However if turns out that I have to keep two more values and do two more instructions during hsync to flip etc I'm not sure it would all fit in the limited remaining longs. :frown:
Am I mistaken or does that sound like the burst color has it's V component inverted?
The more I look at this and the YUV space below the more I think you are right and it is probably not a rotation of 45 degrees. But I don't know why it does this, and if I flip the odd/even starting parameters for CV_PAL, which should be like inverting V anyway, it doesn't change. So why else would red and green be swapped like this I wonder?
However what is weirder is that the colours change part way down the screen at the top once the TV "adapts" . I am not doing anything different in this portion of the screen in my code. All scanline's hsync colour bursts and flips are treated the same in the whole field.
The top of the screen looks like the V component isn't being decoded at all (which in turn looks very similar to a colorblindness simulation filter).
I wonder if changing the CQ parameter dynamically does anything nasty to the signal for a while? In the code I am just applying the new CQ in the hsync blanking period then flipping to the alternate value with the XOR mask for the next scan line.
The code doing it is this:
hsync xzero m_sn, hsync1 'generate the sync pulse
setcq cq
wrlong status, statusaddr 'update the sync status per line
dobreeze xcont m_br, hsync0 'do breezeway before colour burst
doburst xcont m_cb, colourburst 'do the PAL/NTSC colour burst
flipref xor cq, cqflip 'toggle PAL colour ref per scanline
bp _ret_ xcont m_bv, hsync0 'generate the back porch
I might try moving the setcq operation later after the breezeway streamer command is issued to be sure that the colour space converter change is not during any active portion of the previous scanline in case that might be upsetting things perhaps.
Have you got access to any older, more analog PAL TVs? Testing on such a set might give more insight
No nothing else at home to test with right now, just a plasma TV and that Dell LCD monitor taking PAL, no fancy PVM or old school CRT TVs here unfortunately.
EDIT: Another thing: does the color carrier line up properly with its 64µs-delayed self?
Not sure, can I test easily for this with an oscilloscope? Can a cheap dual input scope with delayed trigger do anything like this? I don't think the basic Rigol unit I use can do much like that. It's pretty basic and the trigger options are limited.
Update: I thought the colour carrier phase should be advanced by 1/4 of its wavelength plus also negated 64 microseconds later. So more like 270 degree change or something. Why should it line up?
I also captured the colour bar scan line output I am sending from the P2 on my scope. Seems like the correct order being sent and generated here for Y. Hopefully this tells us if U, V might be getting computed correctly for this sequence as well. I haven't checked every value on the scope to match it up yet, but they seem to be decreasing in the expected order based on their colour contributions to Y which is a start. The excursions from the Y value may also tell us something perhaps.
Update: also measured the colour oscillation excursions overlayed on Y and added numbers above for each coloured bar.
Update2: also measured the Y levels of each above (using S-video output to eliminate chroma making it easier to measure). They line up with theory pretty well too for SAT=70, certainly within measurement error from the scope.
I've got a couple of old style analogue CRT PAL TVs. The newer one is a pokey little 12" I got about 15 years ago. The older one is my brother's 27" that ended up here when they got a plasma.
EDIT: Another thing: does the color carrier line up properly with its 64µs-delayed self?
Not sure, can I test easily for this with an oscilloscope? Can a cheap dual input scope with delayed trigger do anything like this? I don't think the basic Rigol unit I use can do much like that. It's pretty basic and the trigger options are limited.
Update: I thought the colour carrier phase should be advanced by 1/4 of its wavelength plus also negated 64 microseconds later. So more like 270 degree change or something. Why should it line up?
Looking at the block diagram of a PAL decoder, it seems to me that the carrier ought to line up with what comes out of the 64µs delay line for it to make sense. Maybe I'm wrong here, though.
-The carrier is not stable to match the PAL norm.
-The carrier is not exactly at 45° you have calibration marks on "WFM7100_1D0206_2019-Dec-04_16-20-21.bmp"
"WFM7100_1D0206_2019-Dec-04_16-25-07.bmp" is in V+ mode, adding the phase together.
Update: I thought the colour carrier phase should be advanced by 1/4 of its wavelength plus also negated 64 microseconds later. So more like 270 degree change or something. Why should it line up?
My understanding of PAL was that the burst phase flips +/- 45 degrees each line, but averages to zero.
It needs to average to zero, to have the PLL properly lock.
My understanding of PAL was that the burst phase flips +/- 45 degrees each line, but averages to zero.
It needs to average to zero, to have the PLL properly lock.
Yes according to the diagrams I've been looking at online the burst phase seems to alternate between 225 and 135 on the UV plane and the average is 180 degrees, as would be sent for NTSC. I've tried to solve for RGB values that give these vectors or close to them, maybe there is still some error from the scaling due to SAT and/or CORDIC stuff or my math is wrong.
A difficulty or delay to lock a PLL might be the issue seen at the start of the frame on my plasma. Also on my Dell LCD I haven't been able to get it to sync up at all with the real swinging burst. So perhaps this burst phase average is still non-zero due to the parameters I am using not being 100% right yet. I do see some slight ringing on top of the white colour bar on the scope when I zoomed in, will have to compare that with NTSC output. Maybe quantisation error somewhere.
A difficulty or delay to lock a PLL might be the issue seen at the start of the frame on my plasma. Also on my Dell LCD I haven't been able to get it to sync up at all with the real swinging burst. So perhaps this burst phase average is still non-zero due to the parameters I am using not being 100% right yet.
Thinking about that, any lock should only happen once (as signal first arrives), and not be per-frame.
Do you send a correct burst during the whole frame sync ?
-The carrier is not stable to match the PAL norm.
-The carrier is not exactly at 45° you have calibration marks on "WFM7100_1D0206_2019-Dec-04_16-20-21.bmp"
"WFM7100_1D0206_2019-Dec-04_16-25-07.bmp" is in V+ mode, adding the phase together.
I put all the pictures and used code in the zip
Nice work Ltech. If only you had a P2 you could compare the burst phase angle too to see what it is.
In both your PAL and NTSC oscilloscope captures of three scan lines together, do you know why the middle lines are not showing a full colour burst? That looks strange to me.
Thinking about that, any lock should only happen once (as signal first arrives), and not be per-frame.
Do you send a correct burst during the whole frame sync ?
No colour burst sync is normally sent in the vsync portion with serration and equalization pulses. However there is the thing with burst blanking of the first scanline preceding and following that is meant to happen over 8 fields. Right now I am not 100% adhering to that due to not having space for coding all the logic required. If TVs are picky about this it might be something they wouldn't like.
Eg. It looks like you are meant to send colour bursts according to the following table:
field first burst final burst
scan line scan line
1 7 309
2 319 621
3 6 310
4 320 622
5 7 309
6 319 621
7 6 310
8 320 622
Fields 1-4 have one type of U phase, while 5-8 have the reverse. This is due to the colour burst being related to 1135/4 * scanline frequency, so it takes 4 scanlines to complete the full cycle. Also the half line from interlacing and 625 lines/frame means the entire cycle to repeat the same phase takes 8 fields.
In my case I think I still have the burst sent on lines 310 and 623 at the end of all fields and it begins on line 7 or 319 at the start of the fields. Perhaps some TVs are picky and need it to begin on line 6 in some cases. The code below shows the interlaced PAL sync logic (NTSC is a bit different but shares this code with some patches).
testb fieldcount, #0 wc 'field interlace state
cy if_c call #\hsync 'deal with interlaced field lines
ci if_c xcont m_slim, hsync0 'send a slim half line
cq
bitmask
ntsc1 rep #2, #5-0 'defaults to PAL
muxmask xcont sync_000, hsync1 'generate horizontal blanking/sync
offset xcont sync_001, hsync0
decod status, #31 'update status - in vertical sync
bpp setbyte status, fieldcount, #2 'update field counter in status
writestat wrlong status, statusaddr
ntsc2 rep #2, #5-0 'defaults to PAL
xcont sync_002, hsync1 'generate horizontal blanking/sync
xcont sync_003, hsync0
ntsc3 rep #2, #5-0 'defaults to PAL
xcont sync_000, hsync1 'generate horizontal blanking/sync
xcont sync_001, hsync0
'PAL variant below is the default
'while NTSC gets patched
ntsc4 if_c xcont sync_000, hsync1 'generate horizontal blanking/sync
ntsc5 if_c xcont sync_001, hsync0
ntsc6 xcont m_half, hsync0 'remainder of interlaced line (PAL)
If it were me, I would comment one of your features out and link the color parameters to some buttons.
Tune it in close, then work backward to sort the math.
Yes, I think this makes sense too and was almost about to start doing that yesterday. A mouse slider for some cq/ci parameters would be nice and might give me an excuse to finally add in garryj's USB code and use my mouse sprite.
Thinking about that, any lock should only happen once (as signal first arrives), and not be per-frame.
Do you send a correct burst during the whole frame sync ?
No colour burst sync is normally sent in the vsync portion with serration and equalization pulses. However there is the thing with burst blanking of the first scanline preceding and following that is meant to happen over 8 fields. Right now I am not 100% adhering to that due to not having space for coding all the logic required. If TVs are picky about this it might be something they wouldn't like.
Eg. It looks like you are meant to send colour bursts according to the following table:
field first burst final burst
scan line scan line
1 7 309
2 319 621
3 6 310
4 320 622
5 7 309
6 319 621
7 6 310
8 320 622
Oops, yes, you are right, I was relying on memory, the archives here have this info (attached)
(There must be a blanking-gate on the burst phase detector for no-burst cases)
Maybe the phase matters - this shows resume burst is the same phase as the last-sent burst in all cases ?
It does rather look like the TV is re-locking when it should not need to.
Does the burst NCO run cleanly across the frame sync time ?
The doc gives fLine = (Fsc-25)/(284-1/4), so I make a 10 line pause, equal to 2837.516 cycles of burst.
In my case I think I still have the burst sent on lines 310 and 623 at the end of all fields and it begins on line 7 or 319 at the start of the fields. Perhaps some TVs are picky and need it to begin on line 6 in some cases.
Depends on their design I guess.
In an analog burst-gated PLL, +/1 one burst will have little effect, but it will be vital that all bursts overlay on a locked ideal, with that -180' +/-45, to avoid disturbing lock.
If you make OUT high on the PAL video pin, it will enable the ADC which will report its bitstream on IN. Then, use a nearby smart pin in SCOPE mode with the shortest filter and set trigger levels low to trigger on the SYNC dip. Then, another cog can capture the 8-bit sample stream to hub RAM for display, like in the HDMI scope demo. Then, You won't need an oscilloscope. The P2 will do the job.
In an analog burst-gated PLL, +/1 one burst will have little effect, but it will be vital that all bursts overlay on a locked ideal, with that -180' +/-45, to avoid disturbing lock.
Hmm, this is interesting especially given the fact that my plasma seemed to have difficulty at the top of the screen and that might be hinting at this being a problem. I need to see if the these overlap with my scheme. They may not right now.
Comments
Hardware capture devices didn't like the P1 PAL driver much. Pretty sure that came down to jitter. PAL requires more precision and consistency than NTSC does. Those things do matter on an NTSC signal, and can be seen too. It's just that NTSC will allow a lower grade signal, and variations in color tend to blend in the human eye across frames and fields. (Hello VHS!)
I would imagine newer TV's, sampling at 13.5Mhz may have issues with the P1 driver.
But, more analog displays, basically older ones, displayed it very reasonably.
Conversely, a non-TV.spin-derived driver may come out like this.
Anyways, this is getting way off topic....
Am I mistaken or does that sound like the burst color has it's V component inverted?
I guess the math got applied to everything. Not exactly intended.
LOL, the power to censor by deleting posts!
GREEN = 255 ($FF)
RED = 77 ($4D)
r=SAT * 1280/1646 <<--- this is also adjusted from 1000/1646 to boost the level sufficiently.
However even with this the colours are still wrong. To me it roughly looks like red/green might be phase shifted by 45 degrees. I believe this makes sense as only the Q (V) component is being used to modulate the colour output not U.sin(wt) + V.cos(wt). The order of the colour bars from left to right is meant to be white, yellow, cyan, green, magenta, red, blue, black but the image shows something else.
Notice how the TV seems to adapt part way down from the top and how the colours started out even uglier there. The colour bar change at the bottom is because my software intentionally shifts these bars to prove it is my video output not the TV displaying its own thing.
I think the way to make it work for PAL might be to adjust both U and V signals per line, such that the colour bursts are situated along -U,0 and 0,-V axes instead of at -U, -V and -U, +V, i.e. introduce another 45 degree rotation. This may mean that I need to keep both cq and ci as well as the two xor flips for them unless there is a way to setup the co-efficients differently to achieve the same rotation thing but only flipping either U or V by itself during each scanline. However if turns out that I have to keep two more values and do two more instructions during hsync to flip etc I'm not sure it would all fit in the limited remaining longs. :frown:
However what is weirder is that the colours change part way down the screen at the top once the TV "adapts" . I am not doing anything different in this portion of the screen in my code. All scanline's hsync colour bursts and flips are treated the same in the whole field.
Have you got access to any older, more analog PAL TVs? Testing on such a set might give more insight
EDIT: Another thing: does the color carrier line up properly with its 64µs-delayed self?
The code doing it is this:
hsync xzero m_sn, hsync1 'generate the sync pulse setcq cq wrlong status, statusaddr 'update the sync status per line dobreeze xcont m_br, hsync0 'do breezeway before colour burst doburst xcont m_cb, colourburst 'do the PAL/NTSC colour burst flipref xor cq, cqflip 'toggle PAL colour ref per scanline bp _ret_ xcont m_bv, hsync0 'generate the back porchI might try moving the setcq operation later after the breezeway streamer command is issued to be sure that the colour space converter change is not during any active portion of the previous scanline in case that might be upsetting things perhaps.
No nothing else at home to test with right now, just a plasma TV and that Dell LCD monitor taking PAL, no fancy PVM or old school CRT TVs here unfortunately.
Not sure, can I test easily for this with an oscilloscope? Can a cheap dual input scope with delayed trigger do anything like this? I don't think the basic Rigol unit I use can do much like that. It's pretty basic and the trigger options are limited.
Update: I thought the colour carrier phase should be advanced by 1/4 of its wavelength plus also negated 64 microseconds later. So more like 270 degree change or something. Why should it line up?
White (R+G+B) 0.3 + 0.59 + 0.11 = 1, Y=540mV above black
Yellow (R+G) 0.3 + 0.59 = 0.89, [measured colour = ~280mVp-p, Y=480mV, 480/540 = 0.89]
Cyan (B+G) 0.11 + 0.59 = 0.70, [measured colour = ~400mVp-p, Y=380mV, 380/540 = 0.70]
Green (G) 0.59 [measured colour = ~380mVp-p, Y=320mV, 320/540=0.59]
Magenta (R+B) 0.3 + 0.11 = 0.41 [measured colour = ~380mVp-p, Y=210mV, 210/540 = 0.39]
Red 0.3 [measured colour = ~400mVp-p, Y=150mV, 150/540 = 0.28]
Blue 0.11 [measured colour = ~300mVp-p, Y=60mV, 60/540 = 0.11]
Black 0
Update: also measured the colour oscillation excursions overlayed on Y and added numbers above for each coloured bar.
Update2: also measured the Y levels of each above (using S-video output to eliminate chroma making it easier to measure). They line up with theory pretty well too for SAT=70, certainly within measurement error from the scope.
I return end of week. Point me to some code and I will fire it up and report back.
Tune it in close, then work backward to sort the math.
Looking at the block diagram of a PAL decoder, it seems to me that the carrier ought to line up with what comes out of the 64µs delay line for it to make sense. Maybe I'm wrong here, though.
A quick test for chip, P1 PAL and NTSC . I do not have a P2 yet.
On a Tektronix WFM7100, waveform vector scoop (broadcast grade)
TV.spin "v1.1 - 17 May 2006"
Propeller project board, pin8...10 1k; 560; 270 resistors
-The carrier is not stable to match the PAL norm.
-The carrier is not exactly at 45° you have calibration marks on "WFM7100_1D0206_2019-Dec-04_16-20-21.bmp"
"WFM7100_1D0206_2019-Dec-04_16-25-07.bmp" is in V+ mode, adding the phase together.
I put all the pictures and used code in the zip
My understanding of PAL was that the burst phase flips +/- 45 degrees each line, but averages to zero.
It needs to average to zero, to have the PLL properly lock.
Yes according to the diagrams I've been looking at online the burst phase seems to alternate between 225 and 135 on the UV plane and the average is 180 degrees, as would be sent for NTSC. I've tried to solve for RGB values that give these vectors or close to them, maybe there is still some error from the scaling due to SAT and/or CORDIC stuff or my math is wrong.
A difficulty or delay to lock a PLL might be the issue seen at the start of the frame on my plasma. Also on my Dell LCD I haven't been able to get it to sync up at all with the real swinging burst. So perhaps this burst phase average is still non-zero due to the parameters I am using not being 100% right yet. I do see some slight ringing on top of the white colour bar on the scope when I zoomed in, will have to compare that with NTSC output. Maybe quantisation error somewhere.
Thinking about that, any lock should only happen once (as signal first arrives), and not be per-frame.
Do you send a correct burst during the whole frame sync ?
Nice work Ltech. If only you had a P2 you could compare the burst phase angle too to see what it is.
In both your PAL and NTSC oscilloscope captures of three scan lines together, do you know why the middle lines are not showing a full colour burst? That looks strange to me.
No colour burst sync is normally sent in the vsync portion with serration and equalization pulses. However there is the thing with burst blanking of the first scanline preceding and following that is meant to happen over 8 fields. Right now I am not 100% adhering to that due to not having space for coding all the logic required. If TVs are picky about this it might be something they wouldn't like.
Eg. It looks like you are meant to send colour bursts according to the following table:
field first burst final burst scan line scan line 1 7 309 2 319 621 3 6 310 4 320 622 5 7 309 6 319 621 7 6 310 8 320 622Fields 1-4 have one type of U phase, while 5-8 have the reverse. This is due to the colour burst being related to 1135/4 * scanline frequency, so it takes 4 scanlines to complete the full cycle. Also the half line from interlacing and 625 lines/frame means the entire cycle to repeat the same phase takes 8 fields.
In my case I think I still have the burst sent on lines 310 and 623 at the end of all fields and it begins on line 7 or 319 at the start of the fields. Perhaps some TVs are picky and need it to begin on line 6 in some cases. The code below shows the interlaced PAL sync logic (NTSC is a bit different but shares this code with some patches).
testb fieldcount, #0 wc 'field interlace state cy if_c call #\hsync 'deal with interlaced field lines ci if_c xcont m_slim, hsync0 'send a slim half line cq bitmask ntsc1 rep #2, #5-0 'defaults to PAL muxmask xcont sync_000, hsync1 'generate horizontal blanking/sync offset xcont sync_001, hsync0 decod status, #31 'update status - in vertical sync bpp setbyte status, fieldcount, #2 'update field counter in status writestat wrlong status, statusaddr ntsc2 rep #2, #5-0 'defaults to PAL xcont sync_002, hsync1 'generate horizontal blanking/sync xcont sync_003, hsync0 ntsc3 rep #2, #5-0 'defaults to PAL xcont sync_000, hsync1 'generate horizontal blanking/sync xcont sync_001, hsync0 'PAL variant below is the default 'while NTSC gets patched ntsc4 if_c xcont sync_000, hsync1 'generate horizontal blanking/sync ntsc5 if_c xcont sync_001, hsync0 ntsc6 xcont m_half, hsync0 'remainder of interlaced line (PAL)Yes, I think this makes sense too and was almost about to start doing that yesterday. A mouse slider for some cq/ci parameters would be nice and might give me an excuse to finally add in garryj's USB code and use my mouse sprite.
(There must be a blanking-gate on the burst phase detector for no-burst cases)
Maybe the phase matters - this shows resume burst is the same phase as the last-sent burst in all cases ?
It does rather look like the TV is re-locking when it should not need to.
Does the burst NCO run cleanly across the frame sync time ?
The doc gives fLine = (Fsc-25)/(284-1/4), so I make a 10 line pause, equal to 2837.516 cycles of burst.
Depends on their design I guess.
In an analog burst-gated PLL, +/1 one burst will have little effect, but it will be vital that all bursts overlay on a locked ideal, with that -180' +/-45, to avoid disturbing lock.
Hmm, this is interesting especially given the fact that my plasma seemed to have difficulty at the top of the screen and that might be hinting at this being a problem. I need to see if the these overlap with my scheme. They may not right now.