Re: LCD Flat Monitor to Apple IIgs?

[mjmahon@aol.com (Michael J. Mahon)]

In article <b5rvaq$9k8$1@newsl.dti.ne.jp>, "Jim Maricondo"
<jimm@uranus.dti.ne.jp> writes:

>See my web page at www.maricondo.org.

Very nice description, Jim, and fine photo documentation of the
results.  ;-)

I note that the major problem you encountered was video "jitter"
(random 1-pixel horizontal shifts of video features).  This happens
whenever the producer and consumer of a digitally generated
video signal operate on unsynchronized clocks.

If both the producer and the consumer agree about the number
of horizontal pixels, then a good phase-locked loop can lock to
the pixel positions and recover them stably.  But if they do not
agree, then such pixel lock is not possible, and there will be
(at least) regions where a producer pixel is randomly assigned
to one of two adjacent consumer pixels.

In your setup, you have two pairs of producers and consumers:
first, the IIgs and the scan doubler, and second, the scan doubler
and the LCD.

The fact that the scan doubler menus exhibit jittery edges on
the LCD suggests that, whatever is going on between the IIgs
and the scan doubler, there is a pixel clock asynchrony between
the scan doubler and the LCD.  Since the LCD presumably is
designed for VGA pixel counts, and the scan doubler is designed
to produce them, this is surprising.  Assuming that the LCD acts
properly when driven by a VGA card at the same scan rates and
resolution, then the fault must be in the scan doubler video generator.
Perhaps there is jitter in the horizontal sync, or even in the horizontal
period.  An oscilloscope could be used to verify that the scan doubler
output (of its own internally generated menus) is stable and of the
correct pixel count.

Assuming that this is corrected, there is still the issue of the first
producer-consumer pair, the IIgs and the scan doubler.  Here the
problems are more fundamental.  There is no "standard" for how
many pixels are in an analog NTSC horizontal line, but the digital
TV standard sets it at 640 pixels (in the time between the end of
one horizontal blanking pulse and the beginning of the next).  The
IIgs certainly does not meet the dot rate "standard" for digital NTSC.

This means that there are always going to be pixels generated by
the IIgs which fall ambiguously between "standard" pixel positions,
and this situation will often result in a jittery "assignment" of the
pixel transition to one or the other of the "standard" pixels.  When
the internal scan doubler buffer is read out at VGA rates, it will
reflect the jittery assignment of the IIgs pixels as they were digitized.

It may be possible to "lock" the dot clocks of the IIgs and the scan
doubler digitizer to some fairly simple harmonic relationship (like
157:135, or some such ridiculous ratio) using simple analog coupling
of the clocks (!), but, at root, there is a pixel enumeration problem which
will continue to produce artifacts.  For example, some of the IIgs pixels
will have to control _two_ adjacent VGA pixels in some cases, since
560 is less than 640, and (of course) does not evenly divide it.  This
will produce irregularities (banding) in "halftone pattern" IIgs screens,
and, of course, some vertical lines will appear to be twice as wide as
on the IIgs screen.

If you were displaying on an analog CRT, then the scan doubler-to-LCD
issue would not exist, and the scan doubler's own menus should be
stable.  But this would still not address the issues of digitizing the
IIgs video with an asynchronous dot clock.

The underlying issue could be addressed by digitizing the IIgs video
_only_ between its blanking pulses (a shorter line) with exactly 560
pixels, and phase locking the digitizer to the video.  But this is likely
only with either a very specialized IIgs scan doubler (a labor of love
because of the small market) or a very general professional scan
converter which can be customized to virtually any input (and with
a professional pricetag).

Truly, an unfortunate situation.  ;-(

Does anyone know if the Apple Video Overlay Card outputs its
pixels in the "middle 560" of a 640-pixel digital NTSC line?  If so,
then its output should be able to be stably "scan doubled" by non-
professional equipment.

-michael

Check out amazing quality 8-bit Apple sound on my
Home page:  http://members.aol.com/MJMahon/