Please help! Generating Composite video signals from scratch

Thread Starter

PauloConstantino

Joined Jun 23, 2016
266
The 2-inverter crystal oscillator is good enough for this application. The TV dos not care about a fraction of a percent error in video frequencies.

In the US I would start with a 14.31818MHz crystal. This is 4 times the color burst frequency in NTSC video. I don't know what the equivalent frequency is in the PAL system. I vaguely remember using something like 20.5 MHz.

Found it -- see the PDF -- actually 2.5625 MHz. I think I started with the 20.5 MHz and divided it by 8 to get the clock for the ZNA134. The 20.5 MHz was used for the pixel clock. You probably don't need that many pixels on a TV line.


I was thinking differently. I was thinking of using a clock which is 15.625kHZ to generate just the SYNC signals. And then using another clock to control the pixels. What am I missing? I thought I would just gate the sync signals on the same line. I guess it would lose SYNC then ?

So if I dont start with the pixel clock it will lose sync? omg...
 

Thread Starter

PauloConstantino

Joined Jun 23, 2016
266
I think I will just go with VGA for now. But I need to buy a VGA monitor for that........... I wanted to use my old composite monochrome tv..........
 

AnalogKid

Joined Aug 1, 2013
10,986
The first and last images have it all inverted, why ?
The "sync-positive" waveform is what modulates the transmitter, so that is the waveform seen at by the transmitter people. Sync-negative is what runs all over the production and distribution systems.

The video signal is AM on a carrier, so up is maximum carrier amplitude. This puts most of the transmitter emitted energy into the sync tips, assuring that even a weak and noisy picture is stable. That was a system-level tradeoff, stable but noisy, or clean and flapping all over the place.

ak
 

Thread Starter

PauloConstantino

Joined Jun 23, 2016
266
How am I supposed to generate the small variations in the sync signals? For example let's take the back, sync, and front porch signals. The back porch is 2us, the hsync is 4us and the front porch is 6us. Should I have a clock that goes with the period of 2us ? So that I can generate all these multiples? Then there is the thickness of the vsync signals too, for example the vsync signal is 27.3us, then it goes blank for 4.7us. How on Earth can I generate a negative pulse 4.7us long in hardware ? :(

I guess these should be generated by dividing the main pixel clock ? Which is at the Megahertz frequencies ? Is that it ?
 

AnalogKid

Joined Aug 1, 2013
10,986
Before TTL, sync generators were large and ungainly beasts. In the 70's things settled down to starting with a 10.7 MHz or 14.31818 MHz crystal clock (in the US) and counting everything down from there. Those two frequencies are 3x and 4x the NTSC color subcarrier frequency, and all timing is derived from integer dividers. They also served as the master clock for video A/D and D/A systems, such as in digital timebase correctors. Way back I used a predecessor to the LM1882. I haven't used the 7049, but it looks like a good place to start.

ak
 

Thread Starter

PauloConstantino

Joined Jun 23, 2016
266
Before TTL, sync generators were large and ungainly beasts. In the 70's things settled down to starting with a 10.7 MHz or 14.31818 MHz crystal clock (in the US) and counting everything down from there. Those two frequencies are 3x and 4x the NTSC color subcarrier frequency, and all timing is derived from integer dividers. They also served as the master clock for video A/D and D/A systems, such as in digital timebase correctors. Way back I used a predecessor to the LM1882. I haven't used the 7049, but it looks like a good place to start.

ak

I don't understand colour signals. Can you explain it to me in terms of the monochrome sync pulses? If you take the smallest part of the period, those little tiny bits of the duty cycle, is that part also then generate by this 14.31818MHz clock then ? And also the front, and back porches, I can't make sense of them in terms of multiples of a single clock...
 

AnalogKid

Joined Aug 1, 2013
10,986
All of my numbers are in the US NTSC system, but there are parallel numbers for the British system.

