PAL vs. NTSC - Electronic Circuits Projects Diagrams Free

Hank Fletcher · 5th June 2008, 01:41 AM

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 · 5th June 2008, 01:52 AM

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.

AVR based TV cronograph
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 · 5th June 2008, 01:57 AM

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 · 5th June 2008, 02:48 AM

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 · 5th June 2008, 03:01 AM

Quote:

Originally Posted by blueroomelectronics

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

It's a pretty good book.

Mike, K8LH · 5th June 2008, 04:33 PM

Hank,

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

Mike

Hank Fletcher · 6th June 2008, 03:31 AM

Quote:

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:

Quote:

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 · 6th June 2008, 12:05 PM

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

Hank Fletcher · 6th June 2008, 08:57 PM

Quote:

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 · 6th June 2008, 09:15 PM

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 · 6th June 2008, 09:26 PM

Hi Bill,

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

blueroomelectronics · 6th June 2008, 09:33 PM

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

Or this
Programming the MC6845 - The Vintage Computer Forums

monkeybiter · 6th June 2008, 09:37 PM

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

Mike, K8LH · 6th June 2008, 09:37 PM

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 · 6th June 2008, 09:48 PM

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

Quote:

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).

http://home.netcom.com/~fastfwd/answers.html#PIC00066

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Similar Threads
Thread	Thread Starter	Forum	Replies	Latest
Ntsc	TKS	Micro Controllers	5	1st June 2006 08:44 PM
Convert an NTSC in-car TV	mcncy	Electronic Projects Design/Ideas/Reviews	4	21st March 2004 09:47 AM
NTSC-PAL conversion	apakhira	Electronic Projects Design/Ideas/Reviews	0	25th February 2004 05:04 PM
NTSC to PAL CONVERTER	thesim	Electronic Projects Design/Ideas/Reviews	9	13th February 2004 03:32 PM
NTSC to PAL convertor circuit (NTSC=>RGB; RGB=>PAL)	apakhira	Electronic Projects Design/Ideas/Reviews	2	30th January 2004 05:05 AM

5th June 2008, 01:41 AM	(permalink)
Hank Fletcher	PAL vs. NTSC 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!

5th June 2008, 01:52 AM	(permalink)
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. AVR based TV cronograph 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. __________________ "Because I be what I be. I would tell you what you want to know if I could, mum, but I be a cat, and no cat anywhere ever gave anyone a straight answer, har har." Last edited by Sceadwian; 5th June 2008 at 02:00 AM.

5th June 2008, 01:57 AM	(permalink)
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...? Last edited by Hank Fletcher; 5th June 2008 at 01:57 AM.

5th June 2008, 02:48 AM	(permalink)
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 __________________ Bill Smart Kits build Smart People http://www.blueroomelectronics.com Last edited by blueroomelectronics; 5th June 2008 at 02:54 AM.

5th June 2008, 04:33 PM	(permalink)
Mike, K8LH	Hank, What kind of dot pulse resolution do you need on a typical scan line? Mike Last edited by Mike, K8LH; 5th June 2008 at 04:35 PM.

6th June 2008, 12:05 PM	(permalink)
monkeybiter	have you seen this Rickard's electronic projects page - PIC-Pong

6th June 2008, 09:15 PM	(permalink)
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. __________________ Bill Smart Kits build Smart People http://www.blueroomelectronics.com Last edited by blueroomelectronics; 6th June 2008 at 09:15 PM.

6th June 2008, 09:26 PM	(permalink)
Mike, K8LH	Hi Bill, Any idea how that particular crystal frequency makes it easier to produce an NTSC/RS-170A video signal?

6th June 2008, 09:33 PM	(permalink)
blueroomelectronics	It's the frequency used on the old CGA cards, 14.318MHz (4 times the NTSC subcarrier frequency). http://z80cpu.eu/mirrors/www.seasip....agePC/cga.html Or this Programming the MC6845 - The Vintage Computer Forums Last edited by blueroomelectronics; 6th June 2008 at 09:36 PM.

6th June 2008, 09:37 PM	(permalink)
monkeybiter	I think you'll find you need to resort to assembly to attain the neccessary timing accuracy [and possibly speed]