Re: Apple ][gs VGA Card

[ntt@cleese.apana.org.au (Jonathan Pratt)]

 Herbert Fung (herbertf@ersys.edmonton.ab.ca) wrote:
 : Previously ntt@cleese.apana.org.au (Jonathan Pratt) wrote:
 :  
 : >Interlaced = the image is sent in two parts (theoretically more but I've
 : >not seen it implemented).  The video signal represents half the screen
 : >each time.  The hardware outputs the signal for alternate scan lines
 : >(btw a scanline = one horizontal row of pixels) all the way down the
 : >screen, and then the next cycle provides the ones in between which were
 : >skipped last time.  This makes the screen update cycle half of the
 : >original and can occasionally show picture abberations like flicker
 : >(uncommon) or aliasing.
 :  
 : How does this help display higher resolution modes?
 
This is an old technique for getting video pictures from DRAMs at higher
resolutions.  DRAMs have a single access port - that is you address the
memory you want and R/W it as you desire.  From the video point of view
that's a read and you need to have hardware counters to keep up with the
location.  The old apple //'s get video from DRAMs (which is a
signifigantly rate limited process) and convert them to serial information
(1 byte = 7 pixels), and for a 14 MHz video /pixel rate, you only need to
address the RAM at 2MHz which is well within the speed restriction of
DRAMs (even in 1977) with plenty of time for the CPU to address the DRAMs
at the 'same' time and modify the screen image.

If you recall, the old apple // screen produced colour by putting a pixel
in just the right place to correspond with an NTSC colour pixel (but two
together results in white).

To produce better resolutions (or simply more colour choices) you need to
address the DRAM faster, squeezing out cycles for the CPU to address the
Video portion of memory.  (the 65816 in the GS can only write the video
screen at 1 MHz, freeing it up for the VGC to get at it as much as it
likes)  In a 'fast' machine this bottleneck is intolerable (since those
fast machines like to be graphic intensive.

Even then, there's a limit to the resolution you can display (using FIFO
queueing techniques) because of the speed restriction of the DRAMs.  For
example a screen of 1024*768 with 256 (8-bit) colours would be difficult
to implement in DRAMs.  The problem is that if you refresh the screen at
less than 72 cycles/second then you can get flickering which is highly
undesirable.  1024*768*8 = 768KHz for each screen update (say 72) which
corresponds to over 50 MHz (this is a gross understatement - you need
around 80MHz for this resolution) which is just simply beyound the access
speed of DRAMs.  Complicated hardware 'polling' of DRAM chips might
overcome the problem, but this is not a pretty solution.  To cut back on
the overheads you can do two things - cut the refresh rate (hey a 1 Hz
screen update could give you a superb resolution ;^) introducing
flickering, or use interlacing. (actually both are done, but hey this is
only a broad description...)

A 60Hz refresh rate produces tolerable results, and even 50 (or 42 is
bearable) - just look at your GS monitor.  But you can interlace the
picture (send half the picture each refresh, using alternating scanlines)
and refresh at only 30hz to get a slightly duller image but one that
doesn't have too much flickering  (it looks more like a 60 Hz refresh rate
but the entire picture takes two 60 Hz cycles = 30Hz actual screen drawing
time.)  This reduces the needto access the DRAMs by 50%, and hence the
access rate dropped to practicle levels (you still wouldn't easily get
8-bit colour, 1, 2 or 4 possibly...)

The need for this technique died with the introduction of cheap VRAMs
(although people thought that it was so nifty that they kept it up until
N/I monitors became affordable)  The VRAM has two access ports - a RAM
port the same as the DRAM, and a serial port. A 256K * 4 VRAM chip is
divided into 512 blocks of 512 four bit sections.  If you address the VRAM
in a certain way it sends one of those blocks into the serial port which
then requires no further addressing to send consecutively each of the 512
four bit sections through the serial port.  Using two of these together (8
bits) or six together (24 bits) can produce the number of colours you
want.  The serial ports are fast enough to keep up (without too much
hardware trouble) with the 80 MHz clock rate, and not (much) interfere
with the CPU addressing the screen portion of memory.

The output of the VRAM can go directly into a D/A converter, but modern
VDACs actually support various modes, and have internal memory which acts
as a look up table.  That is you tell it an 8 bit number, it looks in its
internal memory for the corresponding 24 bit number which it promptly
proceeses as the next pixel on the screen.  (a la the colour tables for
your GS)

hope this helps

cheers
ntt@cleese.apana.org.au