One of the most common questions we get asked during The Retro Roundtable podcast is “What is the proper way to generate CSYNC from HSYNC and VSYNC?”. People understandably ask this because we’ve mentioned several times that nearly all implementations of this process are incorrect. The question is typically asked with the expectation that it can be quickly answered. I mean, if we’re able to so easily point out improper implementations, then shouldn’t we be able to just as easily explain the correct implementation? Unfortunately, this isn’t true with nuanced topics such as this one. Therefore, I’m going to try my best and explain this subject here in detail so it can be properly documented and easily referenced. I’ve determined that this information would be best presented and understood when split into 3 separate parts. Let’s begin with the first part which covers what CSYNC is and why it exists in the first place. This background is necessary for understanding the difficulties that arise with the proper creation of CSYNC from discrete HSYNC & VSYNC.

Defining “Sync”

Sync is short for synchronization, and refers to how a video system needs to be “locked on” or, in simpler terms, stabilized. CSYNC, or composite sync, can be described as a combined version of the HSYNC and VSYNC signals. Since CSYNC is defined by those two sub-components, we need to first understand them. HSYNC is horizontal sync and VSYNC is vertical sync. A video system’s end goal is to display an image on a 2D screen, where the two dimensions are horizontal and vertical. Therefore, HSYNC keeps the horizontal axis (each line) stable by defining the horizontal reference point, while VSYNC does the same thing for the vertical axis (each frame or field). Both of these references are required for the image to be properly reconstituted on a display device. An example showing the HSYNC and VSYNC waveforms for 60Hz standard definition video is shown below. As discussed in our Sync Jitter article, the falling edges of these waveforms represent the desired reference points (line start for HSYNC; field start for VSYNC). Note that in this example there are two unique fields which keep alternating between each other. The second field of each two-field sequence begins in between two lines and is used to achieve interlacing* as detailed further below in this article.

*NOTE: I’m not going to get into the whole concept of interlacing and why it was chosen for television broadcasting. The only thing required to know is how interlacing affects the structure of HSYNC & VSYNC and the encoding of CSYNC.

HSYNC and VSYNC waveforms representing 60Hz standard definition video. Line numbers are labeled as are the two unique fields required for interlacing.

HSYNC and VSYNC waveforms representing 60Hz standard definition video. Line numbers are labeled as are the two unique fields required for interlacing.

When monochrome (black&white) television broadcasting (as defined by RS-170/EIA-170) was first introduced in North America, a scheme needed to be devised to combine (encode) all the required audio & video information into a single signal for transmission over the airwaves. One of the steps involved in achieving this was to convey the HSYNC and VSYNC information in a way such that it can be interpreted and utilized by the display device to make the final image. “Information” is very crucial to emphasize here. Video cameras and other video source equipment destined for TV* consumption do not explicitly generate separate HSYNC and VSYNC signals which are later combined into CSYNC via a separate circuit or procedure. The CSYNC signal is generated directly in a manner where the underlying HSYNC and VSYNC data can be inferred by the circuitry in the target device. The takeaway here is that the explicit HSYNC and VSYNC signals are only ever accessed at the display side.

*NOTE: This discussion focuses only within the context of television. The modern computing and PC space handles things differently, where HSYNC and VSYNC signals are explicitly generated and transmitted over a short distance to the display (e.g. VGA cables).

Generating a Practical CSYNC

The most straightforward way of doing this would be to simply widen the HSYNC pulse whenever VSYNC is active [section (A) in the figure below]. The main problem with this is that a display device loses HSYNC lock during this portion. The solution is to introduce a series of wide pulses which still have falling edges where HSYNC falling edges would occur [section (B) in the figure below]. In analog video terminology, these are called “serrated pulses”. This should be all that’s needed, but in order to effectively implement the interlacing scheme used by standard definition TV, we require one more tweak. Because the VSYNC is offset by half a line (i.e. halfway between HSYNCs), double-pulses at twice the HSYNC rate are introduced in the areas around and including VSYNC [section (C) in the figure below]. During the 3 line period prior to VSYNC, there exist 6 “pre-equalization” pulses. Similarly, during the 3 line period after VSYNC, there are 6 “post-equalization” pulses. Additionally, the width of these equalization pulses is half the width of the normal HSYNC pulses. The evolution of this concept along with the various waveforms are shown below.

