Color SVideo. Like the AD725 chip except in software?

Other Hardware Displays
1

For the last couple of days I've been mulling over trying to get color video from an arduino onto a TV. It started when I revisited a Namco TV PlugNPlay game with Pacman, DigDug, Etc. I was wondering if I could use an arduino to hijack its graphics chip. Anyways, I opened it up and found a bunch of surface mount components. Lol, not surprising. I guess I could still hijack the controls.

Anyways, I was looking into various options like the TVOut library. Google Code Archive - Long-term storage for Google Code Project Hosting.
Black and white and low resolution.

In fact, until yesterday I had little understanding of analog NTSC signals. From TVOut I learned that a sync signal is 0V, black is some fraction, and white is 1V.

Another thing I looked into was an antiquated monitor that has inputs for H and V Sync and R, G, and B. Component video.

Then I stumbled upon the Uzebox. It had both SVideo and Composite video. The Uzebox uses an ATMega644 overclocked a bit and another chip, the AD725, to do the NTSC modulation: http://www.analog.com/en/digital-to-analog-converters/video-encoders/ad725/products/product.html

Looking at the image, it looks like it takes component video and outputs both SVideo (Y/C) and composite video. After much research, much of which was on wikipedia, composite video is like SVideo except mixed together (with more subcarrying of course).

So, as far as I can tell, it's like having TVOut drive the Y part of SVideo and writing a new piece that does color (with some color burst timing that I'll mention after this next bit).

Although, there's a bit I don't quite understand yet.

Here's this that I'll be quoting from: NTSC - Wikipedia

"In NTSC, chrominance is encoded using two 3.579545 MHz signals that are 90 degrees out of phase, known as I (in-phase) and Q (quadrature) QAM. These two signals are each amplitude modulated and then added together. The carrier is suppressed. Mathematically, the result can be viewed as a single sine wave with varying phase relative to a reference and varying amplitude. The phase represents the instantaneous color hue captured by a TV camera, and the amplitude represents the instantaneous color saturation."

Notice that last sentence. Anyways, that sounds like HSV colorspace: HSL and HSV - Wikipedia
Does this mean I can generate one sinewave (with phase and amplitude modulation) that represents Hue and Saturation? If so, I could cut out RGB from the graphics entirely and have it native HSV. It would be a bit different than most video chips, but it could provide interesting advantages. If you wanted to implement pacman, you could have one ghost bitmap with S and V. H would then depend on the ghost. If you want a basic bitmap a sprite, you still only need to store 3 values. Of, course, any sort of color (or even grayscale) throws a framebuffer out the window on our ATMega chips. Tile and sprite graphics to the max! One thing I was curious about was if you could do a square wave instead of a sine for the color modulation. Although that probably doesn't work, due to the signals only matching up at the top and bottom of the sine.

I think what's left is color burst, syncs, and interlacing. Uzebox has some helpful info on that:
http://belogic.com/uzebox/video_primer.htm
http://belogic.com/uzebox/hardware.htm

Also this: NTSC - Wikipedia

The interlacing means there's two fields per frame at a framerate of about 30Hz. That's like having two half (vertical) resolution frames at a rate of 60Hz. Something I'd like to experiment in is displaying 640x480@30 and also 320(or even 640 or 720 or 256 or whatever)x240@60. Although, if I understand corectly, the two frames will blur together because of how the interlacing was designed. This could be useful for "transparency" effects that flicker a sprite off and on between "fields."

What I'm worried about is generating the sine wave for the color. This page says: Uzebox - The ATMega Game Console

"The AD725 requires two more input to perform its job. One is the composite sync signal generated by the MCU. The other one is a clock signal at 14.31818Mhz. This clock happens to be four times the frequency of the color burst and is absolutely required in order to generate color. That clock's frequency also happens to be exactly half that of the MCU. This is no coincidence. The MCU has a timer set to toggle an output pin at half its main clock."

This is why the ATMega on the Uzebox is overclocked to 28 and some MHz. I don't think our Arduino, clocked at 16MHz, can generate a clear sine wave at 3.579545MHz. 16/3.579545 = 4.469841837. That means the maximum we could get at that frequency would be a resolution of 3 values. -1, 0, and 1 (on the sine). That's like two square waves ith one following sine and the other following cosine. So at this point I think we need some sort of (voltage controlled?) external oscillator to do the color. And then we need some way to control the amplitude of that sine. For that we might need a transistor that does that. So far I think we have 3 DACs. One for black/white value, one for the frequency (or phase) modulation of the sine, and one for the amplitude modulation. Also an extra pin for the DC offset for sync stuff on the Y part of SVideo just like TVOut does.

So, that's a bit more hardware than I expected coming in. But it does reduce the need for your surface mount AD625 NTSC encoder.

As I stated, until yesterday I knew none of this. I hope I got it right, though.

EDIT: I just thought of something. Maybe a filter could be used to filter a 3.57945MHz square wave into a comparable sine wave?

2

