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

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.

Color BASIC scaling demo.

Your challenge, should you decide to accept it, is to take this code and make it run faster.


  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 ????


  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
    140 NEXT A

  4. Adam

    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.

      1. Adam

        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.
        FORA=1TO H

        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.

  5. Pingback: Color BASIC optimization challenge – attempts | Sub-Etha Software

  6. Pingback: Color BASIC optimization challenge – more attempts | Sub-Etha Software

Leave a Reply

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