Commander X16

While many of you are creating games, videos, music and generally being amazing, I'm still noodling around the edges and building my 6502 assembly skills as I can find the time.

Here's a quirky little cellular automaton, called Langton's Ant.

While the result isn't some amazingly spectacular pattern, what's intriguing is that the ant exhibits three different modes of behaviour:
1. The first few hundred moves seem to create simple patterns.
2. Then, movement appears to be fairly random for about 10,000 moves.
3. Finally, the ant starts to build a recurrent 'highway' consisting of 104 repeating moves.

I have screen wrapping on to make things a little more interesting once the ant starts off on the highway.

Slow version: Try It Now!

Fast Version: Try It Now!

Anyway, source code is available on my github for other newbies seeking sample code to look at, pull apart, and improve.

Enjoy

I like it! I think it's great! I also like how you started with something that's not super complicated (Always a good idea when you're already juggling a half dozen learning curves just to get into asm language on a new platform.) and at the same time, well within the x16's wheelhouse.

Cheers

a peculiar observation: the drawing seems to be much quicker in the top of the screen when compared to when the ant is crawling near the bottom...?

desertfish wrote: ↑Tue Jan 07, 2025 8:22 pm a peculiar observation: the drawing seems to be much quicker in the top of the screen when compared to when the ant is crawling near the bottom...?

Yeah, I noticed that too. It's due to me doing the X/Y conversion to VRAM Addr calculation for every pixel.

If I just used the VRAM Addr to track the ant's location, it would be way faster.

Still, it shouldn't matter if Y=10 or Y=300 the calculation should take about the same number of instructions.
I've looked quickly in the source code and I see what is going on, you seem to use a loop to add an offset to the address Y times, to achieve basically a multiplication by Y. Which explains why it's slower when Y is larger
Too bad the 6502 doesn't have multiplication instructions !

An often used technique to avoid this problem altogether, at the cost of some memory, is to not calculate anything. Just define a precomputed table with the multiplication results for all possible Y values, and then simply look up the value directly.

desertfish wrote: ↑Tue Jan 07, 2025 8:47 pm An often used technique to avoid this problem altogether, at the cost of some memory, is to not calculate anything. Just define a precomputed table with the multiplication results for all possible Y values, and then simply look up the value directly.

Oh, what a good idea.

I've used lookup tables before; I wonder why I didn't consider it for this? (decades of coding in high level languages is probably the answer )

Updated the fast version to use a lookup table for the row address in VRAM for each YPos value.

Thanks for the suggestion @desertfish!

Yay well done, it is so much faster now! And the results of the wrap-around at the screen edges makes for some interesting results.