@cgracey said:
I posted a new version at the top which has a 310/621-line PAL mode (set 'pal' to 2, not 1). These modes retrace color phase twice as fast for less flicker and truer color.
Old/new version of the demo+driver seems to be gone from your top post.
@Baggers said:
I get zero dot crawl on NTSC and only very slight shimmer on PAL it's the closest I've seen a PAL driver.
The progressive NTSC mode is fine. PAL also didn't have crawl, but static artifact colors. The version I posted tweaks the timing to get rid of them like the NTSC mode.
I saw that you reduced the PAL visible lines to make a 60Hz display, but I didn't notice that anything else changed. What else did you do?
I posted two files: one has PAL50 with two additional blank lines (looks better to me), the other has PAL60.
I was calculating the number of colorburst cycles in a 312-line progressive PAL frame yesterday and I came to the same conclusion that we need to add or subtract TWO lines, in order to get the phase to flip on each progressive frame.
Progressive PAL 312 lines x 283.75 colorburst cycles = 88,530.00 cycles, which leaves the phase the same. We need a 180-degree net change, or cycles ending in .50. So, 312+2 lines = 9,097.50, which gives the needed flip.
Interlaced PAL 625 lines x 283.75 = 177,343.75 cycles, which results in a net change of 270, or -90, degrees. Seems like we should add a line to that mode to get things ending in .50, to get a net 180-degree flip.
For both progressive (263-line) and interlaced (525-line) NTSC, we have odd total lines, with 227.5 colorburst clocks, yielding a net 180-degree flip, which is ideal.
So, it seems we should add or subtract two lines from progressive PAL to get the 180-degree flip. For interlaced PAL, we need to add 1 or subtract 3 lines to get the 180-degree flip. Why, though, did they design 50 Hz PAL to wind up at -90 degrees? I guess, just to get closest to 50 Hz, sacrificing optimal colorburst cycles.
In theory the color carrier should just naturally drift relative to the video by being 25 Hz higher than it "should" be. Changing the frequency by small amounts like that seems to have no effect on your driver though.
IDK if adding or removing lines is better. Looking at what info I can find, most retro systems seem to generate 312 lines .The PAL NES in particular is 310 lines, so maybe that's better than 314? IDK, everything I've tried syncs fine to either.
Wuerfel, the frame timing is computed from the color burst frequency, so that they are synchronized. That is why changing the color burst didn't change the relative timing.
I just realized that we could tweak the frame timing to be anything. Instead of 283.75 cycles/line in PAL, we could probably just do 283.5 and get NTSC sanity. This would involve just a few constant changes. I will try this today.
@cgracey said:
I just realized that we could tweak the frame timing to be anything. Instead of 283.75 cycles/line in PAL, we could probably just do 283.5 and get NTSC sanity. This would involve just a few constant changes. I will try this today.
@cgracey said:
I just realized that we could tweak the frame timing to be anything. Instead of 283.75 cycles/line in PAL, we could probably just do 283.5 and get NTSC sanity. This would involve just a few constant changes. I will try this today.
No, I tried that, doesn't work.
So, this must mean that PAL requires colorburst-frame synchronization, right?
Probably needs an external filter or just use s-video for better results. Earlier, Wuerfel_21 posted this:
@Wuerfel_21 said:
Of course S-Video is excellent. As said above, it'd be better to create the composite signal externally from the s-video outputs, with a notch filter to get rid of artifact colors.
Anybody who wants to emulate old computers and games consoles with PAL output.
I'm not sure what "half" means in "5H, 5L, 5H, half" in the driver, nor "H" for that matter. I have a book that says 312-line non-interlaced was often implemented using 6S-5L-5S, where S is short vertical sync pulse (pre- or post-equalization) and L is long sync pulse. Change from L to S occurs halfway through line 3, the same as field 1 for interlaced.
There are probably more examples of 314-line (e.g. TMS9929A VDP) than 310-line.
@Wuerfel_21 said:
For me 312 lines with 283.5 cycles still has artifact colors (but different ones).
Do you think it's possible to get it all the way right?
Not sure, I tried a lot of things but couldn't get it right. 310 lines is fine. Who wants 50Hz PAL, anyways? PAL60 is more useful.
Will all PAL TV's work with a 60 Hz frame rate? Yes, 50 Hz is slow.
Most, but not quite all. VCRs and other odd equipment generally not like it.
I say that it is more useful not because 50Hz is bad, but because PAL60 allows running the same program with NTSC and PAL output without the speed and resolution changing.
Anybody who wants to emulate old computers and games consoles with PAL output.
I'm not sure what "half" means in "5H, 5L, 5H, half" in the driver, nor "H" for that matter. I have a book that says 312-line non-interlaced was often implemented using 6S-5L-5S, where S is short vertical sync pulse and L is long. Change from L to S occurs halfway through line 3, the same as field 1 for interlaced.
There are probably more examples of 314-line (e.g. TMS9929A VDP) than 310-line.
In my own driver I've tried to follow the specs for 625/50 PAL (PAL B,D,G,H...) as much as possible when it comes to lines around vertical syncing. Between frames, halfway along line 623 (which in theory is only a half line of active video), is followed by 5 half lines with short sync, then the serration of 5 half lines with long syncs, then 5 half lines with short syncs again. This is then followed by lines 6-23, and like line 623, line 23 can carry half a line of active video information to interlace at the start; in fact you used to sometimes see these half television lines showing at the top/bottom of some old CRT TVs with reduced overscan. To transition to the next field, at line 311, the same 5,5,5 pattern is followed, but line 318 is sent as a full length line that includes the sync from the 5th line of post-equalization it its first half. I also flip the PAL colour phase used on line 7 between two full frames. I think this is the proper thing to do for PAL. It should come naturally if the phase alternates on each scan line because of the odd number of scan lines per frame but vsync handling could come in the way, it needs to be checked it is correct.
For progressive PAL I had 312 lines total per field and for vsync I send 4 short sync half lines, followed by 5 wide sync half lines, then 5 short sync half lines again. The PAL colour phase remains the same on line 7 as for the previous field, unlike the interlaced version. In progressive PAL because 312 lines is exactly divisible by 4 scan lines and there are ~283.75 colour cycles per scan line then the phase is intact between fields/frames. But for interlaced, it will take 4 full frames of 625 lines to (almost) get the phase back. This deviation is due to that small 25Hz offset in the colour frequency.
PAL colour burst frequency = (1135/4 + 1/625) x line frequency
I've not looked into the 525/60 form of PAL (eg. PAL M), but it shouldn't be hard to add at some point.
Chip, I think you are sending video starting on line 335, while I am sending it starting on 336. In most cases might not matter too much in the end, unless it messes up interlaced order perhaps...?
@potatohead said:
What code is the latest, or in need of a test?
Hi @potatohead this is the state of play since you've been out ...
There are two driver's I'm aware of to try out - Chip's latest one here which now does both PAL/NTSC more accurately, and my own one in the P2 DVI/VGA driver thread which was based on earlier settings by Chip but which I'd extended and added PAL timing+colour. You'd looked at it before and found the sync stuff was spot on, but Weurfel_21 reports the colours could still be off and I tended to agree that in comparison to NTSC which looks rather oversaturated/vibrant, PAL colours looked somewhat anemic. I had intended to try to take the latest colour levels Chip was using and add to my driver in the next release, but Weurfel_21 has also made some modifications to my driver to try to improve colour on a range of display as well (which I've not tried yet). I'm not sure what colour settings looks the best...so if someone like you has good monitors and TV test knowledge it could be of real help to us...
The *3 is with 32+7, ie: 32+21 or 53.
The addpins 1 means also use the next adjacent pin, two pins in total. If that was a 2 instead of 1 then it would mean next two adjacent pins, three pins in total.
In the PAL system, one component of the subcarrier is switched by 180° from line to line.
How- ever, this cancels the offset for this sub- carrier component so that a pronounced interference pattern would appear in the compatible black-and-white picture.
This is avoided by introducing a quarter-line offset of the subcarrier plus an additional offset of fv/2 = 25 Hz.
standard colour subcarrier frequency in the PAL system is fsc=283.75 x fh + 25 Hz = 4.43361875 MHz
The rigid coupling of the subcarrier fre- quency to the line frequency is ensured by deriving the line frequency fh or twice the line frequency 2fh from the frequency fSC of the colour subcarrier
Why PAL switching?
PAL reduce the problem of phase errors in the received chrominance signal. This can happen if, for example, you're getting a signal directly from the transmitter and also bouncing off a nearby building. The reflected signal takes slightly longer to arrive, so it's shifted in phase with respect to the line-of-sight signal. Adding them together gives a vector in a slightly different direction, resulting in a hue error. (This problem is why some people say that NTSC stands for "Never Twice the Same Colour".)
In the PAL system, the phase of the R-Y component is inverted on alternate lines (hence "Phase Alternating Line"). This has the effect of reflecting the chrominance vector about the B-Y axis. Then, in the receiver, the chrominance for the current line is averaged with a copy of the chrominance from the previous line with R-Y inverted again. This cancels out the phase error, at the expense of a slight change in saturation, which is much less noticeable
Trying to find an old analogue video analyser, and only find one with burned power supply.
Fix it, and try to find time to test.
I use a P2 edge on jon edge breadboard pin group 32, and video AV board, switches to video.
-Tektronix WFM7100 and picture of SMPTE 75% color bar
-setup NTSC: video.start(0,1, 900, 720, 0, 240, 0, @image+$36, @image+$436, video_pin)
-setup PAL: video.start(1,1, 900, 720, 0, 240, 0, @image+$36, @image+$436, video_pin)
First notice on pal and ntsc.
When use calibrated 75 Ohm termination the chroma level is to low, but luma is fine on 0.7 Volt => the luma/chroma level are bad
With 75 Ohm termination Chroma is fine but luma is to high
The burst is little to high.
Used image:
With calibrated 75 Ohm termination
No 75 Ohm
With 75 Ohm
No 75 Ohm
No 75 Ohm
Comments
Old/new version of the demo+driver seems to be gone from your top post.
Thanks for pointing that out, Roger. I fixed it.
deleted
Wuerfel, the frame timing is computed from the color burst frequency, so that they are synchronized. That is why changing the color burst didn't change the relative timing.
Ah, that makes sense. I guess you should subtract 25 when generating that timing?
I just realized that we could tweak the frame timing to be anything. Instead of 283.75 cycles/line in PAL, we could probably just do 283.5 and get NTSC sanity. This would involve just a few constant changes. I will try this today.
No, I tried that, doesn't work.
So, this must mean that PAL requires colorburst-frame synchronization, right?
I changed the 283.75 to 283.5 and it works fine.
It's not like it doesn't display, but it doesn't get rid of the artifact colors.
I see. I think that 310/621-line PAL mode I added achieves the same thing, effectively.
For me 312 lines with 283.5 cycles still has artifact colors (but different ones).
Do you think it's possible to get it all the way right?
Probably needs an external filter or just use s-video for better results. Earlier, Wuerfel_21 posted this:
Not sure, I tried a lot of things but couldn't get it right. 310 lines is fine. Who wants 50Hz PAL, anyways? PAL60 is more useful.
Will all PAL TV's work with a 60 Hz frame rate? Yes, 50 Hz is slow.
Anybody who wants to emulate old computers and games consoles with PAL output.
I'm not sure what "half" means in "5H, 5L, 5H, half" in the driver, nor "H" for that matter. I have a book that says 312-line non-interlaced was often implemented using 6S-5L-5S, where S is short vertical sync pulse (pre- or post-equalization) and L is long sync pulse. Change from L to S occurs halfway through line 3, the same as field 1 for interlaced.
There are probably more examples of 314-line (e.g. TMS9929A VDP) than 310-line.
Most, but not quite all. VCRs and other odd equipment generally not like it.
I say that it is more useful not because 50Hz is bad, but because PAL60 allows running the same program with NTSC and PAL output without the speed and resolution changing.
Of course. Just hyperbole.
In my own driver I've tried to follow the specs for 625/50 PAL (PAL B,D,G,H...) as much as possible when it comes to lines around vertical syncing. Between frames, halfway along line 623 (which in theory is only a half line of active video), is followed by 5 half lines with short sync, then the serration of 5 half lines with long syncs, then 5 half lines with short syncs again. This is then followed by lines 6-23, and like line 623, line 23 can carry half a line of active video information to interlace at the start; in fact you used to sometimes see these half television lines showing at the top/bottom of some old CRT TVs with reduced overscan. To transition to the next field, at line 311, the same 5,5,5 pattern is followed, but line 318 is sent as a full length line that includes the sync from the 5th line of post-equalization it its first half. I also flip the PAL colour phase used on line 7 between two full frames. I think this is the proper thing to do for PAL. It should come naturally if the phase alternates on each scan line because of the odd number of scan lines per frame but vsync handling could come in the way, it needs to be checked it is correct.
For progressive PAL I had 312 lines total per field and for vsync I send 4 short sync half lines, followed by 5 wide sync half lines, then 5 short sync half lines again. The PAL colour phase remains the same on line 7 as for the previous field, unlike the interlaced version. In progressive PAL because 312 lines is exactly divisible by 4 scan lines and there are ~283.75 colour cycles per scan line then the phase is intact between fields/frames. But for interlaced, it will take 4 full frames of 625 lines to (almost) get the phase back. This deviation is due to that small 25Hz offset in the colour frequency.
PAL colour burst frequency = (1135/4 + 1/625) x line frequency
I've not looked into the 525/60 form of PAL (eg. PAL M), but it shouldn't be hard to add at some point.
Chip, I think you are sending video starting on line 335, while I am sending it starting on 336. In most cases might not matter too much in the end, unless it messes up interlaced order perhaps...?
Note that PAL M and PAL 60 are different! (3.58 vs 4.43 MHz) .
This BBC R&D paper might have some info that helps with PAL/NTSC encoding:
"Colour encoding and decoding techniques for line-locked sample PAL and NTSC television signals"
https://www.bbc.co.uk/rd/publications/rdreport_1986_02
Entering PAL in Search BBC R&D box produces 71 results.
What code is the latest, or in need of a test?
Hi @potatohead this is the state of play since you've been out ...
There are two driver's I'm aware of to try out - Chip's latest one here which now does both PAL/NTSC more accurately, and my own one in the P2 DVI/VGA driver thread which was based on earlier settings by Chip but which I'd extended and added PAL timing+colour. You'd looked at it before and found the sync stuff was spot on, but Weurfel_21 reports the colours could still be off and I tended to agree that in comparison to NTSC which looks rather oversaturated/vibrant, PAL colours looked somewhat anemic. I had intended to try to take the latest colour levels Chip was using and add to my driver in the next release, but Weurfel_21 has also made some modifications to my driver to try to improve colour on a range of display as well (which I've not tried yet). I'm not sure what colour settings looks the best...so if someone like you has good monitors and TV test knowledge it could be of real help to us...
Cheers,
Roger
Coming from the P1 side,
Witch pin are used in the demo
How do we have to connect to the display
I have an A/V board and put it on pin 32-39 header. No video signal
video_pin = 32+7*3 addpins 1 'change to your video pin(s)=> header V32, with is the meaning of *3 addpins 1?
Thank you
The *3 is with 32+7, ie: 32+21 or 53.
The addpins 1 means also use the next adjacent pin, two pins in total. If that was a 2 instead of 1 then it would mean next two adjacent pins, three pins in total.
Got it
So I need to put the AV board on V48 header?
But, If I need it on the first RCA, I need pin 48 no?
Witch signal coming out on addpin 49?
video_pin = 48 addpins 1 'change to your video pin(s)?Thank-you
That 32+3*7 was a formula was for the ARC8ADE project.
Got video working. Nice picture.
I go analyzing this trough a vectorscope and give you feedback
From Rohde-schwartz
pag 19 https://cdn.rohde-schwarz.com/pws/dl_downloads/dl_common_library/dl_brochures_and_datasheets/pdf_1/Repet_24.pdf
In the PAL system, one component of the subcarrier is switched by 180° from line to line.
How- ever, this cancels the offset for this sub- carrier component so that a pronounced interference pattern would appear in the compatible black-and-white picture.
This is avoided by introducing a quarter-line offset of the subcarrier plus an additional offset of fv/2 = 25 Hz.
standard colour subcarrier frequency in the PAL system is fsc=283.75 x fh + 25 Hz = 4.43361875 MHz
The rigid coupling of the subcarrier fre- quency to the line frequency is ensured by deriving the line frequency fh or twice the line frequency 2fh from the frequency fSC of the colour subcarrier
Why PAL switching?
PAL reduce the problem of phase errors in the received chrominance signal. This can happen if, for example, you're getting a signal directly from the transmitter and also bouncing off a nearby building. The reflected signal takes slightly longer to arrive, so it's shifted in phase with respect to the line-of-sight signal. Adding them together gives a vector in a slightly different direction, resulting in a hue error. (This problem is why some people say that NTSC stands for "Never Twice the Same Colour".)
In the PAL system, the phase of the R-Y component is inverted on alternate lines (hence "Phase Alternating Line"). This has the effect of reflecting the chrominance vector about the B-Y axis. Then, in the receiver, the chrominance for the current line is averaged with a copy of the chrominance from the previous line with R-Y inverted again. This cancels out the phase error, at the expense of a slight change in saturation, which is much less noticeable
I am back,
Trying to find an old analogue video analyser, and only find one with burned power supply.
Fix it, and try to find time to test.
I use a P2 edge on jon edge breadboard pin group 32, and video AV board, switches to video.
-Tektronix WFM7100 and picture of SMPTE 75% color bar
-setup NTSC: video.start(0,1, 900, 720, 0, 240, 0, @image+$36, @image+$436, video_pin)
-setup PAL: video.start(1,1, 900, 720, 0, 240, 0, @image+$36, @image+$436, video_pin)
First notice on pal and ntsc.
When use calibrated 75 Ohm termination the chroma level is to low, but luma is fine on 0.7 Volt => the luma/chroma level are bad
With 75 Ohm termination Chroma is fine but luma is to high
The burst is little to high.
Used image:
With calibrated 75 Ohm termination
No 75 Ohm
With 75 Ohm
No 75 Ohm
No 75 Ohm