Nice!

Why not just go full character mode?

The smooth motion is nice, but a bit of overkill, also it adds complexity to the collision code.

I suspect this can be done using a variation of Bresenham's line algorithm for the trajectories (keeping delta X and delta Y for each ball) and avoid most/all of the complex trig and math. Just addition and subtraction and a few sign changes.

The delta can be kept at a higher resolution than the grid (i.e. 16x so a mask can be used instead of division), so you can fudge the collision with small delta changes on impact using the SID as a RNG.

Hey, thanks for checking this out. I wanted smooth motion to keep close to the JS piece that inspired this; it seemed like it should be eminently possible to get smooth motion, after all.

And yeah, I was reminded of Bresenham's algorithm a few days back, and had a suspicion that I've basically redone it independently (and inefficiently) by doing the trig. As mentioned at the end there, the math isn't where I'm losing most time in rendering though.

The Mastodon release post (cite 0) has comments talking about doing the score recalculation only at time of collision, but the worst thing I do is use a block of RAM for the playing field and another block of RAM for the _display_ of the playing field. Copying those blocks of 20 bytes, gosh it's slow.

I think it's easier to implement with sprites, but the complex trig and math is unnecessary either way.