[stella] My next program...

Subject: [stella] My next program...
From: jvmatthe@xxxxxxxxxxxxx
Date: Wed, 16 Oct 1996 12:15:12 -0400 (EDT)
Well, after about 6 hrs of hard work, I have a nearly working version
of my next program.  Assuming I can fix the one known bug in it, I
may post it in the next day or so.  Anyway, it is only a very early
form of what I plan to have as my big project.  This idea occurred to
me while I was reading the article in Next Generation magazine about
artificial life. 

Here's the plan:

Implement Conway's Game of Life on the Atari 2600 with:
 1) Several starting arrangements available via the select switch
 2) A mode to allow you to set up an initial arrangement via the
    joystick
 3) Speed adjustable via a paddle in port 2
 4) Maybe a two player game based on this (iffy)

So far, I have an 8x8 grid implemented and it is very easy to expand
to 8xY where Y is whatever value you want under 16.  The tough part is
moving from that size grid to a 16x16.  This will only (as far as I
can tell) take less than 40 bytes of the available RAM on the 2600
and should run fairly quickly.  Right now, it updates the displayed
matrix about every 1/20 of a second, but with quadrupling the grid size
it will be slower, but still under a second, I hope.  Anyway, if anyone
wants to suggest a faster algorithm for updating the matrix, I am all
ears.  Here is how it works right now:

Assume only doing an 8x8 grid.  Then there are 10 bytes stored to hold
the grid, numbered A,0,1,2,3,4,5,6,7,B.  A second array is kept on which to
do changes based on the first grid.  The ones that are 0-7 are really
the grid and A and B are empty 'buffer' zones to cut down on the amount
of code necessary for 'boundary' cells.  The cells are divided into two
groups:  middle, left-edge and right-edge.  Each bit of each byte represents
a cell with 1=alive and 0=dead.  

The algorithm picks a bit (column) and works down the bytes (rows).  Here
is the setup:

         76543210  <- bits
         
ArrayA   00000000
Array1   00000000
Array2   00000000
Array3   00000000
Array4   00000000
Array5   00000000
Array6   00000000
Array7   00000000
ArrayB   00000000

So if we are working with bits 1 (a middle bit) in Array1 then we count its 
live neighbors by first counting the ones directly above and directly below 
(six cells there) and then the two on each side (for a total of 8 
neighboring cells).  Then the status of that cell is determined by the
following: 

2 live neighbors --> same status
3 live neighbors --> alive next round
else             --> dead next round

This new status is then changed in NArray1.  A special routine counts neighbors
for bits 0 and 7.  ArrayA and ArrayB are empty and only used as a 'buffer'
zone; they never change.  Once changes have been made in all the NArray#
bytes, they are copied over the old values of Array# and the process starts
all over again.  I haven't finished the timing, but it looks like the process
can be done in the following pieces:  1) do columns 6-4 2) do columns 3-1
3) do columns 0,7 and update new matrix.  Since this will repeat every 3
screens, that makes the total cycle 1/20th of a second.

So if you have an idea on how to make a quick algorithm for doing these 
calculations, let me know.  Also, if you have some easy code for working
with the joysticks and maybe moving a player graphic cursor around the
screen, that would be nice to have.  

Thanks!

matt

===========================================================================
 |||  John V. Matthews, III                             | PO Box 50355
 |||  NCSU Mathematics Graduate Student                 | Raleigh, NC 27650 
/ | \ http://www4.ncsu.edu/~jvmatthe/www/               | (919) 515 7324
===========================================================================

Current Thread