Evolution in the design of a proper CSYNC signal for practical transmission and recovery:  (A) = Naive direct logical combination of HSYNC and VSYNC  (B) = Addition of serrated pulses during VSYNC to keep HSYNC lock  (C) = Addition of double-pulses and shortened width for pre/post-equalization pulses to maintain interlacing

Evolution in the design of a proper CSYNC signal for practical transmission and recovery:

(A) = Naive direct logical combination of HSYNC and VSYNC

(B) = Addition of serrated pulses during VSYNC to keep HSYNC lock

(C) = Addition of double-pulses and shortened width for pre/post-equalization pulses to maintain interlacing

To validate the practicality of the finalized CSYNC waveform above, we can briefly examine simple examples* of how HSYNC & VSYNC can be recovered at the display side of the video system. Since this properly constructed CSYNC retains all of the original HSYNC’s falling edges, we can use those edges to trigger a monostable multivibrator (aka “one-shot”) to generate HSYNC pulses at their standard widths and at the correct locations. If required for a particular application, a second non-retriggerable one-shot, controlled by the same CSYNC input but with its output set just shy of the total line length (at about 95%), can be used to inhibit the output of the first one-shot in order to ignore the double-pulses during pre/post-equalization and VSYNC. For discrete VSYNC recovery from CSYNC, a simple two-stage RC integrator (filter) followed by an analog comparator set at a suitable threshold can be used to recover the wider VSYNC while ignoring all the shorter HSYNC pulses. An example circuit of this outlined VSYNC recovery method and its relevant waveforms are shown below.

*NOTE: These examples are highlighted and discussed for educational purposes only.

Simple RC integrator + analog comparator VSYNC recovery circuit.

Simple RC integrator + analog comparator VSYNC recovery circuit.

31 Flavors of 240p

The above CSYNC timing structures describe the 525-line 60Hz system (59.94Hz for color), or “480i” as it’s more commonly known today. 240p, in its most simple representation, is a slight variation on the above timing. Instead of drawing 262.5 lines in between each VSYNC edge to achieve interlacing, the idea is to have an integer number of lines which is needed for progressive scanning (the ‘p’ in 240p). There are two main ways of accomplishing this. Game consoles, retro computers, and various other devices are known to implement either one of these two types. You can either get rid of a half-line resulting in 262 lines, or add an additional half-line bumping you up to 263 lines. Regardless of which method is implemented, each field’s timing pattern now looks exactly the same, and the concept of first/second fields no longer applies. Therefore, the term “field” is dropped and the set of lines between each VSYNC edge is known as a frame. Because of all this, even more variations of 240p manifest themselves. The double-pulses no longer serve a practical purpose, so a common variation used by video equipment manufacturers is to remove them from the pre-equalization section, VSYNC serrated pulse section, and post-equalization section. On top of that, some implementations choose to also increase the widths of the shorter pulses during pre/post-equalization back to the normal HSYNC pulse width.

As you can see, it starts to get quite messy once 240p comes into play. A handful of some different possible 240p flavors are shown below. Although there are many combinations of these slight variations, not one of them is documented within a video standard. However, within most implementations of 240p CSYNC the critical properties of the timing structure stay intact, increasing the likelihood that the signal can be properly recovered and interpreted by modern television receivers. These properties include (1) having 262 or 263 total lines per frame, (2) the length between each HSYNC edge being constant from line to line, and (3) the length between each VSYNC edge being constant from frame to frame. #1 is important because although analog CSYNC was never standardized, both 262-line and 263-line progressive video are standardized in the digital CEA-861 timing specifications used for HDMI. Therefore, a modern digital display at least has a defined target digital destination it can map an incoming analog CSYNC source onto. #2 and #3 are vital because PLLs (phase locked loops) are used to regenerate the pixel clock by locking onto consistently occurring HSYNC and VSYNC edges. Any peculiarity in the position of the edges can cause the PLLs to lose lock and result in a “no signal” message, a “mode not supported” message, or a flickering screen. #2 and #3 are so important that they also apply to any input format, and aren’t exclusive to 240p.

