# Color BASIC optimization challenge – scaling

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

1. 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.
2. 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!

## 18 thoughts on “Color BASIC optimization challenge – scaling”

1. George Phillips

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.

1. Allen Huffman Post author

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.

1. Allen Huffman Post author

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.

2. simon

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

1. Allen Huffman Post author

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?

1. Simon

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 :)

1. Simon

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

3. Jason Pittman

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

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.

1. Allen Huffman Post author

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

1. Allen Huffman Post author

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.

This site uses Akismet to reduce spam. Learn how your comment data is processed.