John H. Conway's Game of Life for the 3k expanded VIC

[huffelduff]

Hi there everyone,

I'm finishing up some more games at the moment, but in the meantime here's another version of Game of Life.
Its a zero player cellular automata simulation.
Joystick only for the 3k expanded VIC. PAL and NTSC

The usual request: Please test on physical hardware

Greetings

Older software:
viewtopic.php?f=10&t=9845
viewtopic.php?f=10&t=10074
viewtopic.php?f=10&t=10077
viewtopic.php?f=10&t=10087
viewtopic.php?f=10&t=10100

[Mike]

It was John Horton Conway who invented the Game of Life, not Tim Conway.

Actually, a text mode GOL on the VIC-20 only offers a rather contrained space to begin with. You can't even run the smallest glider gun in it.

[huffelduff]

Hi there Mike,

Thanks for the correction.

I wonder how I got that name in my head?
Tim Conway...ha ha you mean the Disney actor who invented Game of Life!

Anyhow yes the grid space is rather limited on the VIC.
Perhaps I'll revisit it and build one that's multi-screen.

Greetings

P.S. I've corrected the documentation and the opening screen with John Conway and not Tim.

[Mike]

P.S. I've corrected the documentation and the opening screen with John Conway and not Tim.

O.K. - I changed the thread title to follow suit.

Perhaps I'll revisit it and build one that's multi-screen.

Or you may want to take a look at my version: viewtopic.php?t=365. That one requires at least a +8K RAM expansion, though.

[huffelduff]

Hi Mike,

I had a look. I really like how you get a macro view of what's happening and the gliders that just keep on going on and on.
I am now considering doing a pixel level version.
Another thing that occurs to me is to look into other cellular game types to see what's out there.

Greetings

[chysn]

