jbn@glacier.STANFORD.EDU (John B. Nagle) (09/06/88)
The problem with MMUs is that they are generally designed to map
sections of sequential addresses into physical memory. For a
windowed display, one wants the ability to map rectangular areas of
memory to rectangular areas of the display. Given such hardware,
individual processes could each modify their own window memory directly
while being totally unaware of the other windows.
Sprite hardware is exactly such a mechanism. Sprites are rectangular
areas of memory that can be mapped to any portion of the screen. The
implementation involves video refresh hardware which, rather than simply
reading from sequential addresses, continually checks sprite boundary
registers for all sprites on every reference, and begins referencing
from a sprite when the refresh point enters a sprite area. When
sprites overlap, the highest priority sprite is considered to be "in
front", and it is the one which appears. Usually, sprites have a
color considered "transparent", so objects can be stored in a sprite
with their background transparent. This allows one to move small irregular
objects around the screen cleanly and with great rapidity.
Unfortunately, sprite hardware was developed for video games, and
while a number of machines, including the older Atari machines and
the Amiga have it, in these machines, the dimensions of the sprites
are very limited. They're big enough for "players" and "bullets",
but not for windows. It's not clear why, in the Amiga's case, this
limitation is enforced. In the Amiga, there's no height limit, but there's
a rather small width limit. (Yes, for all the Amiga maniacs
out there, I know all about how the blitter, the copper, and the ROM
kernel are made to cooperate to work around this limitation. However,
the end result does not result in support of software-transparent
overlapping windows, which is my point here.)
Some custom VLSI devices have been built which were real hardware
MMUs. One, I recall, allowed multiple Hercules-compatible windows on
a DOS machine. But the machine for which it was developed never caught on.
The trend, rather than being toward screen MMUs, seems to be toward
imposing an arm's length relationship between the application program
and the screen. Sun Windows, in which each process directly wrote the
screen (with an incredibly elaborate coordination mechanism to keep
them from stepping on each other) has been superseded by NEWS, which is
a sort of software-implemented smart terminal system in which one sends
commands from the application to the "terminal" interpreter. X Windows
has a similar model. In a less decoupled way, the Mac and Amiga interfaces
follow much the same model, although in a non-protected mode operating
system where unprotected memory-sharing is a way of life. How does
OS/2 with the Presentation Manager do it? Or is that text-only?
For a simple application, the "smart terminal" approach does make
things simpler at the application end. However, animated graphics
requires a wideband pipe between the application and the terminal interpreter,
as well as a terminal interpreter fast enough to keep up with the pipe.
This takes much computational power. Given, though, that there are few
applications that generate animation at high-speed on systems that don't
have great computational power, this may not be a serious problem at
the workstation power level. Those involved in vision, video editing, or
interactive videogames on low-end systems may have problems. Trying
to run something like Flight Simulator through X Windows on a PC will be
tough. Still, I hear there are X-based games.
John Nagle