NTSC composite timing for retroconsoles - Page 1
Forum section: electronics / beginners

author: jameswilddev
author_rank: Contributor
timestamp: February 25, 2021, 09:44:22 am
content: 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 (fromhttps://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 understandwhythese 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.

author: oPossum
author_rank: Super Contributor
timestamp: February 25, 2021, 10:15:28 am
content: Quote from: jameswilddev on February 25, 2021, 09:44:22 amColorburst phase is inconsistent from line to line because the line period is not a integer multiple of color burst cycles.

author: PKTKS
author_rank: Super Contributor
timestamp: February 25, 2021, 11:40:52 am
content: To sum up ...PAL and NTSC were never intended when designed to workoutside a full carrier transmission profile...Alas.. theywherewere designed for transmission .. so this isthe main reason for these "magic numbers" ...Channels were in sight and cramming so much stuff insidethem required some creative solutions..Equalizing pulses, shifted sub carriers each (PAL/NTSC), andeven intrinsic details on RECEIVERS in which the MAIN PHASE(50 or 60Hz ) plays a decisive role.When stripped from transmission.. obviously all drawbacksappears as annoying problems.. as they were never intendedor designed at that time to work without a transmitter/receiver schemaOn the RECEIVER side.. the local oscillators do some magic stuffto proper lock the V and H synch train pulses and without themagic synch separator tricks these locking frequently fail.Modern stuff will not have trouble with that but will certainlygive some headaches to achieving a proper timing doing sowithout all the necessary surrounding paraphernaliaPaul

author: jameswilddev
author_rank: Contributor
timestamp: February 25, 2021, 01:22:16 pm
content: Quote from: oPossum on February 25, 2021, 10:15:28 amAh, 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?

author: PKTKS
author_rank: Super Contributor
timestamp: February 25, 2021, 01:27:13 pm
content: Not a *lot*... because you need a proper burst cyclesto 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 thisburst 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 withprovided pulses on the signalPaul

author: CaptDon
author_rank: Super Contributor
timestamp: February 25, 2021, 03:22:03 pm
content: 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.

author: jameswilddev
author_rank: Contributor
timestamp: February 25, 2021, 04:51:23 pm
content: 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 andnoneof 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.

author: CaptDon
author_rank: Super Contributor
timestamp: February 25, 2021, 07:08:13 pm
content: 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.

author: oPossum
author_rank: Super Contributor
timestamp: February 25, 2021, 10:09:16 pm
content: Quote from: jameswilddev on February 25, 2021, 01:22:16 pmIt 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.

author: jameswilddev
author_rank: Contributor
timestamp: February 26, 2021, 02:30:40 am
content: Thank you guys!