Every like four years since childhood, I have a cellular automata kick that lasts long enough for me to do a little project, then goes dormant for another four years. Most recently, I wrote a Game of Life implementation that ran as synthesizer module firmware (https://github.com/Chysn/O_C-Hemisphere ... -(Retired)), designed for providing modulation for sound parameters, running on a tiny OLED screen. Four years prior, I did a web-based hex version with a parameterized ruleset (http://jasonjustian.com/hex_ca), and spent some time with the hex gliders.

Technically, I'm about 18 months away from another CA project, but I think it might be fun to do one using the 4x4 PETSCII characters. I've sort of been scoping out an excuse to build something with that "graphics mode."

So, I'm always happy to see this kind of thing. Yours is particularly cool, with respect to its interface and animations. It's really easy to navigate, set up the cells, and get it going. The 3D loop-around is always best-practice (IMO), and is especially welcome given the size of the VIC-20 screen.

If I had any criticism--which, come on, I really don't--I'd like to be able to edit the current state rather than a starting state. One feels slightly more like a capricious god with that ability.

Nice work, and thanks for sharing!

[Mike]

Hi!

Of course with a history as large as Denial has, there's always the possibility that one's own programming efforts end up as 'already done elsewhere'. Even if there is - in principle - a search function at hand to check out prior art, this is bound to happen.

I had a look. I really like how you get a macro view of what's happening and the gliders that just keep on going on and on.
I am now considering doing a pixel level version.

Thanks! I wrote this implementation nearly 20 years ago. Even though there are some optimizations inside - the 'fine' counting algorithm is only thrown at bitmap bytes that might contain cells in the next generation, and not the whole bitmap -, in the meantime another poster (IsaacKuo) presented an altogether faster counting algorithm. Unfortunately, he insisted on using an unexpanded VIC-20 and a so-called 'sparse' bitmap, which isn't exactly the thing you want to do if you want to be able to set/reset all pixels on screen as you want.

So there's surely room for improvement. I'd suggest though you take a good look at how MINIGRAFIK builds the screen bitmap. That has been established as standard over the last years - really no need to reinvent the wheel here.

Another thing that occurs to me is to look into other cellular game types to see what's out there.

The 1D automata that build cells in the next row from the cell values above it are quite nice. Wireworld might be a nice application for a multi-colour bitmap, with black as background, orange as copper, light blue as electron tail and white as electron head. If you stack 3 multi-colour pixels atop, you get square chunky pixels for an effective 80x64 resolution.

Greetings,

Michael

[huffelduff]

Hi there Michael and chysn,

... the 'fine' counting algorithm is only thrown at bitmap bytes that might contain cells in the next generation, and not the whole bitmap... I'd suggest though you take a good look at how MINIGRAFIK builds the screen bitmap...The 1D automata that build cells in the next row from the cell values above it are quite nice. Wireworld might be a nice application for a multi-colour bitmap, with black as background, orange as copper, light blue as electron tail and white as electron head. If you stack 3 multi-colour pixels atop, you get square chunky pixels for an effective 80x64 resolution.

That's a very good idea, I brute force everything and the border calculations really slow it down as well.
As regards MINIGRAFIK I'm playing with it.
That Wireworld computer looks pretty amazing. I'll get into it over the coming weekend.

...Four years prior, I did a web-based hex version with a parameterized ruleset (http://jasonjustian.com/hex_ca), and spent some time with the hex gliders.
... but I think it might be fun to do one using the 4x4 PETSCII characters. I've sort of been scoping out an excuse to build something with that "graphics mode."...-I'd like to be able to edit the current state rather than a starting state. One feels slightly more like a capricious god with that ability.

Whoah 4 x 4 PETSCII grpahics. I've never used the mode, nor even contemplated something like it. Did a search on 4 x4 PETSCII and saw a nice Picture converter. Now my interest is peaked. Sounds like something one could use very well for adventure games maybe.
Do you know of any good software examples I could have a look at?
Regarding the edit mode rather than resetting to start, duly noted. I will modify it accordingly.
Dungeon of Dance is awesome. And for the unexpanded VIC to boot!
Also I messed around with your hexagon cellular automata. Correction I'm still messing with it.


Thank you so much for your feedback.

Greetings

[chysn]

Whoah 4 x 4 PETSCII grpahics. I've never used the mode, nor even contemplated something like it. Did a search on 4 x4 PETSCII and saw a nice Picture converter. Now my interest is peaked. Sounds like something one could use very well for adventure games maybe.
Do you know of any good software examples I could have a look at?

No, but the mapping of those characters to a 44x46 plane should be straightforward, in principle. I know that it's part of TRSE now.

Dungeon of Dance is awesome. And for the unexpanded VIC to boot!

Thanks for trying it!

[srowe]

No, but the mapping of those characters to a 44x46 plane should be straightforward, in principle. I know that it's part of TRSE now.

I also implemented a "lowres" graphics mode in V-Forth

https://eden.mose.org.uk/gitweb/?p=vfor ... fs;hb=HEAD

I used mappings between the PETSCII codes and a 2-bit value (bit 0 of X and Y).

[chysn]

I just wrote this. It seems to work okay, and I'll look for optimizations. But the idea is

Code: Select all

ldx #x_pos ; 0-43
ldy #y_pos ; 0-45
sec        ; Set carry to set, clear carry to unset, which I think is what we'll want for CA applications
jsr ChunkyPlot

And here's the code:

Code: Select all

SCREEN  = $0288
ZP      = $61
CH_IX   = $63

* = $1800

; Plot in Chunky Bitmap
; X = 0-43
; Y = 0-45
; Carry set = set
; Carry clear = clear
ChunkyPlot: php                 ; Save Carry to determine set or unset
            txa                 ; Save X and Y for later, to determine
            pha                 ;   whether they're even or odd
            tya                 ;   ,,
            pha                 ;   ,,
            lda #0              ; Initialize the ZP pointer to the top
            sta ZP              ;   of the screen, wherever it happens
            lda SCREEN          ;   to be.
            sta ZP+1            ;   ,,
            tya                 ; Divide Y by two to calculate the actual
            lsr                 ;   screen location
            tay                 ;   ,,
            beq add_x           ; If Y is 0, then just calculate based on X
-loop:      lda #22             ; Add 22 to screen address for each row
            clc                 ; ,,
            adc ZP              ; ,,
            sta ZP              ; ,,
            bcc cl_y            ; ,,
            inc ZP+1            ; ,,
cl_y:       dey                 ; ,,
            bne loop            ; ,,
add_x:      txa                 ; Now halve X and add it to the pointer to
            lsr                 ;   get the actual screen address
            tax                 ;   ,,
            clc                 ;   ,,
            adc ZP              ;   ,,
            sta ZP              ;   ,,
            bcc cl_x            ;   ,,
            inc ZP+1            ;   ,,
cl_x:       ldx #0              ; What character is currently at the specified
            lda (ZP,x)          ;   position?
            ldy #15             ; After this loop, Y will be the bitmap table
-loop:      cmp Bitmaps,y       ;   index, which also doubles as the bitfield
            beq found           ;   of set locations. Note that if the character
            dey                 ;   isn't found in the table, this bitfield will
            bne loop            ;   be 0 (all four locations empty)
found:      sty CH_IX           ; Store this current bitfield for later
            ldy #%00000001      ; Which bit do we even care about?
            pla                 ; If the Y value is odd, we care about bit 2
            ror                 ;   or 3 
            bcc x_bit           ;   ,,
            ldy #%00000100      ;   Reset starting point to bit 2
x_bit:      pla                 ; If the X value is even, we shift one to the
            ror                 ;   left
            bcs plot_char       ;   ,,
            tya                 ;   ,,
            asl                 ;   ,,
            tay                 ;   ,,
plot_char:  lda CH_IX           ; Remember, this is the CURRENT index
            tya                 ; Move the NEW index to A for manipulation
            plp                 ; Get caller's status, interested in Carry
            bcc plot_clr        ; If carry is clear, clearing the location
            ora CH_IX           ; Otherwise, setting the location
            bcs save_char
plot_clr:   eor #%00001111      ; Generate a bit mask of everything except the
            and CH_IX           ;   specified bit, then clear it out
save_char:  tay                 ; Return this new index to Y, so that it can
            lda Bitmaps,y       ;   be used to acquire the new character
            sta (ZP,x)          ; And store it at the calculated screen address
            rts
            
; Character at Index N
; N bit 0 = Upper Right (y=even, x=odd)
; N bit 1 = Upper Left  (y=even, x=even)
; N bit 2 = Lower Right (y=odd, x=odd)
; N bit 3 = Lower Left  (y=odd, x=even)          
Bitmaps:    .byte 32,124,126,226,108,225,127,251
            .byte 123,255,97,236,98,254,252,160
            

[Mike]

Every like four years since childhood, I have a cellular automata kick that lasts long enough for me to do a little project, then goes dormant for another four years.

I tune in to Life Wiki somewhat more regularly, and it is astonishing what the GOL community has found/constructed in the last years, like oblique spaceships, unit life cells and universal constructors. The 160x192 resolution of my GOL implementation is just barely sufficient to see the smallest of those newly found patterns running on the VIC-20.

The 3D loop-around is always best-practice (IMO), and is especially welcome given the size of the VIC-20 screen.

The rules of GOL are supposed to work on an infinite plane. A 2D torus is only useful so one does not need to worry about the exact placement of the initial pattern and only as long as the pattern keeps within one full screen size, but the overview is quickly lost when the pattern size grows beyond the screen capacity or gliders appear and wrap around. Then the rules are broken. With a 1 cell thick "death zone", it is easier to assess the limits of the implementation, and at least that method stops gliders from wrapping around (they are turned into 2x2 blocks that mark where the glider 'left' the scene!).

I think it might be fun to do one using the 4x4 PETSCII characters.

That is surely quite interesting, implementation-wise. As an intermediate step between a text mode GOL and a bitmap GOL, it should at least use an overscan screen though.

Greetings,

Michael

[chysn]

I think it might be fun to do one using the 4x4 PETSCII characters.

That is surely quite interesting, implementation-wise. As an intermediate step between a text mode GOL and a bitmap GOL, it should at least use an overscan screen though.

What is meant by “overscan screen” here?

[Mike]

What is meant by “overscan screen” here?

VIC can resize the display window to show other than 23 rows by 22 columns. Check VIC registers $9000..$9003 and note that PAL and NTSC need different default values for XPOS and YPOS when (re)centering the screen window. Sensible values can be derived as offsets from the default VIC register table in the KERNAL at $EDE4.

With NTSC, 24 columns and 27 rows should be doable, which gives 48 x 54 cells with chunky 4x4 pixels. PAL has more border around the display window to begin with, 26 columns and 32 rows should work on most displays which allows for 52 x 64 cells. Of course that extended screen makes it necessary to put the screen base to somewhere else than $1E00. Working out further details left as exercise to the reader.

[chysn]

Oh! See, back in my day we called that an "embiggened screen."

But seriously, it's a good idea, because for the regular Game of Life rules, there's an enormous difference between 22 and 48 cells in width. You need around 40 cells in width (maybe a little less?) for the smallest functioning gun.