  % -*- Mode:TeX -*-
\chapter{Advanced interconnection techniques}\label{multi}

This chapter introduces techniques for going beyond the standard
256\by256\by4, toroidal wrap-around format---by interconnecting in
special ways the bit-planes of one or more \cam\ cards.

\section{Edge gluing}\label{gluing}

\Cam's normal mode of operation, without any external connections, is as
four planes of 256\by256 bits.  In order to simulate larger systems,
provision is made for {\sl gluing} the edges of bit-planes together to form
larger bit planes.  We shall first describe how gluing is performed on
a single \cam\ card to allow it to simulate two planes of 512\by256 bits or
(with some limitations on the neighborhoods that can be used) one plane of
512\by512 bits.  Then we shall describe how the bit-planes of one card may be
glued\index{Gluing} to those of another,\index{Bit-plane/edges} for example allowing four cards to simulate four
planes of 512\by512 bits (with no limitations, in this case, on the choice of neighborhood).

\medskip

Gluing a single \cam\ card requires hardware and software actions.  The
hardware action, to be described in more detail below, consists of
appropriately cabling certain {\sl glue} connectors on the card; the
software action consists of issuing commands to turn on the horizontal-
and/or vertical-glue bits of the {\sl control and configuration
register}\index{Control and configuration register}, after the experiment
has been initialized by \id|NEW-EXPERIMENT|.  Turning on these
bits causes \cam\ to listen to the signals on the glue connectors, which
it would otherwise ignore.

Each \cam\ card contains a 16-pin {\sl horizontal-glue} connector,
organized into an input half and an output half, and a similarly
organized {\sl vertical-glue} connector; you'll need two eight-wire {\sl
gluing cables}, one marked ``even,'' which can be used to connect planes
0 to 2 and 1 to 3; the other, marked ``odd,'' to connect planes 0 to 1
and 2 to 3 (see file \prog{PINOUT.DOC} for details).

\subsection{Horizontal glue}\label{hglue}