A handful of the many possibilities for 240p CSYNC. All the flavors shown here adhere to the 3 critical timing rules discussed above.

A handful of the many possibilities for 240p CSYNC. All the flavors shown here adhere to the 3 critical timing rules discussed above.


The main takeaways from Part 1 are as follows:

1.) CSYNC is typically generated directly, and not from a combination of existing HSYNC and VSYNC signals.

2.) Many properties for proper CSYNC were established specifically for interlaced television broadcasting applications. These properties are now standardized and need to be followed today even if the original technical reasons are no longer relevant.

3.) 240p CSYNC, due to its similarity to 480i, has many variations which can easily confuse display devices.

4.) Adhering to the outlined critical timing specifications as strictly as possible greatly increases the chances that no issues arise when decoding CSYNC signals, regardless of input format (i.e. 240p, 480i, 480p, etc.).

Stay tuned for Part 2 where I’ll describe common CSYNC implementations derived from explicit HSYNC & VSYNC signals which don’t quite cut the mustard. These implementations break one or more of the timing properties established above.


  1. Benson, Blair, and Jerry Whitaker. Television Engineering Handbook: Featuring HDTV Systems. 2nd ed., McGraw-Hill, 1992.

  2. Jack, Keith. Video Demystified: A Handbook for the Digital Engineer. 4th ed., Newnes, 2005.

  3. Poynton, Charles. Digital Video and HDTV: Algorithms and Interfaces. Morgan Kaufmann Publishers, 2003.

  4. Consumer Electronics Association. "CEA-861-D." A DTV Profile for Uncompressed High Speed Digital Interfaces, June 2006.

  5. Electronic Industries Association. "EIA-170." Electrical Performance Standards - Monochrome Television Studio Facilities, Nov. 1957.

  6. Society of Motion Picture and Television Engineers. "SMPTE 170M-2004." Composite Analog Video Signal - NTSC for Studio Applications, Nov. 2004.

AuthorSte Kulov

Salutations, fellow ghosts and goblins! It's been awhile. And though we're sure you haven't missed us, we just reached a point where we're able to give you a decent status update. Here we go:

First, the main reason we've been quieter than usual is due to the fact that we moved out of the basement/dining room and into an actual office/lab space. It was a lot of time and work setting this up, but it has already paid off in streamlining our new development projects and how we operate in general. Those new development projects, including the Dreamcast YPbPr cables, are still in progress. No further updates about those just yet, but the mailing list will get an update as soon as we have something significant to share.

OK, we do have one small update on new projects. As of last month we officially became a licensed HDMI® Adopter, which means we can now legally design, manufacturer, and sell products using HDMI® technology. We're excited to be one of the first companies in the retro gaming/computing arena to be allowed to do this.

The factory just wrapped up a production order that contains Genesis YPbPr cables, SNES YPbPr cables, PlayStation adapters, 5x RCA Male-to-Male cables, and 5x RCA Extension cables. These will soon be on their way via ocean freight, and will take the usual unpredictable amount of time to get here. We will not be reopening our store right away when they arrive. In order to continue making progress on new projects, our store will remain closed for awhile longer. However, you will be able to purchase from the new shipment of products through distributors such as CastleMania Games and Please visit their websites for information/updates about what stock they'll have and when. CastleMania may be doing a pre-order system soon -- check with them for details.

When we eventually do reopen our own store, we will only be offering shipping to domestic (USA) customers. Selling internationally adds too much complexity and risk for us, making it much harder to continue doing things other than running a store. International customers can still purchase through the aforementioned distributors.

