1-Dimensional Cellular Automaton

Programs: RMcell.z80, RMcell2.z80, RMcell2s.z80

This is a similar concept to the Game of Life, but uses a line, rather than a grid of elements, each of which  can be either on or off, depending upon the total number of 'on' elements within a set distance (referred to in the program as the 'radius') of the specific element.

In the first program, in RMcell.z80, the user is prompted for the radius (0 to 9), and on the screen an empty array is generated with a number of elements equal to twice the radius plus 2. The first element from the left corresponds to no 'on' elements within the set distance. The second element corresponds to 1 'on' element in total. The third element corresponds to 2 'on' elements in total, and so on. The user is prompted to enter the new state of the element for each of these values. This defines the 'totals' scheme. Finally, the user defines the initial state of the automaton, by entering a series of numbers in the range 1 - 256. When each number is entered, the corresponding pixel is displayed on the top line. To signify that the initial state of the automaton has been set, the user enters a blank in the prompt for the next number, and the program applies the totals scheme to each element of the line in turn and displays a new line underneath. This continues until the bottom of the screen is reached.

When I first saw the image above emerge, I knew I'd nailed the program as I'd seen it before in a magazine article (probably Scientific American) which had inspired me to create the program in the first place. The radius is '3', the totals scheme is '00011010', and the 'on' elements are: 101 to 110 inclusive, 112, and 113. The behaviour of this automaton is rather interesting. Towards the bottom, a pattern propagates out to the right. This pattern is called a 'glider', and the initial state that gave rise to it is called a 'glider gun'. New gliders are shot out at regular intervals. Notice also that when a left-moving glider meets a right-moving glider, they are both destroyed. 

This is a two-state automaton, but they can have multiple states, which can be represented by different colours (but sadly not on the Spectrum). Also, it is possible to define automata that use schemes that are not totals, but instead refer to the settings of specific elements to define the next state.

In the example below, the radius is '1' , the totals scheme is '0100' and the only 'on' element is 128. The figure is a type of fractal called a Sierpiński triangle.

The second program, in RMcell2.z80, uses BASIC code to take input from the user, as before, but the next state is determined by a routine in machine code that I first wrote in assembly language. This new version runs much, much faster!

I also took the opportunity to change the display to a flattened cylinder rather than a bounded flat sheet, as in the first program. So, for example, if you generate the Sierpiński triangle with the on element at the right, say at ~ 200, the graphic will go beyond the right side of the display and start appearing from the left side, as shown below. This change reduced the number of lines needed by about one third, as shown by comparing the code with an old listing I have of it.

The assembled routine was loaded in line 70 in the BASIC program: LOAD "celll" CODE . This had already been done when I first saved the program and the step has now been commented out.

The routine is run at line 620 in the BASIC program: RANDOMIZE USR 50008, where 50008 is its location in memory.

The source assembly language code is provided for reference, along with ZEUS, in image RMlife2s.z80. Ideally I wouldn't have included ZEUS, but I couldn't see any other way to make the source code readily visible.