[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IIgs RGB to VGA continued
Michael J. Mahon wrote:
> TomCh wrote:
> > Michael J. Mahon wrote:
> >
> >>jsnospam@cimmeri.com wrote:
> >>
> >>>The basic setup is:
> >>>AL875 ADC
> >>>AL250 scan doubler
> >>>ICS1523 clock generator in a PLL
> >>>
> >>>We tried changing the dot clock sampling rate. We noted many
> >>>interesting effects, but no overall image improvement.
> >>>
> >>>Also considered phasing: it's done by the ICS clock generator chip.
> >>>The phasing is adjustable and we tried changing it throughout its range
> >>>and it made no difference. Not during dot clock adjustment.
> >>>
> >>>Now look at:
> >>>http://members.aol.com/mdnttrain/vga6.jpg
> >>>
> >>>In this latest photo, a first order low pass filter was added on each
> >>>of the 3 color inputs. This reproduces the lower bandwidth of the
> >>>older monitors and makes the modulation bars disappear. We are
> >>>beginning to believe that the modulation bars are really coming out of
> >>>the machine like that and not a defect of the converter itself. A
> >>>supporting observation is that the beat bars are quite "solid" looking
> >>>(real beat bars we've seen are soft).
> >>>
> >>>Another is that they don't show up on the black and white portions of
> >>>the image as Vince noted. That means that if the bars ARE present,
> >>>they are always white bars on white backround, and black bars on black
> >>>backround .. which seems inconsistent with the other bars we're seeing.
> >>>
> >>>Do you all agree with our theory, or think something is still wrong in
> >>>the converter's phasing circuit / dot clock rate?
> >>
> >>Your results prompt a little application of sampling theory. ;-)
> >>
> >>If non-synchronous sampling is to work, the bandwidth of the incoming
> >>signal(s) must not exceed the Nyquist frequency, or half the sampling
> >>frequency.
> >>
> >>Since the RGB signals coming from the IIgs are not band-limited, I
> >>would expect some pretty sharp edges, and therefore frequencies well
> >>over 14MHz. The patterns you see are the result of aliasing of those
> >>frequencies to lower frequencies (the difference between the dot clock
> >>frequency of the IIgs and the sampling frequency).
> >>
> >>If you're sampling around 15MHz, then the bandwidth of the RGB signals
> >>should not exceed 7.5MHz, or, for practical filters, 6.5MHz.
> >>
> >>The bad news is that using a filter also kills the bandwidth required
> >>for sharp 80-column text. ;-(
> >>
> >>That's why I still recommend *synchronous* sampling.
> >>
> >
> > What would you use as your sync?
> > You have to use the video CLK from the motherboard, right?
>
> That would be the easiest way, but it's probably possible to
> phase lock to the pixel stream, too, like most LCD displays do
> for VGA frequencies.
>
The AL875 flyer suggests using HSYNC as an input ref clk to the PLL:
http://www.averlogic.com/admin_en/product_en/pic8/688058.pdf
Is HSYNC available externally from the GS?
It looks like only composite sync is available:
http://home.swbell.net/rubywand/R023PINOUTS.htm#013
Can HSYNC be decouped from the composite sync signal?
J: What are you using as your ref clk for the PLL?
Note that both black and white have the same 3 values for R/G/B.
I guess if you try any grey colour then you won't see this banding
(since R/G/B are all the same). Like Michael says you'll see banding
due to aliasing (since R/G/B values are not the same).
J: Can you post a picture of how 80-col text looks with you low-pass
filter?
Tom