To configure \cam\ horizontally into two planes of 512\by256 bits, bend
the even gluing cable into a U shape and plug one end of it into the
left half (looking at the component side) of the \cam\ card's horizontal
glue connector and the other end into the right half of the same
connector.  Make sure that the word `even' faces upward
to insure that the connections between the planes are permuted in the
proper fashion (i.e., 0 to 2 and 1 to 3).  In software, issue the
command \id|HGLUE SET-CCR|, to turn on the horizontal-glue bit in the
configuration control register.  Leave the vertical glue connector
uncabled and the vertical glue bit clear.  Planes 0 and 2 will now be
joined horizontally, as will planes 1 and 3.  In other words, \camb\ is
now a horizontal extension of \cama.  Therefore, in running an
experiment, it is necessary to specify the same neighborhood and rule
table for \camb\ as for \cama, which can conveniently be accomplished by
defining the neighborhood and table in \cama\ and then issuing the
command \iprog{B=A}.  By the same token, the minor neighborhood
selection \id|&/CENTERS| should be avoided since it will now refer to
the site 256 units away from \id|CENTER| in what is now the {\sl same}
bit plane.

\medskip

Although \cam\ is now logically connected as a 512\by256 array, the
display still treats the bit planes as before, so that the two halves of
the larger array will be seen superimposed on the screen.  For example,
using the {\sl IRGB} color map, the two halves of glued plane 0--2 will be shown
as grey and green superimposed, while the two halves of glued plane 1--3
will be shown as red and blue superimposed.  If this proves confusing,
one can turn off the display of planes 2 and 3 (e.g., by hitting the color
toggle keys \keyfn8 and \keyfn{10}) and one will be left with a display that shows a
256\by256 window into the 512\by256 system. The arrow keys can be used to
shift this window.

\subsection{Vertical glue}\label{vglue}

To connect \cam\ as a single 512\by512 system, install the even gluing
cable as described above on the horizontal glue connector, and install
the odd gluing cable in an analogous manner on the vertical glue
connector.  In software, issue the commands \id|HGLUE SET-CCR| and
\id|VGLUE SET-CCR| to enable gluing both horizontally and vertically.
Since all four planes are now logically connected into one large torus,
the neighborhood selection must be one that makes the same neighbors
available on all four bit planes.  This means that \id|N/VONN| or any of
the Margolus neighborhoods can be used, but \id|N/MOORE| cannot.  The
transition rule must of course also be the same for all bit planes:
plane 1's new state must be the same function of the neighbors
\id|NORTH'|, \id|SOUTH'|, etc.\ as plane 0's is of the neighbors
\id|NORTH|, \id|SOUTH|, etc.  The following is a typical example,
in which the nonmonotonic majority function \id|5ANNEAL|\cf{5.4,8.3} is
applied to all 4 bit planes.
        \begin{verbatim}
    NEW-EXPERIMENT
    HGLUE SET-CCR  VGLUE SET-CCR
    N/VONN                                             : 5ANNEAL
                               + + + + { 0 0 1 0 1 1 } ;
                                                       : RULE
       NORTH  SOUTH  EAST  WEST  CENTER  5ANNEAL >PLN0
       NORTH' SOUTH' EAST' WEST' CENTER' 5ANNEAL >PLN1 ;

MAKE-TABLE RULE
B=A\end{verbatim}
        For display, toggling off all but one of the colors will provide a
256\by256 window into the 512\by512 array, which can again be shifted using
the arrow keys.

\subsection{Gluing cards together}\label{cardglue}

Gluing can also be performed between bit planes of {\sl different\/} \cam\
cards.	We describe how to configure two \cam{}s to operate as a 512\by512
array with two bits per site and no restriction on the main neighborhood selection.
Other configurations are analogous.

\medskip

First, each of the two cards is cabled individually as described above
for a 512\by256 array, with an even gluing cable, bent into a U shape,
running from the left half of each horizontal glue connector to the right
half of the same connector.

Next these two 512\by256 systems are glued together
vertically into a single 512\by512 system by using the two ``odd''
gluing cables to cross-cable between the boards, each cable running from
the left half of one board's vertical glue connector to the right half of
the other board's vertical glue connector.  When cabling between boards,
the cables should be installed upside-down (with the word ``odd'' facing
down).	This causes the planes to be connected in a straight (i.e., non-permuted) fashion,
plane 0 of one card being connected to plane 0 of the other card, and
similarly for the other planes.

Finally, the two cards are connected by a master/slave cable 
(also available as an option) and
installed in two slots of the same \pc, and their video connectors are
daisy-chained together---as described in the next section on multiple
\cam{}s.  In the software, commands are issued to initialize both
\cam{}s, turn on vertical and horizontal gluing, and enable the desired
monitor configuration.  A typical format is given below.
        \begin{verbatim}
    NEW-EXPERIMENT   2 CAMS  
    N/MOORE                                : RULE
                                       ...
                         an arbitrary rule 
              depending on Moore neighbors 
                                       ... ;
    MAKE-TABLE RULE
    B=A
    TAB>BUF    
                                           : INIT-ALL
                              FOR-ALL-CAMS
            VGLUE SET-CCR  HGLUE SET-CCR
                 CAM-AB N/MOORE  BUF>TAB
                                  NEXT-CAM ;
    INIT-ALL\end{verbatim}
        As explained in the next section, the loop \id|FOR-ALL-CAMS|\ldots\id|NEXT-CAM|
issues the same information (neighborhood, glue-bits, and rule table) to
the two \cam{}s, only one of which can be spoken to at a time.

\section{Multiple CAMs}\label{multiple}

Up to eight \cam\ cards can be ganged together%\index{Multiple \sc cam\rm s}
and operated jointly in a
relatively straightforward manner; in this way, one can obtain 
\cam\ systems having substantially greater capabilities. Typical applications
of multi-card systems are
        \begin{itemize}
        \item The use of one \cam\ card to supply good-quality,
finely-tuneable random numbers to another.
        \item Simulating two-dimensional automata with more than 16 states per
site.
        \item Simulating three-dimensional automata.
        \item Simulating two-dimensional arrays 
larger than 256\by256 while retaining all of the features available with a single card
(cf.\ \ref{gluing}).
        \end{itemize}
\medskip

Operating multiple \cam{}s for any of these reasons is not difficult, but
it requires attention to several kinds of physical connection among the
cards and appropriate commands for communicating with them individually
or collectively from the \pc.

The most important physical connection among the cards (aside from the
shared \pc\ bus into which they are all plugged) is a chain of master/slave
and slave/slave connections which serves to distribute a common clock
signal (that of the ``master'' \cam) to all the other ``slave'' \cam{}s, and causes
each \cam\ to map itself into a different region of the \pc\ memory---with the
master occupying addresses {\tt DF800} to {\tt DFFFF} and the slaves (up
to eight) occupying consecutively lower 2K byte regions.\footnote
        {The whole 16K byte region (normally {\tt DC000}--{\tt DFFFF}) of the address space
reserved for the eight \cam{}s can be remapped by means of programming jumpers
in order to avoid conflicts with other cards. Cf.\ the \hm\ and
{\tt CAM-BASE} in the glossary.}	
        To set up the chain of connection, the sixteen-pin {\sl
master-out} connector of one \cam\ (which becomes \cam\ 0---the {\sl
master}) is cabled to the {\sl slave-in} connector of another \cam\
(which thereby becomes {\sl slave} \cam\ 1).  If there are further
\cam{}s in the system, the slave-out connector of \cam\ 1 is cabled to
the slave-in connector of another card (which thereby becomes slave
\cam\ 2), and so on for up to seven slaves.  As explained in the \hm, if
there are more than three slaves, the two cables connected to slave 4
are different from the other cables.

A second kind of connection is generally needed to handle the displays.
As explained in Appendix \ref{monitor}, each \cam\ has a nine-pin video-in connector and a matching video-out
connector, which can be switched under software control between displaying
that \cam's own video signal or simply passing on a video signal
received from some other \cam\ (or from the \pc\ color card) via the card's
video-in connector.  If all the CAMs are daisy-chained together, with the
video output of one going to the video input of another, and the output of
the last CAM going to the monitor, then it becomes possible to display any \cam's
video-output at will under software control.

    A third kind of connection will depend very much on the particular
application of the multi-\cam\ system.  This is the connection among
the user connectors of the various \cam{}s.  Since all the \cam{}s are
operating under the same clock, plane-output lines (e.g., C1,
designating the center cell on plane 1) from one \cam\ may be wired to
table address inputs (e.g., UA10, designating the tenth user input to
\cama's lookup table) of another \cam, in the same manner as custom
neighbor connections are made on the user connector of a single \cam\
(see Section \ref{user}).\index{User connector} In this way, it
becomes possible, using $n$ \cam{}s, to simulate cellular automata
rules depending on up to $4n$ bits per site, or, alternatively, to
simulate a three-dimensional array of 256\by256\by$4n$ with one bit
per site.  

    A fourth kind of connection has already been discussed: the gluing
cables used to connect bit planes (in the same or different \cam{}s) into
arrays larger than 256\by256 sites.  These connections are made only when
gluing is desired.

\medskip
        
Having made the necessary hardware connections, it becomes necessary to
communicate with the multiple \cam{}s via software.  Immediately after
\id|NEW-EXPERIMENT| one should include the command `$n$ {\tt CAMS}'
(e.g., \id|3 CAMS|) to tell the \pc\ how may \cam{}s there are.  As a
rule, communication (specifically, loading a table or color map, setting bits
of registers such as {\tt CCR}, {\tt PCA}, and {\tt PRA}, operations
such as \id|RND>PL| on data in the bit planes, and the assignment of
values to pseudo-neighbors such as \id|<ORG-HV>| and \id|<PHASES>|) takes
place with only one \cam\ at a time; uder the control of the
word \iprog{CAM-SELECT}.  For example, \id|0 CAM-SELECT| causes subsequent
commands to refer to \cam\ 0, the master, until a subsequent command such
as \id|2 CAM-SELECT|, after which communications would be directed at \cam\ 2.
The only exceptions to the rule that commands are directed to one \cam\ at
a time are the commands \iprog{NEW-EXPERIMENT}, which resets all \cam{}s, and \iprog{STEP},
which causes all \cam{}s to step.  When uniform data must be directed at
all the \cam{}s (e.g.,  giving them all the same rule) the command in
question (such as \id|VGLUE SET-CCR|) is put in a loop demarcated by the words
\iprog{FOR-ALL-CAMS}\ldots \iprog{NEXT-CAM}.	 An example is given at the end of the
previous section on gluing. Note in particular that neighborhood selections must
be repeated.

