Re: How does the apple2 RGB card work?

["Bryan Parkoff" <none@nospam.net>]

"General_Failure" <tristan.mumford@gmail.com> wrote in message 
1148662506.033090.224480@j73g2000cwa.googlegroups.com">news:1148662506.033090.224480@j73g2000cwa.googlegroups.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.

    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.

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

    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.

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

    Almost correct.  Understanding the Apple //e manual gives the pinout of 
AUX slot connector.  It does tell C sync.  I can't remember if it has H sync 
and V sync.  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 is possible to 
use Y splitter so C sync can connect to H sync and V sync directly through Y 
spliter.  It will work.

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

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

Bryan Parkoff