(I pinged the author and the source link is now updated! See also this post and comments.)

A fascinating set of posts. How much of the work for the game would be done in an FPGA ? It seems like the 6502 may be doing too much of the work. Here is a link to one solution (it uses a different processor): http://www.syntiac.com/tech_fpga_life.html The game uses FPGA block ram and I think it calculates 512 cells in parallel.
It’s tempting to expand the game a little bit and use double bits so that barrier objects could be placed.

_________________
http://www.finitron.ca

Interesting! I see the FPGA in that case (from the Turbo Chameleon 64 project) is a Cyclone II with 66 block RAMs, giving a maximum width of 1188 bits. That's pretty similar to the LX9 in the Matchbox copro, which has 32 block RAMs and a maximum width of 1152 bits.


That's blazingly fast, but on a grid limited to normal video resolutions... I'm quite fond of the very large universes possible with a list-based or tile-based life. Then we'd be back to the constraints of RAM speed... the Matchbox has the advantage of 32 bit wide pSRAM, but the 55nS access limits the cycle time to 18MHz. I'm not sure if Life's locality would allow us to get some advantage by mixing on-chip and off-chip memory. Surely some advantage.

A hash life usually uses enormous memory structures. I wonder if a mini hash life could usefully fit the hashes into the 64k of on-chip RAM. Or if hash access has some locality and we can use the on chip RAM as a form of cache for tables in the 2Mbyte pSRAM.

If there's enough space between active areas, you may be able to copy an area to internal ram, and then run a number of generations before copying it back.

Thank you!! Indeed an amazing piece of code. No sleep tonight I don't think...

Kind regards,

Oscar.