Yup, you are right. Same number of clock cycles. I thought it was 1 less.
All it can do is save space to fit more code on an 8K cart.
I could still move a few things to page zero but it's not that much savings.
The only time the code isn't fast enough visually is explosions and I was hoping to cut enough clock cycles to eliminate that issue without cutting the explosion, which may not even be possible without a major rewrite. Cutting a few regular stars and part of the explosion could be enough. That's defined somewhere in the line 450 range with STRNUM and EXPNUM.
The stars are too close anyway so cutting a few of those shouldn't be a big deal, but the real issue is once there is an explosion which adds 32 stars.
While rather spectacular that's a lot of calculations. Reducing those numbers was actually the first thing I tried and cutting both by 1/3 seems to help a lot during the explosions. I attached that version below.
The divide is large compared to what you'll find on the internet at a glance, but the first section is setup for looking forward or looking back.
Then it has to check if the divisor is larger than the dividend (overflow) and multiply by 80 at the end which is a table lookup.
There may be some clock cycles to be saved, for example overflow could be detected right away (if the divisor is larger it's overflow) but I'd need to look at the impact of that change.
At the very least, the loop could be unrolled with a 16K cart.
Some sort of table lookup is the only way that would be significantly faster all the time and that's probably a rewrite of a lot of code.
The main reason I was looking at the code was to see how tough it would be to port.
Edited by JamesD, Tue Oct 20, 2015 10:09 AM.