PAL vs. NTSC

[Hank Fletcher]

I'm kind of following up on my "hacking a TFT" display. With respect to that, I've since noticed that there are some good (albeit soporific) webinars on the Microchip website describing how to interface various LCD displays (including QVGA TFTs) to PIC mcus.

Anyways, I've digressed a bit and I'm interested in the intermediate step of creating an NTSC signal from a PIC to display graphics and text on a CRT TV. I've found this guy on Youtube, who seems to know what he's doing. He seems like a nice guy, as long as you can get past the Natural-Born-Killer vibe:
YouTube - PIC Microcontroller generating PAL TV signal

So what I'm wondering is this: from what I've learned, all the PIC to TV projects are using PAL signals on PAL TVs, which have exactly 64us horizontal scan lines. NTSC doesn't - the horizontal scan is slightly less than that, in order to provide for added coding (for colour, I think) on top of what was the original protocol.

The difference in vert sync frequencies, or the different number of horizontal scan lines, between PAL and NTSC don't seem to me to be as big an issue as the fact that each NTSC horizontal scan line is 63.[something] us long.

How can accommodate the point-something microseconds if I'm using a PIC mcu?. Or do I need to? I'm not sure how big a deal this is. What I've managed to do so far is get a signal into my TV that looks like scrambled video, but all I've had to experiment with is a 16F88 running from its internal oscillator. I think I'll try ordering some 20MHz oscillators, and perhaps some faster ones to push the tolerance of the mcu a bit, and see what I can make happen with some finer time resolutions. I've only managed a time resolution as small as 10us up to now - I know that's not quite good enough to get something happening.

Anyway, any advice on NTSC signal creation would be greatly appreciated!

 

[Sceadwian]

A crystal oscillator is going to be needed for a TV signal, stability if nothing else. This is one of the departments AVRs excel at because their I/O is 4 times faster than a PIC at the same clock frequency. There are many college projects done interfacing an AVR to a TV, will give you something to google for information.

**broken link removed**
Small AVR-based TV terminal | µ[micro]electronics info

Considering the pulse widths needed a normal PIC probably isn't gonna cut it for a video signal. Even AVRs can at best do a few 100 pixels.

 

[Hank Fletcher]

Did you check that guy's video? He's got something going on with the PICs, so he must be some kind of wizard. He mentions Sparkfun in either that or one of his other videos, so maybe I'll go take a look to see what I can dig up there. This whole 64us PAL vs. <64us NTSC thing is really bugging me. I didn't anticipate that it'd be something like that holding me up.

I wonder what the Atari 2600 used...?

 

[blueroomelectronics]

One of the chapters in Learning to fly the 16bit PICs (24F) includes a 24F series NTSC generator. Don Lancasters old Video Cookbook showed off a circuit that used the old 6502 to generate video.
Amazon.ca: Programming 16-Bit PIC Microcontrollers in C: Learning to Fly the PIC 24: Lucio Di Jasio: Books

PS don't use 20MHz find something that divides exactly into the VSYNC interval (59.9Hz if I recall) and HSYNC 15.734kHz

 

[futz]

One of the chapters in Learning to fly the 16bit PICs (24F) includes a 24F series NTSC generator.

It's a pretty **broken link removed**.

 

[Mike - K8LH]

Hank,

What kind of dot pulse resolution do you need on a typical scan line?

Mike

 

[Hank Fletcher]

What kind of dot pulse resolution do you need on a typical scan line?

It's just for fun for me, so "need" doesn't really come into play so much. I suppose what would be useful would be something over 100, maybe aim for 160? The Stanford lab kchriste linked to in another thread I started in this interest (I was trying to widen the net to get advice on NTSC from people who might not by interested in mcus) gives full marks to students for setting up a 10x10 paint program with an 8MHz AVR. I reckon I might be able to do at least that good!

Incidentally, in the wiki on PIC mcus, there's a reference in the interupt description for using a PICs interupt capabilities to produce a video signal:

The constant interrupt latency allows PICs to achieve interrupt driven low jitter timing sequences. An example of this is a video sync pulse generator. Other microcontrollers can do this in some cases, but it's awkward. The non-interrupt code has to anticipate the interrupt and enter into a sleep state before it arrives. On PICs, there is no need for this.

Would anyone care to expand and further explain that to me?

 

