[Coco] CoCo RGB video timing and levels

[James Dessart]

On Mon, 23 Aug 2004 jdaggett at gate.net wrote:

> In 80 character text mode the CM8 is displaying  480 pixels. Each 
> horizontal line is 114 characters times 6 pixels or 684 pixels. Take 684 
> times 15701 and you get a pixel clock of 10.739484 MHz. 
> 
> In 640 pixel graphics mode I would figure that the pixel clock is closer to 
> 12.56 MHz. That is if the GIME is actually doing 800 pixels total for ech 
> line. In that case then the access time would be 80nS for the memory . 
> 150nS fast page mode dram will handle that speed barely. Based on the 
> CM8 specs, at 59.7 Hz field frequency the nominal number of lines per 
> field will be 263. Maximum would be 276 lines and the lowest would be 
> 251. That is taking the min and max field frequency and dividing it into 
> the allowable tolererance of the line frequency. 

So how does the receiving monitor know what the pixel clock is set to?
There doesn't seem to be a line in the RGB pinout to signal it. Does the
monitor just scan across at a particular speed, or are there signalling
values in the RGB signals?

> Field frequency and the nu mber of lines in a field will determine the line 
> frequency. In standard defined VGA with a field frequency of 60 Hz and  
> 525 lines per field requires 31.5 KHz line frequency. Each line requires 
> 800 pixels total for display, sync and border. 800 times 31.5 KHZ results 
> in a 25.2 MHz pixel clock.

Right, which is much faster than the GIME could have handled at the time
without being prohibitively expensive, I imagine.

> Basic equations:
> 1) Pixel clock is equal to the line frequency times the # of pixels per line
> 2) Line frequency is the field frequency times the # of lines per field. 
> 3) Pixel clock establishes how fast the video ram needs to be.
> 4) Field frequency can be whatever the monitor can handle. This ranges 
> from about 30 Hz to 125 Hz.

These I had figured out, but thanks for affirming my hypothesis. :)

> The RGB levels out of the Coco 3 are 0.8 to 2.0 VDC and for the syncs, 
> they are TTL level. My guess is that they are four voltages of  1.85VDC, 
> 1.55VDC, 1.25VDC and 0.95VDC. If you are  interested, by altering the 
> three resistors in the base of the drive transistors one could make them 
> also TTL levels. 

What I want to do is interface to that B&W LCD that was linked to, the one
at $11. As such, I need to be able to take in the CoCo's analog RGB at the
right pixel clock, as either a TTL 1 (for the two higher values) or 0 (for
the other two), pack 4 pixels into a packet the panel recognizes, as well
as just pass on the h and v sync.

I was hoping to do this with an AVR, but the ones I'll be working with are
16MHz, which I doubt is fast enough to handle the rate it'd need to be
working at. I plan to get into FPGAs at some point, so that might be my
first project. Would a 50K gate chip be enough for that kind of logic? I
think so... just needs to store 4-8 bits at a time, and forward on
horizontal and vertical syncs, right?

Speaking of AVRs, it seems they could be used in some nifty CoCo expansion
projects. Some support clock crystals, so they can function as an RTC. As
well there's a lot of code out there to interface to all sorts of
hardware, IDE, MultiMediaCards, etc. With one cheap part, you could create
a multi-function card, that could even be reconfigurable at run time. When
the CoCo's off, it would put itself to sleep (except for the rtc
functionality) and run off a CR2320.

James