Basically each horizontal scan the electron gun shoots corresponds to a 64uS waveform. The first 4uS are the sync pulsem the next 8uS prime the electon gun, and the last 52uS correspond to the asctual image you see( .3V is black and 1V is white)

I'm using the same Digital to Analog converter shown on the websiteto generate 0V, .33V, .67V, and 1V based on pin 2(D0) and pin 3(D1). I tested the different voltage to make sure I haven't wired anything wrong, and the hardware seems to be fine. My code should just continously display lines white, but I'm getting moving white and black lines.http://www.datablue.net/random/badVid.AVI

I've tried some other waveforms( another site said the wave form should be a 2uS black pulse, a 4us sync pulse, another 4uS black pulse, and a 54uS image data) but still didn't get proper results.I've also read that it should be 63.5uS not 64uS.

I beleive it's a timing problem with my sync pulse (possibly becuase the digitalWrite() function is taking a few microseconds or beacuse the delayMicroseconds() isn't accurate enough?)

Daniel

great, really complex question. Composite video is an amazing pain in the ..um...I used to build video edit suites, with miles of precisely cut cable and ten thousand dollar little boxes (time-base correctors) whose sole purpose was to correct the timing of the sync signals coming from VTR's. All that was so that you could get this thing called a "dissolve". A lot of executives at Sony bought a lot of hot tubs and fancy cars from that technology.

I am not sure you can really do what you want to do <and> do anything else useful at the same time with the Arduino, as generating video has to be done constantly and very accurately, or the screen loses sync and the image disppears rolls, tears, etc etc. That's probably why most designs use an outboard video chip that is devoted to that job.

Anyway. I don't remember everything, but you are sort of on the right track. You have described the horizontal blanking interval, which is the time the beam is between drawing lines. In the HBI you've got the horizontal sync, and then some quiet time, and then the colour burst. There's something called the "breezeway" and the "back porch" in there too. (In fact, if you look closely, you can almost see abunch of old TV engineers in white lab coats sitting around in front of miles of tall grey rack mount gear, with their coffee cups perched on their Tektronix roll-around oscilloscopes.)

This standard has been around for a long time, and they have all kinds of cool names for each part of it. I'm assuming you will ignore the colour burst, as I doubt you could generate it in the Arduino (the colour is phase encoded onto a 3.58Mhz signal, which gets sent at the right end of the HBI for about 2.5 microseconds. Most Tv's will just default to B/W if the colour burst is there or minimally there, as this was the work-around, in NTSC at least, to make colour TV's receive stations that were transmitting B/W back when colour was introduced. Yes this stuff is that old.

There are two things you haven't mentioned: the colour standard and the vertical blanking interval. You need to find the specs for the standard waveform for wherever you are: NTSC (aka 'never twice same colour'), SECAM or PAL? The blanking intervals are different for each. Diferent countries use different standards.. it's all very political.

Next, you've got to have some code for the Vertical blanking interval, which includes the vertical sync. (This is probably why your code doesn't work-- you don't have a vertical blanking interval.) Vertical sync, If I remember correctly, is easy. They used to derive it by half-wave rectifying the power line frequency... so in Canada it's 60hz/2= 30hz, and in Europe it's 50hz/2= 25 hz. ( there are some finicky exceptions to this rule, as later on they started deriving the sync signal from the colour burst crystal at 3.58Mhz, and the closest they could get to 30 was 29.94, which led to a whhole industry in machines to convert between those rates in production houses) Anyway, the vertical sync has to be in the middle of the vertical blanking signal.

So, in NTSC for example, you have this happening thirty times per second:- vertical blanking interval, with vertical sync moves beam to top- horizontal blanking interval, with H sync, moves beam to left of screen - phase of the colour burst signal locks the colour decoded in the TV- line gets drawn- repeat sync, burst and horizontal line for odd lines- another vertical interval, with vertical sync,- repeat sync, burst and horizontal line for even lines- Voila, you have a frame!

The even lines and odd lines get drawn separately, since if they were drawn consecutively, the phosphor on the top part of the screen would fade before the linews were all drawn.

Last but not least, all this stuff has to be really precise! A little "jitter" in the signal, and it doesn't work.

The good news is that this is an extensively documented standard: hundreds of millions of tv's and video cameras have been made for NTSC, and they all use the same signal standard. Here's one excellent document on the video signal:http://www.maxim-ic.com/appnotes.cfm/appnote_number/734

But hey.. there are lots of chips around that are designed to do this for you, why not use one of those?

Example of a really old video chip: http://en.wikipedia.org/wiki/MC6847Example of recent one that can insert 'arbitrary graphics' into 8 video sources...http://www.maxim-ic.com/quick_view2.cfm/qv_pk/3415The MC1377 is another old old old chip.. it takes RGB analog values and the chip adds the required sync.

Daniel

PS: if you are really into the pain and suffering of generating your own video, then the smart thing to do seems like:code a dedicated Atmega8 to generate the video, and have it look for the information on what it should display during the (relatively) long vertical blanking interval. Even so, you'll need a lot of ram (a full frame of digital video uncompressed is something like 4MB) to store the screen data for even the simplest of images. The Atmega serial port isn't really known for its capacity to process that kind of throughput.

the arduino is also having some timing issues, the delayMircoseconds don't work so well for delay between 2-10 uS, but the delay for 1 uS is working perfekt. So for a delay with 4 us you should write 4x delayMircoseconds(1), the same for the 8 us delay, the 52uS delay should work on the normal way.One the other hand you should use the c code for writing the pins. Just copy it from the arduino library, this will save some time. You can also have a look in the DMX512 code example on the arduino wiki (not on the arduino website, the one on the website is not working!) For DMX you also have to use 4uS delays.

Thanks for all of the ideas. I realize how critical it is to get the timing just right. At the moment I'm still having issues witht the video syncing up so I'm really not sure what to do. I've tried using the delayMicroseconds(1) but I'm having similar difficulties as before.

I haven't even begun to play around with the vertical blanking interval since right now I'm just trying to get it to display solid lines down, so I know I have the horizontal timing right.

I'm not giving up yet, but I'm kinda stuck :/

One of my goals is to have a small protable text generator to use in some other projects. If i can I'd like to make some basic atari-like games as well.

Daniel

composite video won't display anything correctly without a vertical refresh twice per frame, or 60 tims per second, so try that. It's the same idea as the horizontal sync, but for the vertical retrace. Without a vertical sync signal, you would get exactly what you're describing: rolling lines.

Daniel

But you need the vertical sync signal, that's why it's rolling. You can't jump ahead and work on the image part until you have the sync signals right... video won't display any kind of image correctly until you give it nice stable vertical <and> horizontal sync signals! That establishes the 'canvas' to which you can write your images. Using one sync without without the other is like trying to walk on one foot only.

Hello, this is my first post after reading some months, please ignore any mistakes.

I just got this out of my arduino:

and no, i did not write the code myself, i only ported it to my arduino wich was not very hard, got the code from this website:

http://mitglied.lycos.de/polyxos/video.htm

I followed the (german) instructions and burned the resulting hex file into my board with my (eprom)programmer, had to use other fuse settings as the arduino uses a x-tal unlike the schematic on the site.

Now i would like to disassemble his code to make some mods, anyone know how to do this? is there a disasm with the arduino?