> Is the PIC fast enough to be useable as a character generator to overlay
> text/graphics on NTSC video?  About 10 chars/line is all I need; nothing
> fancy.  (I want to overlay date/time on a camera feed.)
>
Offhand, I would say yes.  Last summer, someone else mentioned using RRFs on
a port to shift new bits to a single pin that serves as the serial output. A
font with each character 5 pixels wide and blank pixels between characters
could be displayed with a sequence like:

        movfw   gline
        movwf   PORTB           ;Display first pixel (B.0 is video output)
        rrf     PORTB,f         ;display second from left
        rrf     PORTB,f         ;
        rrf     PORTB,f
        rrf     PORTB,f         ;display fifth active pixel.
        clrf    PORTB           ;Video off.
        nop                     ;Blank between characters.
Then repeat the sequence for each character that is to be displayed, using data
from a different RAM location:
        movfw   gline+1
      etc. (repeat for 10 characters)
In order for this to work, pins B.1 thru B.4 have to be configured as
outputs so the bits will shift properly.  The desired output is B.0, which
shold force the picture "white" while it is high, and have no effect while
low.  If a black background is desired, that could be enabled while shifting
the pixels out using another output pin (of another port).  The rest of port
B will output garbage during the display period but could be reused for user
interface at other times.

During the rest of the line, the characters stored in RAM would be converted
to pixels for the next line using a table.  This process would probably take
about 10 instructions per character, so for a 10 character per line display,
the PIC instruction rate would need to be at least 100(overhead) + 80
(display) times the line rate, or a modest 2.8 MHz (11 MHz PIC clock).  Of
course the final clock rate chosen has to be an integral multiple of the
line rate.  At 2.8 MHz instruction rate, the line of characters would take
up 28 us, or about half of the visible part of the scan line.

This routine requires a byte of RAM to hold the pixels presently being
displayed for each character, in addition to a byte holding the character
code for the characters.  This could push the limits of a low-RAM PIC.  If
more space between characters is acceptable, RAM could be saved by
translating on the fly inbetween shifting the pixels for each character out
(or inbetween the date and time, etc.)

The other major problem is to synchronize the PIC's operation to the video
signal so the time display stays at a constant position on the picture.  One
method would be to program the PIC to output pulses at the line rate, then
phase-lock the PIC clock so these pulses do occur at the rate of the
incoming horizontal sync pulses.  Vertical sync would be with software.

Another method could be a RC or LC oscillator which is forced to start at a
known phase on every sync pulse, but the overall frequency is not critical
or controlled (it would affect only the width and position of the displayed
characters).  TV sets which display directly on the screen generally use
this method, although they have a special microprocessor with a video
generator section clocked by its own L-C.  Also as it is built into the TV,
it has access to the sweep generator pulse which is a lot cleaner and more
reliable than the sync pulse from the video signal.  For this project, it
could be as simple as clamping a L-C oscillator (crystal probably too slow
to restart, and R-C not rated for 12 MHz) off during each sync pulse.  This
would be OK for closed-circuit but would probably jitter too much with
over-air signals.

Especially for non-commercial applications, it may be OK to just use a
crystal oscillator running constantly at the 'right' frequency, and let the
text slant and jitter a bit.  Obtaining sync by software can be good to one
pixel (do multiple samples), but it might be better to use a larger "window"
and allow the text to drift over a larger range and jump back rather than
jitter rapidly.  Overall, not synchronizing the oscillator is not likely to
work very well, especially with low-cost cameras that are likely to not be
very precise in the line rate that they send.

If the PIC's oscillator is allowed to vary, it won't be suitable for
time-keeping.  Consider using the RTCC in external mode, either from the
power line if available or a crystal oscillator and divider, as a time base
for keeping the time-of-day.  The time and date registers would be updated
during the rest of the video frame, before waiting for vertical sync again.
Polling of the user's inputs would also be done during that time.

-Mike