6502.org

TINYLIFE-6502
https://github.com/orac81/miniapples/ra ... fet06b.zip

This is a "size-code" version of the classic LIFE game, for the Commodore C64, C16, VIC20, PET. The smallest version is 126 bytes (see smallbin folder), but I recommend using the slightly bigger version with built in edit and help.

To use, just edit using the PET editor to create the patterns using the letter "O" for the cells.
Note that the program is very simple, ie. it doesnt handle screen
wrap properly. But it is quite fast.

The "small" version needs the user to edit before running. Put the "run" command on the 2nd line. This version needs VIC20 users to type:
POKE 36879,8:print chr$(5)chr$(147) before editing.

To avoid all that, use the "big" version!

Released as FREE/GPL3 software, source included.

126 bytes is an extraordinary achievement! Well done... there was a 256 byte program mentioned previously - follow the breadcrumbs here (or go direct).

Cool. It would even fit in RAM on the Atari 2600. ^.^

Thanks! This version will go down by 12 bytes (to 114 bytes) if you loose the basic stub and start with a sys. But it does rely on the PET editor to setup the start pattern, some machines dont have that. As a simple hack you could just fill the screen with random data to start.
The code depends on having a pet style mem mapped char screen. So it might transfer to uk101 or BBC text mode or Apple2 text (with address translation) but other bitmap screen 6502 systems (oric?) would need additional code. I don't think the Atari 2600 has enough screen ram for a useful life demo, unless you use a cart with extra ram. Most sizecode stuff is very system dependant.

The code makes a complete copy of the screen with just bit 0 kept, so each byte is 0 or 1. Letter O or petscii "ball" (81) have bit 0 set. It then uses this code to count the surrounding cells:
Now if you kept a 3 line rolling wrap around 256 byte buffer instead you can just use 8 ADC abs,Y instructions, which will be faster.
You could implement proper wrap around at the same time. That would make the code bigger that 126 bytes though.

A version using Petscii quarter pixel gfx would give 80x50, with the right code using that method should be quite fast. It would need a special editor for it.

You could also use the regular screen editor and treat that as being a 1/4 size (40x25) starting point for the "whole" (80x50) screen. Basically the same program, just with more room to "evolve". Might cost a few more bytes to do the translation, though.

Yes, but with the current code you hit a key to stop, edit, then restart with ENTER, which is a nice feature for such a small program. Really if you make a quarter char pixel version, you break the "small code" because of look ups to handle that at speed, so you might as add code for edit, proper wrapping etc..
I forgot to say this runs on C128, and 8032 too.