Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!decwrl!waikato.ac.nz!ldo
From: ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University)
Newsgroups: comp.arch
Subject: Dynamic Display Architecture
Message-ID: <1991Apr15.200955.3438@waikato.ac.nz>
Date: 15 Apr 91 08:09:55 GMT
Organization: University of Waikato, Hamilton, New Zealand
Lines: 45

I've been talking with some friends about different display architectures,
notably contrasting the hardware-intensive approach of the Commodore Amiga
with the software-intensive one of the Apple Macintosh.

Now, raster displays are neat, but it takes a lot of memory accesses
to move those bits around, like when you're doing animation. The Amiga's
sprites and other capabilities are powerful, but I can't help thinking there
are too many arbitrary numbers hard-wired into that architecture for it to
be a long-term solution.

But one of the interesting bits of hardware in that machine is a processor
called the "Copper": its sole job is to watch the video beam, and poke
various machine registers (that you specify) when the beam gets to particular
positions on the screen. For example, you could change to a different
frame buffer halfway down the screen, or redefine a set of colour table
registers. It's true the CPU can do all this as well, but it makes
sense to pass as much of the load as possible to the Copper.

This set me to thinking: what if you have a very fast, reasonably
general-purpose processor, whose sole job was to feed a stream of pixel
data to the video beam? In other words, it would be directly controlling
the intensities of the R, G and B components of the beam as it traced
out the raster. In the simplest case, this processor could be reading
data from a frame buffer. It could even use the data it reads as an
index into a separate "colour table" array before feeding the results
to the beam.

But, depending on how much processing time you have, it could get
much more fancy than this. You could read from several different
areas of memory, producing the equivalent of any number of "sprites".
And that's just the beginning.

Assuming (just looking at the machine I'm running now) a 640 * 480
display refreshed at 67Hz, you're looking at generating about 20
million pixels per second. Is this practical?

Is the current generation of RISC machines up to it?

Lawrence D'Oliveiro                       fone: +64-71-562-889
Computer Services Dept                     fax: +64-71-384-066
University of Waikato            electric mail: ldo@waikato.ac.nz
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00
"...so she tried to break into the father bear's computer, but it was
too hard. Then she tried to break into the mother bear's computer, but
that was too easy..."