There is some problem with Byran's hookup, since the LM1881 generates
a quite respectable Vsync pulse when operated correctly.
It's strange that they would have wasted money on a chip that has no
useful effect. That does concern me. Does the chip do anything to the
signal at all, in your observations?
The RGB card has no use for any sync signal except, possibly, horizontal
sync, since it is provided with the master 14MHz dot clock, and the
3.58MHz color reference, with which all color information can be derived
from the composite video signal. The card just passes composite sync
through to the monitor (and most RGB monitors can handle composite
sync).
Michael J. Mahon Said:
And you would also have to track Main/Aux bank switches, too.
Sure would. Any data locations that affect video display would need to
be tracked.
Instead, the Apple accesses both main memory and AUX memory to generate
composite video, which is supplied to the AUX slot. An RGB card decodes
this composite signal to generate R, G, B, and "I" signals for a digital
RGB monitor (originally, the AppleColor 100).
That is so messy. It kind of saddens me that it was done that way. A
means to an end I guess.
Actually, it is electronic poetry.
It is this technique that permitted the Apple II to have color graphics,
even hi-res graphics, years before memory became cheap enough to permit
multi-plane frame buffers in personal computers. (And the larger the
pixel, the more processor time is required to "draw" in the buffer.)
The video signal of an Apple II takes on only two values (except sync
and color burst): "0" and "1", and all the colors are artifacts of this
binary signal!
Basically, yes. All Apple II color is "artifact" color resulting from
video signal pulses which contain 3.58MHz "color" information, in
various amplitudes and phases, causing an NTSC monitor to display color.
That explains the choice of NTSC then. It's not so easy to generate
colour artifacts with PAL.
True--a PAL card has to do work similar to an RGB card.
The sync, blanking, and color burst are generated by logic, not read
from memory, but the entire structure of the video line is created from
information read from memory--without any translation in the case of
hi-res and double-hi-res graphics modes.
I didn't think that I understood correctly before, because it would
have meant that every time a write to the video region of RAM was done,
something would need to recalculate the phase shift accordingly.
If you needed to represent *colors* in a "mirror" frame buffer, then
such a computation *would* be needed, and a change could affect the
rendition of neighboring pixels, too.
-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."