Shop OBEX P1 Docs P2 Docs Learn Events
Propeller 2 PAL Standards what is in mind — Parallax Forums

Propeller 2 PAL Standards what is in mind

Mike_GTNMike_GTN Posts: 106
edited 2012-03-25 17:48 in Propeller 1
Interested and Curious what PAL Video standards the Propeller 2 will provide, and mainly to what "compliance level" without relying on the output device sorting out problems using own internal circuitry. Basically will we have clean PAL video output using P2 without video artifacts now? All well known, but watered down problems with Propeller 1.

This question is pretty much aimed at the designers, who might only really think that NTSC is the video standard need to spend time on as customer base for this is the major one.

Thank-you for your insight and interest in this question.

Mike.

Comments

  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2012-03-23 17:20
    Mike,

    Neither the Prop I nor Prop II are designed to be PAL-compliant, NTSC-compliant, or anything-compliant, for that matter. The so-called video generator is entirely generic, and video output is but one of the things it gets used for. Maybe the Prop II will work better for PAL than the Prop I; maybe it won't. But, either way, it's not because anyone planned on complying with the spec or planned to ignore it. It will be because the very generic video generator can be programmed to meet the spec -- or not.

    -Phil
  • jmgjmg Posts: 15,183
    edited 2012-03-23 19:56
    Mike_GTN wrote: »
    Interested and Curious what PAL Video standards the Propeller 2 will provide..

    Basically will we have clean PAL video output using P2 without video artifacts now?

    What 'video artifacts' are there in PAL on Prop1 ? - and would a faster clock alone, solve them ?
  • potatoheadpotatohead Posts: 10,261
    edited 2012-03-23 22:10
    The big artifact easily seen is color fringing and patterns. The PAL color reference tolerance is very tight, and the jitter in the Prop I doesn't work well for PAL color. The Parallax reference driver TV.spin generates one of the better PAL signals. How good it is depends on the clock input, target display tolerance, etc...

    I don't know about a faster clock. A more accurate one is needed.

    Several of us have toyed with running right off a PAL xtal. That would probably great a great display, but would result in a fairly slow Prop... I don't recall anyone actually doing it. It's easy enough to modify TV.spin though. It runs well at over 64Mhz. The PAL 4.43Mhz would put the prop at 70Mhz or so.
  • Christoph_HChristoph_H Posts: 31
    edited 2012-03-24 02:58
    potatohead wrote: »
    Several of us have toyed with running right off a PAL xtal. (...) I don't recall anyone actually doing it.
    I have done this (with the TV_Text_Demo.spin) and there weren't any improvements compared to the "standard" crystal frequencies if I remember correctly.

    One area where it's AFAIK not possible for the Propeller to follow the specification is the ratio between the line frequency and the color carrier frequency. If the system clock is 16x(color carrier) you can't make every line exactly 64µs. Although I don't know if this makes any difference.
  • Toby SeckshundToby Seckshund Posts: 2,027
    edited 2012-03-24 07:42
    With figures like 1135/4 * FH and a 25 Hz offset (4.43 ....MHz) things were always set to be tricky. Pal (and probably NTSC) was never intended to give perfectly filled fine detail, it was just a way of colouring over the existing monochrome picture. I have found that "miss-quoting" the Xtal frequency slightly, ie 4_999_500 instead of 5_000_000 etc, can improve the background beating, but edges/text will always be alien to the original colouring over principal.

    At least the Prop gives video and VGA out with ease.
  • potatoheadpotatohead Posts: 10,261
    edited 2012-03-24 08:49
    NTSC wasn't intended for color detail at all. Actual color resolution is very low, on the order of 80-160 pixels in the safe area, depending on the display. Detail above that requires planning on the colors used.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2012-03-24 09:11
    It will be interesting to see how the Prop II performs with video output. On the one hand, the video output is directed to the on-chip DACs, which is nice. On the other hand, all output is synchronized to the internal clock -- even the PLL outputs -- which means that all output transitions have to line up with the 5 ns clock (200 MHz). This could make precise timing of the colorburst and syncs more complicated for NTSC and PAL video, entailing use of the DACs to create "fuzzy edges".

    -Phil
  • potatoheadpotatohead Posts: 10,261
    edited 2012-03-24 09:29
    I'll bet it's a non-issue with NTSC. NTSC more or less operates well on a very wide range of timing configurations. ie: Can tolerate very significant abuse and still be displayed well and or clearly by many devices --the older the device, the more abuse is possible. Consistency is more important than precision is.

    PAL requires both consistency and precision. It will be interesting.
  • jmgjmg Posts: 15,183
    edited 2012-03-24 15:34
    Christoph_H wrote: »
    I have done this (with the TV_Text_Demo.spin) and there weren't any improvements compared to the "standard" crystal frequencies if I remember correctly.

    One area where it's AFAIK not possible for the Propeller to follow the specification is the ratio between the line frequency and the color carrier frequency. If the system clock is 16x(color carrier) you can't make every line exactly 64µs. Although I don't know if this makes any difference.

    Is PAL really any worse than NTSC on this issue ?

    Precise line frequency is unlikely to help color fringing and patterns - the reason behind the spectrum offset is to lower inter modulation interference, due to pathway non linearities. TV PAL is modulated again onto a carrier, and transmitted and received and envelope detected back into the CVBS - so a cable should always be better.
    Even the spectrum offset is of an academic nature, as sync edges are well removed from visible colour, and it is hard to imagine a receiver filter being able to remove line and frame harmonics.


    Did you try S-Video and Component video signals ?
    http://en.wikipedia.org/wiki/S_video
    http://en.wikipedia.org/wiki/Component_video

    S-Video ensures no shared paths, and also allows higher Luminance bandwidth than PAL-TV.
    ( so testing with this, should remove intermodulation effects)

    Component video side steps the chroma carrier modulator/demod steps entirely.

    Those standards are likely to fade, as consumer products move on, and PAL/NTSC will remain for video camera applications, like security and vehicle backing where they are not exactly 'quality focused'.
  • Cluso99Cluso99 Posts: 18,069
    edited 2012-03-24 15:51
    I tried a 14.31818 MHz xtal on my RamBlade3 and it worked. But I never fully tested the props full operation. But this is the max xtal freq that worked on my overclocked pcbs.
  • jmgjmg Posts: 15,183
    edited 2012-03-24 16:07
    Cluso99 wrote: »
    I tried a 14.31818 MHz xtal on my RamBlade3 and it worked. But I never fully tested the props full operation. But this is the max xtal freq that worked on my overclocked pcbs.

    Hehe, that is way outside reliable, ;) , but it would be an interesting bench-litmus-test, on if more having Chroma Samples helps reduce fringing, and generate both PAL and NTSC from this, to see if a Chroma multiple matters ..
    (or even a 8.8672MHz choice.. for less over in the over-clocking department )
  • SapiehaSapieha Posts: 2,964
    edited 2012-03-24 16:25
    Hi jmg.

    I have run Cluso's 3Blade more that 6 month with that frequency with PLL 8 -- Fully lasted Propeller (all 8 COG's runing) without any failure.
    And all PCB I made for Bill Henning are tested with that frequency!

    jmg wrote: »
    Hehe, that is way outside reliable, ;) , but it would be an interesting bench-litmus-test, on if more having Chroma Samples helps reduce fringing, and generate both PAL and NTSC from this, to see if a Chroma multiple matters ..
    (or even a 8.8672MHz choice.. for less over in the over-clocking department )
  • evanhevanh Posts: 16,113
    edited 2012-03-24 23:18
    Sapieha wrote: »
    I have run Cluso's 3Blade more that 6 month with that frequency with PLL 8 -- Fully lasted Propeller (all 8 COG's runing) without any failure.
    And all PCB I made for Bill Henning are tested with that frequency!

    Ah-ha! This is where I ask if PLLx8 is superior to PLLx16? As in using the 14 MHz crystal is more reliable than the 7 MHz, right?
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2012-03-25 00:10
    evanh wrote:
    As in using the 14 MHz crystal is more reliable than the 7 MHz, right?
    No, quite the contrary. 14 MHz results in a 224 MHz VCO frequency, which is pushing the envelope to the extreme. With a 7 MHz crystal, the VCO frequency is half that. It doesn't matter which PLL divider you use; the VCO frequency is always 16x the crystal frequency.

    -Phil
  • evanhevanh Posts: 16,113
    edited 2012-03-25 01:24
    That's why I'm asking. I'm sure I read somewhere that x8 worked more reliably. Which, if true, obviously means it's not as simple as max VCO figure being the limit
  • potatoheadpotatohead Posts: 10,261
    edited 2012-03-25 08:54
    I thought it was Andre' who mentioned that. HYDRA uses a 10Mhz xtal.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2012-03-25 09:01
    The reason the Hydra, Propeller Backpack, Spin Stamp, et al. use a 10 MHz crystal is that you can't get small SMT 5 MHz crystals. So they have to run with PLLx8 to get a reliable system clock frequency. There are two separate issues here: the lock frequency vs. the free-running frequency of the VCO (which is only slightly north of 224 MHz at room temperature) and the maximum reliable frequency of the system clock. The PLL will not lock at a frequency higher than the VCO free-running frequency. But the VCO will run comfortably at 160 MHz (10 MHz x 16). That's too high for the system clock, though, so the VCO has to be divided down to get 80 MHz. (PLLx8 is actually VCO/2.)

    -Phil
  • potatoheadpotatohead Posts: 10,261
    edited 2012-03-25 12:58
    My HYDRA has a socketed xtal, same as Demoboard, etc...
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2012-03-25 13:02
    In that case, there's no good reason to prefer a 10 MHz crystal over a 5 MHz unit.

    -Phil
  • evanhevanh Posts: 16,113
    edited 2012-03-25 16:46
    Phil Pilgrim (PhiPi) wrote: »
    ... The PLL will not lock at a frequency higher than the VCO free-running frequency. But the VCO will run comfortably at 160 MHz (10 MHz x 16). That's too high for the system clock, though, ...

    Ok, so, the VCO is good for more than twice the system clock. That would explain why x8 is okay. The second part of why x8 might be better may have something to do with the divider circuit or maybe just jitter ...

    Sapieha, what's your experience here? Do you have a reason for using x8 instead of x16 for your overclocked boards?
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2012-03-25 17:39
    evanh wrote:
    The second part of why x8 might be better may have something to do with the divider circuit or maybe just jitter ...
    Assuming that the VCO has a 50% duty cycle, there can be nothing at all intrinsically better or more robust about using PLLx8, compared with PLLx16.

    -Phil
  • evanhevanh Posts: 16,113
    edited 2012-03-25 17:48
    Yet Sapieha uses x8 on his reliability tests.
Sign In or Register to comment.