NTSC composite timing for retroconsoles

[jameswilddev]

Hello!

Recently I've been tinkering with Arduinocade and having a go at writing my own implementation.  I've done a lot of research into how NTSC works and feel I've got a good understanding.  Of course, being similar to a retro console or retrocomputer, Arduinocade doesn't implement the NTSC specification to the letter; it only uses one field (so 240p60hz), doesn't include equalization pulses, doesn't adjust timing for VSYNC lines (they're single-pulse normal length lines rather than double-pulse 64usec lines) and uses artifact colors rather than generating real sine waves at 3.7MHz.  This works fine though.

I've been configuring my AVR to produce a NTSC signal based on this diagram from Maxim (from https://www.maximintegrated.com/en/design/technical-documents/tutorials/7/734.html#Composite%2FCVBS%20Interface):



My understanding here is that the line should be 63.5usec long, and the colorburst should begin 5.3usec after the falling edge of the HSYNC pulse.

When I generate a signal using the closest available approximations of these values, my test displays (a car reversing camera display with composite input, and a USB capture card; will have access to a real CRT from next week) don't seem to get a good vertical hold lock and the signal is interpreted as greyscale.  I have verified that the program is producing the expected signal timing using a pocket DSO. 

I will note here that I'm having trouble with voltage drop on the breadboard I'm using for prototyping; it's about 0.5V below the target 5V at the IC.  I've tried using a power bank as a substitute power supply  but its output was noisy and well above 5V at the low current draw this circuit has.  I've got some PCBs on the way in 2-3 weeks which should resolve this.

Looking at the source for Arduinocade (https://github.com/rossumur/Arduinocade/blob/e2ad97f164a6c520ea146478839cc6cd9102cb54/video.cpp#L41), lines are actually 63.7303003530484usec, and the colorburst begins at 6.2usec (TICKS_HBLANK).

If I plug these values into my program I get a good stable picture, which is great, but I'd like to understand why these specific timings (which don't seem right) seem to work.  Have they been adjusted slightly to compensate for some of the NTSC specification simplifications mentioned at the start?  Or is it more likely that voltage drop is the real culprit, and it is coincidence that these adjusted timings seem to work?

Thanks.

[oPossum]

signal is interpreted as greyscale.

Colorburst phase is inconsistent from line to line because the line period is not a integer multiple of color burst cycles.

[PKTKS]

To sum up ...

PAL and NTSC were never intended when designed to work
outside a  full carrier transmission profile...

Alas.. they where were designed for transmission .. so this is
the main reason for these "magic numbers" ...

Channels were in sight and cramming so much stuff inside
them required some creative solutions..

Equalizing pulses, shifted sub carriers each (PAL/NTSC), and
even intrinsic details on RECEIVERS in which the MAIN PHASE
(50 or 60Hz ) plays a decisive role.

When stripped from transmission.. obviously all drawbacks
appears as annoying problems.. as they were never intended
or designed at that time to work without a transmitter/receiver schema

On the RECEIVER side.. the local oscillators do some magic stuff
to proper lock the V and H synch train pulses and without the
magic synch separator tricks these locking frequently fail.

Modern stuff will not have trouble with that but will certainly
give some headaches to achieving a proper timing doing so
without all the necessary surrounding  paraphernalia

Paul

[jameswilddev]

signal is interpreted as greyscale.

Colorburst phase is inconsistent from line to line because the line period is not a integer multiple of color burst cycles.

Ah, so I would guess that the figure derived from the diagram there is more an example, and the position of the colorburst within the porch can vary a lot?

[PKTKS]

Not a *lot*...    because you need a proper burst cycles
to allow the receiver oscillator perform the synch.

Make sure you can fit the necessary minimum burst cycles.
Location is not so important as the cycle length as this
burst will synch the receiver local  decoder oscillator.

Same thing to both V and H pulse train..
You just need to make sure you have local synch with
provided pulses on the signal

Paul

[CaptDon]

The position of the colorburst is important as related to phase shift. If the start of the burst was shifted early by the distance of 1/2 cycle of burst then the the phase of the start of the burst must be coherent and agree with an already phase locked color oscillator. In other words you can't just start the sinewave at zero crossing rising edge and place it where ever you want, at least it must be consistent frame to frame. As for the vertical not wanting to lock correctly, have you implemented all of the equalizing pulses during the vertical blanking/retrace envelope? Most receivers can sync on blanking alone even if the vertical sync pulse is missing because many older CRT t.v.'s simply used a low pass integrator to create V-Sync for the sweep circuit.
Some of the old CGA cards with NTSC baseband out had really horrible specs and yet most A/V input consumer televisions displayed an 'acceptable' picture.

[jameswilddev]

So I've just modified an older prototype PCB to work with this newer code I'm working on for generating the TV signal and the voltage problem is gone there so that's definitely not a factor.

The figures from the spec just not working persists though - I've now got a few more different composite displays behind a splitter for experimentation and none of them seem to work with a 63.5usec line duration - only when it's bumped up to 63.7 do they suddenly get a perfect vertical hold and the color works.

My project's derived from Arduinocade so it does the same things to produce a video signal - including using serial output to generate squarish pulses in place of the sine waves usually used to produce the burst/color information.

Just making changes all over to see what works, I've found that the most consistent colors are produced by 5 cycles of colorburst, not 9 - no idea what that's all about.  Again, I'm checking this on a DSO and it doesn't look like the signal timing or voltage is wrong if these docs online are accurate.  I'm wondering if the tricks Arduinocade (and by extension older retrocomputers/consoles) play to get working-ish NTSC out of low-end hardware mean the timings need to be fudged because that's what I'm seeing in front of me - only by deviating from the spec do I get a good color picture on every test display I have.

[CaptDon]

What you are seeing with a longer horizontal time may make sense. A very long time back horizontal was 15,750 hz but now it is a tiny bit lower at 15,734 which is a derivative of the color burst frequency for frequency spectrum interleaving. so your 63.7us sounds about right.

[oPossum]

signal is interpreted as greyscale.

Colorburst phase is inconsistent from line to line because the line period is not a integer multiple of color burst cycles.

Ah, so I would guess that the figure derived from the diagram there is more an example, and the position of the colorburst within the porch can vary a lot?

It is the phase, not the position that I think is your problem. If you are generating the colorburst in the same way as the code you linked to, then the number of clock cycles per line must be divisible by 8 to maintain colorburst phase. That is 228 * 8 in the linked code.

To get exact timing you need 227.5 colorburst cycles per line. That requires changes to the ISR to flip the relative phase every other line. That will keep the absolute phase correct.

[jameswilddev]

Thank you guys!