Thanks. I got this up next on deck. I will get to take a pass at it soon.
Yeah, the slow beat does not impact much except text and thin lines. Sticks right out on both of those. The spiral is best case. It can be seen on the bird when color saturation is high.
I may want to try both fixed phase change, and or a color burst created from pixels too.
Have you viewed it on Svideo? This may not actually be a thing in that configuration.
I suppose we can also just use a multiple of the color burst for a crystal input too.
S-video looks really solid now with this change. It does still have a strange blurriness to some colours/positions on the screen though which is weird. Might be my Dell LCD doing it, not sure.
A colour burst from pixels may help if it locks it down. In my driver's case though I don't think I'll have much spare COG space to do repeated pixel streamer commands though unless it could be streamed out directly from memory perhaps with a single command?
Update: The S-video blurriness seems to be particular colour combinations not the positions. It's more noticeable in 80 column mode vs 40 columns and it repeats when the same combinations are used. Simple green on black is very clean in 80 columns with S-video but has some slowly oscillating red/blue fringing with CVBS plus an annoying flicker frequency which would be nice to eliminate if possible.
Yeah light VGA red on dark VGA green is a bad one so is light VGA blue on the same green. It just can't be resolved. No matter, this is normal, certain colours don't work well together on TVs due to low resolution and I already knew this. I'm glad the S-video image is more stable now though. Before it was shimmering which was due to the xzero per scanline.
Yes that'd probably be it. It's hard to know exactly when exactly it completes the full phase slip just by looking on the scope due to the thickness of the traces etc, but that would be it.
I was wondering if you'd get a better picture if the NTSC line was set to exactly 455 pixels wide from the streamer perspective. This way in theory there are 227.5 colour burst frequency oscillations per line and it lines up exactly with two pixels per colour burst. Both oscillators (XFRQ+CFRQ) may be able to stay harmonically locked and slip synchronously then perhaps...?
I'll give it a go.
Update: gave it a go and saw the colour burst stay perfectly locked on each scan line on the scope with no slipping, but I couldn't get the monitor to show anything or sync to it, I suspect it was probably too far off the colour frequency for it to like it.
I used the following settings:
229MHz clocked P2
XFRQ = 1<<26
CFRQ = 1<<26
Horizontal Front Porch = 10 pixels
HSync = 34 pixels
Breezeway = 7 pixels
Colourburst = 18 pixels (9 cycles)
Remaining H back porch = 51-18-7 = 26 pixels
Active pixels = 360
Total pixels = 455
I'll keep trying perhaps with a colour frequency much closer to 3.579545MHz instead of 3.578125MHz.
Update2: Yep that was it, I have a signal with a colour burst it likes now using XFRQ & CFRQ = 67135496 and all other parameters same as above. Colour phase seems locked and only flicker is showing up in the composite, no colour halo phasing, and the S-video is beautiful with a few blurry colour combinations but everything rock solid there by the looks of it. The 360 pixels seems like a better match for the colour resolution and any double wide text even better.
Update3: Doubling everything for XFRQ but keeping CFRQ the same, also seemed to work and got it back to 720 active pixels but with 910 on the scan line instead of 858 and it showed 87 columns of the 90 on my LCD. You could trim this back to 80 with borders and/or adjustments to the porches. It probably brings the aspect ratio closer to 16:9 too which is helpful for widescreen monitors.
The actual color frequency used should not matter too much. The TV will sync up to whatever got used and does so each colorburst. With NTSC, "never the same color" one can abuse just about any part of the signal. The most important thing is to do so consistently.
With this problem, it's literally a beat frequency between the color system and the pixel clock. So long as that doesn't happen, whatever other error there is should play out just fine.
In case you haven't tried this,
20 MHz * 126/11 = 64 * NTSC colour burst frequency (315/88 MHz) exactly.
Thanks! I was beginning to look for some such PLL ratio last night and was about to build a spreadsheet to see if I could come up with dividers/multipliers to try to get the perfect colour burst frequency, thanks for finding it.
Even though this gets the frequency value spot on with no slips, It would be useful to try to let it run at other P2 frequencies. I know 229MHz already works which was pretty close but I think others should too. The key is probably in keeping the CFRQ/XFRQ integer related. However if they are not simple powers of two and one slips at say exactly 2x the other will the colour phase error accumulate over time I wonder? Perhaps we still need to keep them both the same value?
I'll keep trying perhaps with a colour frequency much closer to 3.579545MHz instead of 3.578125MHz.
Update2: Yep that was it, I have a signal with a colour burst it likes now using XFRQ & CFRQ = 67135496 and all other parameters same as above. Colour phase seems locked and only flicker is showing up in the composite, no colour halo phasing, and the S-video is beautiful with a few blurry colour combinations but everything rock solid there by the looks of it. The 360 pixels seems like a better match for the colour resolution and any double wide text even better.
Update3: Doubling everything for XFRQ but keeping CFRQ the same, also seemed to work and got it back to 720 active pixels but with 910 on the scan line instead of 858 and it showed 87 columns of the 90 on my LCD. You could trim this back to 80 with borders and/or adjustments to the porches. It probably brings the aspect ratio closer to 16:9 too which is helpful for widescreen monitors.
That makes sense, as TV's lock by pulling a crystal, usually trimmed to centre on the exact MHz.
1-3.579545/ 3.578125 = -397ppm, which is rather too large to pull a crystal.
In case you haven't tried this,
20 MHz * 126/11 = 64 * NTSC colour burst frequency (315/88 MHz) exactly.
Thanks! I was beginning to look for some such PLL ratio last night and was about to build a spreadsheet to see if I could come up with dividers/multipliers to try to get the perfect colour burst frequency, thanks for finding it.
I think I essentially need to rotate Chip's numbers by +/- 45 degrees to get the two burst values and alternate between them, but I'm not sure how Chip figured out those numbers ($50_70_00 for RGB) in the first place and also I'm not sure they yield the expected 40 IRE unit pk-pk amplitude, looks like quite a bit less on the scope.
The actual burst "color" is always the same - the phase of the color carrier is inverted on the entire line.
(I think that you think that just the burst changes phase, if I'm not mistaken.)
Yes Wuerfel_21 I thought/hoped I could just flip the colourburst "colour" to a different set of RGB values on each alternating line to invert its phase just during the burst. Do I need to do something different or in addition to this for all the pixels on the line, and if so, how should it be done with the P2 modulator if you've taken a look at how it works?
I read a long time ago that these video acronyms have special meanings...
NTSC - Never The Same Color (I don't know if that's true)
PAL - Pay A Lot (no cheap TV's for the Europeans)
SECAM - Something Essentially Contrary to the American Method (SECAM was a French thing)
With PAL, it's 45 degree phase changes away from the reference color. That reference may well be the same as the NTSC one, or it can be, if you want it to be. I think it can be.
If you've computed the phase changes, yes. Just different pixels. Nothing need be done for the other pixels. It's really all about phase changes every other line.
And, when done properly, with the signal non-interlaced to make 50Hz frame rates, this allows for vertical color artifacting like NTSC allows for horizontal color artifacting. This was used in the demoscene to get more colors from the C64 regularly, and was also featured in some games.
I have a PVM, PAL capable. Actually will do SECAM too.
Is the driver code at top of thread current? Do we have an NTSC setup demo yet?
Lol Chip. I had heard the NTSC one, but not the others.
Do you happen to know how you came up with the $50_70_00 RGB values for NTSC burst? If I saw how that was done I might be able to do one for PAL hopefully.
@potatohead the stuff you added above doesn't help me that much with the colour burst RGB as it looks like it relates to someone's custom windows palette tool I don't have, when I took a quick look at your link.
Hmm, a cursory glance reveals that there seems to be no way of directly affecting the modulator's phase...
Is this seriously the same old design flaw from the P1 video generator? How did that one fly past everyone's radar?
Anyways, it should be possible to invert the chroma phase by flipping between two sets of colorspace coefficients. I think it's just a matter of inverting everything in CQ (except the lowest byte, obviously)
Yeah, I figured the degree was worth noting. But yes, after looking deeper, I see the same thing. Not a good resource.
Re: Phase
I am pretty sure that's what was done for PAL on the HOT edition. I no longer have that code, but someone did a color text driver NTSC, PAL...
@rogloh I have a bit of time. Any chance you can point me to a simple, compile and display setup for NTSC? Right now, I'm working through the docs, but would be nice to have a confirmed known good setup.
Hmm, a cursory glance reveals that there seems to be no way of directly affecting the modulator's phase...
Is this seriously the same old design flaw from the P1 video generator? How did that one fly past everyone's radar?
Anyways, it should be possible to invert the chroma phase by flipping between two sets of colorspace coefficients. I think it's just a matter of inverting everything in CQ (except the lowest byte, obviously)
Ok if so that is not ideal but maybe workable. It would require me to keep the CQ value around, and xor it and issue another SETCQ.
I was already XORing the colourburst (with a register holding 0) in preparation for PAL, so I guess that goes away and I would do this now.
not cq ' flip it
xor cq, #$ff ' restore low byte
setcq cq ' update it
Plus I'd retain cq in a register from where it was loaded per frame. If I shuffle the display parameter order to put cq earlier I can avoid the added copy instruction it would otherwise need.
So if this worked and was the way to do PAL basically I would:
lose my colour flip reg (-1 long)
lose the xor colourburst, colorflip operation (-1 long)
then add in the above code plus the extra cq register (+4 longs)
Maybe this only adds 2 more instructions in my spare 5 in the driver. I hope it is not more than that.
Is the driver code at top of thread current? Do we have an NTSC setup demo yet?
The driver code posted in the first post of my DVI driver thread is still the same beta code as originally posted. It is not the updated NTSC stuff I worked on last night and am still playing with that improves the output quality, but it is usable, you just enable the line in the complex demo that initializes the display to use the S-VIDEO output instead of the one for VGA or DVI etc. If you've been reading up what I posted in these threads since yesterday you might be able to make the same changes I did to improve it with Chip's timing etc. I think I've mostly documented what I changed.
Got it. That exceeds my time this evening. I'll come back for another pass in a bit. I may take Chip's simple one to experiment on too. I've got small bits of time to work with right now. PITA, but is what it is.
I read a long time ago that these video acronyms have special meanings...
NTSC - Never The Same Color (I don't know if that's true)
I think it refers to how the phase of the color carrier can shift in strange ways (dependent on the underlying luma, so drifting relative to the burst!) in an over-the-air RF transmission due to linearity problems both inside the TV (especially bad on pre-solidstate sets) and up the transmission chain, as well as conditions such as the weather (yes). PAL averages(?) the seperated chroma component over two lines, so ANY hue distortion is turned into a saturation distortion.
SECAM doesn't suffer from that problem at all, with it only modulating one color channel per line. It does however suffer from significantly higher complexity (especially in encoding. Few computers ever directly generated it. The french versions of many a system often just came with RGB SCART cables...) and significantly worse quality.
Anyways, when dealing with modern(-ish) TVs and baseband AV signals, NTSC colors are infact, often the same.
I was alreadying XORing the colourburst (with a register holding 0) in preparation for PAL, so I guess that goes away and I would do this now.
not cq ' flip it
xor cq, $ff ' restore low byte
setcq cq ' update it
Plus I'd retain cq in a register from where it was loaded per frame. If I shuffle the display parameter order to put cq earlier I can avoid the added copy instruction it would otherwise need.
NOT is off by one from a proper per-byte NEG. Should be fine, but not ideal.
How about instead of
not cq ' flip it
xor cq, $ff ' restore low byte
have
xor cq, some_constant
where some_constant is the precalculated XOR of inverted phase and normal phase?
Sure we could do that, but if the CQ is dynamic it requires re-computing this some_constant per frame which adds another instruction. Perhaps CQ is not going to be allowed to be dynamic for PAL/NTSC anyway. From the high level application I mean. I still allow it to be changed dynamically for VGA use.
Comments
Yeah, the slow beat does not impact much except text and thin lines. Sticks right out on both of those. The spiral is best case. It can be seen on the bird when color saturation is high.
I may want to try both fixed phase change, and or a color burst created from pixels too.
Have you viewed it on Svideo? This may not actually be a thing in that configuration.
I suppose we can also just use a multiple of the color burst for a crystal input too.
A colour burst from pixels may help if it locks it down. In my driver's case though I don't think I'll have much spare COG space to do repeated pixel streamer commands though unless it could be streamed out directly from memory perhaps with a single command?
Update: The S-video blurriness seems to be particular colour combinations not the positions. It's more noticeable in 80 column mode vs 40 columns and it repeats when the same combinations are used. Simple green on black is very clean in 80 columns with S-video but has some slowly oscillating red/blue fringing with CVBS plus an annoying flicker frequency which would be nice to eliminate if possible.
Yes that might be the best way to improve quality and lock things down.
With phase shift, one, or the other are resolved nicely enough to make out.
Really good circuits can interpolate. But, that 3.58Mhz is what it is.
Yes that'd probably be it. It's hard to know exactly when exactly it completes the full phase slip just by looking on the scope due to the thickness of the traces etc, but that would be it.
I was wondering if you'd get a better picture if the NTSC line was set to exactly 455 pixels wide from the streamer perspective. This way in theory there are 227.5 colour burst frequency oscillations per line and it lines up exactly with two pixels per colour burst. Both oscillators (XFRQ+CFRQ) may be able to stay harmonically locked and slip synchronously then perhaps...?
I'll give it a go.
Update: gave it a go and saw the colour burst stay perfectly locked on each scan line on the scope with no slipping, but I couldn't get the monitor to show anything or sync to it, I suspect it was probably too far off the colour frequency for it to like it.
I used the following settings:
229MHz clocked P2
XFRQ = 1<<26
CFRQ = 1<<26
Horizontal Front Porch = 10 pixels
HSync = 34 pixels
Breezeway = 7 pixels
Colourburst = 18 pixels (9 cycles)
Remaining H back porch = 51-18-7 = 26 pixels
Active pixels = 360
Total pixels = 455
I'll keep trying perhaps with a colour frequency much closer to 3.579545MHz instead of 3.578125MHz.
Update2: Yep that was it, I have a signal with a colour burst it likes now using XFRQ & CFRQ = 67135496 and all other parameters same as above. Colour phase seems locked and only flicker is showing up in the composite, no colour halo phasing, and the S-video is beautiful with a few blurry colour combinations but everything rock solid there by the looks of it. The 360 pixels seems like a better match for the colour resolution and any double wide text even better.
Update3: Doubling everything for XFRQ but keeping CFRQ the same, also seemed to work and got it back to 720 active pixels but with 910 on the scan line instead of 858 and it showed 87 columns of the 90 on my LCD. You could trim this back to 80 with borders and/or adjustments to the porches. It probably brings the aspect ratio closer to 16:9 too which is helpful for widescreen monitors.
In case you haven't tried this,
20 MHz * 126/11 = 64 * NTSC colour burst frequency (315/88 MHz) exactly.
The actual color frequency used should not matter too much. The TV will sync up to whatever got used and does so each colorburst. With NTSC, "never the same color" one can abuse just about any part of the signal. The most important thing is to do so consistently.
With this problem, it's literally a beat frequency between the color system and the pixel clock. So long as that doesn't happen, whatever other error there is should play out just fine.
Thanks! I was beginning to look for some such PLL ratio last night and was about to build a spreadsheet to see if I could come up with dividers/multipliers to try to get the perfect colour burst frequency, thanks for finding it.
Even though this gets the frequency value spot on with no slips, It would be useful to try to let it run at other P2 frequencies. I know 229MHz already works which was pretty close but I think others should too. The key is probably in keeping the CFRQ/XFRQ integer related. However if they are not simple powers of two and one slips at say exactly 2x the other will the colour phase error accumulate over time I wonder? Perhaps we still need to keep them both the same value?
1-3.579545/ 3.578125 = -397ppm, which is rather too large to pull a crystal.
What you need is a calculator that gives the Best Rational Approximations to Real Numbers, something just like this:
http://www.maths.surrey.ac.uk/hosted-sites/R.Knott/Fibonacci/cfINTRO.html#section8
Select denominators from 1 to 64 (P2 limit) of 315/88*64/20
or some other expression
I've been using an earlier version of this excellent aid for several years that I saved to a local drive.
For PAL the proper hicolor yuv video palette is P:C4:B44:A44:Y84:N04, which results in colour burst amplitude 5.7, phase 135.0 degrees
(I think that you think that just the burst changes phase, if I'm not mistaken.)
NTSC - Never The Same Color (I don't know if that's true)
PAL - Pay A Lot (no cheap TV's for the Europeans)
SECAM - Something Essentially Contrary to the American Method (SECAM was a French thing)
If you've computed the phase changes, yes. Just different pixels. Nothing need be done for the other pixels. It's really all about phase changes every other line.
And, when done properly, with the signal non-interlaced to make 50Hz frame rates, this allows for vertical color artifacting like NTSC allows for horizontal color artifacting. This was used in the demoscene to get more colors from the C64 regularly, and was also featured in some games.
I have a PVM, PAL capable. Actually will do SECAM too.
Is the driver code at top of thread current? Do we have an NTSC setup demo yet?
Do you happen to know how you came up with the $50_70_00 RGB values for NTSC burst? If I saw how that was done I might be able to do one for PAL hopefully.
@potatohead the stuff you added above doesn't help me that much with the colour burst RGB as it looks like it relates to someone's custom windows palette tool I don't have, when I took a quick look at your link.
Is this seriously the same old design flaw from the P1 video generator? How did that one fly past everyone's radar?
Anyways, it should be possible to invert the chroma phase by flipping between two sets of colorspace coefficients. I think it's just a matter of inverting everything in CQ (except the lowest byte, obviously)
Re: Phase
I am pretty sure that's what was done for PAL on the HOT edition. I no longer have that code, but someone did a color text driver NTSC, PAL...
@rogloh I have a bit of time. Any chance you can point me to a simple, compile and display setup for NTSC? Right now, I'm working through the docs, but would be nice to have a confirmed known good setup.
Ok if so that is not ideal but maybe workable. It would require me to keep the CQ value around, and xor it and issue another SETCQ.
I was already XORing the colourburst (with a register holding 0) in preparation for PAL, so I guess that goes away and I would do this now.
not cq ' flip it
xor cq, #$ff ' restore low byte
setcq cq ' update it
Plus I'd retain cq in a register from where it was loaded per frame. If I shuffle the display parameter order to put cq earlier I can avoid the added copy instruction it would otherwise need.
So if this worked and was the way to do PAL basically I would:
lose my colour flip reg (-1 long)
lose the xor colourburst, colorflip operation (-1 long)
then add in the above code plus the extra cq register (+4 longs)
Maybe this only adds 2 more instructions in my spare 5 in the driver. I hope it is not more than that.
I think it refers to how the phase of the color carrier can shift in strange ways (dependent on the underlying luma, so drifting relative to the burst!) in an over-the-air RF transmission due to linearity problems both inside the TV (especially bad on pre-solidstate sets) and up the transmission chain, as well as conditions such as the weather (yes). PAL averages(?) the seperated chroma component over two lines, so ANY hue distortion is turned into a saturation distortion.
SECAM doesn't suffer from that problem at all, with it only modulating one color channel per line. It does however suffer from significantly higher complexity (especially in encoding. Few computers ever directly generated it. The french versions of many a system often just came with RGB SCART cables...) and significantly worse quality.
Anyways, when dealing with modern(-ish) TVs and baseband AV signals, NTSC colors are infact, often the same.
How about instead of have where some_constant is the precalculated XOR of inverted phase and normal phase?