Quite some time ago I made a few RGB to s-video adapters for the CoCo3 using the Analog Devices AD725 encoder IC. These produced some really good results and were used by a couple of people in the CoCo community for doing video capture to produce youTube videos and the like.
Initial video converter example
One unexpected thing that I discovered in working with these was that although they worked well with the ’87 version of the GIME chip found in the CoCo3, they were non-functional with the original (1986) version.
For those who are unaware, the ’86 version of the GIME chip differs from the ’87 in several respects. Among other things, memory timing errors exist in the ’86 that prompted the ’87 revision to make fixes. RGB output levels and sync timing also differ.
Discovering that whatever differences were actually enough to affect whether the video could be converted with an encoder IC like the ‘725 intrigued me. I set out to study the differences and create a converter that would work with both versions if possible.
The only signals involved in conversion are the 3 analog video channels, and the 2 sync signals. I did a pretty involved study of the signals using an oscilloscope, and though there were a number of minor differences, the chief difference, and as it turns out, the problem in conversion turned out to be the HSYNC pulse.
The HSYC pulses on both GIMEs are wider than they should be, though in the case of the ’87, it has been somewhat corrected, bringing it close enough to spec to function with the AD725 encoder. The pulse starts much too early on the ’86 however, and just won’t work.
You can see the difference in HSYNC width in the built in composite video here. The output from the 1986 GIME is pictured up top.
Composite signal – 1986 vs 1987 GIME
As you can see, the HSYNC pulse starts earlier and is nearly half a microsecond wider in the 86 version. This results in video off center on televisions. This is the composite signal however. We are using the separate syncs available at the RGB port for our converter. Here is a comparison of HSYNC at the RGB port.
GIME RGB port HSYNC – ’86 vs ’87
Even more of a difference in pulse duration here, which must be cleaned up to a certain degree by the internal conversion circuitry when generating composite in the GIME. Though both of these are pretty wide for an HSYNC pulse. For example, both PAL and NTSC video call for a pulse width of 4.7us. CGA, another 15.7KHz format, calls for a similar duration. Suffice it to say, the GIME has a wide HSYNC pulse, too wide in the case of the ’86 GIME.
Note, this did work with old CRT displays such as the CM-8 and CRT televisions as they are among the most forgiving of display types as far as signaling is concerned. For conversion with a modern encoder IC though, it’s a no go.
With what I learned of the signals, I decided to design a new converter reconstructing the sync signals as needed. I also wanted to generate (in addition to s-video) a good composite video signal from RGB, something better than the built in composite for RGB games, and possibly supporting artifact colors as well.
To do this, we need a clock for the encoder IC that is synced to the GIME clock itself, otherwise terrible artifacting results (dot crawl, etc). My solution is to tap the GIME clock circuit, and feed that signal into our converter. This 28.636MHz clock then can be divided down to provide the NTSC encoder, and also to drive the logic reconstructing the syncs. Using this method also has the benefit of not needing a clock generating circuit on the converter PCB itself. I settled on a Xilinx CPLD to handle these tasks, and designed a new board.
A new RGB2NTSC converter
The new board works very well, providing compatibility with both ’86 and ’87 GIMEs. Artifact colors on CoCo 1/2 games are also supported, over the composite connection only. The long stemmed button in the center of the board is used to adjust the color phase for artifact colors in CoCo 1/2 games. The following is a little demo video showing the converter in action.
The new converter in action
The output is very good, and I’m more or less satisfied with the state of this project. I’ll probably produce a few for release to interested members of the community to use and enjoy.