Start with 14.31818 MHz.
Divide by 4 to get 3.579545 MHz, the color subcarrier frequency. A sinewave at this freq is amplitude and phase modulated to produce the color subcarrier signal that is summed with the mono signal to form composite color video.
Divide that by 227.5 (or divide the 14.3 clock by 910) to get the horizontal line frequency.
Divide that by 262.5 to get the vertical field rate.
Divide that by 2 to get the vertical frame rate, 29.94 frames per second.

Within a horizontal line, different counts of the high frequency clock define the start of horizontal blanking, the start of H sync, the end of H sync and the start of the back porch, the start and end of the color burst, and the end of H blanking. Or, once you have the start of horizontal blanking, a series of monostables can start and end H sync and burst, and the end of blanking. A 14 MHz clock has a very short period, and stacking up those periods can define all of the video frame timing signals with excellent resolution.

ak
 

Thread Starter

PauloConstantino

Joined Jun 23, 2016
266
All of my numbers are in the US NTSC system, but there are parallel numbers for the British system.

Start with 14.31818 MHz.
Divide by 4 to get 3.579545 MHz, the color subcarrier frequency. A sinewave at this freq is amplitude and phase modulated to produce the color subcarrier signal that is summed with the mono signal to form composite color video.
Divide that by 227.5 (or divide the 14.3 clock by 910) to get the horizontal line frequency.
Divide that by 262.5 to get the vertical field rate.
Divide that by 2 to get the vertical frame rate, 29.94 frames per second.

Within a horizontal line, different counts of the high frequency clock define the start of horizontal blanking, the start of H sync, the end of H sync and the start of the back porch, the start and end of the color burst, and the end of H blanking. Or, once you have the start of horizontal blanking, a series of monostables can start and end H sync and burst, and the end of blanking. A 14 MHz clock has a very short period, and stacking up those periods can define all of the video frame timing signals with excellent resolution.

ak

I cannot thank you enough AnalogKid! That's a fantastic explanation and very clear. All this time I have been struggling with how to define those small little periods inside the signals and couldn't figure out how! Until you told me about the 14MHz clock. That makes so much sense. I really appreciate that.

As for the monostables.... That sounds so good too. Actually I didn't know about monostables at all. So they stay on or off for some period and then go off and on again ? That would be fantastic however I don't know the formulas to calculate the precise periods for a monostable...?

In the end do we combine all these signals by logic gates or do we add up the voltages in series ? Will start thinking about this now!
 

ian field

Joined Oct 27, 2012
6,536
Ricardo, help me generate the signals ? What kind of oscillator should I build? I read in a tutorial that there is a stable oscillator that can be made with NOT gates. I am thinking of building state machines to control the syncs. Is it easier to use just counters?
Many years ago; Elektor published a TTL based TV pattern generator - the schematic was a huge maze published over a few issues.

AFAICR: the master clock used a 10MHz crystal. The articles included tables of Boolean algebra explaining how all the necessary pulse trains were derived, there should be enough information there to re-design it for whatever scan rates are required - but I'd imagine any modern computer resolution has a faster dot clock than the master clock in that project.

There are/were numerous video generator chips produced for when most home computers had a TV output. AFAICR: the Atari had a video chip that didn't look too daunting for a home project. It was a very popular machine - so there could be the occasional appearance on eBay.
 

ian field

Joined Oct 27, 2012
6,536
All of my numbers are in the US NTSC system, but there are parallel numbers for the British system.

Start with 14.31818 MHz.
Divide by 4 to get 3.579545 MHz, the color subcarrier frequency. A sinewave at this freq is amplitude and phase modulated to produce the color subcarrier signal that is summed with the mono signal to form composite color video.
Divide that by 227.5 (or divide the 14.3 clock by 910) to get the horizontal line frequency.
Divide that by 262.5 to get the vertical field rate.
Divide that by 2 to get the vertical frame rate, 29.94 frames per second.

Within a horizontal line, different counts of the high frequency clock define the start of horizontal blanking, the start of H sync, the end of H sync and the start of the back porch, the start and end of the color burst, and the end of H blanking. Or, once you have the start of horizontal blanking, a series of monostables can start and end H sync and burst, and the end of blanking. A 14 MHz clock has a very short period, and stacking up those periods can define all of the video frame timing signals with excellent resolution.

