  % -*- Mode:TeX -*-
\chapter{Resources}\label{resources}

The present chapter briefly reviews---directly or through pointers to
other material---the hardware resources of \cam\ and the software
commands that control them.  Most of these resources are adequately
discussed elsewhere (the previous and following chapters of this
manual, the glossary, the \cambook, and the annotated experiment
files).  Here we provide connecting material and
some technical details.

\section{The lookup tables}\label{lookup}

\begin{figure}[htb]
 $$
{\setlength{\tabcolsep}{0pt}
 \renewcommand{\arraystretch}{0.5}
 \def\addr#1{$\langle{\rm addr}\hfill#1\rangle\longrightarrow$}
 \begin{tabular}{c}
 \addr{0}\\ \addr{1}\\ \addr{2}\\ \addr{3}\\ \addr{4}\\
 \addr{5}\\ \addr{6}\\ \addr{7}\\ \addr{8}\\ \addr{9}\\[1ex]
 \addr{10}\\ \addr{11}
 \end{tabular}}\relax
 \raisebox{-3.5ex}{\begin{tabular}{|c|c|c|c|}\hline
  \rule{0pt}{30ex} & & & \\\hline
  \multicolumn{1}{c}{$\Big\downarrow$}&
  \multicolumn{1}{c}{$\Big\downarrow$}&
  \multicolumn{1}{c}{$\Big\downarrow$}&
  \multicolumn{1}{c}{$\Big\downarrow$}\\
  \multicolumn{1}{c}{\tt PLN0} &
  \multicolumn{1}{c}{\tt PLN1} &
  \multicolumn{1}{c}{\tt AUX0} &
  \multicolumn{1}{c}{\tt AUX1} 
 \end{tabular}}
 $$
  \caption{The lookup table of \cama\ (for that
of \camb, replace {\tt 0} and {\tt 1} in the output labels by {\tt 2} and {\tt 3}).
The twelve address lines can be connected to a variety of signals.}
 \label{fig.lookup-table}
\end{figure}

As explained in Chapter 7 of the \cambook, \cam\ consists of {\sl two}
independent halves, called \cama\ and \camb, which may be used
separately or coupled together.  Each half, consisting of two
bit-planes, has its own lookup table (Figure
\ref{fig.lookup-table})---whose main function is to to turn the data
currently in the bit-planes into new data according to a specified
dynamics\index{Lookup table}.  Each entry of this table consists of
four bits; thus, the table can be visualized as four {\sl columns} of
data.  The table contains 4096 (=$2^{12}$) entries (or {\sl rows}); a
particular entry is accessed by a given combination of \id|0|s and
\id|1|s on the table's 12 address lines.\index{Lookup table/row}
\index{Lookup table/column}  Depending on the currently
selected neighborhood, the twelve bits that make up a lookup table's
{\sl input} may come from any of several sources (Table
\ref{eq.neigh}):
      \begin{itemize}
        \item Some signals  originate from within the \cam\ card, and are
extracted from
          \begin{itemize}
            \item The two bit-planes of this particular half \cam.
            \item The two bit-planes of the other half \cam.
            \item The horizontal and vertical address of a cell ({\sl
          spatial phases}\index{Spatial phases}).
          \end{itemize}
        \item Some signals have an external origin:
          \begin{itemize}
            \item {\sl Temporal phase}\index{Temporal phases} signals
are supplied by the \pc; they are generated in real-time by the \cam\
software as specified by the {\sl run cycle} (Section \ref{run-cycle}).
            \item Signals coming from the most disparate sources can
be fed to the {\sl user connector}\index{User connector} (Chapter
\ref{user}); these sources may include other \cam\ cards, special-purpose
hardware attachments, a video camera, etc.
          \end{itemize}
        \item The above signals are used for deciding which table
entry to {\sl read}, instant by instant, during a simulation.  There
are also provisions for deciding in which table entry to {\sl write}
something---but this only concerns the low-level software routines
in charge of downloading the tables' contents.
      \end{itemize}
        \noindent In turn, the four bits that appear at the table's {\sl output}
may go to different destinations:
      \begin{itemize}
        \item The first two columns of a table (also called {\sl
regular} tables\index{Lookup table/regular}) are generally used for
determining the new state of the two bit-planes of the corresponding
\cam\ half.
        \item The remaining two columns ({\sl auxiliary}
tables\index{Lookup table/auxiliary}) may
          \begin{itemize} 
            \item Be left unused.
            \item Replace the regular tables
in determining the new state of the two bit-planes (Section \ref{doubleup}).
            \item Be used for computing an output
function\index{Output function} (Section \ref{show-function}),
to be used in conjunction with the color map.
          \end{itemize}
      \end{itemize}

\par\noindent One of the functions of the \cam\ Forth software is
to provide simple and intuitive ways to exercise the above options.

\section{Neighborhoods}\label{neighborhoods}

The \cam\ neighborhoods provide a way of physically connecting
different subsets of signals to the tables' inputs, and attaching
appropriate mnemonic names to the signals so selected, as explained in
Chapter 7 of the \cambook.  The generally useful neighborhood
assigments\index{Neighborhood assignment}\index{Lookup table/address-line assignment} are listed in the following
tables.\footnote
        {There happen to be a few more neighborhoods available.  One is
used for the expanded view provided by the \cxp's \keyx\ key; two others
are components of {\tt N/MOORE} and {\tt N/VONN}, with lines 6, 7, 8,
and 9 left as user neighbors.  All neighborhoods are listed in the
glossary.}

 \begin{equation}\label{eq.neigh}\tt
   \setlength{\tabcolsep}{0.2em}
 \begin{tabular}{l}
  \begin{tabular}{|c||l|l|l|l|l|l|}
\multicolumn{7}{l}{\sc major neighborhoods}\\\hline
\rm addr
    &\multicolumn{1}{c|}{N/MOORE}
            &\multicolumn{1}{c|}{N/VONN}
                    &\multicolumn{1}{c|}{N/MARG}
                    &\multicolumn{1}{c|}{N/MARG-PH}
                            &\multicolumn{1}{c|}{N/MARG-HV}
                                    &\multicolumn{1}{c|}{N/USER}\\\hline\hline
0 ==&CENTER &CENTER &CENTER &CENTER &CENTER &CENTER\\\hline
1 ==&CENTER'&CENTER'&CENTER'&CENTER'&CENTER'&CENTER'\\\hline
2 ==&S.EAST &EAST'  &CW     &CW     &CW&$\langle$\rm user 2$\rangle$\\\hline
3 ==&S.WEST &WEST'  &CCW    &CCW    &CCW&$\langle$\rm user 3$\rangle$\\\hline
4 ==&N.EAST &SOUTH' &OPP    &OPP    &OPP&$\langle$\rm user 4$\rangle$\\\hline
5 ==&N.WEST &NORTH' &CW'    &CW'    &CW'&$\langle$\rm user 5$\rangle$\\\hline
6 ==&EAST   &EAST   &CCW'   &CCW'   &CCW'&$\langle$\rm user 6$\rangle$\\\hline
7 ==&WEST   &WEST   &OPP'   &OPP'   &OPP'&$\langle$\rm user 7$\rangle$\\\hline
8 ==&SOUTH  &SOUTH  &$\langle$\rm user 8$\rangle$&PHASE  &HORZ
   &$\langle$\rm user 8$\rangle$\\\hline
