Shop OBEX P1 Docs P2 Docs Learn Events
Is NTSC vs PAL an issue with users outside of the US? — Parallax Forums

Is NTSC vs PAL an issue with users outside of the US?

Oldbitcollector (Jeff)Oldbitcollector (Jeff) Posts: 8,091
edited 2011-02-02 15:38 in Propeller 1
Some of the my current work uses a TV driver which is based on NTSC video output.

How much of an issue is it to users outside of the US? I'm getting the feeling that most modern televisions support the NTSC standard. Should I be digging out my video capture card and working out the PAL standard in the driver? Or is this a non-issue which has been solved by modern technology?

Thanks!
OBC

Comments

  • Toby SeckshundToby Seckshund Posts: 2,027
    edited 2011-02-01 09:20
    All of the TV s in my house can cope with NTSC.
  • LeonLeon Posts: 7,620
    edited 2011-02-01 09:21
    I've got a little LCD monitor that I use with the Propeller which is switchable between NTSC and PAL. NTSC tends to give a better image with the Propeller than PAL does, because the timing with the latter is slightly off. I think that my LCD TV can handle NTSC, but I don't even use it with PAL as I have an RGB connection to my BT Vision box
  • max72max72 Posts: 1,155
    edited 2011-02-01 09:34
    The small LCD TV I use takes care of the NTCS/PAL stuff, so no problem here.
    Massimo
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2011-02-01 09:46
    I've noted comments from Australia regarding the lack of PAL capability in my TV overlay object for the Propeller Backpack. So I assume it's an issue for some.

    -Phil
  • Ahle2Ahle2 Posts: 1,179
    edited 2011-02-01 11:15
    In Europe it hasn't been an issue for the last 15 years or so, as most TVs has NTSC support.

    /Ahle2
  • ericballericball Posts: 774
    edited 2011-02-01 13:05
    Phil Pilgrim (PhiPi) wrote: »
    I've noted comments from Australia regarding the lack of PAL capability in my TV overlay object for the Propeller Backpack. So I assume it's an issue for some.
    It may be that overlay is more of an issue because while most PAL TVs will handle an NTSC signal, the input signals they have access to are generally PAL.
  • hippyhippy Posts: 1,981
    edited 2011-02-01 15:45
    PAL TV output was never as good as NTSC and there were comments about that from myself and some others a couple of years ago. The quality was tolerable but not something which I felt could be utilised in a commercial product, even when sold into the hobby market.

    The argument that most modern PAL TV's will handle NTSC doesn't hold up IMO simply because not all do and not all do it well, plus the loss of those extra scan lines is simply undesirable. It's simply ducking the issue. Not to mention that PAL is a superior system to NTSC and usually noticeably so on a PAL TV of any quality.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2011-02-01 16:02
    So is the issue with the Prop that it cannot do PAL properly due to a hardware deficiency, or that the objects that claim to support PAL need additional work?

    -Phil
  • Cluso99Cluso99 Posts: 18,069
    edited 2011-02-01 16:23
    Phil: I am in Australia. Most of our TV for the past 10+ years have been capable of NTSC. My testing on the sets I have do both NTSC & PAL. However, PAL has more lines (and for some reason I thought I could also get more characters on a line but not sure if this is true) so we certainly get more lines. I did quite a bit of experimenting with my 1pin driver. The results are in the published source code.

    So,
    1. Perhaps there are problems with some PAL drivers
    2. PAL gives more lines of characters
    3. NTSC is not really a problem in Australia any more IMHO
  • hippyhippy Posts: 1,981
    edited 2011-02-02 04:18
    Phil Pilgrim (PhiPi) wrote: »
    So is the issue with the Prop that it cannot do PAL properly due to a hardware deficiency, or that the objects that claim to support PAL need additional work?

    I'm not sure and it would take someone who understands PAL, the Prop video drivers and hardware to answer that with any authority.

    AIUI, the hardware video output isn't quite right when run from a 5MHz crystal, but that could be a driver issue. I also recall some comment on a ( PropGFX ? ) thread that there was some subtle issue in the drivers which when corrected improved PAL quality. The discussions were a while ago so I don't exactly remember.

    To be fair to the Prop; PAL does work, just doesn't work as perfectly as it perhaps should.
  • potatoheadpotatohead Posts: 10,261
    edited 2011-02-02 05:58
    I've received some comments from people needing PAL.

    We have a reasonable PAL template from Parallax and Eric Ball. In monochrome, PAL is a good thing, just because it's got more vertical resolution, and it's blanking time is longer. But, in color, it's just kind of crappy on the Prop, compared to the excellent NTSC output. IMHO, the older discussions, and my own testing with PAL devices shows me that PAL is extremely picky about it's color burst reference. The mechanics of generating the signal are not difficult on the Prop, but getting a good signal is, because of accuracy issues. PLL jitter, in particular.

    To get really great looking PAL, it's pretty much necessary to run off some multiple of the PAL colorburst, and that tends to clock the Props either a bit slow, or a bit fast. 4 or 8 mhz.

    I have found that getting a driver running to look better requires tweaking, and that tweaking varies by crystal or target device, it seems. All of the PAL color output I've seen has banding and rippling in it, because of that. I've never seen a signal that looks good, or great though. I find there is a lot of variance, in that I can tweak one board, and have it look reasonable, then try another setup, and it looks Smile.

    One other issue is how the driver signal is built. There are several bits of core code one can start from, each with trade-offs. Some of those have PAL output, or a PAL alternative, and others don't, or operate differently generating PAL, which makes higher level driver code difficult to move from one format to another. In general, things built from the Parallax driver can get some PAL output, because the core driver does PAL, but do so poorly. NTSC allows for a very simple signal output, and a fair amount of code written against those simple signals too. Those are a rewrite to make work in PAL, IMHO.

    If the signal quality was better, I would be inclined to help port some stuff, but I've not seen that happen with any consistency. Maybe there is a xtal frequency that is some nice in-between multiple that could clock the prop somewhere between 80 and 104 Mhz that makes sense. Often, I've wondered about that. If the jitter can be minimized, PAL is going to look a lot better, IMHO.
  • potatoheadpotatohead Posts: 10,261
    edited 2011-02-02 06:01
    One other thing is VGA output. It's really good, as would be component video for TVs. We've not done a component driver yet, though I'm thinking about it, but we have done VGA. The 640x200 timings that were used on the latest sprite and tile driver are pretty nice. It might make more sense to just get the basic TV driver stuff OBC is working on ported to VGA. That's going to look great, and there are not display issues. Fewer colors though.
  • Toby SeckshundToby Seckshund Posts: 2,027
    edited 2011-02-02 06:19
    A long time ago I tried a 4.43MHz rock (and a 8.86MHz one) but the driver I was using didn't like being less than 80MHz, as stated in the code's preamble.
  • ericballericball Posts: 774
    edited 2011-02-02 07:13
    Although I don't have much personal experience with PAL (other than writing video drivers based on the spec), I suspect potatohead is correct - PAL is more sensitive to colorburst frequency imperfections. In addition to less than precise clock crystals, at 80MHz the FRQA is $0E30_0515 (%1110_00110000_00000101_00010101), so there's going to be low frequency blips in the PLL input (due to the 515), which will affect the output frequency. (In fact, there might be some value in using FRQA = $0E30_0000, which is 0.0005% slow but should be much more stable.)

    From a spec perspective, TV.spin (and my PAL template) don't generate a perfect 135/225 degree colorburst. This probably only affects the actual hues produced and not the color stability. Although it is possible to generate the correct colorburst, it makes palette generation much more difficult as a simple XOR $80 can't be used to alternate the colors.

    Just to clarify one item mentioned by Cluso regarding horizontal resolution. Although a PAL line is nominally longer than NTSC (64usec versus 63.555us), there's no significant visible difference (especially given overscan). However, from a Propeller driver perspective, a PAL line is 4540 PLLA clocks while NTSC is 3640 PLLA clocks. So if the driver isn't CPU clock constrained, it is possible for the Propeller to generate higher resolution. The higher colorburst frequency also means higher luma resolution without color artifacts. (Line averaging might also reduce color artifacts.)

    Some of my NTSC drivers can't be modified for PAL because they don't use the video generator in composite video mode, so handling the alternating colorburst phase becomes next to impossible. High resolution drivers, even if they use composite video mode, may not have enough cycles to modify the color register on the fly. There are also differences at the frame level which makes a single driver which handles both PAL and NTSC more complex.
  • Oldbitcollector (Jeff)Oldbitcollector (Jeff) Posts: 8,091
    edited 2011-02-02 15:38
    Thanks for the input guys.. While it looks like we would have been better off on this side of the ocean to adopt the PAL standard, it sounds like it has become a non-issue in regard to compatibility.

    @potatohead, I'm looking forward to being able to communicate with VGA with the ease that we are currently using the TV drivers. That tile driver may be just the trick. :)

    OBC
Sign In or Register to comment.