Re: How does the apple2 RGB card work?

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

Bryan Parkoff Said:
>    I want to make sure what I understand your view.  You want video modes
>(TEXT40/80, LORES40/80, and HIRES40/80) from aux/main memory to be mapped
>into video memory.  Then RGB card reads video memory and displays pixel by
>pixel to the screen.

Yes. Well, partially. It's more of a mirroring than mapping. I was
thinking of a card which keeps a copy of the video data on its own
board. The video data is based on listening to write accesses performed
on the video area of memory. The card would never need to interact with
the system bus, except in its passive listening state.

>    I do not think that 80 Col / RGB card have video memory.
The 80 column/language card in my //e does. It has 64kb. However I
suspect that the RGB card does not. Having never seen an actual unit or
a schematic of one I cannot tell.

> It only runs
>at 1/14M or 70 ns to read NTSC pulse from aux or main memory.  NTSC pulse
>goes through the RGB circuit to translate into R, G, B, and I signal.
By NTSC pulse from memory, what exactly do you mean? Are you saying
that the colour data in memory is pre-encoded with NTSC modulation. Ie
with the phase shifts coded into the colour information?

>  RGBI
>forms a pixel to the screen.  It is how 15.734K horizontial freq is
>manipulated from 14M.  I am not too sure if EGA is 15.734K.
EGA is also the same to my knowledge. It is just a minor extension to
CGA.
VGA was the first to use the faster HSync.

>    You ask about sync.  H sync and V sync are created through logical truth
>table from videocounter and H sync and V sync are combined into composition
>sync to the NTSC monitor.
Right, so it's done in the video counter. That makes sense.

  RGB card receives C sync and separate it into H
>sync and V sync because most analog / digital monitors don't have C sync
>except Apple IIgs' analog RGB monitor.

Are you saying that the built in video creates a seperate H and V sync,
and then combines them. And then the RGB card has to re-split them for
its own use? I feel as if I have misunderstood you. Please correct me
if I am wrong about what I have said.

>    You can design a video card to create video memory which it allows to
>copy byte by byte from aux and main memory into video memory.  It will not
>depend on 14M, but it uses its own frequency to maniuplate VGA or higher
>resolution.
More or less. Except it doesn't perform any operations of its own. It
just listens and updates its own RAM accordingly.

To achieve much higher resolution, including colour depth, a register
based approach would be easiest. Ie, a PIO mode single byte write to
the fictional graphics card's memory, or a simple register based memory
banking to expose a window of the card's RAM to the system bus.

I am just taking these ideas from the way graphics are implemented in
x86 machines. It is not the best way, but it is designed for a legacy
system.

>    Is it what you are referring?  It is what I am doing to capture video
>data from R, G, B, and I signal and also well with Apple IIgs' RGB signals.

At which point are you capturing the signal?