Don't be so negative
I've traced the problem back to the ball.move routine itself (Though I've absolutely no idea what it's doing wrong, the other thing could be memory corruption but pti doesn't have memory read/write watchpoints and flashdebugger is being annoying). Everything else is running correctly as I told it too.
I'll find it... Hopefully it's related to bug #2 (as listed above).
Here's a screenshot of the mess:
![Sick :x](./images/smilies/grayscale_sick.gif)
(balls with grey around them are moving, the others are... well I don't know what they're doing there)
Just to be sure, this is the way I calculated the overhead:
I hope this format makes it more readable
A single ball.move takes around 3,000-4,000cc (using pti's clock counter), we'll round that to
5,000cc.
Suppose 15 balls that move every 3 interrupts (108 Hz, it's the slowest speed), that's 36 pixels per second.
The overhead generated by moving the balls is:
15×108/3×5,000 =
2,700,000cc/s
But updating the lcd also takes a lot of time, currently it's fixed at an update per 3 interrupts (~36 fps), an update itself takes less then 60,000cc:
108/3×60,000 =
2,160,000cc/s
Everything else is at this moment peanuts compared to these two.
Thus per second we need
4,860,000cc/s but the ti83+ can handle 6,000,000cc/s so it can run it, especially since we gravely overestimated the number of cc's it actually takes to move a ball/ update the lcd.
Final note: Don't worry, balls aren't moved during the interrupt itself, but are queued, the next time the mainloop restarts all 'events' (moving a ball/ updating the lcd) are executed.
The problem is that the queue overflows a lot (it can hold 64 entries however) which indicates that the processor can't keep up. BUT we just calculated it should...