Shop OBEX P1 Docs P2 Docs Learn Events
Say I got a NTSC color reference xtal — Parallax Forums

Say I got a NTSC color reference xtal

potatoheadpotatohead Posts: 10,261
in Propeller 2
What do I need to do to run an evaluation board from that crystal?

Just a swap in? Is there a particular kind?

I just got hold of a great CRT that needs alignment and calibration. It is way better than the old Atari computer I normally use for this task.

Thought I might just make a set of P2 programs to get this done. It's output will be more than good enough.

I am asking because I remember some discussion about xtals and P2, but can't quite remember it. On my P1 boards, I would just drop the new one in, setup and go.

Maybe that's true for the eval boards as well?

Comments

  • cgraceycgracey Posts: 14,155
    edited 2020-09-17 21:30
    The P2 Eval board has an SMT 20MHz crystal soldered on. You'd have to desolder it.

    I just did a compile check and if you set _clkfreq to 3_579_545 * 64, you get 229,090,909 Hz, which is only 29 Hz above the target 229,090,880 Hz. That's an error of only 0.127ppm, which is much better than the base crystal accuracy.
    _clkfreq = 3_579_545 * 64

..yields..

CLKMODE:   $01287DFB
CLKFREQ: 229,090,909
XINFREQ:  20,000,000

    So, maybe there's no need to use that colorburst crystal.
  • jmgjmg Posts: 15,173
    potatohead wrote: »
    Say I got a NTSC color reference xtal What do I need to do to run an evaluation board from that crystal?

    Just a swap in? Is there a particular kind?
    either 3.579545MHz or 14.31818MHz should work.
    The lower MHz one would likely need 30pF pin C selected.

  • Cluso99Cluso99 Posts: 18,069
    Not sure a 3.5MHz xtal will work on P2 ?
  • jmgjmg Posts: 15,173
    edited 2020-09-18 00:43
    Cluso99 wrote: »
    Not sure a 3.5MHz xtal will work on P2 ?

    Why would it not ?
    It's a CMOS inverter oscillator, and those are good for 3~24MHz on most MCUs
    The PLL has plenty of scope on the dividers.

    Usually, a new design would pick a higher MHz because they are smaller and cheaper.
    cgracey wrote: »
    I just did a compile check and if you set _clkfreq to 3_579_545 * 64, you get 229,090,909 Hz, which is only 29 Hz above the target 229,090,880 Hz. That's an error of only 0.127ppm, which is much better than the base crystal accuracy.
    Good point, if that operating point is good enough.
    20MHz / 11 is a high enough PFD to have low jitter.


  • potatoheadpotatohead Posts: 10,261
    Thanks everyone. I will go with the low jitter setting.


  • TonyB_TonyB_ Posts: 2,178
    jmg wrote: »
    cgracey wrote: »
    I just did a compile check and if you set _clkfreq to 3_579_545 * 64, you get 229,090,909 Hz, which is only 29 Hz above the target 229,090,880 Hz. That's an error of only 0.127ppm, which is much better than the base crystal accuracy.
    Good point, if that operating point is good enough.
    20MHz / 11 is a high enough PFD to have low jitter.

    20MHz * 126 / 11 = 64 * NTSC colour burst exactly.
  • roglohrogloh Posts: 5,787
    edited 2020-09-18 10:42
    Ok, so if we were to set a pixel clock to be this 229MHz P2 clock (20M*126/11) divided by 16 and send 910 total pixels per line (720 active), as well as setting the colour burst frequency to be this 229MHz rate divided by 64, I wonder if the NTSC colour decoders would be happy with that signal...? That should give us exactly 455 colour clocks per scan line pair which I think they require. Maybe the colour would be solid then with no strange phasing. I should try this out on my driver. The good thing with those divider ratios, is that I think the XFRQ and CFRQ values can then be exact numbers with no rounding errors. Just wondering if the dot clock can reliably be a pure multiple of the colour burst frequency instead of its typical 13.5MHz etc, or if that somehow introduces other problems....

    Update: just tried it. Looks pretty clean. S-Video has no real artifacts except some foreground and background colour combinations don't look good together. Composite is stable colour but has a little bit of crawl on the character edges with some colour combinations. This might be normal too. The picture below is the composite output from my driver with these settings on a Dell monitor. I wonder how it looks on a decent CRT monitor? @potatohead would you like a binary with this test inside it? If so, it is attached below. It outputs the s-video on pins 0,1 and CVBS on pin 2 of a P2-EVAL with the A/V breakout board fitted on pins 0-7.

    IMG_2630.png

    And here's the s-video version:

    IMG_2631.png
    IMG_2630.png
    800 x 600 - 630K
    IMG_2631.png
    800 x 600 - 647K
    zip
    zip
    ntsc.zip
    14K
  • TonyB_TonyB_ Posts: 2,178
    edited 2020-09-18 11:31
    Another option perhaps with /20 for pixel clock is 286.3636MHz =
    20MHz * 315 / 22 = 80 * NTSC colour burst exactly.
  • Wuerfel_21Wuerfel_21 Posts: 5,053
    edited 2020-09-18 10:46
    rogloh wrote: »
    Just wondering if the dot clock can reliably be a pure multiple of the colour burst frequency instead of its typical 13.5MHz etc, or if that somehow introduces other problems....

    Try displaying some checkerboards and vertical stripes - those will cause solid artifact colors when the pixel clock is a multiple of the color carrier. (Proper NTSC encoder chips filter put the luma through a 3.58 MHz notch filter to avoid this. You could do that with the S-Video output on the prop, too, to get higher quality composite.)
  • roglohrogloh Posts: 5,787
    Yeah external filters could probably help drop the Luma response at that frequency. I'm just happy the colour seems stable now from my driver. I just wish PAL was as easy... :frowning:
  • TonyB_TonyB_ Posts: 2,178
    edited 2020-09-18 11:47
    A 14.31818MHz pixel clock (4 * NTSC colour burst exactly) could be generated at least three ways:

    229.0909MHz = 20MHz * 126 / 11, divided by 16
    257.7272MHz = 20MHz * 567 / 44, divided by 18
    286.3636MHz = 20MHz * 315 / 22, divided by 20

    257.7272MHz could output 640x480 HDMI using increased blanking (818 pixels/line).
  • roglohrogloh Posts: 5,787
    The problem with the 18 and 20 divisors is they are not perfect binary multiples like 16 is so CFRQ and XFRQ can't easily be computed without introducing rounding errors.
  • TonyB_TonyB_ Posts: 2,178
    rogloh wrote: »
    The problem with the 18 and 20 divisors is they are not perfect binary multiples like 16 is so CFRQ and XFRQ can't easily be computed without introducing rounding errors.

    Is that a real issue with XFRQ? Anyway, I thought I'd post those frequencies to save others calculating them.
Sign In or Register to comment.