[Coco] again: CoCo RGB to VGA conversion

[jdaggett at gate.net]

Kevin

The fuzzy edges on the actual pixels is either due to noise or the 
bandwidth of video amps and CRT are insufficient and cause pixel 
smear. 

When converting a digital signal to analog the DAC itself does not 
produce a sine wave but a stair step wave form. Each color red,  
green, and blue will be one of four levels. When switching between 
these four levels, the transisition from one level to another has a 
response that is often called in electronics, a response to a step 
function. The Coco 3 provides little or no filtering. Depending on the 
capacitive load of the monitor you will have one of three conditions, 
overdamped,  underdamped and marginally damped. In an 
underdamped situation the transisition is the common problem of a 
square wave, ringing on the front part of the square wave. 

It is this ringing that creates harmonics of the pixel clock and thus 
noise. The longer the ringing the more the problems. Proper filtering  
helps eleiminate this. Over filtering creates a problem of rounded 
off square waves. As I see it the Coco 3 provides little or no filtering 
of the RGB signals outputs. This is all left to the monitor. Since I 
have my CM8 service manual in storage, at this time I can not 
qualitaviely speak on the filtering inside the CM8. 

Considering the problems that the CM8 has, I would not be all to 
surprised that the design is marginally acceptable at 640 horizontal 
line resolution. My guess is the video amps are optimized fro 320 
pixels and 640 suffers some. What that means is at 640 pixels the 
video amps are overdamped and that causes severely rounded 
square waves. For a large percentage of the pixel clock time the 
value of the RGB signal is still coming up to proper level. This 
would tend to lead me to believe that the filters are optimized 
somewhere between 320 and 640. That is between 6 and 12 Mhz, 
TV quality or about 480 horizontal pixels. Thus pixel smearing.

If one were to open the bandpass to accommodate 640 pixels, 192 
pixel resolution will suffer. So take your choice. 


james

On 19 Aug 2004 at 9:27, Kevin Diggs wrote:

Date sent:      	Thu, 19 Aug 2004 09:27:04 -0700
From:           	Kevin Diggs <kevdig at hypersurf.com>
To:             	CoCoList for Color Computer Enthusiasts 
<coco at maltedmedia.com>
Subject:        	Re: [Coco] again: CoCo RGB to VGA 
conversion
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>

