Search:

On EEVBlog I stumbled across a link to an old (1979) issue of BYTE Magazine, in it there's an article on algorithms for this Game of Life thing. Thought it might be interesting:
...

The array transform routine, as posted above executes in 4.66ms on my test hardware (18F46K42 @64MHz).
It's a small improvement but I managed to reduce that to 4.28ms by changing it into two...

This shaved another 4ms off here, instead of:

IF population > 3 OR population < 2 THEN
lednew[counter] = 0
ENDIF

Do:

IF Population > 3 THEN LEDNew[Counter] = 0
IF Population < 2 THEN...

From 3 to 15 frames per second in a couple of hours, I call that improvement.
At one place (at least) you first do IF LED[Counter] = 0 and then a couple of lines further down you do IF LED[Counter]...

Great that it all still works!
I timed it and Richards is a quite a bit quicker. On my test setup it went from 67 to 48ms which is not surprising since, generally speaking, anything involving...

There's also an array called colour, how large is that?

For this I just toggle an output and measure it with the scope but for more precise measurements I use one of the onboard timers. Reset it,...

In the Grid Evalutaion section, precalculating the Array index values and replacing the AND-logic with nested IF/THEN saves Another bunch of cycles

'Grid Evaluation

CntPlus33 VAR WORD...

What size are all the different arrays?

Here's another tiny tweak to the array transformation routine that makes quite a difference:

FOR Row = 0 to 31 ' Cycle thru 32 rows

TempW = ROW * 32 ' Precalculate this...

Hi,
It might very well be that I don't quite understand what you're doing in the code but replacing all that OR logic with some math increases the performance in that particulat section of the code...

Here's an idea, untested, don't know if it compiles.


InPtr VAR BYTE
OutPtr VAR BYTE

Row VAR BYTE
Col VAR BYTE

Even VAR BIT