9 ==&NORTH  &NORTH  &$\langle$\rm user 9$\rangle$&PHASE' &VERT
   &$\langle$\rm user 9$\rangle$\\\hline
  \end{tabular} \\
                \\
  \begin{tabular}{|c||l|l|l|l|}
\multicolumn{5}{l}{\sc minor neighborhoods}\\\hline
\rm addr&\multicolumn{1}{c|}{\&/CENTERS}
                  &\multicolumn{1}{c|}{\&/PHASES}
                           &\multicolumn{1}{c|}{\&/HV}
                                  &\multicolumn{1}{c|}{\&/USER}\\\hline\hline
10 ==   &\&CENTER &\&PHASE &\&HORZ&$\langle$\rm user 10$\rangle$\\\hline
11 ==   &\&CENTER'&\&PHASE'&\&VERT&$\langle$\rm user 11$\rangle$\\\hline
  \end{tabular}
 \end{tabular}
 \end{equation}

Neighbor assignments have both a {\sl software} and a {\sl hardware}
effect.\index{Neighborhood assignment/software effects}\index{Neighborhood
assignment/hardware effects} The software effect is to make the
appropriate neighbor words available---and mask out the others, for
your protection.  The hardware effect, which takes place immediately,
is to wire the appropriate signal sources to the specified table
inputs.

\noteskip

{\small If you are perverse you can defeat the software protection---which
is based on the use of vocabularies. For example, the word \id|S.EAST|
belongs to a small, specialized vocabulary which is included in the search order
only when the \id|N/MOORE| assignment is in effect. You can make
a duplicate of this word in the main {\sl Forth} vocabulary, as follows
        \begin{verbatim}
    N/MOORE               : S.EAST
                   S.EAST ;\end{verbatim}
        Now, if you say
        \begin{verbatim}
    N/VONN\end{verbatim}
        and try to define a rule in terms of \id|S.EAST| (which is meaningful
only in the \id|N/MOORE| neighborhood), the software will let you
do it without warning.

}

\noteskip

In certain circumstances it is meaningful to use a rule that uses two
different neighborhoods (one at a time; say, on alternating steps)
depending on the value of a phase bit that is visible in both
neighborhoods (Section \ref{doubleup}).  In this case, the neighbor
declarations that have been used (for their software effects) in
different places in the definition of the rule must be issued again in
the appropriate sequence (for their hardware effects) by the run cycle
that drives the simulation.\index{Neighborhood assignment/software
effects}\index{Neighborhood assignment/hardware effects}

\medskip

In essence, the software effect of \id|N/MOORE| is just to introduce,
say, \id|S.EAST| as a mnemonic for ``table input no.\ 2;'' this
mnemonic can be applied by you indifferently to the table of \cama\ or
that of \camb---which have identical structure.  On the other hand,
the hardware effect of \id|N/MOORE| is restricted to the currently
selected \cam\ half (specified by the command \iprog{CAM-A} or
\iprog{CAM-B}); however, the command \iprog{CAM-AB}---which is the
default one---lets subsequent neighborhood assignments go to {\sl
both} \cam\ halves at once (until overridden by \id|CAM-A| or
\id|CAM-B|).  Moreover, if you have more that one \cam\ card, the
neighborhood declaration's hardware effect will apply only to the
currently selected card (cf.\ Section \ref{multiple}).

