[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Apple ][ to VGA monitor adapter board - looking for best color decoding method
On Apr 4, 3:02 pm, ferd...@gmx.de wrote:
> I've been working on a board to double each line of the Apple //e's
> video output so that it can be viewed on a normal VGA monitor. My
> goal was the perfect picture quality. To yield it, I sampled the Apple
> video signal with the original Apple clock, stored it in RAM and
> displayed each line twice with double speed. This works so far (except
> for one timing problem that can be fixed by touching the correct
> line... this is going to be fixed) and produces an extremely crisp
> picture. Especially the 80-col mode is way better readable because the
> lines aren't that far apart as on a monochrome monitor.
> So far, so good. Now the problem starts: color. The signal needs to be
> converted to RGB somehow.
> I tried:
>
> 1. Latch the video signal 4 times at different phases to COLOR
> REFERENCE. (7M rising, 14M falling with 7M high, 7M falling, 14M
> falling with 7M low - note that COLOR REFERENCE becomes 7MHz after the
> conversion). These 4 signal are mixed to form the 3 colors. This
> method gives exact reproduction of the 15 LORES colors (I designed it
> to do so) but blurs the picture in HIRES.
>
> 2. decode the color as above, but gate it with the monochrome signal,
> so that a green horizontal line actually becomes a dotted line. With
> some displays this looks really nice, but it sometimes produces ugly
> color fringes on white areas.
>
> The Apple //e's PAL encodes uses a circuit with a quad D-FF, but I
> don't know how it is wired.
> So I'm looking for the schematic of the //e's PAL encoder or the PAL
> color card for the ][.
>
> BTW: I'm missing both the Eurapple jumpers and the 14M/Graphics time
> signals on Slot 7 in the Apple //e PAL. I had to jumper them directly
> from the main board.
Since an Apple RGB display (except for SHR) is a bit of a "freak"
(since it attempts to represent NTSC artifact colors as if they were
continuous color signals), you will have to make some compromise.
Either you go for crispness and conformity to the normal "RGB card"
experience, or you go for fidelity to the usual NTSC display.
Although
the latter does better justice to most existing Apple II graphics, the
former is the usualy route, and is less complex.
In an ideal world, it would be possible for the user to select NTSC
emulation or RGB card emulation, but that may be asking too much.
Sinplicity and crisp, clean 80-column displays argue strongly for
the RGB card emulation if a choice must be made. And at least
the weird treatment that RGB cards provide to many Apple graphics
is "familiar". ;-)
-michael
-michael