ak
Some of the up market home computers used a master clock 4x the colour subcarrier frequency.

A quadrature clock was certainly useful in the PAL system - I don't know about NTSC.
 

AnalogKid

Joined Aug 1, 2013
10,986
Some of the up market home computers used a master clock 4x the colour subcarrier frequency.
The original IBM PC (August 12, 1981) had a 4.77 MHz CPU clock instead of a more normal 4.00 or 5.00 MHz. Why? Because the primary video adapter used a color NTSC ***television*** for a monitor, and had a little channel 3/4 modulator just like a VCR. The motherboard crystal frequency was 14.31818 MHz, 4 x color subcarrier, so the video adapter could use the same signal and save a buck. The 14.3 was divided by 3 to give the 4.77 CPU clock - and screw up timing routines for decades to come. Having a CPU clock that was not a binary, decimal, or combo multiple of 1 Hz was a colossal screw up.

Why did they do that? Because IBM's much-vaunted marketing arm identified video games as the PC's #1 application, and Atari as it's #1 market competitor. Once the deed was done, there was nothing the rest of the industry could do. As clones arrived and motherboards grew up, the master clock freq increased steadily over the the next two decades. But every single motherboard had two crystal clocks, one for the CPU and one at 14.318 for backward compatibility with the PC and PC/AT (now ISA) bus. I think it was the PC99 design standard that dropped ISA slots, and hence the need for the video clock.

ak
 

Thread Starter

PauloConstantino

Joined Jun 23, 2016
266
Thanks everyone.

I'm still thinking of the best way to do the circuit. I can't decide whetehr to create state machines to control the signals or to just use counters.

The information on the web is so contradictory. Every website has the timings differently. Number of lines differently and everything else.

I am finding it difficult to stick with one strategy.

Im planning to start with a 4MHz clock. The length of the horizontal sync signal is around 4us. If I divide the 4MHz clock to get a wave with period 8us, which is double the sync signal length, then this wave will be High for 4us each cycle. And If I control the counter by finding when it is at the begining of a line, and then gate this with the 8us clock, then I will get the sync period for every line.

However this must only happen 24 lines after the vertical sync. So I need to find the number of clock cycles ellapsed since the vsync signal and Gate this with the horizontal sync signal. Should I do this by ANDing and ORing the bits from the counter? Seems like a lot of work.

Then for the vertical sync signals....

The equalization pulses are 2us long, and happen six times after each field. And also 5 times after vsync pulses. Should I also use a cunter to find a condition when these are true?

It seems that a way of doing this is to AND and OR the bits from each counter in order to put a condition on when each signal should he true.

Apart from this I'm thinking of creating some sort of state machine to sort of count cycles and output accordingly. I have no ideas which is easier.

I am so lost, this seems really hard to do :(
 

nsaspook

Joined Aug 27, 2009
13,079
The equalization pulses are 2us long, and happen six times after each field. And also 5 times after vsync pulses. Should I also use a cunter to find a condition when these are true?

It seems that a way of doing this is to AND and OR the bits from each counter in order to put a condition on when each signal should he true.

Apart from this I'm thinking of creating some sort of state machine to sort of count cycles and output accordingly. I have no ideas which is easier.

I am so lost, this seems really hard to do :(
If you want to build it from scratch 100% exactly to NTSC specification it is hard. The precise signal parameters were designed to make the receiver side synchronization (originally using tubes) simple not the sync generator. There is really a fair amount of slop in what a receiver will accept and still generate a stable video signal as transmission standards usually generate the most precise signal possible and design the receiver to accept the most imprecise signal while still giving acceptable performance.

Just like I remembered, one of my old design 8080/TTL S100 video graphics systems used something like Don Lancaster's composite video circuit to generate the required signals using old Archer RS-2031 transistors for the video level drivers.
 
Top