See also: part 1, part 2, part 3, part 4 and part 5.

Since I like to jump around, let’s do just that.

CoCo cross development revisited

Awhile ago, I posted about Microsoft Visual Studio Code and CoCo cross development. I just remembered this was a thing, so I have been doing some experiments tonight using the Xroar emulator and Visual Studio Code to quickly type up BASIC code and then load it into the emulator via an ASCII file (simulating a cassette tape).

My process is this:

1. With the Color BASIC extension for Visual Studio Code installed, I type up my BASIC program and save it out to a file called “ASCII.BAS”. (The filename doesn’t matter.)
2. In Xroar, I select Load (from the cassette menu, or Apple-L on my Mac) and browse to this ascii.bas file I just saved.
3. In Xroar, I type CLOAD and watch it quickly load in my text file as if it was loaded as an ASCII basic program from tape.
4. I type RUN and see if it worked…

This let’s me write code quickly on my Mac, and then test it out on the emulated CoCo without too much effort.

With that out of the way, let’s return to discussing this bouncing ball project…

Discussing the ball project

My earlier experiments show that the fastest way to print a block of characters on the screen is to calculate the position and then use PRINT@. For example, here is a 10 x 7 block of text that sorta looks like a ball. With variable P being the top left corner to PRINT@ to, I just add offset values to get to each line. I use hex values because that’s faster than using decimal:

100 REM BALL
110 PRINT@P+&H00,"  XXXXXX  ";
120 PRINT@P+&H20," X      X ";
130 PRINT@P+&H40,"X        X";
140 PRINT@P+&H60,"X        X";
150 PRINT@P+&H80,"X        X";
160 PRINT@P+&HA0," X      X ";
170 PRINT@P+&HC0,"  XXXXXX  ";

I can adjust the location of P and have this print the ball anywhere I want on the screen. But, since it’s a ball, it doesn’t really make sense for me to print those empty corners, so I removed them and adjusted the offsets:

100 REM BALL
110 PRINT@P+&H02,  "XXXXXX";
120 PRINT@P+&H21, "X       X";
130 PRINT@P+&H40,"X         X";
140 PRINT@P+&H60,"X         X";
150 PRINT@P+&H80,"X         X";
160 PRINT@P+&HA1, "X      X";
170 PRINT@P+&HC2,  "XXXXXX";

Just so I could see the ball better, I added spaces before the string quotes in lines 110, 120, 160 and 170. To make it faster, I’d remove those, and put all these PRINTs on one line (if it fits). Every little bit helps, but we’ll optimize for speed later.

Now, Jim Gerrie’s demo had different frames of animation which he did using an array of strings. But, printing arrays is slower (since it has to look up the values each time). I decided I’d try raw PRINTs and make each “frame” of the ball be a subroutine. It takes time to GOSUB to that routine, but it will RETURN quickly.

I could then use a variable to represent which frame to print, and use ON/GOSUB to get to it (at the overhead of teaching forward in the program to find that line number).

40 ON F GOSUB 100,200,300,400,500,600,700

We’d need to benchmark to see if searching the array is faster than searching line numbers. (Since each array string would have to be looked up, versus one search for a line number, I expect the GOSUB approach will be faster unless the program is huge and it has to search through tons of lines.)

Now I can do my X and Y movement calculating, conversion that to a PRINT@ location, and then GOSUB to the appropriate frame routine to display it.

To erase the ball, I could just clear the entire screen (CLS), or I could make a subroutine that just PRINTs over the old ball:

1000 REM ERASE
1100 PRINT@P+&H02,  "      ";
1200 PRINT@P+&H21, "        ";
1300 PRINT@P+&H40,"          ";
1400 PRINT@P+&H60,"          ";
1500 PRINT@P+&H80,"          ";
1600 PRINT@P+&HA1, "        ";
1700 PRINT@P+&HC2,  "      ";
1800 RETURN

This should greatly reduce the amount of flicker.

Let’s see what the program looks like now:

10 CLS
20 X=0:Y=0:XM=1:YM=1:F=1:FM=1
30 GOSUB 1000:P=X+Y*&H20
40 ON F GOSUB 100,200,300,400,500,600,700
50 X=X+XM:IF X<&H1 OR X>&H15 THEN XM=-XM:FM=-FM
60 Y=Y+YM:IF Y<&H1 OR Y>&H8 THEN YM=-YM
70 F=F+FM:IF F>7 THEN F=1 ELSE IF F<1 THEN F=7
80 GOTO 30

In line 10, I clear the screen. Right now, I’m just using text on the green screen, but ultimately I’ll want to clear the screen to some background color, and “erase” by printing that color over the old ball.

Line 20 initializes the variables I will be using:

• X – X position of the top left corner of the ball.
• Y – Y position of the top left corner of the ball.
• XM – value to add to X for the next X movement (1 to move to the right, -1 to move to the left).
• YM – value to add to Y for the next Y movement (1 to move down, -1 to move up).
• F – frame of the ball to display. Since ON GOTO/GOSUB uses base-1 values, frames will be 1-x.
• FM – value to add to F to get to the next frame. When moving left to right, I’ll add 1 and increment the frame. When the ball bounces off the right side of the screen, I’ll start adding -1 and reverse the animation.

Line 30 erases the ball at the current position. This doesn’t make sense the first time we RUN, but it will have something to erase every time after that. We also calculate the PRINT@ P position from the X and Y values.

Line 40 does the ON GOSUB to the routine to print whatever frame we are supposed to display. If F is 1, it GOSUBs to 100. If F is 4, it GOSUBs to 400.

Line 50 adds the XM value to X, giving us our next X position. It then checks to see if X has gone too far left, or too far right, and reverses the XM value if so.

Line 60 is the same as above, but for the Y value.

Line 70 is similar, but either increments or decrements the frame, then checks to see if it needs to wrap around to the frame at the other side.

After this, we just need the routines that print the ball frames and erase the ball frame:

100 REM FRAME 1
110 PRINT@P+&H02,  "XXXXXX";
120 PRINT@P+&H21, "X      X";
130 PRINT@P+&H40,"X        X";
140 PRINT@P+&H60,"X        X";
150 PRINT@P+&H80,"X        X";
160 PRINT@P+&HA1, "X      X";
170 PRINT@P+&HC2,  "XXXXXX";
180 RETURN

200 REM FRAME 2
210 PRINT@P+&H02,  "XXXXXX";
220 PRINT@P+&H21, "XX     X";
230 PRINT@P+&H40,"XX       X";
240 PRINT@P+&H60,"XX       X";
250 PRINT@P+&H80,"XX       X";
260 PRINT@P+&HA1, "XX     X";
270 PRINT@P+&HC2,  "XXXXXX";
280 RETURN

300 REM FRAME 3
310 PRINT@P+&H02,  "XXXXXX";
320 PRINT@P+&H21, "XXX    X";
330 PRINT@P+&H40,"XXX      X";
340 PRINT@P+&H60,"XXX      X";
350 PRINT@P+&H80,"XXX      X";
360 PRINT@P+&HA1, "XXX    X";
370 PRINT@P+&HC2,  "XXXXXX";
380 RETURN

400 REM FRAME 4
410 PRINT@P+&H02,  "XXXXXX";
420 PRINT@P+&H21, "X XX   X";
430 PRINT@P+&H40,"X XXX    X";
440 PRINT@P+&H60,"X XXX    X";
450 PRINT@P+&H80,"X XXX    X";
460 PRINT@P+&HA1, "X XX   X";
470 PRINT@P+&HC2,  "XXXXXX";
480 RETURN

500 REM FRAME 5
510 PRINT@P+&H02,  "XXXXXX";
520 PRINT@P+&H21, "X  XX  X";
530 PRINT@P+&H40,"X  XXXX  X";
540 PRINT@P+&H60,"X  XXXX  X";
550 PRINT@P+&H80,"X  XXXX  X";
560 PRINT@P+&HA1, "X  XX  X";
570 PRINT@P+&HC2,  "XXXXXX";
580 RETURN

600 REM FRAME 6
610 PRINT@P+&H02,  "XXXXXX";
620 PRINT@P+&H21, "X   XX X";
630 PRINT@P+&H40,"X    XXX X";
640 PRINT@P+&H60,"X    XXX X";
650 PRINT@P+&H80,"X    XXX X";
660 PRINT@P+&HA1, "X   XX X";
670 PRINT@P+&HC2,  "XXXXXX";
680 RETURN

700 REM FRAME 7
710 PRINT@P+&H02,  "XXXXXX";
720 PRINT@P+&H21, "X    XXX";
730 PRINT@P+&H40,"X      XXX";
740 PRINT@P+&H60,"X      XXX";
750 PRINT@P+&H80,"X      XXX";
760 PRINT@P+&HA1, "X    XXX";
770 PRINT@P+&HC2,  "XXXXXX";
780 RETURN

1000 REM ERASE
1100 PRINT@P+&H02,  "      ";
1200 PRINT@P+&H21, "        ";
1300 PRINT@P+&H40,"          ";
1400 PRINT@P+&H60,"          ";
1500 PRINT@P+&H80,"          ";
1600 PRINT@P+&HA1, "        ";
1700 PRINT@P+&HC2,  "      ";
1800 RETURN

(After I typed this, I realize I need a FRAME 8, but I’ll fix that later.)

You can see my simple attempt at making the ball “spin” in action here:

With this proof-of-concept done, I can now get back to trying to make it get done faster by optimizing the BASIC code for speed.

To be continued…

See also: part 1, part 2, part 3, part 4 and part 5.

The prolific Jim Gerrie recently posted a video of an MC-10 bouncing ball demo he wrote in BASIC:

Thanks to Jim, the MC-10 joins a long list of 80’s home computers that thought bouncing a ball around the screen was a good demo.

Seeing his demo inspired me to revisit my Benchmarking BASIC series and see if we can expand on this.

I begin with the excellent (and free) Xroar Emulator. For those that want to play along, there is now a web browser version you can try without installing anything, or you can try the original JS Mocha emulator. Both should be more than enough for this experiment.

