In the previous design of the CAM library the concept of a generic
Cellular Automata Machine did not exist.  It was designed with the
CAM8 computer in mind.  A consequence of this is that the objects
which make up the library closely follow the hardware in concept.  Of
particular importance was the separation of the CAM8 computer and its
host (a Sun workstation).  Users interact with CAM8 through its device
driver (hidden beneath the STEP software) to allocate memory on the
host computer for transfering data between them.  It is only after
instructions and data are transfered to CAM8 that the CA becomes
``real''.  This distinct separation is not found in the current design
concept.  The generic CAM object represents an virtual machine that
has all the necessary hardware to realize any CA.  For the CAM8
computer this would include the actually hardware and its host
computer.  The two are viewed together as a virtual CAM.  A generic
CAM need not be a CAM8 computer but can also be the CAM8 simulator, a
workstation running some software that provides a CA environment, a
MPP architecture such as the CM5, or some new computer as yet to be
built.  In either case the CAM object provided by the library must
capture the minimum requirements for a virtual CAM.  In this way CA
experiments can be written in a high level language using well a defined
interface to the ``machine'' it will run on.

The notion of a virtual CAM extends includes all the components you
would find in a workstation class computer.  CAMs have components that
separate function in a logical fashion:

1) Computation Engine - This is what would be the processor in a
typical architecture.  CAMs typically are parallel machines (either
physically so or simulated in software).  Control of the entire
machine is centered here.  The core doesn't execute assembly code as a
typical processor does but instead coordinates interactions between
all other aspects of the CAM.  These include such things as loading
and saving the CA space, initializing the display, getting input from
various devices, etc.

2) Memory Subsystem - Memory in a CAM comes in a number of flavors: the
CA space, LUTs, pattern buffers, and general buffers.  Often the CA
space is not organized as memory typically is in a ``normal''
computer (for example in CAM8 its is a collection of indepenedant bit
slices).  LUTs are essentially simple memory buffers but in a CAM it
is a limited resource.  Pattern buffers are compact representations of
the CA space.  They may or may not have the same layout as the CA
space.  General buffers are just arbitrary chunks of memory with no
special features or limitations.

3) Filesystem - All computers need mass storage.  The CAM's filesystem
allows all and any memory in the machine to be stored and retrieved as
necessary.  This is essential in the case of LUTs and pattern buffers
becasue there are a limited number of LUTs that can be memory resident
and an vast collection of pattern buffers that may be used by any
particular program running on the CAM.

4) Network - The network is a special case of the I/O subsystems in
the CAM.

5) I/O - There are an unlimited variety of I/O subsystems that can
exist in a CAM.  The ones that are required are keyboard input,
terminal output, graphic input (mouse movements, GUIs events, etc),
and graphic output (framebuffers, windows, etc).  Many other I/O
susbsystems may exist (digital camera input to CAM8 and XCAM display
ouput from CAM8 for example).  Anything that is a means of getting
information from the outside world into the CAM is an input
susbsystem.  Anything that is a means of representing information
inside the CAM to the outside world is an output subsystem.