> Hi,
> 
>  Ok, now I;m confused. I thought that the lack of
> sharpness in the CM-8 would diminish the blockiness, not
> increase it. Maybe there are two things at work:  large
> dot pitch (increase blockiness) and fuzzy vertical edges
> (reduce blockiness).
> 
>  I am surprised that there was not more discussion
> about using TVs with component video. As someone pointed
> out there is a colorspace difference. But isn't it just
> some algebra to go from one to the other. If done right
> there should not be any loss of ... information.
> 
>  Anyone know where to get a data sheet for the 1372?
> That color mixer thing.
> 
>      kevin
> 
> jdaggett at gate.net wrote:
> > 
> > On 19 Aug 2004 at 11:58, Nickolas Marentes wrote:
> > 
> > From:           	Nickolas Marentes <NickM at qm.qld.gov.au>
> > To:             	"'coco at maltedmedia.com'" 
> > <coco at maltedmedia.com>
> > Date sent:      	Thu, 19 Aug 2004 11:58:05 +1000
> > Subject:        	[Coco] again: CoCo RGB to VGA conversion 
> > 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>
> > 
> >>>I don't think trying to get it sharp is the problem. The
> >>>problem is that a VGA monitor is to sharp.
> >>
> >>It's not sharpness that is the problem, it's blockiness.
> >>
> > 
> > ^^^^^^^^]
> > 
> > One of th emajor casues for the Blockiness is that the CM8 uses 0.52
> > mm pitch pixels. Most modern monitors are now between 0.24 and 0.28
> > mm Pitch pixels. The CM8 has "BIG PIXELS" and big pixels and low
> > resolution leads to blockiness. 
> > 
> > 
> > james
> > 
> > 
> >>>I don't see how buffering a "field" will do any good? Unless
> >>>you are playing a game, the display is changing slowly (at least
> >>>relative to the screen refresh rate). This degenerates into scan
> >>>doubling. Only with a lot more complexity to get it.
> >>
> >>I don't think you understand when I say buffering. Let me make it
> >>clearer..
> >>
> >>How many horizontal scanlines does the CoCo3 produce?  Answer = 225
> >>max What is the horizontal resolution of standard VGA (not SVGA or
> >>XGA)? Answer = 480
> >>
> >>So how are you going to display 480 horizontal scanlines (full
> >>screen) on a 31Khz VGA monitor when your CoCo can only produce a max
> >>of 225?
> >>
> >>Scandoubling.
> >>
> >>You take each scanline produced from the CoCo3 and send it out
> >>twice. 2 x 225 = 450.
> >>
> >>This effectively makes every pixel double height or if you like,
> >>fills the vertical space between each pixel with an extra scanline
> >>which is a copy of the previous one.
> >>
> >>What is ideally needed to avoid scandoubling is to replace the
> >>doubled-up scanline with a fresh scanline made up of new data. It's
> >>complex to explain but essentially we're creating an interlaced
> >>display that is not interlaced (this won't make sense but maybe
> >>someone else can describe it better than I).
> >>
> >>
> >>>The statement that "scan doubling" makes pixels double
> >>>height is nonsense. Keep in mind we are filling the same vertical
> >>>space. We are just doing it with twice as many scans (that are half
> >>>as thick). The pixels will look different. You will be able to
> >>>clearly see that they are made up of two scans. This will probably
> >>>have some psychological impact on "how they look".
> >>
> >>A pixel is not defined as one scanline. A pixel can take up as many
> >>scanlines as it takes to display the graphic resolution. In this
> >>case, the CoCo3's resolution is unchanged, only the number of
> >>scanlines being used to represent it. The scanlines are closer
> >>together (but there is still a fine black division between them)
> >>which makes each pixel appear larger and "squarer".
> >>
> >>
> >>>I do agree that without special processing the display will
> >>>look different from the CrapMaster-8. It would probably be possible
> >>>to add some horizontal "fuzz" to more closely simulate the CM-8
> >>>(perhaps adding a 1F capacitor to the output lines would match the
> >>>CM-8). Adding vertical fuzz would be MUCH more difficult. And
> >>>almost certainly not worth the cost. Another possible solution is
> >>>to take a piece of plexi-glass and blur it using sandpaper. Put
> >>>this on the monitor when using it for coco displays!
> >>
> >>You're trying to be funny right?  :)
> >>
> >>
> >>>I would gladly accept the vertical blockiness that scan
> >>>doubling will cause to get the increased horizontal sharpness.
> >>
> >>I know what you mean, I have a CM-8 and it is fuzzy on the
> >>horizontal resolution. It is afterall a budget 15khz analogue RGB
> >>monitor. I also have an Amiga 1942 monitor that displays .21 dot
> >>pitch (same as most VGA monitors) and the horizontal resolution is
> >>great!
> >>
> >>The vertical blockiness would give me the sh*ts. Graphics actually
> >>look "lo-res". I guess everyone has a personal preference.
> >>
> >>
> >>>I am fairly certain that the coco is NOT interlaced. There
> >>>is only 1 field.
> >>
> >>Maybe someone can clarify this. The coco sends a frame 60 times per
> >>second. Each frame is overlayed over each other the same. What
> >>Sockmaster has found is that he can fool the 1986 GIME into dropping
> >>down a scanline, into the black region. By alternating 2 frames of
> >>data with this scanline skip, he simulates an interlaced VGA
> >>resolution display (15Khz still). (He write a terminal program that
> >>utilizes this mode called Twilight Term). This is why I thought a
> >>de-interlacer circuit would then convert it to a nice flickerfree
> >>VGA 31Khz output.
> >>
> >>Maybe Sockmaster can clarify?
> >>
> >>Nick
> >>
> >>Nick
> >>
> >>-- 
> >>Coco mailing list
> >>Coco at maltedmedia.com
> >>http://five.pairlist.net/mailman/listinfo/coco
> > 
> > 
> > 
> > 
> 
> 
> -- 
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco