Just for fun! Finished in about an hour, although it's currently far too slow for my liking-- optimizations are more than welcome (especially for that augment()/seq() monstrosity in the middle of it).

Screenies:
Glider-- only loading 6 of the 16 total horizontal cells.

Loafer-- loading the entire field. Yes, it really is this slow.


[A] should be a 13x16 [that's 13 tall, 16 wide] matrix with its cells initialized according to the pattern you want; live cell is 1, a dead one is 0. The game doesn't modify the matrix, however (calculations are done by testing pixels), meaning that you can run the same pattern as many times as you want without changing [A].
If you want to start with a random field, replace 255[A](1+.1B,1+.1A) with 255real(8,3,2).

No download as of yet.

Code:

It looks like you are reading the state of each pixel from its color value on the screen. If you store the state of the screen in some sort of buffer, it will be much faster to access (because the parser will spend much less time), and you may even be able to vectorize some of the operations.

I wonder if a 44-pixel-high BASIC Game of Life could be done by storing 44 pixels in each element of a list of dimension equal to the width as bits in a binary integer.

That's precisely what I'm doing, but I'm not sure how buffering (I assume you mean using a matrix) would help much with speed; I'd still have to spend time iterating over the current cell's Moore neighborhood... and that's really the only thing slowing this down.
What do you mean by vectorizing operations?

Well, let's forget rounding errors for now and assume that a TI float can store 44 bits of information. We can store the screen in a list of say 100 elements, each one representing a column of pixels. Then the Moore neighborhood can be obtained quite easily. Say we want to know which of the cells to the left of column 42 are. That's just L1(41); the cells to the right are L1(43), the cells below are 2L1(42), and the cells above are .5L1(42). So we can add all of these up, and get a map of how many bits are set; then we can recalculate the pixels based on that.

The following code will work for base-10 storage, and is limited to 14 rows, but this can be expanded to 44 at the cost of speed.

Code:


I think this should work.

Edit: Nope. At least seven errors. I'll fix it tomorrow.

Nice! This is long overdue!