[Coco] CoCo RGB video timing and levels

[jdaggett at gate.net]

In true VGA as set down by IBM on the older PCs monitor resolution was 
determined by the polarity of the vertical and h orizontal sync pulses. This method 
you had four different resolutoins off of one pixel clock of 25.175 MHz. 

640x240
640x350
640x400
640x480

On Older VGA monitors the host PC drivers would use border pixels and border 
lines to center the display area in the middle of the CRT. 


AVRs are nice devices. Essentially t  hey are Atmel's answer to the ever popular 
Motorola HC11/HC12 series. Lot of imilar functionality between them. Though the 
code is far different. In fact the code written for the 6809 is closer related to that of 
the HC11/HC12.

I saw that display for $11 bucks. I am tempted to get one. As for interfacing it to the 
Coco,  I have the spec sheet on the MSM6255 Oki chip and it is in PDF form. If you 
want a copy, I can email it to you. You might be able to do enough of the functions 
to drive it in a large CPLD with say at least 108 macrocells. Haven't looked at that 
yet. I was planning on incorporating a functional version of that in a GIME II type 
chip for my needs. I can do without full color.In fact monochrome will  be nice. 

james

On 23 Aug 2004 at 15:18, James Dessart wrote:

Date sent:      	Mon, 23 Aug 2004 15:18:30 -0400 (EDT)
From:           	James Dessart <james at skwirl.ca>
To:             	CoCoList for Color Computer Enthusiasts 
<coco at maltedmedia.com>
Subject:        	Re: [Coco] CoCo RGB video timing and levels
Send reply to:  	CoCoList for Color Computer Enthusiasts 
<coco at maltedmedia.com>
	<mailto:coco-
request at maltedmedia.com?subject=unsubscribe>
	<mailto:coco-
request at maltedmedia.com?subject=subscribe>

> 
> 
> 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