NTSC composite video-out interface

Hey Arduino community,

I've been trying to design an NTSC composite video-out interface using an Arduino or two. I've found several threads/sites about this topic, as well as Arduino-specific implementations, and even pre-built shields, yet I would like to create my own implementation from scratch for fun and learning. My ultimate goal is to create a pseudo-command line interface; but video-out clearly come first.

I've been reading up on the NTSC and composite-out signal format (See next post for link) and feel that I understand a general approach I may take. The two issues I still cannot work around is memory usage and output timing.

I understand the NTSC format is 525 horizontal lines, with only 486 of those lines visible (The extra buffer is to allow internal hardware to move back to the appropriate position for older systems?). The screen is rendered out at 30 frames per second, with the even lines drawn first and then odd lines per frame (So the rendering occurs at 60 Hz). On today's modern NTSC systems, the expected resolution is 720 by 480. Is this all correct?

First issue: Memory. If I allow one bit per pixel (white or black), then I must reserve ( (720 * 480) / 8) = 43,200 bytes, which is clearly too large for the 8KB SRAM. My options seem to be either a) reduce the resolution (which is fine, but I hate to loose the detail, though 180 by 120 is only 3KB!) or to b) interface with a large off-board SRAM chip, which I have never done before. What would you recommend as I do not know of the time overhead of reading off-board memory?

Second issue: Speed. I am thinking of getting the Arduino Mega, which runs at 16 MHz with roughly 16 MIPS, in which I try to bitshift out (is this possible with the Arduino chip?) to my video lines. My main concern here is will I have enough speed to render out at the highest resolution (720 by 480) or will I only have enough speed to render out at a low resolution (180 by 120)? I know MIPS assembly, though that may greatly differ from the Arduino's processor assembly version; I expect maybe 10 instructions max per pixel out, but have no idea how to even start the math to understand if it will be too slow or too fast?

One final question: If I do have enough speed to render out, when will I be able to run my general logic? I define general logic as non-rendering specific logic, but standard code where I might be reading for a button input, reading a sensor, etc... I was thinking about placing an external timer for a set-interval interrupt in which I place my general logic in "void loop()" but have the interrupt call the render routine.

Sorry for the huge write-up, I actually haven't found any good site that talks about these issues, so I want to help the community by explaining my problem and solution in detail for future use. Thanks for any and all help; I'm all ears for any ideas!

NTSC Format link: http://www.rickard.gunee.com/projects/video/pic/howto.php

Sorry about that; I needed a first post before able to apply a link.

Reading off-board memory is going to be super-slow so let’s stick with on-board RAM. A 64us scan line 1024 cycles. Optimistically assign 4 cycles for each pixel (2 to read RAM, 2 to diddle output bits) and you can maybe get 256 pixels horizontally. With 1 bit per pixel (black or white) that gives you 32 vertical lines if you use up your 8kB of memory. Or you can have 128x64 and looser timing on the horizontal.

I don’t think there’s any way you’re going to get 720 pixels across.

You can run your general logic during vertical retrace.


I see the math and logic behind the resolution and timing solution. I see this shouldn't be as intensive as I thought timing wise; and thank you for the off-board memory extension.

Sorry but this is really not on. If you are using software to bit shift the video data out of a byte then when you change the byte that adds extra time and spoils the pattern. You are going to suffer problems with jitter as well. You might be able to display a few horizontal bars but vertical bars are a different matter. If you really want to do this then you would be better off using dual ported ram feeding into a shift register with a hardware digital TV time base derived from a clock. I designed many circuits like this in the 70's and have tried most variations so I am not just talking theoretically here.