[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IIgs RGB to YPbPr Component experiment



roughana wrote:
jsnospam@cimmeri.com wrote:

I asked the guy who is producing this unit if it may be suitable for
use with an Apple IIgs and this was his response:

====
My converter is designed for TV use ... Computer video is  RGBHV, ie RGB with separate H-orizontal and V-ertical sync.

  The IIgs doesn't put out RGBHV... it puts out RGBs.. plus sync on R,
G, B.   If the Aptus1 works, so will this other unit you are looking
at.   Just tell the fellow "RGBs", and that the Aptus1 works fine.


And the response to that follows:

===
If the IIGS RGB has sync on Green, or even sync on all three signals, a
converter like mine will not give you what you want.  Simply expressed,
the converter arithmetically combines the (sync-less) R,G & B signals
to produce Y, Y-B, Y-R, where Y=Luminance and Y-B,Y-R are the colour
difference signals (also expressed loosely as YUV, YPrPb, YCbCr).  It
also strips sync from the Composite video signal, regenerates it and
adds it to the Y signal.

If you were to use my converter, or the Cypress CSY-2100 with the IIGS
video you might get some kind of result. I could probably calculate
what would happen but it's likely that there would be significant
corruption of the sync signal, as well as sync artefacts on the colour
difference signals, if only because neither converter performs black
level restoration. But to continue with your current plan, a converter
like mine or the CSY-2100 could be modified to first strip the sync
from your RGBS then regenerate the RGB, convert to YUV and add sync on
Y using the composite video as at present.

Unless your TV automatically switches between NTSC and PAL,
incidentally, you would also need to set the IIGS frame rate to 50Hz.

If your IIGS has the standard 320 x 200 x 50Hz x 16 colour video output
I doubt it would look very good on any TV anyway ( the bigger the TV,
the more chunky and flickery) so the cost of conversion to component
seems an academic exercise at best.  If the machine has upgraded video
then it would seem more sensible to adapt it to drive a PC monitor
which will give better results than a TV due to its much smaller dot
pitch.  You then need a scan converter to strip the sync from the RGBS
and generate RGBHV with a scan rate of ~30kHz for VGA...
===

So... given the better knowledge of what this guy is doing, do you
still think it will work?
I'd buy an Aptus1, but importing it from the UK and paying pounds are
two disadvantages.

Cheers,
Andrew

I agree that there is confusion!

He is apparently concerned about DC-level shifts caused by the
presence of sync on the color signals.  Any non-DC-related effects
would be invisible, since they occur during blanking.

Sync could be stripped from *any* of the signals to be added to
the Y signal, but normal matrixing would preserve composite
sync on Y, so separate processing of sync may be irrelevant.

I would expect any monitor using component input to clamp the
input signals to black, making signal behavior during blanking
intervals irrelevant.  Some experimentation may be in order.

NTSC/PAL has no role in any of this, since any analog converter
is blind to the difference in scan rates.  We're talking NTSC here,
and his device doesn't need to know that.

Of course the observations about displaying a limited number of
pixels on a large screen are well known.

And suggesting a VGA output modification is relevant (though it
would have even more "chunky" resolution issues than a TV monitor)
but is of a significantly higher complexity than analog matrixing.

-michael

Parallel computing for 8-bit Apple II's!
Home page:  http://members.aol.com/MJMahon/

"The wastebasket is our most important design
tool--and it is seriously underused."