Lastly, we placed a couple of our more basic products on for sale and distribution. Depending on how well these sell on Amazon, we might consider posting more products there in the future.


Have a very spooky October!

The terms HDMI and HDMI High-Definition Multimedia Interface, and the HDMI Logo are trademarks or registered trademarks of HDMI Licensing Administrator, Inc. LLC in the United States and other countries.

AuthorNickolaus Mueller

We have some important news to share, so please read on if you're interested in what we're doing. We appreciate the great response to all the products we've brought to market so far, with many of our items selling much faster than we anticipated. So... thank you for that! But as you might already know, that success has come with a lot of non-technical work that has taken up our time and prevented us from progressing in development on projects such as Dreamcast component cables and the HD-mizer.

With that in mind, we're going to be temporarily closing down the shop beginning July 1st. We're still moving forward with placing new orders for our existing products, but while those are getting manufactured, we need to focus our attention on getting development done. We'll of course share a reopening date to the mailing list when we have one.

If there's something you'd like to order directly from us, please do it by the end of June. Though our shop will be temporarily closed after that, Castlemania Games and will remain open and *may* have stock of whatever you're looking for.

Thanks for all the support you've shown us over the years!

Ste & Nick

Screen Shot 2018-06-11 at 8.40.49 PM.png
AuthorNickolaus Mueller

Three quick updates for you today:

1) PS2/3 cables are back in stock. As in right now.

2) Despite our best efforts, we're getting a lot of emails inquiring about a Genesis cable restock. The answer right now is that we do not know when we'll have more. We're still working out forecasts for ourselves and with our distributors, and once we have those we'll be able to place an order and give people a better idea of a date. In short: no restock on our store for at least a few months.

3) Dreamcast YPbPr cables are still in development. Unfortunately, the project hasn't been worked on since before we restocked the store in March, due to being bogged down with non-stop sales and support issues during that period. That boring stuff has slowed down recently, so we're trying our best to pick back up our pending Dreamcast tasks within the next few weeks.


AuthorNickolaus Mueller

Recently, we received multiple email contacts from people in Brazil who had viewed a YouTube video that appears to offer some critical analysis of our Genesis YPbPr cable. Unfortunately, this person did not reach out to us first, so we had no chance to have a back and forth about its content before it was published. The video is in Portuguese, so we don't know exactly what is being said, but one of the emails we received appears to do a decent job of breaking down the important points. While we have some reservations about even posting a response (do we have to do this every time someone creates a video like this?), since much time was spent analyzing the claims within the video to respond in detail to the emails we received, we figured it could be enlightening for others to read.  Here's an edited-for-blog version of our email response to the person who gave us the breakdown. For full disclosure, we made some minor edits, changed some of the photos, and rephrased some of the explanations for a more generic audience. For those of you like us who are deficient in Portuguese language comprehension, the main claim in the video is that the video outputs are out of spec:

The email we received states: He first measures each signal with the contrast switch turned off and gets the following measurements: Y = ~1.06V, Pb = ~640mV, Pr = ~620mV. He tells that the Y signal is within recommended level because it's delivering 700mV of video signal plus 300mV of sync signal on this line. But he says Pb and Pr are below the recommended level of 700 mV.

Thank you for giving us the breakdown and taking the time to do so.  Now I can actually understand the content of the video.  I did watch the video in its entirety after I read your summary, just to make sure I wasn't missing any context in the test setup.  As you would expect, I have many problems with the way the testing was done, but I think my objections are justified (you can decide yourself).  Some are major points, and some are minor, but I won't go into detail categorizing them as such below.

1.) When doing a video like this showing measurements down to millivolts, I personally would start by showing a rough DC validation to instill confidence in the viewer.  Many oscilloscopes drift in DC accuracy (offset and gain) over time, which is why there's a whole equipment calibration business out there with equipment calibrated annually.  Anyway, I typically set a DC power supply to 1 volt or less, measure it with a known accurate DC multimeter, and then see how close the oscilloscope measurement is to the meter measurement.  It doesn't have to be exact, but it's nice to have it within ±30mV.  Offset error (more common) is likely to be constant, so you can add/subtract it in your subsequent measurements.

Basic oscilloscope verification

Basic oscilloscope verification


2.) The way the measurement is being done on the scope is prone to much error.  He's using the auto-measurement tool to measure peak-to-peak voltage.  A few problems here.  First, the timescale is set way too wide, showing several frames of video within the small measurement window of the scope when we only need to measure a single line.  The auto-measurement tool has a finite time-precision so on a signal that's changing a lot within the capture window, it's not always going to be landing its time-samples where you need them to.  Plus, any random noise spikes or ringing on video edges can be reported if a sample happens to land on such an area.  You can see evidence of how poor this method is by how much the measurement on screen keeps changing, up to around 40mV (that's around 15 RGB values in an RGB 0-255 system).  The proper way to do this is to zoom into a couple lines of video, and use the manual cursors at the top and bottom of the video waveform to get the delta, since you should know where these are and what you're looking at.  I attached an example for you:

Plot from oscilloscope (same as verified above) of Sega Nomad using Genesis YPbPr cables. This is the Pr signal during a proper 100% colorbar pattern. Notice how the auto-measurement (red - incorrect) is higher than the cursor measurement (green - correct).

Plot from oscilloscope (same as verified above) of Sega Nomad using Genesis YPbPr cables. This is the Pr signal during a proper 100% colorbar pattern. Notice how the auto-measurement (red - incorrect) is higher than the cursor measurement (green - correct).


3.) The colorbar test pattern being used is suspicious.  First, it's being described as a SMPTE colorbar pattern which implies that all the vertical bars are 75% of the maximum levels.  However, the Genesis is incapable of generating something at exactly 75%, due to its low color bit-depth (3-bits per color channel).  The closest you can get is 5/7 = 71.43%.  This is what our own test software uses to approximate 75% bars.  However, let me make the assumption that this "hacked Sonic ROM" that is being used might actually be generating 6/7 = 85.71% bars.  If we take the value of Pr he measures and apply the inverse of 0.8571 to correct it, let's see what we get: 620mV / 0.8571 = 723mV.  This is much closer to ideal, but it doesn't account for all the other caveats I'm outlining in my other numbered points.

The justification for why I think this is the case can be seen in the video itself.  Notice how the white bar is darker than the white square at the bottom of the screen.  That square is true-white while the bar is not.  It also can be seen on the oscilloscope, and the square is the reason why the luma measurement on the scope is close to ideal while the Pb/Pr ones are much lower.  The method of of auto-measuring (outlined above) captures the white square and ignores the white bar since it's shorter in height.  I attached some snips for you to show you what I'm talking about:

Snips explaining which parts of the video signal correspond to what is actually shown on the screen.

Snips explaining which parts of the video signal correspond to what is actually shown on the screen.


When measuring YPbPr video levels, it's proper practice to use a non-SMPTE pattern which is 100% saturation on all the vertical bars, adds a black vertical bar at the end, and also removes the junk on the bottom which is meant for CVBS and S-Video systems.  This is stated clearly in the CEA-770.2-D specification.  We actually got permission from CEA to post the relevant figure from their controlled document, and it's shown on our FAQ page:

I don't know why this hacked Sonic ROM was chosen in the first place.  Our own test software is clearly the correct choice for this type of test, since all the source code is available in case someone questions the validity of the pattern generation.  This ambiguity is the reason why we write our own software.  We only trust things to be done correctly if the underlying fundamentals are understood, and therefore important caveats like the inability for the Genesis to generate exactly 75% are known to us.

