PicTV

(or how I learned NTSC will never save the planet)

While I have been well aware of the fact NTSC is the video standard for the US of A, I never really explored why it worked, or how.  As someone who works primarily with video, and in particular live video manipulation, it seemed foolish to not take advantage of this opportunity to explore the standard, and find out what makes it tick.  Plus, low-resolution imaging is something I adore.  Before undertaking the project, I had toyed with the idea of building a digital video synthesizer, so I had a few specific parameters in mind.  In addition to the actual image generation, I also wanted to be able to manipulate whatever was being drawn on screen through an external control.  I had found some Pic to TV experiments on the web during preliminary investigation, but most of it was in PAL and in assembler.  Having no real knowledge of assembler, I decided to tackle the project in PicC.

What happened?

The first step was assembling the circuit.  Using resources on the web, I was able to construct a 2-bit DAC that would provide us with the necessary voltage levels to get the synch signal (0V), broadcast black (.33V), grey (.66V) and white (1V).  Not having exact resistor values (450ohm and 900ohm) we fudged and went with 470 and 903.  With the basic circuit completed, we attempted to implement a timing scheme on an 877A to match the NTSC rate. 

Then we struggled.  The code, while efficient, and running at 5x the speed of other examples we found online, is still not completely accurate.  NTSC, while loose enough for us to be off by a few microseconds, is still fairly strict, particularly when it comes to the number of lines being drawn.  We tried using a counter to determine the pin outs for the timing routines (based on Dan Hirshman's pwm routines), but it didn't work as we anticipated.  After several unsuccessful attempts, we tried what I termed the "brute force" method.  Essentially, we hardcoded the timing information for a horizontal line into the Pic.  When the brute force routine worked, we started to work with the problem of the vertical synch.  Again, we fudged a bit with this, but wrote in the equivalent of three lines of blanking information, three lines of vertical synch, and three more lines of blanking.  After some trial and error, we were able to lock in on the signal and hardcode a "neopolitan" screen (a static bar of white, grey and black across the screen). 

So we had an NTSC video signal.  Now what?  We had no spare time on the chip to do anything interesting with the image.  I tried adding an ADC to the Pic with a 10k pot, but all it managed to do was lose synch.  One night, I had a dream.  In the dream I plugged a BX24 into the circuit.  The next day I was discussing it with Shawn, and we came to the realization we could use a second chip to do the imaging and ADC.

We set up a circuit with an 18f452 running at 40mHz (!!) to draw and do ADC.  We stared an external interrupt (detecting the rising edge from the 877) every time we wanted to draw on the screen.  Once we got the interrupt working (and realized that we couldn't drop both pins low on the 877 or we would lose synch) we were able to start to implement some basic drawing algorithms to put information on the screen.

Can you tell me more about this timing you speak of?

The NTSC video standard for black & white television (aka RS-170) goes something like this: there are 525 lines of information in each frame (@29.97fps). Each horizontal line is 63.5µs long.  There is a "front porch" of .33V that lasts for 1.4µs, followed by a 4.7µs synch pulse (0V).  A "back porch" of 4.8µs (.33V) follows, leaving ~53µs of picture information for each line.  When a horizontal line is finished drawing* (from right to left), it crosses to the other side of the screen and continues drawing.

NTSC is interlaced, it draws 1/2 of the image in one pass, then draws the other half.  This is to reduce flicker, and keep persistence of vision.  So not all lines are drawn at a time.  When one field is finished drawing, the electron beam moves from the lower left corner of the screen back to the top right.  This is the vertical synch time.  The total time is equivalent to 9 horizontal lines (571.5µs).  The beam then redraws the horizontal lines in the other field before returning to the first field.  The lines draw like this:

523-16** vertical blanking interval (vbi)

17-259 even field image data

260 (1/2 of standard line) produces interlace

261-281*** vertical blanking interval (vbi)

282-522 odd field image data

With all this process and knowledge what could go wrong?

We experienced a few setbacks.  Most notably for me was the lack of true interlaced video.  I still can't figure out what is happening, except that we may be timing things wrong.  It's frustrating because with some of the tests involving dynamic scaling we were able to wrap lines to the other field and get a true interlaced image.  This is something I plan on continuing to look into.

Ok this is all fine and good, but what will you do with this?

I made this primarily because of my interest in video art and my desire to know more about the medium.  I think some of the timing problems we experienced produced some aesthetically pleasing effects, but nothing I'd really want to write about.  I plan on continuing this exploration in the future.  Stripping images of their timing information could provide interesting results (as when we plugged a camera into out circuit as it was running, creating a weird warped effect).  General image manipulation and synthesis are what this system seems best designed to do.  We are somewhat limited by the processing power and our programming abilities.

The system, being modular, can be used as a platform for other video artists and people interested in image synthesis.  We have created an environment in which people can play and create their custom low, or no cost applications. 

I'm looking forward to using this digital image synthesis as a springboard for research into analog video synthesizers in the near future.