There are a lot of neat things to do with Cellular Automata and the CAM-8 machine in particular. I actually don't use the CAM-8 that much, since my main tasks are to develop software for the host SparcStation which make it easier to use the CAM-8.

I have three main projects:

• The Cam Compiler
• Campat
• Steplib

My real long-term goal (which I hope to use as my Master's Thesis) is to develop a new language for designing cellular automata, and write a compiler which compiles this language into experiments which will run on the CAM-8. Currently, all experiments run on the CAM-8 are written in Forth, an ancient language which most people hate to use. (But my boss likes it.)

While the CAM-8 is insanely powerful in many respects, it also has some hard limitations, which require sneaky work arounds. For instance, the look up tables for site updates can only have 2^16 entries, and each entry can have only 16 bits of data. Thus, even though a given cell can have an arbitrary amount of state associated with it, the update rules must be decomposed into functions which are 16 bits in, 16 bits out.

When someone dreams up an automata with more than 16 bits of state, this presents a problem. However, most of the operations which make up the functions used can be decomposed into a series of smaller functions.

A clever compiler could erase all this hassle by:

• Assigning data fields to locations within the cell (or sub-cells) which don't interfere with each other
• Automatically creating fields for temporary data or data movement as necessary
• Automatically decomposing large function tables into a series of smaller ones when possible
• Re-ordering functions and composing functions whenever possible to decrease the number of scans needed to do an update
• Advising the user about functions create an unresolvable bottleneck

Moreover, a good language would go a long way into making CA experiments more understandable and modifiable. Since most people don't have much familiarity with Forth, and even people who do have a hard time reading other people's code, a clean language which is specifically designed for readability and ease of use would be a big help to the CA field in general.

This is currently my highest priority project. Progress has been somewhat slow though. There are too many interesting things in the world to spend time on.

Campat

Overall, what campat needs is:

• A better organized, more powerful description language.
• The capability to generate scenes with more than 2 dimensions.
• More powerful and more efficient drawing routines
• A mechanism for handling sub-cells.
• A graphical user interface.
• A drawing interface which accesses the CAM hardware directly, rather than saving to a file

This library will help in two ways. First, it extends the drawing capabilities of the system into 3 dimensions. Second, it provides a very modular way of changing the lowest level routines without changing anything else. This feature will make the implementation of a direct interface to the CAM-8 hardware very simple.

I did manage to get a new version of campat mostly working, which included 3d primitives, more powerful specification, and a generally nicer interface. Unfortunately, I haven't documenteded it or polished it yet. This will happen eventually.

Steplib

Steplib is really Harris's project, but I'm pretty involved in it as well. Steplib is an attempt to make a library of C routines which access the CAM-8 hardware without using Forth routines. If we really get it to work, it could be the greatest thing the CAM has ever seen, since it will entice people to use the CAM who would otherwise look at Forth code and shudder with horror. Moreover, a good non-forth interface is needed for my CAM Compiler project to be practical.

When I last worked on Steplib, we had a lot of good stuff working, but we weren't free of the Forth yet. Part of the difficulty is that the forth version of Step has both low-level routines for talking to the CAM hardware, (which we've mostly re-written in C) and a familiar user interface (with an interpreted language) for actually running the experiments. Thus, in order to actually run anything, we still need the Forth code, and we dynamically link in our C funtions.

Some work has been done to integrate Steplib into Tcl, in order to make a new interface which will be "Forth Free". But not a whole lot has been accomplished yet. (As far as I know.) Since I'm not a big fan of Tcl, I may try to develop an interface to Scheme (or Guile?).

Since Harris is now working out at Phillips Labs for Jeff Yepez, (one of our collaborators) I'm no longer up to date on what he's doing. I hope he's made some real progress!