Re: Apple II GS Questions

[dempson@actrix.gen.nz (David Empson)]

Mitchell Spector <spec@vax2.concordia.ca> wrote:

> In article Jeff Lemke <lemke@terra.cira.colostate.edu> writes...
> 
> >Not enough video RAM, I guess.
> 
>     The VGC doesn't have any dedicated video RAM. I think it uses
> memory from main RAM (32K I believe).

Correct.  Identical in principle to the video hardware of earlier Apple
II machines (ignoring third-party cards).

> I'm not so sure that is the reason more colors per scanline can't be
> used, it is most likely a limitation of the VGC controller itself.

The VGC is designed this way, but the main reason for this design is to
keep the size of the video buffer manageable.

The VGC supports two memory encoding formats for the lines,
corresponding to 320 and 640 modes.  In both cases, there are 160 bytes
per line, with two pixels per byte in 320 modee (4 bits per pixel, hence
16 choices for the colour), four pixels per byte in 640 mode (2 bits per
pixel, hence 4 choices for the colour).

The palettes are stored separately at the end of the video buffer area,
and are read by the VGC during the horizontal blanking period at the end
of each line.  (This is why you cannot change palettes on the fly within
lines.)  The scan line control byte for the current line is also read at
this point, so the video modes can change from line to line.  (320 mode,
640 mode, 320 fill mode; interrupt enable; which palette to use.)

To be able to support more than 16 colours per line, it would be
necessary to reduce the number of pixels per line (e.g. 8 bits per pixel
would leave 160 pixels per line), or to increase the number of bytes per
line (e.g. 320 bytes per line to get 320 pixels with 256 colours
available).

It would also be necessary to increase the size of the palettes
(currently 32 bytes, would need to be 512 bytes per palette for 256
colour mode).

There are currently 512 bytes for all 16 palettes, so assuming the 16
palette count was retained, the screen buffer would need to increase by
at least 7680 bytes just for the palettes.  If 320x200 256 colour mode
was supported, the pixel image part of the buffer would be 64000 bytes.
The whole thing wouldn't fit in 64K, let alone 40K (the practical limit
for "slow" RAM banks).  Adding more "slow" banks without the I/O
remapping (starting at bank $E2) could have solved this.

Another problem with more bytes per palette is that it would not be
possible to read the palettes between scan lines - they would have to be
read during the vertical retrace interval.

The best way to resolve this would probably be to put the palettes and
scan line control bytes into special registers in the VGC, accessed
through the I/O space, or have a dedicated 8K static RAM controlled by
the VGC for this.  That would just leave the pixel data in memory.  It
doesn't solve the problem with the size of the image, but bank switching
could be used if necessary.

(The Video Overlay Card has a special interlaced 400 line mode in which
it uses $2000-$9FFF in banks 0 and 1 to hold the entire 64K image.)

If we stick to the limit of 32K for the video buffer, then there is one
possible arrangment that could have been supported:

160 pixels per line, 256 colours per pixel, one palette for the entire
screen.

This is comparable to the practical horizontal resolution of Hi-Res or
Double Hi-Res mode (in colour), but it wouldn't be useful for
implementing a graphical desktop.  320 mode is pretty limiting; 160
would be unusable.

> >That's a real graphic display crippler,
> 
>     Yep, the GS really should have been able to do 256 colors per
> scanline from the start, I can't imagine it would have been too
> difficult to have engineered that (or what it desparately lacked,
> 400 lines of resolution vertically, which was the real crippler).

It would have to be 400 lines interlaced, to keep with the principle of
TV-compatible video output.  If you are going to remove that
restriction, then doing everything outside the CPU's address space (as
with the Second Sight) makes more sense.

-- 
David Empson
dempson@actrix.gen.nz
Snail mail: P.O. Box 27-103, Wellington, New Zealand