Roger, I don't know how your driver computes the SETXFRQ value relative to the SETCFRQ value, but I spent a few days and got the computation resolution maximized using the CORDIC, and now it locks the frame timing to the colorburst phase really well.
This is great Chip. I was able to get your code to lock sharply in both PAL and NTSC. Progressive looked very good. Interlaced modes also worked but didn't look quite as nice and had some flicker on my Dell monitor but the colours were still stable and didn't phase in and out. The interlaced PAL mode probably looked the worst and there was a little bit of crawl. Appropriate selection of the XFRQ and CFRQ values seems to be critical to get things solid with the P2. I'll have to check how S-video looks in comparison.
Would you mind if I use some of your calculations and try to incorporate them into my video driver for generating the TV modes so it hopefully avoids the video dot crawl that remains there? You've done all the hard work for achieving decent PAL/NTSC colour output so it would be good to re-use this now.
@rogloh said:
This is great Chip. I was able to get your code to lock sharply in both PAL and NTSC. Progressive looked very good. Interlaced modes also worked but didn't look quite as nice and had some flicker on my Dell monitor but the colours were still stable and didn't phase in and out. The interlaced PAL mode probably looked the worst and there was a little bit of crawl. Appropriate selection of the XFRQ and CFRQ values seems to be critical to get things solid with the P2. I'll have to check how S-video looks in comparison.
Would you mind if I use some of your calculations and try to incorporate them into my video driver for generating the TV modes so it hopefully avoids the video dot crawl that remains there? You've done all the hard work for achieving decent PAL/NTSC colour output so it would be good to re-use this now.
Of course, I want you to use it however you can. On PAL, I don't see dot-crawl, since the phase is locked, but there is more shimmering than there is in NTSC. Not sure what can be done about that.
Up till now, I had been using floating point in CON blocks to compute everything, but a 24-bit mantissa didn't get the job done. Now I just take the crudest numerical data and compute everything in Spin using CORDIC operations. This gets the job done. You'll see I maximized the computational bits before each division and then rounded the result eveywhere.
I have seen many different CVBS NTSC/PAL video outputs from many different retro systems (I have huuuge collection). They all do their color burst/IQ modulation differently and most do not conform to the standards. The most pleasant CVBS picture quality comes from the Amiga (not only because I'm a fan). I have never hooked up an Amiga to a scope and looked at the signal. But I think (just by observing) that the chrominance part of the signal is phase shifted between two states (alternatively the color burst is also shifted). So it's kind of like how interlace works for lines, but this is for the chrominance part. This makes the resolution of the color encoding appear doubled while at the same time fooling the eye that there is no dot crawl. (I can be totally wrong though, this is only guessworks) The Apple II is the coolest of them all by not having any hardware for IQ modulation and just relying on a lockstepped pixel clock and "high" resolution patterns to emulate the chrominance part. (It does generate the color burst though obivously)
But I think (just by observing) that the chrominance part of the signal is phase shifted between two states (alternatively the color burst is also shifted). So it's kind of like how interlace works for lines, but this is for the chrominance part. This makes the resolution of the color encoding appear doubled while at the same time fooling the eye that there is no dot crawl.
I think what you mean is what happens when the line frequency is color carrier * (n+0.5). Relative to the video, the phase inverts every line. Actually shifting the phase of the color carrier (PAL aside), even just by a little bit, is not something that should ever be done. Many displays deal with it fine, but many do not.
I'll go test Chip's code, just have to hook up the P2 again.
In PAL, if you don't get the colorburst phasing right, the color gets quite diminished or even inverted. You must toggle the colorburst by +/-45 degrees for each scan line. It turns out the phase appears to be 0, 0, 180, 180, 0, 0, 180, 180... on a scope, since each line is 283.75 colorburst cycles long, adding 90 degrees (the 0.75 fraction) to the +/-45 degrees of toggling. During the zoom meeting yesterday, I went forward one line and saw that it was the same phase and I couldn't figure out why. I should have gone backwards to the prior line and I would have seen the phase shift.
If my driver is not optimal, already, I don't know what can be done to improve it. I will check it again for phase-lock, since I might have broken something during code optimization.
I spent a long time messing with it and have figured out how to get rid of artifact colors (well, make them alternate at 25Hz so you can't see them) in PAL 288p: Just increase blank lines from 16 to 18 (change parameter to ADDX in line 106 from #6 to #8). In theory the same effect should be achieved without altering the timing by adding 50 Hz to the color carrier, but that doesn't work, IDK why.
The best solution to the problem would be to have a notch filter on the luminance to filter out the artifact colors. This is what most video encoders do.
For the P2 it'd have to be constructed externally and would use 3 pins (luma, chroma and another to adjust the filter frequency.)
If there is another P2 respin, could a digital filter be added that does this?
Unrelatedly, you probably want to add PAL60 to the driver. Avoids having to deal with a change in resolution/framerate when providing NTSC/PAL switching.
NTSC 240p is good.
PAL 240p has lots of weird artifacts. I think the frequency is slightly off.
NTSC/PAL 480i both have horrible dot crawl.
Here's what the artifacts in PAL 240p mode look like for me. It's a bit difficult to see on photo, it's much worse in person.
As I say, NTSC 240p mode is all good:
Wuerfel, if you look at the beginning of the PAL lines, you can see the phase difference manifesting as luma. You know, it looks like I need to review the number of PAL lines in the progressive display mode, because it looks like we are not getting phase toggling on the individual lines, from frame to frame.
As for the interlaced NTSC, it looks as stable as can be, to me.
@cgracey said:
As for the interlaced NTSC, it looks as stable as can be, to me.
I get heavy dot crawl on it. But I couldn't figure out a way to help it. I've attached a modified version of the driver that gives me good quality PAL50.
Also, here is one that does absolutely rock-solid PAL60 (but only that, just a quick hack. You should be able to figure out a way to do this properly.)
@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.
@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?
By the way, this simple video demo does not run under FlexSpin. @ersmith do you know why it wouldn't?
To build it with FlexSpin we need to change the code:
VAR md, cb, cy etc
into
VAR long md, cb, cy etc
but something else after that is stopping it from working...
I know some time back your compiler had a difference in the order of execution for the ? : statement vs Chip's and I think I pointed it out before but you might have fixed that since. Chip is using that ? syntax a lot here in the timing calculations so if that is wrong it could explain the non-syncing of video.
Yeah that was it @ersmith . Changing this line fixed the problem and it works under FlexSpin now. So it was an order of operations/precedence type of issue. I would recommend fixing this one to avoid future problems down the track.
repeat i from @bs to @lh step 4 'turn bs..lh into streamer commands
'long[i] |= i == @dv ? $7F08_0000 : $7F01_0000 ' FlexSpin no likey
long[i] |= (i == @dv) ? $7F08_0000 : $7F01_0000 ' FlexSpin is happy now
S-video output looks great in all 4 modes of PAL/NTSC & interlaced/progressive. Just tried it on a Plasma TV input. Nothing noticeably bad IMO but some displays might be fussier.
For S-video output just change to this line and plug chroma one pin higher than luma on the P2.
setcmod #%10_1_0000 'set colorspace converter to YIQ mode (Y/C)
@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.
@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.
@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.
It turns out that on these LCD displays, they like to NOT have the phase toggling on each progressive rescan, though I know why an analog PAL TV would benefit from that, with the edge luma artifacts of the color modulation filling in on rescan.
What really looks good on LCDs is 624-line interlaced PAL, since there is no phase change on each line as it gets rescanned. The decoders seem to really like that, though an analog PAL TV would show artifacts. The sad thing is, though, that one of my LCD monitors needs an ODD number of scan lines to reliably determine how to position the interlaced fields, so we have to stick with the off 625-line complete scan. This gets us back to -90 degree phase shift on each rescan, which produces a (25 Hz / 4) 6.25 Hz crawl. There is no winning with PAL. What works best for analog PAL TVs does not work best on LCDs that decode PAL.
Yeah PAL is tricky to get right. It looks like it is meant to take 8 fields (4 frames) to get the phase back to where it was in a 625 line PAL interlaced system. The video demystified book diagrams show the sequence. You can google the pdf if you don't have it.
That must be your particular hardware, chip. For me both 310 and 314 lines look great on my cheapo LCD, my big Phillips CRT and my capture card. If whatever you have doesn't handle it well, it may not properly support support progressive signals to begin with - try alternating between a black and white frame. If it comes out as stripes, toss the display into the bin
I just noticed that the output shimmer/ripple in the PAL modes I still see (albeit with S-video now) does reduce if I increase the P2 clock rate. At 300MHz for example, it is not really perceptible, while at 100MHz it was. I had interlaced PAL enabled at the higher resolution with the larger image and was seeing some small pixel ripple around Mario's eyeball. Maybe some type of PLL or NCO effect at play here?
So Wuerfel_21 you could try that out too to see if it helps with anything you are seeing. Also S-video really gets rid of the crawl, at least on my LCD monitor.
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.
By going to 300MHz from 100MHz, you are dropping the NCO update period from 10ns down to 3.3ns. So, this makes the timing much finer-grain. I will check this, too.
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.
Comments
Roger, I don't know how your driver computes the SETXFRQ value relative to the SETCFRQ value, but I spent a few days and got the computation resolution maximized using the CORDIC, and now it locks the frame timing to the colorburst phase really well.
This is great Chip. I was able to get your code to lock sharply in both PAL and NTSC. Progressive looked very good. Interlaced modes also worked but didn't look quite as nice and had some flicker on my Dell monitor but the colours were still stable and didn't phase in and out. The interlaced PAL mode probably looked the worst and there was a little bit of crawl. Appropriate selection of the XFRQ and CFRQ values seems to be critical to get things solid with the P2. I'll have to check how S-video looks in comparison.
Would you mind if I use some of your calculations and try to incorporate them into my video driver for generating the TV modes so it hopefully avoids the video dot crawl that remains there? You've done all the hard work for achieving decent PAL/NTSC colour output so it would be good to re-use this now.
Of course, I want you to use it however you can. On PAL, I don't see dot-crawl, since the phase is locked, but there is more shimmering than there is in NTSC. Not sure what can be done about that.
Up till now, I had been using floating point in CON blocks to compute everything, but a 24-bit mantissa didn't get the job done. Now I just take the crudest numerical data and compute everything in Spin using CORDIC operations. This gets the job done. You'll see I maximized the computational bits before each division and then rounded the result eveywhere.
That's great. I'll try to add it when I work on the video driver again. After PSRAM...
Chip,
I have seen many different CVBS NTSC/PAL video outputs from many different retro systems (I have huuuge collection). They all do their color burst/IQ modulation differently and most do not conform to the standards. The most pleasant CVBS picture quality comes from the Amiga (not only because I'm a fan). I have never hooked up an Amiga to a scope and looked at the signal. But I think (just by observing) that the chrominance part of the signal is phase shifted between two states (alternatively the color burst is also shifted). So it's kind of like how interlace works for lines, but this is for the chrominance part. This makes the resolution of the color encoding appear doubled while at the same time fooling the eye that there is no dot crawl. (I can be totally wrong though, this is only guessworks) The Apple II is the coolest of them all by not having any hardware for IQ modulation and just relying on a lockstepped pixel clock and "high" resolution patterns to emulate the chrominance part. (It does generate the color burst though obivously)
deleted
I think what you mean is what happens when the line frequency is
color carrier * (n+0.5). Relative to the video, the phase inverts every line. Actually shifting the phase of the color carrier (PAL aside), even just by a little bit, is not something that should ever be done. Many displays deal with it fine, but many do not.I'll go test Chip's code, just have to hook up the P2 again.
Ok, so here are my results:
NTSC 240p is good.
PAL 240p has lots of weird artifacts. I think the frequency is slightly off.
NTSC/PAL 480i both have horrible dot crawl.
Here's what the artifacts in PAL 240p mode look like for me. It's a bit difficult to see on photo, it's much worse in person.
As I say, NTSC 240p mode is all good:
In PAL, if you don't get the colorburst phasing right, the color gets quite diminished or even inverted. You must toggle the colorburst by +/-45 degrees for each scan line. It turns out the phase appears to be 0, 0, 180, 180, 0, 0, 180, 180... on a scope, since each line is 283.75 colorburst cycles long, adding 90 degrees (the 0.75 fraction) to the +/-45 degrees of toggling. During the zoom meeting yesterday, I went forward one line and saw that it was the same phase and I couldn't figure out why. I should have gone backwards to the prior line and I would have seen the phase shift.
If my driver is not optimal, already, I don't know what can be done to improve it. I will check it again for phase-lock, since I might have broken something during code optimization.
I spent a long time messing with it and have figured out how to get rid of artifact colors (well, make them alternate at 25Hz so you can't see them) in PAL 288p: Just increase blank lines from 16 to 18 (change parameter to ADDX in line 106 from #6 to #8). In theory the same effect should be achieved without altering the timing by adding 50 Hz to the color carrier, but that doesn't work, IDK why.
The best solution to the problem would be to have a notch filter on the luminance to filter out the artifact colors. This is what most video encoders do.
For the P2 it'd have to be constructed externally and would use 3 pins (luma, chroma and another to adjust the filter frequency.)
If there is another P2 respin, could a digital filter be added that does this?
Unrelatedly, you probably want to add PAL60 to the driver. Avoids having to deal with a change in resolution/framerate when providing NTSC/PAL switching.
Wuerfel, if you look at the beginning of the PAL lines, you can see the phase difference manifesting as luma. You know, it looks like I need to review the number of PAL lines in the progressive display mode, because it looks like we are not getting phase toggling on the individual lines, from frame to frame.
As for the interlaced NTSC, it looks as stable as can be, to me.
I get heavy dot crawl on it. But I couldn't figure out a way to help it. I've attached a modified version of the driver that gives me good quality PAL50.
Also, here is one that does absolutely rock-solid PAL60 (but only that, just a quick hack. You should be able to figure out a way to do this properly.)
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?
By the way, this simple video demo does not run under FlexSpin. @ersmith do you know why it wouldn't?
To build it with FlexSpin we need to change the code:
VAR md, cb, cy etc
into
VAR long md, cb, cy etc
but something else after that is stopping it from working...
I know some time back your compiler had a difference in the order of execution for the ? : statement vs Chip's and I think I pointed it out before but you might have fixed that since. Chip is using that ? syntax a lot here in the timing calculations so if that is wrong it could explain the non-syncing of video.
Yeah that was it @ersmith . Changing this line fixed the problem and it works under FlexSpin now. So it was an order of operations/precedence type of issue. I would recommend fixing this one to avoid future problems down the track.
repeat i from @bs to @lh step 4 'turn bs..lh into streamer commands 'long[i] |= i == @dv ? $7F08_0000 : $7F01_0000 ' FlexSpin no likey long[i] |= (i == @dv) ? $7F08_0000 : $7F01_0000 ' FlexSpin is happy nowS-video output looks great in all 4 modes of PAL/NTSC & interlaced/progressive. Just tried it on a Plasma TV input. Nothing noticeably bad IMO but some displays might be fussier.
For S-video output just change to this line and plug chroma one pin higher than luma on the P2.
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.
This PAL standard is messy and overcomplicated.
It turns out that on these LCD displays, they like to NOT have the phase toggling on each progressive rescan, though I know why an analog PAL TV would benefit from that, with the edge luma artifacts of the color modulation filling in on rescan.
What really looks good on LCDs is 624-line interlaced PAL, since there is no phase change on each line as it gets rescanned. The decoders seem to really like that, though an analog PAL TV would show artifacts. The sad thing is, though, that one of my LCD monitors needs an ODD number of scan lines to reliably determine how to position the interlaced fields, so we have to stick with the off 625-line complete scan. This gets us back to -90 degree phase shift on each rescan, which produces a (25 Hz / 4) 6.25 Hz crawl. There is no winning with PAL. What works best for analog PAL TVs does not work best on LCDs that decode PAL.
Yeah PAL is tricky to get right. It looks like it is meant to take 8 fields (4 frames) to get the phase back to where it was in a 625 line PAL interlaced system. The video demystified book diagrams show the sequence. You can google the pdf if you don't have it.
That must be your particular hardware, chip. For me both 310 and 314 lines look great on my cheapo LCD, my big Phillips CRT and my capture card. If whatever you have doesn't handle it well, it may not properly support support progressive signals to begin with - try alternating between a black and white frame. If it comes out as stripes, toss the display into the bin
I just noticed that the output shimmer/ripple in the PAL modes I still see (albeit with S-video now) does reduce if I increase the P2 clock rate. At 300MHz for example, it is not really perceptible, while at 100MHz it was. I had interlaced PAL enabled at the higher resolution with the larger image and was seeing some small pixel ripple around Mario's eyeball. Maybe some type of PLL or NCO effect at play here?
So Wuerfel_21 you could try that out too to see if it helps with anything you are seeing. Also S-video really gets rid of the crawl, at least on my LCD monitor.
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.
By going to 300MHz from 100MHz, you are dropping the NCO update period from 10ns down to 3.3ns. So, this makes the timing much finer-grain. I will check this, too.
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.