Many pairs of neighbor words (such as \id|CENTER| and \id|CENTER'|, or
\id|HORZ| and \id|VERT|) are accompanied by a {\sl joint} version, which
is always a two-bit variable.  The least significant bit is the value of
the first element of the pair, the next bit that of the second element
(in arithmetic notation, ``the first bit plus twice the second'').
Thus, \idpad{\tt CENTERS}={\tt CENTER}+2\by{\tt CENTER'}\idpad, and
\idpad{\tt HV}={\tt HORZ}+2\by{\tt VERT}\idpad.

\medskip

By default (after \iprog{NEW-EXPERIMENT}) the major neighborhood assignment
is \id|N/USER| and the minor one \id|&/USER|: the corresponding table
address lines are connected to input pins on the user connector via a TTL
buffer. If you are curious, a {\sl floating} TTL input (i.e., one that is left
unconnected) looks like a \id|1|---not like a \id|0|; thus, if you
forget to make a neighborhood assignment your rule will run as if all
the neighbors are in the \id|1| state.\footnote
    {Except for {\tt CENTER} and
{\tt CENTER'} (lines 0 and 1), which are internally
connected to the bit-planes in all neighborhoods---including {\tt N/USER}.}

{\sl Note that, after you have explicitly made a minor neighborhood
assignment, you cannot make a new one without explicitly making a new
major assignment first}\index{Neighborhood assignment/order} (even if this is the same as the previous one).
Thus, if during the course of an experiment you want to change the minor
neighborhood from \id|&/CENTERS| to \id|&/PHASES|, you cannot say
        \begin{verbatim}
    N/MOORE &/CENTERS
    ...
    &/PHASES\end{verbatim}
        You have to say
        \begin{verbatim}
    N/MOORE &/CENTERS
    ...
    N/MOORE &/PHASES\end{verbatim}
        Moreover, a new major assignment also resets the previous
{\sl minor assignment}. Thus, after
        \begin{verbatim}
    N/MOORE &/CENTERS
    ...
    N/VONN\end{verbatim}
        the current minor assignment is no longer \id|&/CENTERS|
but the default \id|&/USER|.

\section{Table generation}\label{table-generation}

\Cam\ Forth encourages you to give a {\sl structural} description for
your cellular-automaton rules, using an algorithmic language and
appropriate mnemonics; this description is then translated by the
software into a lookup table.  The best way to fully understand the
magic that turns a \cam\ Forth rule descriptor in the \pc\ into a
cellular-automaton rule in the \cam\ card is to have a conceptual
picture of that translation process.\index{Lookup table/generation}

\medskip

In \cam\ Forth, neighbor names such as \id|NORTH|, \id|SOUTH|, etc.
are used to describe the new state of a cell as a logical
function of neighbors, and thus specify a cellular-automaton
rule.  ``Column dispatcher''\index{Lookup table/column dispatcher} words such as \id|>PLN0| and \id|>AUX0|
specify which column of the lookup table each part of the result
goes to.  \id|MAKE-TABLE| is then used to evaluate a rule for all
possible neighborhood configurations, in order to generate new entries for
all of the indicated subtables.  For example,
        \begin{verbatim}
                                  : TRACE
          CENTER CENTER' OR >PLN1 ;
    MAKE-TABLE TRACE\end{verbatim}
        would produce a table-column for plane 1
instructing each bit of this plane to become a \id|1|
if the bit itself or the corresponding one on plane 0 is a \id|1|. As a result,
during the course of the simulation plane 1 will contain a ``check mark''
for every cell whose bit in plane 0 has {\sl ever} been on, even if it was
subsequently turned off (assuming we start with a clear plane 1).

\id|MAKE-TABLE| goes through all 4096 possible neighborhood
configurations involving 12 neighbors.  For each configuration, it assigns
appropriate values to the neighbor words, which are really
table-compilation variables.  It also assigns a default result for the
table entry being constructed: the old entry.  Words such as 
\id|>PLN0| each change one bit of the table entry; then the entry is
stored in the table and the next configuration is considered.  Words such
as \id|PLN0| and \id|AUX0| can be used to read the current value of the
corresponding bit of the entry---either the old value, or the value last
assigned with \id|>PLN0|, etc.  Thus, one can even generate tables as a
function of their previous contents.

\subsection{Details}\label{table-details}

The following notes are chiefly meant for the advanced user.

\medskip

The twelve bits that collectively make up the input to a lookup table
can be read (in binary) as a number ranging from 0 through 4095 (in
decimal).  During table compilation \cam\ Forth's internals use a
dedicated variable, called \id|X|, to point at a given entry of the
table.  Another variable, called \id|Y|, serves as a scratchpad for
constructing the entry itself; the eight least significant bits of
\id|Y| correspond to the eight columns of the lookup tables (the four
columns of \cama's table and the four columns of \camb's).

The command \iprog{MAKE-TABLE}$\langle$table descriptor$\rangle$ sets
up a loop where \id|X| starts at 0 and runs all the way up to 4095.
For each value of \id|X|, the scratchpad \id|Y| is initialized with
the present contents of the {\tt X}-th table entry; then the
table-descriptor word is executed---and this usually affects some of
the bits of \id|Y|; finally, the new value of \id|Y| is stored back in
the \id|X|-th entry.  During the execution of the table descriptor,
the words responsible for changing some bits of \id|Y| are the
``column dispatcher'' words \id|>PLN0|, \id|>PLN1|, \id|>AUX0|,
etc.\index{Lookup table/column dispatcher} (A word such as \id|PLN0| puts on the
stack the current value of that bit of \id|Y| that would be
overwritten by \id|>PLN0|.  Thus, one can explicitly use the current
contents of the lookup table in generating its new contents.) It is in
this way that \id|MAKE-TABLE TRACE| will fill {\sl all} of column
\id|PLN1|, without changing the contents of the other columns.

\medskip

Ultimately, a table-descriptor specifies how \id|Y| should be changed as
a function of \id|X|.  The bits of \id|X| represent a given neighborhood
configuration, and the bits of \id|Y| represent the values that we want
the tables to return when that configuration is encountered during the
scanning of the bit-planes.  However, instead of explicitly handling
\id|X| and \id|Y|, we use mnemonic words that refer to particular bits
of \id|X| and \id|Y|.  The words that refer to bits of \id|Y| are the
column dispatchers, as we have just seen; the words that refer to bits
of \id|X| are the neighbor and pseudo-neighbor words, such as \id|NORTH|
and \id|PHASE|.


In what follows, we'll suppose that \id|MAKE-TABLE| is in the process
of generating entry no.\ 5 of the tables, for which \id|X| has the value (in binary)
\id|000000000101|.  What state of a cell's neighborhood would yield this
combination of bits as an input to the lookup table---and thus would
produce, as a result of the lookup, the contents of this entry?

If the nine outputs (a 3\by3 window) from each plane were permanently 
wired as inputs of the lookup table, this question could be answered
once and for all. However, since the overall number of plane outputs is 36
(nine neighbors times four planes)\footnote
        {And there are many more signals on the board that one might on
occasion want to feed to the table.}
        and the number of table inputs is only 12, a selection must be
made.  As explained in the previous section, the various \cam\
neighborhoods provide different selections (by means of hardware
multiplexers), and for each selection the wiring (and thus the
meaning) of the 12 input lines changes correspondingly: some
way is needed to automatically keep track of all of this.

\medskip

Suppose the neighborhood assignment is \id|N/MOORE|.  A {\sl neighbor
word}\index{Neighbor word} such as \id|S.EAST| is made available by
the software only in a neighborhood where the corresponding
``south-east'' plane output is wired to the table.  This word knows to
which of the twelve available address positions this output is wired: as
you can see from Table \ref{eq.neigh}, in \id|N/MOORE| the \id|S.EAST|
neighbor indeed appears as address line 2.  With this information,
\id|S.EAST| looks at the current value of \id|X|, namely {\tt
000000000$\underline{\tt1}$01}, and returns the bit in position 2 of
this string (count from the right, starting from 0)---which we have
underlined. In this case, the phrase
        \begin{verbatim}
    S.EAST >PLN0\end{verbatim}
        will extract bit 2 from \id|X| and put it in the ``plane-0'' bit of \id|Y|.
If you said \id|CCW| instead of
\id|S.EAST|, you'd get an error message, since the neighbor word
\id|CCW| is inaccessible in the \id|N/MOORE| context. If you said
        \begin{verbatim}
    LIFE\end{verbatim}
        (where \id|LIFE| is as defined in Figure \ref{fig.barelife}),
        bits 0 and 2--9 of \id|X| would be added (by \id|8SUM|), giving
2 as a result; this 2 as an argument to the case statement
(also in Figure \ref{fig.barelife}) would cause \id|CENTER| to extract
bit 0 of \id|X|; the result, namely \id|1|, would be placed by 
\id|>PLN0| in the corresponding bit-position in \id|Y|, so that when
\id|Y| is copied to the table, this \id|1| would appear in
column \id|PLN0| of entry 5.

\medskip

Note that columns \id|PLN0| and \id|PLN1| belong to \cama, while
\id|PLN2| and \id|PLN3| belong to \camb.  When we compute a bit as a
function of the entry address \id|X|, we obtain a different rule
depending on whether this bit is sent to a table-column belonging to
\cama\ or \camb; all the rest of the above construction is independent
of whether we are programming \cama\ or \camb.  In particular, the
neighbor word \id|S.EAST| knows that it refers to input 2 of a table,
but does {\sl not} know whether we have in mind the table for \cama\ or
that for \camb.  Thus, to make \id|LIFE| run on \camb\ it is sufficient
to replace the \id|>PLN0| in its definition by \id|>PLN2|: the neighbor
names do not have to be changed. 

Though it is possible to use a single table descriptor
for filling all of the table-columns at once (all eight bits of \id|Y|
for each value of \id|X|), if \cama\ and \camb\ use different
neighborhoods it is usually easier to write separate table descriptors 
for the two \cam\ halves.

\section{Phases}\label{phases}

Besides the contents of the bit-planes and signals provided through
the user connector, there are other quantities, called {\sl
phases}, that may be
used as lookup-table inputs (cf.\ Table \ref{eq.neigh} and
\cf{11.1,11.2}).  The {\sl temporal} phases\index{Temporal phases}
are transmitted to \cam\ by the software, and remain constant for the
duration of a step (thus the same value is seen by all cells); the
{\sl spatial} phases\index{Spatial phases} are generated by \cam's
address circuitry, but their ``phasing'' with respect to the origin of
the array may be controlled by the software.  To each phase quantity
there corresponds a {\sl pseudo-neighbor} used during table
generation (see below).

        What the user software reads or writes is not directly the
hardware bits corresponding to the temporal phases or the ``phasing'' of
the spatial phases, but shadows of these bits in the \pc\
memory, which we shall call {\sl pseudo-variables}; lower levels of the
software take care of synchronizing the transfer of these data to \cam\
at each step.

The following words are used for controlling phase pseudo-variables:
        \begin{verbatim}
    <&PHASE>
    <&PHASE'>
    <PHASE>
    <PHASE'>
    <TAB-A>
    <TAB-B>

    <ORG-H>
    <ORG-V>\end{verbatim}
        To set to \id|1|, say, the bit corresponding to \id|&PHASE| you say
        \begin{verbatim}
    1 IS <&PHASE>\end{verbatim}
        (Since only the least significant bit is used, the strange-looking phrase
            \begin{verbatim}
    37 IS <&PHASE>\end{verbatim}
        would give the same result.)
To read whatever value you last gave to this pseudo-variable (in case you
didn't bother to keep a record) you just say \id|<&PHASE>|, and its
value will be pushed on the stack (as the least significant bit
of a cell containing zeros in all other positions). Thus, if you
want to complement the value of this phase you can say
        \begin{verbatim}
    <&PHASE> NOT IS <&PHASE>\end{verbatim}

\medskip

The above pseudo-variables are naturally grouped in pairs, and the two elements
of a pair can be jointly controlled by the following words
        \begin{verbatim}
    <&PHASES>
    <PHASES>
    <TAB-AB>

    <ORG-HV>\end{verbatim}
        which return a two-bit value on the stack and are assigned a two-bit
value by the \id|IS| construct. In each case, the least significant bit corresponds to the
first element of the pair. Thus
        \begin{verbatim}
    2 IS <&PHASES>\end{verbatim}
        is equivalent to
        \begin{verbatim}
    0 IS <&PHASE>
    1 IS <&PHASE'>\end{verbatim}
        Note that the phase bit corresponding to \id|<TAB-A>| (and similarly for \id|<TAB-B>|)
never appears as one of the 12 inputs of \cama's lookup table; rather, it decides whether
the regular or the auxiliary tables are to be used for determining a cell's new state
(Section \ref{doubleup}).

\medskip

One more pseudo-variable with a function somewhat analogous to that of a phase
is controlled by the words \id|SHOW-STATE| and \id|SHOW-FUNCTION| (see Section \ref{show-function}).

\medskip

During table generation, the pseudo-neighbor words referring to those phase signals
that may appear as lookup-table inputs (cf.\ Table \ref{eq.neigh}) are
        \begin{verbatim}
    &PHASE
    &PHASE'
    PHASE
    PHASE'

    HORZ
    VERT\end{verbatim}
        which return one-bit values, and their joint versions
        \begin{verbatim}
    &PHASES
    PHASES

    HV\end{verbatim}
        which return two-bit values.

\subsection{Spatial phases}\label{spatial phases}

As explained in \cf{11.1}, the \cam\ hardware assigns values of
the spatial phases\index{Spatial phases} to each cell of the cell array; namely, \id|HORZ| takes
on alternating values \...{\tt 01010}\...\ on consecutive cells of a row,
and \id|VERT|  alternating values \...{\tt 01010}\...\ on consecutive
cells on a column. In most situations these values are not explicitly fed to the lookup
table, but affect what is fed to it by controlling which three of the eight
cells that surround a given center cell will be seen as its ``Margolus neighbors'' \prog{OPP},
\prog{CW}, and \prog{CCW} (the fourth Margolus neighbor, \prog{CENTER}, is the cell
itself, and is always available). 

By means of \id|<ORG-H>| and \id|<ORG-V>| the user can only control the ``phasing''
of these phases, i.e., the values that they will take on the top-left
cell of the array---and consequently which of the four possible ways of
partitioning the array into 2\by2 Margolus blocks is active during a given step.

Explicit use of the pseudoneighbors \id|HORZ| and \id|VERT| 
(or their aliases \id|&HORZ|, \id|&VERT|) is necessary only if
one wants to use the ``absolute'' Margolus neighbors \id|UL|, \id|UR|, \id|LL|,
and \id|LR| (cf.\ \cf{12.5} and the Glossary), or if one wants to make use
of horizontal or vertical parities (even or odd rows, even or odd columns)
outside of a Margolus-neighborhhod context.

\medskip

We mentioned in Section \ref{magnify} that the grid\index{Spatial grid}
made visible on the \cam\ screen in {\sl Expanded
mode}\index{Control-panel commands/expand, grid} partitions the screen
into 2\by2 blocks; these blocks coincide with the current Margolus
blocks (as determined by \id|<ORG-H>| and \id|<ORG-V>|).  Since the
values of {\sl all \pc-controlled variables relevant to the next step}
(in particular, the phases) are loaded into \cam\ immediately after the
execution of the previous step (cf.\ Section \ref{macrosteps}), whenever
you stop the simulation the Margolus blocks that you see on the {\sl
Expanded mode} screen are, in normal circumstances, those that will be
used during the {\sl next step}.  In other words, during rule debugging
you can ``preview'' (and possibly modify) the Margolus partitioning
before using it.

\section{Using precompiled tables}\label{tab-files}

\index{Lookup table/precompiled}The translation of a table descriptor into
one or more columns of a lookup table may take from a fraction of a
second to several seconds, depending on the speed of your \pc, the
number of table columns involved, and the complexity of the description
algorithm.  Once an experiment has been thoroughly debugged, it may occasionally be
convenient to save the tabular version of the rule on
a disk file (default extension: \id|TAB|), and load the tables
directly from this ``memory dump'' whenever the experiment has to be performed.
This eliminates annoying waiting times in canned demos.
The following commands are used for this purpose at
the \cxp\ level
 $$
  \begin{tabular}{|l|p{8cm}|} \hline 
   \icp\keytab\ & {\sl Save tables}. Save \cam's lookup tables to a specified file
(default extension: \id|TAB|). The tables occupy 4096 bytes.\\ \hline
   \icp\keybacktab\ & {\sl Load tables}. Load \cam's lookup tables from a
specified file (default extension: \id|TAB|). \\ \hline
  \end{tabular}
 $$
    \noindent Within an experiment file,
the corresponding Forth commands are \prog{TAB>FILE}\index{TAB.FILE{\tt TAB>FILE}} and
\prog{FILE>TAB}\index{FILE.TAB{\tt FILE>TAB}}
(cf.\ \ref{data-files} and glossary).\index{File/table}

Note that the entire contents of the lookup tables (4K nybbles for each
\cam\ half, for a total of 4K bytes) is transfered to or from
disk---even if all you are interested in is a column or two. Note also
that {\sl only} the table is transfered; the hardware neighborhood and any
run cycle must be set up separately.

\section{The color map}\label{color-map}

The {\sl color map}\index{Color map} is a small lookup table with four
inputs (called \iprog{ALPHA}, \iprog{ALPHA'}, \iprog{BETA}, and
\iprog{BETA'})---which for the moment we shall assume come from
bit-planes 0, 1, 2, and 3 (but see below)---and four outputs (called
\id|INTEN|, \id|RED|, \id|GREEN|, and \id|BLUE|) which go directly to the
the four color-monitor beams (cf.\ Section \ref{irgb}).  The color map is
written by the command \iprog{MAKE-CMAP}$\langle{\rm table\
descriptor}\rangle$, where $\langle{\rm table\ descriptor}\rangle$ is a
Forth word that describes the table's contents.
For example, the {\sl IRGB} map of Section \ref{irgb} is described
in an obvious way as follows\index{Color map/IRGB}
        \begin{verbatim}
                                      : IRGB-MAP
                        ALPHA  >INTEN
                        ALPHA' >RED
                        BETA   >GREEN
                        BETA'  >BLUE  ;\end{verbatim}
        The conventions for a color-map descriptor are similar to
those used for a cellular-automaton rule descriptor. For each column
(or output line) of the color-map table we define a function of the
available inputs (\id|ALPHA| etc., which play a role analogous to that
of the neighbor words of Section \ref{neighborhoods}) and specify (by
means of a ``dispatcher'' word such as \id|>INTEN|) what column of the
table this data should go to. The actual shipping of data to the
color-map hardware table is done by the command
        \begin{verbatim}
    MAKE-CMAP IRGB-MAP\end{verbatim}

The default---or {\sl standard\/}\index{Color map/standard}---color
map (Section \ref{std-map}) performs some logic on the planes'
contents before displaying it:
 {\small
        \begin{verbatim}
                                      : STD-MAP
    ALPHA      ALPHA'      AND >RED
    ALPHA      ALPHA' NOT  AND >GREEN
    ALPHA NOT  ALPHA'      AND >BLUE
    BETA       BETA'       OR  >INTEN ;\end{verbatim}

 }
{\small That is, a pixel will be {\sl red} if both the bits in planes 0 and 1
are on; {\sl green} if only plane 0 (plane 0 {\sl and not} plane 1) is on;
and {\sl blue} if only plane 1 is on. Moreover, the {\sl intensity} ``beam''
is turned on if either or both of the bits of planes 2 and 3 are on.

}
\noteskip

In many experiments the individual bit-planes represent distinct
features of the model under study (e.g., dynamical variables,
short-term memory, obstacles, thermal reservoir, etc.).  By attaching
a variety of color maps to the \cxp\ keys (Section \ref{attach}) one
can selectively display those features that are of interest at any
given moment (or mask out irrelevant features, as in the example of
Section \ref{doubleup}).  Several examples of color-map programming at
this elementary level appear in the sample experiments. 

\medskip

The usefulness of the \cam\ color table, especially for real-time
analysis of a simulation, is greatly enhanced by the following two
features
        \begin{itemize}
        \item A real-time event counter is attached to the {\sl Intensity} output
of the color map. Thus, by suitably programming the color map
one can select what events are to be counted.
        \item Instead of just the contents of a cell (i.e., one bit from
each plane), one can feed to the color map the outputs of the {\sl
auxiliary} lookup tables---which in turn can be programmed, just like
the regular lookup tables, to compute an arbitrary function of a
cell's {\sl neighborhood}.  Thus, even as the regular lookup tables 
compute the array's next state as a function of its current state, one
can display (and, if desired, count) by means of the auxiliary tables a {\sl different} function of the
current state.
        \end{itemize}

\section{Displaying an output function}\label{show-function}

\index{Lookup table/auxiliary}The lookup tables used for constructing a
cellular automaton's new state have ``twins''---called {\sl auxiliary
tables}---which see the same neighborhood
data as the regular tables but can be filled with different data
(Section \ref{lookup}).  The auxiliary tables consist of four
``columns,'' namely \id|AUX0| and \id|AUX1| for \cama\ and \id|AUX2|
and \id|AUX3| for \camb, which are filled by dispatcher words
(\id|>AUX0| etc.) just as the regular tables.

\medskip

One use of the auxiliary tables is for display processing, as
explained here; another use for them is as an extension of the regular
tables,\index{Lookup table/regular} as explained in Section
\ref{doubleup}. These two uses are, by and large, mutually exclusive:
if you fill the auxiliary tables with data appropriate for display processing,
you can't expect the same data to be useful as an extension of the regular
tables for updating purposes (though it is conceivable that one
may manage to use some of the auxiliary tables' columns for one purpose
and some for the other).

The command \iprog{SHOW-FUNCTION}\cf{7.7} connects the color map's
\id|ALPHA| input to \id|AUX0| rather than to plane 0 (and similarly for the
other inputs); \iprog{SHOW-STATE} restores the default connection to the
bit-planes:
        $$
        {\tt
        \begin{tabular}{|l@{$\rightarrow$}l|}
        \multicolumn{2}{l}{SHOW-STATE}\\\hline
        {\rm plane 0} & ALPHA \\
        {\rm plane 1} & ALPHA' \\
        {\rm plane 2} & BETA \\
        {\rm plane 3} & BETA' \\\hline
        \end{tabular}
        \quad
        \begin{tabular}{|l@{$\rightarrow$}l|}
        \multicolumn{2}{l}{SHOW-FUNCTION}\\\hline
        AUX0 & ALPHA \\
        AUX1 & ALPHA' \\
        AUX2 & BETA \\
        AUX3 & BETA' \\\hline
        \end{tabular}
        }
        $$
        \noindent Thus, an extra processing stage (represented by the
auxiliary tables) may be inserted between the bit-planes and the color
map.  While the color map can only see one cell at a time when tied
directly to the bit-planes, the auxiliary tables can see a whole
neighborhood (within the constraints of \cam's neighborhoods).\footnote
    {Note that in each half \cam\ the auxiliary and the regular tables
use the same neighborhood.}
    The cascading of auxiliary tables and color map provides substantial
power and flexibility for display and counting purposes.  Good examples
are provided by sections \cf{15.5} and \cf{17.6} of the \cambook\ (the
source code for these examples is included in \cam's software).

\section{Doubling up the lookup tables}\label{doubleup}

A {\sl phase} pseudo-neighbor(cf.\ \ref{phases} and \cf{11.1,11.2})
allows one to cut up the lookup table into two halves, and use one or
the other half at any given step depending on the value that
pseudo-neighbor has for the current step (temporal
phases)\index{Temporal phases} or the current cell position (spatial
phases)\index{Spatial phases}.  There are times when we wish to
alternate in a similar way between two rules but we need a {\sl
full-size} table for at least one of the rules.

The command \iprog{AUX-TABS} instructs the planes to take their new
values from the outputs \id|AUX0|\ldots\id|AUX3| of the auxiliary
tables rather than from the outputs \id|PLN0|\ldots\id|PLN3| of the
regular tables;\footnote
        {See {\tt <TAB-A>} in the glossary for the separate control of
this feature in \cama\ and \camb.}
        the command \iprog{REG-TABS} restores the default situation
(new state from the regular tables). 

\medskip

As an example, let us give an explicit rule for Pomeau's
original version of the {\tt HPP} gas\cf{16.5}. 
The four bit-planes represent particles traveling in four
directions (east, west, south, and north, respectively for planes 0, 1, 2, and 3).
Here a ``macro-step'' (cf.\ Section \ref{macrosteps})
consists of two ``micro-steps:''
        \begin{itemize}
        \item[Step 1:]Each particle takes one step
in the appropriate direction; i.e., all of plane 0 shifts one position
eastward, plane 1 westward, etc.
        \item[Step 2:]The contents of a cell is examined and possibly
modified, without looking at the neighboring cells:  if the cell
contains exactly one particle in plane 0 and one in plane 1, these two
particles are transfered to planes 2 and 3 (intuitively, they collide
and come out at right angles from the original directions); the opposite
transfer occurs if the cell contains exactly one particle in plane 2
and one in plane 3.
        \end{itemize}

 \begin{figure}[tb]
 $$        
        \begin{tabular}{|c|}
        \multicolumn{1}{c}{\small\tt Screen 1 \hfill HPP.EXP \hfill (100\%)}\\\hline
        \begin{minipage}{\scrn}\small\smallskip
        \begin{verbatim}
\ Original HPP rule, with a 2-step cycle              04Jan87tmt
NEW-EXPERIMENT  N/VONN &/CENTERS
                                           : SHIFT
                   WEST EAST' NORTH SOUTH'
                   >AUX3 >AUX2 >AUX1 >AUX0 ;
                                           : COLLIDE
                  CENTER  CENTER' = 
                 &CENTER &CENTER' = AND IF
                     &CENTER &CENTER' ELSE   
                      CENTER  CENTER' THEN
              2DUP >PLN3 >PLN2 >PLN1 >PLN0 ;
MAKE-TABLE SHIFT  
MAKE-TABLE COLLIDE
                                           : HPP-CYCLE
              AUX-TABS STEP  REG-TABS STEP ;
MAKE-CYCLE HPP-CYCLE
\end{verbatim}
        \microskip
        \end{minipage}\\\hline
        \end{tabular}
 $$
 \caption{Source screen for the {\tt HPP}-gas rule, slow version (two-step cycle).}
 \label{fig.hpp-slow}
 \end{figure}

The experiment file of Figure \ref{fig.hpp-slow} shows a compact way of
describing this rule to \cam.  The run cycle \id|HPP-CYCLE| takes care
of switching between regular and auxiliary tables on alternating steps.

\noteskip

{\small The \id|SHIFT| micro-step needs the \id|N/VONN| neighborhood
on both halves of the machine; the \id|COLLIDE| micro-step needs
\id|&/CENTERS| on both halves; since these two neighborhoods are
compatible with each other, we simply program the machine with both of
them.  (Had they been incompatible, we would have used separate
assignments for the two micro-step words, and switched neighborhoods
as well as tables in the run cycle.\index{Neighborhood assignment/in
the run cycle}\index{Run cycle})

In writing this rule, we took advantage of the ambiguity of the
neighbor words with respect to which half of \cam\ they refer to (cf.\
Section \ref{neighborhoods}).  In \id|SHIFT|, note that \id|SOUTH'|
and \id|NORTH| refer to \camb\ (planes 2 and 3 respectively), since
they are dispatched to \id|AUX2| and \id|AUX3|.  A similar game is
played in \id|COLLIDE|.  Take the collision case (when the \id|IF|
condition is true), for example; the neighbor words \id|&CENTER| and
\id|&CENTER'|, which are duplicated by \id|2DUP|, generically refer to
``the other half'' of \cam, and specifically mean the contents of
planes 0 and 1 when they are dispatched to planes 2 and 3, and vice
versa. In \id|COLLIDE|, we could have written more concisely
\par\penalty-100
 \begin{verbatim}
                 ... IF
          &CENTERS ELSE
           CENTERS THEN
        DUP >PLNB >PLNA\end{verbatim}

When \id|SHIFT| is compiled, we will be warned that a word
with the same name already exists. Since we don't use this old meaning
in this experiment, we may ignore the warning.

}

\noteskip

If we used the {\sl IRGB} map for this rule, particles going in
different directions would have different colors.  A more appropriate
color map would give to each cell an intensity proportional to the
number of particles (0, 1, 2, 3, or 4) present in it.  For this we
need {\sl five} levels, but with the \pc's color monitor only four
intensity levels are possible (black, grey, white, bright white)
The following color map makes do by using blue as an intermediate
level between grey and white.

{\small
\begin{verbatim}
                                                 : DENSITY
                 ALPHA ALPHA' BETA BETA' + + + + ;   ( -- 0|1|2|3|4)
       : L0  0 >INTEN  0 >RED  0 >GREEN  0 >BLUE ; \ black
       : L1  1 >INTEN  0 >RED  0 >GREEN  0 >BLUE ; \ gray
       : L2  0 >INTEN  0 >RED  0 >GREEN  1 >BLUE ; \ blue
       : L3  0 >INTEN  1 >RED  1 >GREEN  1 >BLUE ; \ white
       : L4  1 >INTEN  1 >RED  1 >GREEN  1 >BLUE ; \ light white
                                                 : DENSITY-MAP
                      DENSITY { L0 L1 L2 L3 L4 } ;
    MAKE-CMAP DENSITY-MAP\end{verbatim}

}

Note that in this implementation of the \id|HPP| rule each macro-step
consists of two steps.  Using the external connector in order to
synthesize an ad-hoc neighborhood for this rule, it is possible to run
twice as fast: both the shifting and the colliding are done in a single step, as
explained in Section \ref{user}.

\section{The run cycle}\label{run-cycle}

Each step of \cam\ is an activity that takes as an input the current
contents of the bit-planes and returns as an output their new contents.
The bit-planes are always available for this activity; however, any
additional input information must be set up by the software before the
step starts, and any additional output information must be picked up by
the software after the step is over.  As explained in Chapter 11 of the
\cambook, the chief function of the {\sl run cycle}\index{Run cycle} is
to provide a regular, automated service for such ``input delivery'' and
``output pick-up.'' For example, in the experiment of Section
\ref{analysis} the run cycle contains provisions for reading the event
count after each step; in that of Section \ref{doubleup} (see also
\cf{11.13} the run cycle is used to toggle the value of a phase
parameter before each step---so that two distinct dynamics take place in
alternation at even and odd steps.


\subsection{The run cycle as a co-process}\label{coprocess}

A run cycle is a Forth word, say, \id|MY-CYCLE|, consisting of
``segments'' separated by occurrences of \iprog{STEP} (or
\iprog{IDLE}\footnote
        {The word {\tt IDLE} is in all respects identical to {\tt STEP}, except
that it does not update the bit-planes.}),
        used as an ``exit marker'' (see below). The command\index{MAKE-CYCLE{\tt MAKE-CYCLE}}
        \begin{verbatim}
    MAKE-CYCLE MY-CYCLE\end{verbatim}
        makes this word the current run cycle, and executes the first segment
of it (i.e., up to the first occurrence of the marker); as soon as the
marker word itself is encountered, the execution of the run cycle is suspended.

Thereafter, at every tick of the cellular-automaton clock (represented
by the command \iprog{NEXT-STEP})\index{Simulation clock}\index{Step/rate}, execution
of the marker word that had suspended the cycle is resumed (thus, a
step is actually initiated only at this moment) and the following
segment is executed, up to the next exit marker.  Execution of the run
cycle continues in this way, driven by the \id|NEXT-STEP| clock.  If
and when the end of the run-cycle word is reached, execution wraps
around to its beginning; the end of the word is {\sl not} treated as
an exit marker. Thus, the run cycle is a {\sl co-process}, i.e., a
separate process that runs in alternation with the main Forth process
(and has its own program pointer and data stack).

When you again use a \id|MAKE-CYCLE| command, either with the same
run-cycle word or a different one, the current run-cycle process is abandoned and
a fresh one is started. 

Typically, the user will never explicitly issue a \iprog{NEXT-STEP}
instruction, since this instruction is automatically generated by the
\cp---singly by the \keys\ command ({\sl Step\/}), and repeatedly by the
\keyS\ command ({\sl Run\/}\index{Control-panel commands/running
control}).  However, \id|NEXT-STEP| may be useful for ``tracing'' the
behavior of a complex experiment---by single-stepping through it by hand
from the Forth interpreter.

\noteskip

{\small Since the run cycle is executed as a co-process, if you
have to do some low-level debugging of its Forth code (e.g., checking what
is on the stack after each word is executed, perhaps using \id|DEBUG|)
you should execute the run cycle directly as a foreground process.
If you type the name of a run cycle at the Forth interpreter level,
the run cycle will be executed just as an ordinary Forth word. \id|STEP|
knows that in this context it does not have to wait for a \id|NEXT-STEP| prompt.

}

\subsection{Micro-steps and macro-steps}\label{macrosteps}

Usually, one pass through the run cycle will not represent the entire
course of an experiment, but rather a small, self-contained portion of
it lasting a few steps and repeated over and over; in this case the
run cycle can be seen as a way of synthesizing a ``macro-step'' out of
a short sequence of ``micro-steps.''\index{Macro-step}

It is often the case that the macro-step should be regarded as an {\sl
indivisible} sequence of operations (cf.\ the two-step cycle of the
\id|HPP| gas, Section \ref{doubleup}).  It is then useful to have a way to insure that one
macro-step has been completed before analyzing the data produced by it
or starting a macro-step of a different nature.  The word
\iprog{NEXT-CYCLE} runs without stopping from the current marker
position on through whatever portion of the run cycle is left,
wrapping around the end once and finally stopping exactly where
\iprog{MAKE-CYCLE} would have left off, i.e., at the first exit
marker.  On the other hand, the word \iprog{FINISH-CYCLE} stops at the
end of the run-cycle word---without wrapping around.  Thus, the sequence
 {\small
        \begin{verbatim}
                             : SAGA
        MAKE-CYCLE HPP-CYCLE     \ attach MY-CYCLE and run initial part
     99 0 DO NEXT-CYCLE LOOP     \ go 99 times through entire MY-CYCLE 
                FINISH-CYCLE ;   \ terminate the cycle\end{verbatim}

 }

\noindent will execute the macro-step defined by \id|HPP-CYCLE| a total
of 100 times---since initialization and termination, used in this way,
together add up to exactly one pass through the cycle---without any
gap or overlap. Specifically, in the {\tt HPP}-gas rule of Section
\ref{doubleup}, the ``initialize'' part executes
        \begin{verbatim}
    AUX-TABS\end{verbatim}
        each iteration of the loop executes
        \begin{verbatim}
              STEP  REG-TABS STEP
    AUX-TABS\end{verbatim}
        and the ``terminate'' part executes
        \begin{verbatim}
              STEP  REG-TABS STEP\end{verbatim}
        The advantage of letting \iprog{MAKE-CYCLE} execute all the
preparatory operations for the first step, stopping just before starting
the step (and similarly for each occurrence of \iprog{NEXT-CYCLE}), is
that the state of the whole machine can be examined exactly as it would
be during the execution of the step. 
If you show the expanded view (using \keyx) with a grid, the
position of the grid will reflect the spatial-phase origin to be used
in the step; the color map will be the one that will be used
during the step, etc. 

\noteskip

 {\small If the auxiliary
tables are filled with a copy of the regular tables and the machine is
left idle after \id|MAKE-CYCLE|, the display will show the state of the
planes as they are before taking the first step. Typing
\iprog{SHOW-FUNCTION} at this point will show the state of the planes as they would be
if the step were executed (cf.\ Sections \ref{show-function} and
\ref{what-when}), {\sl but without actually altering the planes\/}; in
fact, typing \iprog{SHOW-STATE} will show again the actual state of the
planes. In this way one can have at any moment a non-destructive
preview of the exact action of a step, and compare at leisure the
``before'' with the ``after''---which may be useful for debugging
an experiment. 

 }

\section{The event counter}\label{counter}

Since the event counter\index{Event counter} is permanently connected
to the color map's {\sl Intensity} output, the main issue is how to
characterize the events to be counted and route them to this output.
This is done by programming the color map and, if desired, the auxiliary
tables---as explained in the previous two sections.

The software machinery for reading the event counter is adequately
illustrated, for most circumstances, by the example of Section \ref{analysis}.  Should a more
sophisticated use of the event-counter pipeline be necessary, refer to
the information given under \iprog{EVENT-COUNT} in the glossary.

\medskip

Note that a count of 65,536 (256\by256) is just one too many to be contained
in a 16-bit counter. Instead of distinguishing a count of 0 from a count of
65,536 by means of an overflow bit, \cam\ uses a flip-flop that is set when
{\sl at least one event} occurred (thus, this flip-flop is set for
any count from 1 through 65,536). This flip-flop has separate service routines
that are used by the ``stop-on-event'' facility, discussed under \iprog{EVENT-STOP}
in the glossary; this flip-flop is also of course used by \iprog{EVENT-COUNT}
when necessary.

\subsection{What is counted---and when}\label{what-when}

By contrasting two trivial situations, the following remarks will help
you construct a mental model of what actually goes on during display and counting.

\medskip

When the four bit-planes are directly connected to the color map (this
is the default situation, explicitly selected by the command \iprog{SHOW-STATE}),
a pixel appears on the screen at the same time as the corresponding cell is accessed by the
updating machinery, and displays the contents of the cell as of {\sl before}
the updating. Thus, at the end of an active step the screen will have
displayed what the state of the array was just before that step. If you
program the intensity bit to count the number of \id|1|s in a plane
(as in Section \ref{analysis}) and take {\sl a single}, isolated step from a given initial configuration,
the following will happen:
        \begin{itemize}
        \item During the 1/60-th of a second in which the step is performed,
the screen will show the given configuration and the counter will count
the number of \id|1|s in this configuration---while the updating machinery
constructs a new configuration.
        \item During each of the following 1/60-ths of a second the
system will take an {\sl idle} step: the display will repeatedly show
the newly constructed (now current) configuration; the counter will
remain stopped; and the updating machinery will stay idle.
        \end{itemize}
        If you read the hardware counter at any moment now, its value
will refer to what was counted during the active step---and thus to the
initial configuration rather than to the one now appearing on the
screen.

\medskip

Suppose we are running the \id|PARITY| rule\cf{4.2}, defined by
        \begin{verbatim}
    CAM-A N/VONN  
                                       : 5HOOD
          CENTER NORTH SOUTH WEST EAST ;
                                       : PARITY
           5HOOD XOR XOR XOR XOR >PLN0 ;
    MAKE-TABLE PARITY\end{verbatim}
        Let us fill column 0 of the auxiliary tables with
exactly the same function of the neighbors, i.e.,
        \begin{verbatim}
                                       : AUX-PARITY
           5HOOD XOR XOR XOR XOR >AUX0 ;
    MAKE-TABLE AUX-PARITY\end{verbatim}
        so that the new value for the bit of plane 0,
(which comes out of \id|PLN0|) appears in duplicate
at \id|AUX0| (cf.\ end of Section \ref{macrosteps}).

Now, let's say \iprog{SHOW-FUNCTION} and run the simulation.  The end
result is simply that during each step the color map will see the {\sl
terminal} state of the array rather than the {\sl initial} one.
Using, for instance, the {\sl IRGB} map, the event
counter will give us the number of \id|1|s present in plane 0 at the
{\sl end} of a step---rather than at the {\sl beginning} of the step
as in Section \ref{analysis}.

\section{Pattern, data, and table files}\label{data-files}

Pattern files\index{File/pattern} can
be created, edited, saved, and loaded from the \cp, as explained in
Chapter \ref{pledit}.  They can be automatically recalled and loaded by
an experiment file, as in Section \ref{props}; see also
\prog{FILE>PL}\index{FILE.PL{\tt FILE>PL}} and \prog{FILE>IMAGE}\index{FILE.IMAGE{\tt FILE>IMAGE}} in the glossary.

\medskip

If several pattern files will be needed in the course of a demo,
they should all be mentioned in \iprog{OPEN-PATTERN} statements,
usually at the beginning of the experiment. If you say, outside
of a colon definition,
        \begin{verbatim}
    OPEN-PATTERN FIG1.PAT
    OPEN-PATTERN FIG2.PAT
        ...
    OPEN-PATTERN FIGn.PAT\end{verbatim}
        each file is in turn assigned a file control block, opened,
and made the current {\sl pattern} file (i.e., the file that
operations such as \prog{PL>FILE}\index{PL.FILE{\tt PL>FILE}} and \prog{FILE>PL}\index{FILE.PL{\tt FILE>PL}}
use as source or destination).  At the end of this sequence, all $n$
files will have been assigned a control block and will be open (but
only the last one will be the ``current pattern file'').

After this, and at any moment in the course of the experiment,
whenever the Forth word \id|FIG2.PAT| is executed (either from the
interpreter or inside a colon definition) the corresponding pattern
file is made the current pattern file. There is no need to close a
pattern file, even if new data has been written to it.

\medskip

The command \iprog{OPEN-DATA} is used in a similar way for making {\sl
data files}\index{File/data} accessible and/or current.  The file
control block for a data file includes a pointer that is used for
sequential access through the file, and pointer operations (see
\iprog{DATA-PTR} and \iprog{GET-DATA}, and \iprog{PUT-DATA} in the
glossary, for details) always refer to the current data file.

Typical uses for a data file are
        \begin{itemize}
        \item To accumulate selected analysis data produced by a simulation (Section \ref{analysis}).
        \item To provide a sequence of input parameters (e.g., phases) for successive
steps of an experiment.
        \item To recall data generated by a previous run of an experiment, in order
to compare or correlate them, step by step, with those generated by the current run.
        \end{itemize}

\medskip

In a similar way, for the table files (cf.\ Section \ref{tab-files}) we have the words
\iprog{OPEN-TABLE}, \id|TAB>FILE| and \id|FILE>TAB|.\index{File/table}

\section{Initialization}\label{init}

Now that we are familiar with most of the resources of \cam, it will
be useful to know how these resources are affected when the machine is
initialized.\index{Initialization}

The command \iprog{NEW-EXPERIMENT} will
        \begin{enumerate}
        \item Bring the Forth dictionary to its pristine initial state, forgetting
any definitions that were subsequently loaded from files
or typed at the terminal. 
        \item Clear the 4 bit-planes.
        \item Clear the \cam\ lookup tables.
        \item Load the color-map table with the default color map, \iprog{STD-MAP}.
        \item Reset the display mode to the default one (see \id|LONG?| in the glossary).
        \item Select \cam\ 0 (if more than one \cam\ card is present).
        \item Set up to apply hardware effect of neighborhood assignments to both halves of
\cam\ (i.e., execute \iprog{CAM-AB}).
        \item Select the major neighborhood \prog{N/USER}\index{N.USER{\tt N/USER}} and the
minor neighborhood \id|&/USER|.\index{USER.{\tt \char"26/USER}}
        \item Reset the run cycle to \iprog{STEP}.
        \item Flush and reset the event-counter pipeline.
        \item Turn off \cxp\ options (grid, magnification, dot mode, cage mode, etc.).
        \item Reset default \id|TAB|, \id|PAT|, and \id|DAT| files to be undefined.
        \end{enumerate}

On the other hand, the contents of the plane buffers and of the cage
are not affected by \iprog{NEW-EXPERIMENT}, and thus provide
a way of passing plane contents from one experiment to another without
going through a disk file.


