Prerequisite: Optimizing Color BASIC series
Here is a simple Color BASIC program that will scale blue box on the screen from small to large then back, going through the scaling processes 100 times.
0 REM scale.bas 10 SW=32/4 ' SCALE WIDTH 20 SH=16/3 ' SCALE HEIGHT 30 SM=.1 ' SCALE INC/DEC 40 S=.5 ' SCALE FACTOR 70 TM=TIMER:FOR Z=1 TO 100 80 W=INT(SW*S) 90 H=INT(SH*S) 100 P=15-INT(W/2)+(7-INT(H/2))*32 110 CLS 120 FOR A=1 TO H 130 PRINT@P+A*32,STRING$(W,175) 140 NEXT A 150 S=S+SM 160 IF H<1 OR H>15 THEN SM=-SM:S=S+(SM*2) 170 NEXT Z 180 ' 60=NTSC 50=PAL 190 PRINT:PRINT (TIMER-TM)/60;"SECONDS"
After this runs, it will report the approximate number of seconds it took. It does this by resetting the TIMER at the start, then printing the current TIMER value divided by 60 (since the CoCo timer is based on the NTSC video interrupt that happens 60 times a second).
NOTE: If you run this on a PAL system, you will need to change the 60 to a 50 in line 190. (edit: thanks, George P., for catching my typo.)
On the Xroar emulator running on my Mac it reports 25.25 seconds.

Your challenge, should you decide to accept it, is to take this code and make it run faster.
Rules
- You must leave the basic algorithm intact (the SW, SH, S and SH stuff with all the math). You can rename variables, change the representation of values, speed up PRINTing, etc. but the core program flow should remain the same.
- For bonus points, you are welcome to rewrite the program (in BASIC) to improve upon the algorithm in any way that makes sense, provided it achieves the same results (including the 1 to 100 benchmark loop).
There are some very (very!) simple things that can be done to dramatically improve the speed to his code.
Feel free to share your efforts in the comments. If you post your code, be sure to post the resulting time, too.
Good luck!
My current best effort is going full strength reduction on the inner loop. Replace lines 120 to 170 with:
120 L$=STRING$(W,175):FORA=P+32TOP+H*32STEP32:PRINT@A,L$;:NEXT
150 IFH<1ORH>15THEMSM=-SM
170 S=S+SM:NEXT
The STRING$ requires Extended Color Basic which starts at a baseline of 20.4 seconds and those changes get it down to 13.
I like what you did to the loop. I have a “things I did” post written up, and I didn’t even think of that one. But doesn’t it run enough steps for H to go less than 1? I see that was also removed.
Line 150 got garbled. Let’s see if I can get the less than and greater than in there.
150 IFH<1ORH>15THEMSM=-SM
Ah, that makes sense. WordPress really mangles things. You may be able to EDIT your original comment, if you wish to try to update it. I will include your optimizations in my follow-up.
just my 2c….
but error correction etc is totally unnecessary on a 32*16 screen…. you could just use ^2 and centering
unless you are going to add some SG funk to plot 1/2 a char, then all the other stuff is useless
you could try to *emulate* some fixed point for the math
The size scales for 4X3 aspect ratio, so doubling won’t work as it would stretch wide when it gets larger.
Thoughts on fixed point would be appreciated but does that matter since internally everything is a float?
well lets say you wanted to represent 1.5 using 8:8 fixed point…..
that’d be like $180, so if you *wanted* you could add some data statements in the code to have an executable addd in memory
the $80 (128) here is 128/256ths – so the equivalent of .5
again just my 2c
/Simon :)
Well … I see some words there, but I’m not as clever as you so I don’t quite understand what they mean.
it would depend on the speed of something like PEEK (for a value) or varptr for that matter, but potentially one could speed things up a little using some fixed point math….
is there any *particular* reason that the aspect ratio is 4:3 ????
/Simon
The screen display is 4×3 and I wanted the ball to be round rather than oblong.
Interestingly, changing the blue square value on line 130 to hex (“&HAF”) saves about 11.5% for me (27.55 to 24.33). Then, moving the row start calculation out of the print statement takes it down to 22.87.
120 FOR A=32 TO H*32 STEP 32
130 PRINT@P+A,STRING$(W,&HAF)
140 NEXT A
If only we knew then what we know now!
So I was able to cut out 5 seconds doing the following:
– DIM all variables
– Adding variables for constants (2, 32, etc.) for lines 130, 160.
– Removing the math in lines 10, 20.
– Removing the variables after NEXT.
– Removing all remarks.
No change to the original algorithm or PRINT line.
Coco3 (6309): Original code = 27.15s. Optimized code 22.13s.
With high speed poke: 11.05s. :D
I’m intrigued with the post that mentioned using HEX values. I may have to try that.
Good though on replacing constants with variables! You will find HEX to be faster, but a variable looking may be even faster than that unless there are a ton them and it’s further at the bottom. I didn’t think about trying variables for constants in this. I’ll include your tip in the follow up.
I just put the STRING$ statement into a variable as suggested by George Phillips. That took out another 2 seconds! I also ran RENUM 1,,1. Run time is down from 27.2 s to 20.1 s.
L$=STRING$(W,C)
FORA=1TO H
PRINT@P+A*B,L$
NEXT
This is great! I wonder how accurate timing is between real hardware (machine to machine) due to timing crystal differences, and between various emulators on various computers. I’ll have to run the original on a few and see if it reports.
That’s why it’s so good for folks to post their original value with the sample code with the updates.
I will enjoy adding all this the follow-up.
Pingback: Color BASIC optimization challenge – attempts | Sub-Etha Software
Pingback: Color BASIC optimization challenge – more attempts | Sub-Etha Software