[Coco] CoCo RGB video timing and levels

[mmarlett at isd.net]

James,

The Atmel AVRs are nice little units. We have a few projects on that
platform here at Cloud-9 that we haven't released any information on at
this time. I have designed the hardware and written several apps here at
work. They pay me to do this? :)

As far as multi-media. CoCo is currently doing that, see the CompactFlash
4n1 adapter at www.cloud9tech.com . Memory stick is the slowest. The rest
are all about the same in speed. So with the SuperIDE Interface you can do,
CompactFlash(CF), SecureDigital(SD), Memory Stick(MS), SmartMedia and MMC
all on the CoCo. HDB-DOS and NitrOS-9 support. CoCo just keeps getting
smaller!

Regards,

Mark
Cloud-9


 >
>
>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
>
>
>-- 
>Coco mailing list
>Coco at maltedmedia.com
>http://five.pairlist.net/mailman/listinfo/coco
>