If the video-in and -out connectors on the \cam{}s are properly
daisy-chained together, the command \iprog{SHOW-CAM} can switch the
display from one \cam\ to another.  Thus, \id|0 SHOW-CAM| causes the
master to be displayed, and \id|1 SHOW-CAM| displays the first slave.
It is possible, though perhaps confusing, to choose one \cam\ for
communication and another for display.  Keyboard commands such as
\keysemicolon\ ({\sl Random\/}) then appear to have no effect, but in
fact they are operating on a \cam\ that is not being displayed.  The
\cxp\ \keya\ command  alleviates this problem by performing the
functions both of \iprog{SHOW-CAM} and \iprog{CAM-SELECT}; for example,
typing \narg{1}\keya\ causes \cam\ 1 to be displayed and at the same
time selects that \cam\ for communications with the \pc.

\section{Kicking}\label{kicking}

\index{Kicking}A particularly useful consequence of the fact that the \pc\ communicates with
each of the several \cam{}s individually is the ability to rapidly generate
high-quality random numbers on one \cam\ for use by another \cam. The numbers
are generated by a particle-conserving lattice-gas rule on one \cam\ (say, the
slave) for use by another (the master). To reduce correlations
normally found in the lattice gas (due to the locality of the rule of
motion of the particles), the plane containing the lattice gas is {\sl kicked} after every step;
this kicking consists of adding a random offset to the row and column address
registers ({\tt PRA} and {\tt PCA}) of the slave \cam.  This causes the
entire gas configuration to shift by a large random amount (much as in the ``hyperspace'' option in the game
{\sl Asteroids}) at each step, in addition to its normal dynamics, and nearly
obliterates the local correlations that would be exhibited by an unkicked
lattice gas used as a source of noise.  The enclosed source file \id|CAM1RAND.4TH|, intended
to be included in experiments requiring random numbers, sets up the two-\cam\
configuration, loads the lattice gas rule for \cam\ 1, and redefines the run cycle so
as to cause stepping and kicking of the lattice gas in \cam\ 1 each time a
step is taken by the master \cam\ 0 .  The file also defines pseudo-neighbors
\id|RAND0|, \ldots, \id|RAND3|, available in \cam\ 0 under the minor
neighborhood selection \id|&/USER|, and intended to be connected (via the user
connector) to the four bit-planes of \cam~1.  The enclosed
experiment file \id|CANIS2.EXP| makes use of \id|CAM1RAND.4TH| to generate random numbers
for a simulation of the canonical-ensemble Ising model.

\medskip

Of course, kicking can also be performed on a single \cam.  This
approach is illustrated in the accompanying annotated experiment
\id|CANIS1.EXP|, which is similar to \id|CANIS2.EXP| but uses only one
\cam--- containing both the lattice gas and the Ising configuration.
The disadvantage of using only one \cam\ is that---since the kicking
shifts all bit-planes of a \cam\ card by the same amount---any information that one
wishes not to be kicked (in this case the Ising configuration) must be
swapped out of \cam\ (into a buffer in the \pc) each time a kick is
performed.  This slows the simulation several-fold with respect to a one-\cam\
system without kicking (which however has significantly distorted
behavior due to the correlations in the ``random'' numbers) or to a two-\cam\
system with one \cam\ dedicated to the kicked lattice gas.