First, I load up my BENCH.BAS framework so I can do some speed tests. It looks like this:

0 REM BENCH.BAS
5 DIM TE,TM,B,A,TT
10 FORA=0TO3:TIMER=0:TM=TIMER
20 FORB=0TO1000
70 NEXT
80 TE=TIMER-TM:PRINTA,TE
90 TT=TT+TE:NEXT:PRINTTT/A:END

The above sample code will run four tests (0 to 3) and each time it will do “something” 1001 times (0 to 1000) and report the results in CoCo TIMER values (where each number represents 1/60th of a second, give or take). The benchmark code would go between lines 20 and 70.

Let’s see how big of an object we want to display. Using Jim’s video as a reference (where he shows some of the BASIC source code), it looks like 8 characters wide by 9 characters tall:

Based on him using substrings going up to 6, it looks like he may have 7 frames of animation (0-6). Impressive. But let’s just start with displaying 8×9 characters in various ways to see how fast we can do it.

The fastest way in BASIC is to use a PRINT@ statement, so my first test is to see how long it takes to print these characters 1001 times. I will hard-code the location for each line starting with 0 (the top left of the screen). It looks like this:

30 PRINT@0,"12345678";:
   PRINT@32,"12345678";:
   PRINT@64,"12345678";:
   PRINT@96,"12345678";:
   PRINT@128,"12345678";:
   PRINT@160,"12345678";:
   PRINT@192,"12345678";:
   PRINT@224,"12345678";:
   PRINT@256,"12345678";

Running that in the benchmark program results in 3986.

Using decimal values is slow, so next I changed them to hex:

30 PRINT@&H0,"12345678";:
   PRINT@&H20,"12345678";:
   PRINT@&H40,"12345678";:
   PRINT@&H60,"12345678";:
   PRINT@&H80,"12345678";:
   PRINT@&HA0,"12345678";:
   PRINT@&HC0,"12345678";:
   PRINT@&HE0,"12345678";:
   PRINT@&H100,"12345678";

Parsing a hex value is much faster, so this results in 3018. That’s about 25% faster.

And, using variables is even faster, since no parsing is required. A quick test that sets variables I-Q to each value, then does a PRINT@I through PRINT@Q produces 2940. Not a huge gain, but every little bit helps. That’s probably the fastest one can print something like this in BASIC.

The problem with using multiple variables is you have to update each one every time the object moves. If you just use one variable, and do math for all the other lines, you are doing the same math for each line that would have been done for the variable.

At this point, we need to see which way of doing math is faster. Or, perhaps, maybe we can do it without using math. . .

To be continued…

Over in the CoCo Facebook group, Diego Barzio just posted a note about discovering some BASIC program line comments that had left out the REM keyword at the start. Because those lines were never the target of a GOTO, there was no error. This had the side effect of saving a byte (or two, since most do “REM ” at the start) for comment lines.

This made me think about what was going on. BASIC will allow you to type in anything, and will try to parse it (to tokenize the line) and produce an error (?SN ERROR, etc.) if there is a problem. But, when you are typing in a line, this BASIC doesn’t check anything until that line is actually ran in the program. (Other versions of BASIC will check when you hit enter. Didn’t the Apple 2 do that?)

REM

In an earlier article, I mentioned that “REM” tokenized into one byte, and the apostrophe (‘) turned into two bytes because it was “:REM(space)” allowing you do do something like this:

10 REM This is a comment.
20 'This is a comment

Since most folks type “REM(space)”, using the apostrophe without a space after it takes the same room. But if you include the space:

10 REM This is a comment
20 ' This is a comment

…that would make line 10 take one byte less (REM + space is two bytes, versus ‘ + space which is three bytes).

Now, if you do not include REM or apostrophe, you can save a byte or two for each comment. If you program has 50 lines of comments, that’s 50-100 bytes.

BASIC Keywords

However, this made me realize that leaving out the REM would cause it to try to tokenize the line, and turn any BASIC keyword into a token, saving even more memory. If your comment included words like PRINT, OR, ELSE, etc., you’d save even more room!

As you can see, because this comment uses the word PRINT (five characters), the version without the REM appears to save six bytes — it saves the apostrophe (two bytes, or would save “REM(space)” for two bytes) plus tokenizes the PRINT keyword down from five bytes to one (saving four more bytes).

Interesting BASIC interpreter abuse, isn’t it? As long as you never run this line, you might save memory by leaving our REM (depending on if you use any keywords). I could imaging comments saying “SHOW THE USER NAME” changed to “PRINT THE USR NAME” to tokenize two words (PRINT and USR).

You would still need REM at the start of the code for any initial comments, and during the code, but for subroutines you could do this:

10 REM THIS IS MY PROGRAM
20 A$="HELLO, WORLD!":GOSUB 1010
999 END
1000 PRINT THE MESSAGE
1010 PRINT A$:RETURN

The GOSUB jumps to 1010 and can find it, and since the program would END before reaching 1000, that would work.

With great power comes great responsibility. Use this wisely :) and thanks, Diego, for noticing this.

Until next time…