CAM, CAM-6, CAM\PC boards.
CAM-PC Support Staff
instructive. I especially enjoy his lightening of a heavy topic with
informal humor.
In the letter of March 9, however, several of his statements are unclear
and may be very misleading to the casual reader. This particularly refers
to the lack of distinction between "rule" and "neighborhood".
Regarding CAM-PC, Harold writes:
> ...
>
> One price to be paid for this speed is that one is confined to the rules
> ^^^^^
> of evolution which are built into the machine; fortunately the Margolus
> neighborhood, which is one of them, can be used for many interesting
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> statistical applications, and may possibly account for the bulk of the
> interest in these boards. To a degree the machines are flexible, in that
> any rule within several large classes can be loaded into an onboard RAM.
> Modifying the rule requires reloading the table, a juncture at which the
> lack of general purposefulness begins to become evident.
>
> Again, that comment is not entirely accurate; both hardware and software
> switches are provided through which a limited amount of rule variation and
> ^^^^
> ...
Since we make the common distinction that a simple rule is composed of both
a "neighborhood" and a transformation function of that neighborhood, and a
complex rule (run cycle) is composed of a sequence of such simple rules,
the statement "one is confined to the rules of evolution which are built
into the machine" conveys the inaccurate impression that the "rules" are
pre-programmed. At best, one has to read the article very carefully to
conclude otherwise.
Furthermore, since the transformation function is totally programmable, it
is much more accurate to state that the set of possible "neighborhoods" is
fixed. While this fact may limit what can be done in a single application
of a rule, it need be no more limiting than the fact that an instruction
set of a conventional computer is finite--and even here, the trend is
toward RISC architectures with smaller instruction set sizes. In the same
way that such instruction sets are augmented by collecting sequences of
instructions into "macros", the "neighborhood set" of CAM-PC can be
extended beyond the neighborhood set that is built-in.
Nevertheless, even the fixed neighborhood set is fairly rich. In addition
to Moore, Von Neuman and Margolus neighborhoods, the spatial, temporal
(phase) and user connector extensions of CAM-PC provide for a large number
of different neighborhoods. In this sense, a simple neighborhood is
actually a selection of up to 16 of the 50 to 100 signals (depending on
what you count) that are available. The quoted statements (above) would be
much more accurate if "rule" were replaced by "neighborhood" where
underlined.
Harold's choice of developing a complete C environment with a user
interface, hardware driver, etc., is certainly admirable and is
considerably beyond what most people are willing to do. He has also
implemented many mathematical and theoretical analysis routines which are
beyond the scope of the CAM-FORTH environment. Nevertheless, CAMEX, which
is an impressive program, does not appear to implement any sort of run
cycle, which is a critical part of the CAM-FORTH environment. Since the
synergy between a host and a co-processor are critical to the effectiveness
of the co-processor, and this synergy is partially defined by the software,
his impressions of some of the board's limitations may be strongly
influenced by some of the control structures that are lacking in CAMEX. In
spite of its strengths, one can't help but doubt whether CAMEX could be
used to run something as conceptually simple, but practically instructive,
as the LOGODEMO experiment. Or whether an experiment like LOGODEMO would
even occur to someone using CAMEX.
> Manufacturers are understandably reluctant to release their circuit
> diagrams; few clients would probably benefit, even if they did. But one
> cannot help wondering how much of the boards' resources are bound up in
^^^^^^^^
> the complexities of the Margolus neighborhood, of little use to someone
> who would like to work with three-dimensional automata instead. Or who
>From this and other comments, one gets the impression that for some reason
Margolus neighborhoods are to be feared. There is also the implication
that they somehow limit the machine to 2D. In fact, relativily little
resources are consumed by the Margolus neighborhood. Furthermore, Margolus
neighborhoods exist in 3D, and higher dimensions, too.
It seems that the issue of 2D vs 3D is the real point of these comments.
It is certainly possible to develop a 3D real-time processor. It is entirely
another matter to display the 3D data in real-time and this is the limitation
with currently available, low-cost technology, even with "spinning disks" and
other 3D raster approaches. It is very possible to do the computations in
3D and perform perspective rendering to 2D images on a PC, but not in
anything close to real time.
Note that it should be possible to use up to eight CAM-PC's in a partial
3D configuration, e.g. 256 x 256 x 32, updated 60 times/sec. In this case,
you could look at 2D slices through this volume in real-time. It may even
be possible to gang together more CAM-PCs, but we are not presently in a
position to test this speculation.
It should also be noted that if you are willing to give up the feature
of "real time", even a single CAM-PC can be used to perform computations
on 2D and 3D arrays much larger than the 256x256x4 block that happens
to fit in a single board.
Regarding the choice of bit assignments. The two center bits were assigned
as they are to simplify the hardware design, since they are always part of
a standard neighborhood. Naturally hindsight is always clearer than
foresight, and no-one forsaw Harold's particular application which may be
affected by it. It seems, however, that for the vast majority of codes,
bit assignment is unimportant, much as a particular byte order is largely
unimportant for proper operation of most programs on conventional
computers, provided the compiler has this information. Likewise the CAM
programmer may need to know how the bits are assigned (though this detail
is largely irrelevant in CAM-FORTH) and this information is provided.
(Harold, send us private email about what you're after. We may be able
to share a subset of the schematics.)
> For purposes of full disclosure: we are an Automatrix beta test site, we
> do indeed like their board and find it useful, and we are not above
^^^^^^^^^^^^^^^^^^^^^^^^^^
Naturally, we always like to hear that.
> Before the swiss cheese automaton became something of a point of honor, we
> were adapting WireWorld to a mouse in CAMEX, allowing the user to sketch
> out an arbitrary circuit. The FORTH programs allow a certain amount of
> mouse interaction, which has to be one of the answers to the language
> problem. Many automata work well with random fields, but there are those
> for which explicit designs are either necessary or convenient. Life is
> one, WireWorld is another. Consequently there is a demand for fairly
> elaborate mouse programs. Mice can also be used to help set up rules.
It is very convenient to use a mouse to do plane editing with the CAM-PC
environment, though the current release of the software includes a driver
for a Mouse Systems mouse, a Microsoft Mouse driver is being prepared for
release. I also note that it is very easy to code wireworld for CAM-PC.
I hope this discussion has cleared up some confusion about our product.
Robert Tatar
--
CAM-PC Support Staff ca...@automatrix.com (internet)
campc%automatrix.com@CUNYVM (bitnet)
uupsi!automtrx!campc (uucp)
Cellular Automata Machines (CAM-PC) and CA Software Products