Re: How does the apple2 RGB card work?

["General_Failure" <tristan.mumford@gmail.com>]

Bryan Parkoff Said:

>    Actually, 80 Col / RGB card does not have video RAM, but it does have
>AUX RAM.  AUX RAM is used to hold data for Text, LoRes, and HiRes in 80
>column.  I believe that it has 8 chips to hold 64KB.

Well yes, I agree. I apologise if I said otherwise. Sometimes I am not
too good at explaining what I mean.
And yes, I believe you are correct about the 8 chips.

>    Well, one byte is loaded from main memory or aux memory into Load/Shift
>Register.  One bit is loaded and shifted out to the NTSC monitor.  RGB card
>has similiar Load/Shift Register, but it does read a group of four phase
>shift while it translates into R, G, B, and I signals.  RGBI signals have
>color information, but phase shift does not.

Very interesting. I am very surprised about the single bit being output
for NTSC.
So it achieves colour by the artifacting method that is mentioned by
Michael?

I just want to be clear that the RGB card we are talking about has a
seperate R, G, B and sync(s), right?

 It is why RGB card has to output only C sync because CGA
monitor does not have C sync because it does not split C sync into H
sync
and V sync.  You can build an adapter which it has LM1881 chip.  LM1881
chip
splits C sync into H sync and V sync.

>    I have tested in my Oscilloscope to show that H sync and V sync are
>identical.  It seems that LM1881 chip is not necessary.

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?

    I don't agree with most emulator projects because I claim that
video
data is completely wrong for DHGR and HGR.  I appreciate the
programmer's
efforts to guess and build video data in their own.
Video data is usually a sticking point in emulator development. At
least in the early stages of the program's life cycle. Especially when
some really nasty form of bit-banging is needed to translate data.

> It is why I have to
>capture R, G, B, and I signals at video cycle by video cycle.  Then I
>translate RGBI signals into 12 pixels.  I place 12 pixels in the 4,096
>possible data in a table.  I believe that this table can correct video data
>which it looks true VGA monitor like Apple IIgs' analog RGB monitor.  DHGR
>and HGR will look correct according to my efforts of capturing RGBI signals.

Because you cover all 4096 combinations, which is quite an amazing
feat, the bit alignment of the captured signal would not matter.
Correct?

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.

>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.

>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.