Sorry to disappoint you, but the Arduino is nowhere near fast enough to synthesise the colour subcarrier and modulate it. Also, the tolerance on the subcarrier frequency is very tight (the TV synchronizes a crystal oscillator to it). Using an encoder chip is the only practical way, and most video encoder chips are surface mount. You can buy breakout boards for surface mount chips to make connecting to them easier.

3

I just looked that the price of the encoder chip. I didn't realize it was so cheap.

Anyways, I'd still like to look into alternate ways of doing the color. Although, I don't know much about oscillators.

Another thing I'd like is to do a more flexible version of the current TVOut that works on composite or SVideo. Greyscale or monochrome with higher resolution tile and sprite graphics. Then if I can figure out the color later it'll fit into that library.

EDIT: The only unknown at this point is about Voltage Controlled Oscillators or something like that. I don't know much about intricate electronics like this. Know any good tutorials or guides?

EDIT2: There's also the option of doing AM on two 3.5...MHz oscillators with one being 90 out of phase. This would mean we're doing RGB colorspace again (or it would take additional processing for HSV). The reason this might be easier is if the appropriate oscillators are easier/cheaper to obtain and calibrate than it is to build/buy a VCO that can do 3.0... to 4.0...MHz. As I said, I don't know much about such intricate electronics. Nor how to synchronise them as such.

Also, according the picture in this: NTSC - Wikipedia
The color band can vary by half a MHz. Which is why I said 3-4MHz range for the VFO.

4

Jorh:
I just looked that the price of the encoder chip. I didn't realize it was so cheap.

Anyways, I'd still like to look into alternate ways of doing the color. Although, I don't know much about oscillators.

Another thing I'd like is to do a more flexible version of the current TVOut that works on composite or SVideo. Greyscale or monochrome with higher resolution tile and sprite graphics. Then if I can figure out the color later it'll fit into that library.

EDIT: The only unknown at this point is about Voltage Controlled Oscillators or something like that. I don't know much about intricate electronics like this. Know any good tutorials or guides?

EDIT2: There's also the option of doing AM on two 3.5...MHz oscillators with one being 90 out of phase. This would mean we're doing RGB colorspace again (or it would take additional processing for HSV). The reason this might be easier is if the appropriate oscillators are easier/cheaper to obtain and calibrate than it is to build/buy a VCO that can do 3.0... to 4.0...MHz. As I said, I don't know much about such intricate electronics. Nor how to synchronise them as such.

Also, according the picture in this: NTSC - Wikipedia
The color band can vary by half a MHz. Which is why I said 3-4MHz range for the VFO.

Right now, about your best chance at getting workable software-only (mostly) color video out of an Arduino would be to look into how the Craft demo was done:

http://www.linusakesson.net/scene/craft/

It uses an ATMega88 - based on what I can see (and admittedly, I haven't done a side-by-side detailed comparison), it seems to have less power than the 328 commonly used on the Arduino. Of course, there's a ton of tight code being used for the graphics and sound (the guy is a demo coder), not to mention some custom hardware (plus it's clocked at 20 MHz, which might make a big difference).

5

I should probably also mention LFT's other "minimalistic" ATMega88 demo - Phasor:

http://www.linusakesson.net/scene/phasor/index.php

It uses the same/similar platform as Craft, but generates color composite PAL; from what I understand, though (on reading other sites about software generated video), PAL is somehow (I don't understand it really) simpler to implement in code than doing the same with NTSC, and that you probably couldn't generate workable NTSC video with a small microcontroller like the Arduino (then again, maybe I misunderstood everything I read). But don't let that stop you from trying; you may end up proving everyone wrong!

:slight_smile:

6

I have seen Craft before. Not Phasor.

Anyways, reading it, the key is that he clocked the uC to the desired frequency. Arduino already has its own standard clock speed. The Uzebox also does this, but so it can provide the clock to the NTSC encoder chip.

So either I need to under clock the Arduino to 14...MHz or use an external oscillator. Or use an extra AVR as a graphics chip clocked to the correct frequency. At that point it'd be easier to use the encoder chip.

After researching I've found that you can find an external oscillator that'll work. A google search of "VCXO" (for Voltage Controlled (X)Crystal Oscillator).

I'm not sure how feasible it is to get something like this or if you could rip suitable oscillators from existing electronics.

7

Be aware that once you change the arduino's clock frequency you will no longer be able to upload sketches using the normal method and you will have to use a chip programmer.

8

That's why I think using an external oscillator to do the color would be much better.

9

I got my soldering equipment in the mail today. Now I'm waiting on breadboard, etc. from Seedstudio (in china). So hopefully soon I may be able to work on at least the grayscale portion.

10

As an update, I finally got all my things from Seeed Studio. Today I made the hardware for TVout plus a 4-bit R2R DAC. I watched the TVout demo for hours! Well, not quite...

Anyways, I'm going to experiment with doing grayscale tile graphics for awhile. What I'm aiming for (at the moment) is 8-bit grayscale tile graphics at 640x480 resolution. As far as I'm know at the moment, that's possible, but also as far as I know, it's not been done in any projects I've seen.