VIC Life

[Mike]

This is an implementation of John H. Conway's Game of Life for the VIC.



It runs on a 160x192 grid. Requires +8K RAM expansion. Runs on either PAL or NTSC machines.

Instructions:

[0] / [1] / [{CRSR}] / [CLR HOME]: (re)set cell, cursor movement
[RUN STOP]: engine control *)
[L] / [S]: load/save life plane **)
[?]: re-invoke help screen

The program is now contained in the VIC LIFE section of the MG batch suite.

There's still some 1.5K space left for enhancements. Comments, suggestions are welcome.

Greetings,

Michael

*) i.e.: [SHIFT] + [RUN STOP] starts, [RUN STOP] alone stops the engine.
**) I've included the R pentomino which runs over 1000 generations.

P.S.: It recently has been shown - by construction -, that Life is capable of universal computation, i.e. one could build a computer solely out of Life cells! Look here: http://mathworld.wolfram.com/Life.html

Edits: Repaired broken DL link, and added screenshot for MINIGRAFIK version

[Mike]

I rewrote the engine. It's also a little bit faster now. Colour scheme is now as usual - blue on white background, cyan border. As I write this, the old version hosted is already replaced by the new one. You can use the same link above.

Maybe +8K RAM expansions are more abundant.

Michael

[eslapion]

This program appears to be innaccessible.

Do you think it would be possible to provide a new link ?

[mercifier]

How about a 96x64 grid (PAL) on an unexpanded Vic, with up to 6 updates/second?

I thought it would be convenient to use 64 characters with 3x2 cells in each, where each cell corresponds to one bit in the character number. The two upper bits and the color RAM is used as intermediate buffer. After two days of programming I made it work. I will upload it to my homepage one of these days.

I've got two VIC's, but no memory expansion, so I've kind of made it my mission to make useful programs for unexpanded VIC's.

[mercifier]

Life generator for unexpanded VIC now available at:
http://www.algonet.se/~riklund/CBM/viclife.html

There are two versions, PAL & NTSC. The PAL version uses a 32x32 character grid, and the NTSC version is simply just smaller, 24x25 (72x50 cells) because I don't really know the maximum size on NTSC machines.

I will upload the source also when having translated the comments from swedish and completed them.

There are things I would like to add, such as run-time selection of size, run-time selection of wrap-around or not (always on now). I must admit too that it's kind of annoying that the screen blanks during rendering, but since there is no room for double-buffering, the only alternative is watching crap coming up...

I might consider a pixel-based version (but it will be small). After all, the character definitions takes up half a kilobyte...

Btw, try this:

Code: Select all

   O
   O
   O
OOOOOO
  O
  O
  O

I call it the "expanding galaxy"

[Mike]

A re-release. And long, long over-due.

All graphics functions in the editor are now performed by MINIGRAFIK. Only the engine, that computes new generations is still an own ML part.

This way I could shorten the BASIC part by a good amount. The original version had 41 lines.

Greetings,

Michael

Code: Select all

1 REM ** LIFE (+8K)
2 POKE788,194:POKE55,131:POKE56,43:CLR:DN=PEEK(186)
3 SYS57809"CODE",DN,1:POKE780,0:SYS65493:@LOAD"HELP",DN
4 DX=1:DY=0:X=80:Y=96
5 M=0:P=@(X,Y):@1-P,X,Y:GETA$
6 IFA$="0"THENM=-1:P=0
7 IFA$="1"THENM=-1:P=1
8 IFA$="{RIGHT}"THENM=-1:DX=1:DY=0
9 IFA$="{LEFT}"THENM=-1:DX=-1:DY=0
10 IFA$="{DOWN}"THENM=-1:DX=0:DY=1
11 IFA$="{UP}"THENM=-1:DX=0:DY=-1
12 @P,X,Y:IFNOTMTHEN17
13 X=X+DX:IFX<0THENX=0
14 IFX>159THENX=159
15 Y=Y+DY:IFY<0THENY=0
16 IFY>191THENY=191
17 IFA$="{HOME}"ORA$="{CLR}"ORA$="?"THENX=80:Y=96
18 IFA$="{CLR}"THEN:@CLR
19 IFA$="?"THEN:@LOAD"HELP",DN
20 IFA$="L"THEN:@LOAD"DATA",DN
21 IFA$="S"THENOPEN15,DN,15,"S0:DATA":CLOSE15:@SAVE"DATA",DN
22 IFA$="{RUN}"THENSYS11139
23 GOTO5

[IsaacKuo]

I was going to ask if there was any inherent reason why you couldn't do 160x192 version for an unexpanded VIC...but then I figured it would be faster for me to answer it myself (by implementing it).

I'm not familiar with algorithms to do Game of Life computations quickly, though. My program works, but it's slow. It's less a Game of Life simulator and more of a dynamic allocation graphics demonstrator.

[Mike]

I was going to ask if there was any inherent reason why you couldn't do 160x192 version for an unexpanded VIC ...

If I demand, that all pixels in that resolution can be freely defined on or off, then I need to allocate the entire space of $1000 .. $1FFF for this.

I'm not familiar with algorithms to do Game of Life computations quickly, though. My program works, but it's slow.

My implementation uses an off-screen bitmap, which at first contains all live cells, and their neighbors. Cell birth can only happen in direct neighbors of any cell.

This first stage of the off-screen bitmap is produced with a full scan, but quite effectively, with 'bit-shift and or' on whole bytes.

In the second pass, only non-0 bytes in the off-screen bitmap are considered to throw the whole logic against. The data then is gradually replaced by the next generation.

Finally, the off-screen bitmap is blitted over to the visible screen.

...

There are even better methods, with list based, or hashed data structures. They can be extremely fast - but also use much more memory. You might take a look at Golly for this.