4.) Various consoles have minor variation in their RGB signal output.  For the darker switch setting, we based our gain adjustment across measurements from 18 different Genesis console revisions/variants and 6 Sega Master System revisions/variants.  Generated RGB signals seem to vary between 635mV and 715mV, including a slight variation of a few ohms of source impedance.  We used weighted averaging to try to make every console as close to 700mV as possible on the resultant Y, Pb, and Pr outputs after gain & offset correction.  Although I'd like it to be true, there's no way to be 100% perfect in every case.  I should also mention we have never explicitly tested and/or measured a Mega Drive from Brazil, as is reflected in our verified console compatibility list.  My gut tells me it's not going to be much different than anything else, but I think it's worth pointing out.

5.) (The email we received states: "He then mentions the contrast switch is a good feature of the cable because CRT works better with 1V on the Y line while LCD screens work better with 1.3~1.4V on the Y line, so it's good to have that option.") I don't agree with the "better for LCDs" statement.  There are objective video levels set forth in CEA-770.2-D (similar to EBU-N10-1998 which is free to view) for YPbPr video which all consumer electronics products are supposed to adhere to.  I suspect much of the confusion here is related to the 75% colorbar problem described earlier.  I think he's incorrectly assuming the white bar is supposed to be white, when in reality it's some fraction of white.  Flipping the contrast switch to the brighter setting will incorrectly boost this bar back towards 100% white.  In fact, that particular switch setting on our cable is only meant to be used with older revision Sega Master System consoles, which have very weak video output.  We measured the weak Sega Master System consoles to have an RGB output around 475mV.  This SMS correction is the true purpose of the switch feature on the Genesis cable, and should only be used with these consoles.  I had another email asking if the higher output levels when using the wrong console will damage anything, which is a valid question.  The extra voltage won't damage the circuit in the cable, since it can handle much more than we're using it for.  On the TV/display input side, the extra RMS power dissipated in the 75Ω termination resistor is negligible (few milliwatts).  Also, video input stages these days typically run off 3.3V or higher supplies, and have clamping protection if anything is beyond those rails.  Therefore, the only thing you would experience is clipping/saturation of the video signal (i.e. it will look bad and washed out).

6.) (The email we received states: "He says that, ideally, the contrast switch should affect only Luma signal, not color, and that color levels get above the recommended level anyway. He then speculates that the circuit used on the HD Retrovision cable is regulating the RGB signal levels on the input side to save costs with buffering (?), because it should have a buffer for each channel and the buffer should amplify the [output] signal instead of amplifying it on the input.") The statement about how contrast (gain adjustment) is applied only to the luma channel demonstrates a fundamental misunderstanding of video systems.  Historically, these have always been applied in the RGB colorspace, more specifically in the video transistors used to drive the CRT guns.  Modern video systems mostly run internally on the YCbCr colorspace, but the contrast control still needs to adjusted on all three channels. (See the below for a picture from Keith Jack's book demonstrating this, and also one from Charles Poynton's book).  An intuitive example which illustrates why the scheme stated in the video is incorrect is as follows.  Take the color green, convert it to YPbPr, and reduce only the Y (luma) contrast to zero.  Now you're left with zero luma, but Pb and Pr values are still non-zero.  This results in an invalid RGB color (R & B are negative!), and it makes sense since you can't have any color without any luma.  Anyway, the whole point of the gain adjustment switch on the cable is that some consoles output a high variation of RGB signal levels, and we attempt to normalize as much as possible (as described above).  Since adjusting the RGB or YPbPr gains are mathematically equivalent when done correctly, it's much easier (and more compact) to do it on the RGB input side.  It would get very complicated if it was done on the output amplifiers (with no added benefit).

Taken from  Video Demystified: A Handbook for the Digital Engineer (4th Ed.)  by Keith Jack - Pages 208 & 209

Taken from Video Demystified: A Handbook for the Digital Engineer (4th Ed.) by Keith Jack - Pages 208 & 209

Taken from  Digital Video and HDTV: Algorithms and Interfaces (1st Ed.)  by Charles Poynton - Page 346

Taken from Digital Video and HDTV: Algorithms and Interfaces (1st Ed.) by Charles Poynton - Page 346

AuthorNickolaus Mueller