[monkeybiter]

have you seen this
**broken link removed**

 

[Hank Fletcher]

have you seen this
Rickard's electronic projects page - PIC-Pong

I have. It certainly seems to be a popular reference during my various surfings on the subject. Thing is (at least on his related pages describing getting the video going), he's using a 12MHz crystal, if I recall, and the best plan I've been able to reckon so far is getting something going with an 8MHz internal oscillator or a 20MHz. I'm not familiar enough (yet) with the finer details of assembly to be able to deduce what needs to be changed in the code to compensate for various crystal frequencies. There just doesn't seem to be a sure-fire way to do this in a BASIC compiler, since it would seem difficult to deduce what the resultant compiled codes clock cycles might be i.e. to be sure to get the horizontal and vertical timing right (or at least as close as possible).

By the way, if I'm buying a 20MHz crystal (or is a ceramic resonator better), where should I get if from? Is there much that can go wrong in selecting one, e.g. making sure it's a convenient package size?

 

[blueroomelectronics]

Try using a 14.318MHz crystal, it's easy to divide down to NTSC frequencies. It's also very common as it was used in IBM PCs from the last century.

 

[Mike - K8LH]

Hi Bill,

Any idea how that particular crystal frequency makes it easier to produce an NTSC/RS-170A video signal?

 

[blueroomelectronics]

It's the frequency used on the old CGA cards, 14.318MHz (4 times the NTSC subcarrier frequency).
https://z80cpu.eu/mirrors/www.seasip.demon.co.uk/VintagePC/cga.html

Or this
**broken link removed**

 

[monkeybiter]

I think you'll find you need to resort to assembly to attain the neccessary timing accuracy [and possibly speed]

 

[Mike - K8LH]

No, I meant how would that particular crystal frequency make it easier to produce an NTSC video signal using a PIC?

What is an "NTSC subcarrier frequency"?

Mike

 

[blueroomelectronics]

It's a multiple (4x) of the NTSC colorburst frequency, although if you want just B&W you'll need to find a crystal that divides evenly into 15,734Hz if your frequency is off you'll get horizontal tearing in the picture.

NTSC - Wikipedia, the free encyclopedia

How can I generate NTSC video sync, optionally synched to an external source, with a PIC16C71 running at 20 MHz?

Don't. If you must generate sync with a PIC, run it at 14.31818 MHz. You won't be able to sync to an external source, though... The PIC's interrupt latency won't allow it.If I were you, I'd forget about using a PIC altogether, and just use off-the-shelf sync-separator and sync-generator chips. Everybody makes these things... Try National's LM1881 sync-separator and LM1882 sync-gen (or, if your sync source is less than perfect, you may want to use Elantec's separator).

**broken link removed**

 

[Mike - K8LH]

The Stanford document (the other NTSC thread) uses a 63.5 usec horizontal line with a 4.7 usec 'sync' pulse, a 5.9 usec 'back porch', 51.5 usecs of video data, and a 1.4 usec 'front porch'. That works out to a 15,748 KHz frequency. Those timings also work out perfectly for the 100 nsec Tcy when using a 40 MHz crystal on an 18F' device.

There must be some degree of variation that allows the TV to work with different horizontal frequencies?

Mike

 

[Hank Fletcher]

There must be some degree of variation that allows the TV to work with different horizontal frequencies?

Mike

The same Stanford document you mentioned explicitly suggests as much. I think getting in the ballpark of 63.5 microseconds per scan line is sufficient, the ballpark being within 2 or 3 microseconds. The important thing seems to be making sure that whatever time for that is the closest you can manage, that it's exactly consistent from scan line to scan line.

 

[blueroomelectronics]

Point is crystals come in many frequencies, why would you use something like 20MHz when you could use something that's a better fit for the job at hand? Try digikey for some common frequencies.

 

[Krumlink]

I have that same mini TV. It sucks lol.

 

[Roff]

14.31818MHz is exactly 910 times the NTSC horizontal frequency, and exactly 4 times the NTSC color subcarrier frequency. You can generate fully interlaced color NTSC if you start with this frequency. Obviously, if you don't need color, you can start with any frequency that will divide down to 15.734kHz and also will give you enough resolution to get reasonably accurate pulse widths for horizontal sync, vertical sync, and equalizing pulses.