Hitchhiker’s Guide to the Galaxy is 42 years old?

I just heard that the late Douglas AdamsHitchhiker’s Guide to the Galaxy radio play is turning 42 years old this year! According to the always-accurate Wikipedia, it was first broadcast on March 8, 1978.

I did not learn about Hitchhiker’s Guide until a few years later.

I was reading the TV Guide and saw a listing for something called “The Hitchhiker’s Guide to the Galaxy” on PBS channel 8 in Houston, Texas. I watched it, and learned it was a British sci-fi comedy series with production quality (ahem) similar to Doctor Who. PBS had introduced me to Tom Baker‘s Doctor years earlier.

The next day, in (I think) my 7th grade English class, I quoted one of the lines from the TV series. A boy sitting in front of me turned around and said something like “you saw that too?” That boy was Jimmy, and at that point the direction of my life changed forever.

If memory is correct, Jimmy loaned me his Hitchhikers’ book. Little did I know the impact that being introduced to the humor of Douglas Adams would have on me. I was an instant fan.

Jimmy and I became friends, and he introduced me to computers and BASIC programming. (Though the first time I ever “saw” a computer in someone’s home was in 1979 or 80, when I lived in Dallas, Texas, and my next door neighbor had a TI-99 because him mom worked for Texas Instruments. But I digress.)

We’d go down to the local Radio Shack and type in programs on their TRS-80 Model 3. I’d been inside Radio Shacks many times with my dad during the 1970s, but this is what got me going there on my own.

Being exposed to computers is what led me to getting my first home computer, a Commodore VIC-20.

Being exposed to Radio Shack (I would hang out there any time my grandmother took me shopping near one) is what led me to get rid of my VIC-20 and get my first TRS-80 Color Computer.

Getting my first “CoCo” led me to getting a second one, and a third, and then starting my first software company, Sub-Etha Software.

Starting that company got me to go to my first CoCoFest in Atlanta in 1990.

Going to that CoCoFest where so many people asked “does it run under OS-9” got me to learn the OS-9 operating system.

Learning the OS-9 operating system is what led me to getting my first “real” job at Microware in Des Moines, Iowa.

And so on…

If it had not been for seeing that listing in TV Guide, and then quoting a line from it that was head by Jimmy, I think I would have had a far different life.

Thank you, TV Guide, for introducing me to the Hitchhiker’s TV show. And thank you, Jimmy, for introducing me to Douglas Adams, computers, and phone phreaking.

And happy birthday, Hitchhiker’s Guide to the Galaxy! I’ve listened to your radio shows, read your books, played your computer game, watched your movie, and look forward to seeing what HULU does with you in their new 2021 TV series.

Don’t panic!

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.

Color BASIC scaling demo.

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!

Adding gravity to a BASIC bouncing ball.

Using this Color BASIC code as a reference:

0 REM gravity.bas
10 CLS
20 X=1:Y=1:XM=1:YM=1
30 PRINT@P," ";:P=X+Y*&H20:PRINT@P,"O";
50 X=X+XM:IF X<&H1 OR X>&H1E THEN XM=-XM
60 Y=Y+YM:IF Y<&H1 OR Y>&HE THEN YM=-YM
80 GOTO 30

…how would you add simulated gravity to the bounce? When I was a teen, I did this on my CoCo 3. I forget how I did it, but here is what I tried tonight:

0 REM gravity.bas
10 CLS
20 X=1:Y=1:XM=1:YM=.25
30 PRINT@P," ";:P=X+INT(Y)*&H20:PRINT@P,"O";
50 X=X+XM:IF X<&H1 OR X>&H1E THEN XM=-XM
60 Y=Y+YM:IF Y<&H1 OR Y>&HE THEN YM=-YM:Y=Y+YM
70 YM=YM+.25
80 GOTO 30

But on a text screen, the “jump” is large enough when it’s near the bottom that it never actually hits the bottom of the screen. In the CoCo 3’s high-resolution screen, this wasn’t an issue. With only 16 horizontal positions, it’s quite limited.

I’m sure there’s a real clever way to do this. Any thoughts?

CoCo bouncing BASIC ball, part 5

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

It seems any time I touch BASIC these days, it turns into a benchmarking session to see if I can do something faster.My Jim Gerrie-inspired bouncing ball program has taken quite a tangent, and today it not going to change that.

MC-10 has its advantages

As previously discussed, PRINT@ seems to be the fastest way to put characters on the screen. But what if you want something that’s not just text? In Jim’s MC-10 demo, he uses the semi graphics characters in his ball. The MC-10’s BASIC allowed you to type those characters similarly to how Commodore computers let you type in their PETASCII characters. The excellent MC-10 Javascript Emulator has this image showing the keyboard layout:

MC-10 keyboard layout (image from MC-10.com).

If you look at the keys, you will see some contain graphics blocks next to the letter (Q and a solid block, F and checkerboard, etc.). You can generate them with SHIFT-Letter. You also see some keywords above the keys which you could generate by doing CONTROL-Letter. This let them type in graphics characters in a PRINT statement:

MC-10.com emulator showing how to “type” demographics characters.

Advantage MC-10. We have no way to do that on the CoCo.

PRINT CHR$()

So how do we print the graphics characters? We use CHR$() which will print whatever character we tell it to. For example, letter “A” is ASCII 65. We could type:

PRINT CHR$(65)

…and it would print the letter A.

Our graphics characters start at 128 and go to 255, looping the same basic shapes through the 8 available colors (color + black). We can see them all by typing:

FOR A=128 TO 255:PRINT CHR$(A);:NEXT A
Using PRINT CHR$() to print the CoCo semi graphics characters.

If I knew which characters to use to draw a ball, I could print them using CHR$(). Unfortunately, I don’t. I have no idea where my old CoCo “quick guide” is from the 1980s that listed them all. Fortunately, Simon Jonassen has a website that lets us design semi graphics:

http://cocobotomy.roust-it.dk/sgedit/

Using my previous text ball for reference, I want to make a semi graphics ball that is 10×7 characters (so it appears round on the 32×16 4:3 aspect ratio display…). Using Simon’s tool, I came up with this:

http://cocobotomy.roust-it.dk/sgedit/

It’s not a great ball, but it gives me something to start with.

On the bottom right of this web page are buttons to spit out the assembly, BASIC or CSV “code” to display this. But, it’s the whole screen, and looks like this:

10 CLEAR2000:DIMT,A:CLS
20 FORT=1024TO1535:READA:POKET,A:NEXT
100 A$=INKEY$:IFA$="" THEN100
1000 DATA 128,161,166,172,172,172,172,169,162,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128
1010 DATA 161,168,128,128,128,128,128,128,164,162,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128
1020 DATA 170,128,128,128,128,128,128,128,128,165,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128
1030 DATA 170,128,128,128,128,128,128,128,128,165,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128
1040 DATA 170,128,128,128,128,128,128,128,128,165,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128
1050 DATA 164,162,128,128,128,128,128,128,161,168,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128
1060 DATA 128,164,169,163,163,163,163,166,168,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128
1070 DATA 128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128
1080 DATA 128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128
1090 DATA 128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128
1100 DATA 128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128
1110 DATA 128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128
1120 DATA 128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128
1130 DATA 128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128
1140 DATA 128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128
1150 DATA 128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128

That program, when ran, would draw the VDG semi graphics screen. But I only want the ball at the top left, so I should be able to find the values for that.

Side Note: Hey, Simon! I don’t think the CLEAR 2000 is necessary. That’s only used for strings. And since you aren’t using A$ for anything (you don’t DIM it either, I notice), you could do 100 IF INKEY$=”” THEN 100 instead and eliminate that variable. Also, generating the values as HEX would make it draw the screen faster. (Heh, force-of-habit when I write these articles. Simon is one of the most amazing CoCo programmers out there, and in one of my earlier articles, he contributed enhancements to my attempts at assembly code. This is about as “helpful” as I could ever be for someone as talented as Simon.)

There seems to be 16 DATA statements, each containing 32 values. Thus, the first seven DATAs look to be the first seven lines of the screen, and the first 10 values of each of those should be the 10 values for my ball. This gives me the following values:

1000 DATA 128,161,166,172,172,172,172,169,162,128
1010 DATA 161,168,128,128,128,128,128,128,164,162
1020 DATA 170,128,128,128,128,128,128,128,128,165
1030 DATA 170,128,128,128,128,128,128,128,128,165
1040 DATA 170,128,128,128,128,128,128,128,128,165
1050 DATA 164,162,128,128,128,128,128,128,161,168
1060 DATA 128,164,169,163,163,163,163,166,168,128

Those are the numbers I’d use to PRINT CHR$() that ball. I’ll first try it like this:

30 PRINT@P+0,CHR$(128);CHR$(161);CHR$(166);CHR$(172);CHR$(172);CHR$(172);CHR$(172);CHR$(169);CHR$(162);CHR$(128);
31 PRINT@P+32,CHR$(161);CHR$(168);CHR$(128);CHR$(128);CHR$(128);CHR$(128);CHR$(128);CHR$(128);CHR$(164);CHR$(162);
32 PRINT@P+64,CHR$(170);CHR$(128);CHR$(128);CHR$(128);CHR$(128);CHR$(128);CHR$(128);CHR$(128);CHR$(128);CHR$(165);
33 PRINT@P+96,CHR$(170);CHR$(128);CHR$(128);CHR$(128);CHR$(128);CHR$(128);CHR$(128);CHR$(128);CHR$(128);CHR$(165);
34 PRINT@P+128,CHR$(170);CHR$(128);CHR$(128);CHR$(128);CHR$(128);CHR$(128);CHR$(128);CHR$(128);CHR$(128);CHR$(165);
35 PRINT@P+160,CHR$(164);CHR$(162);CHR$(128);CHR$(128);CHR$(128);CHR$(128);CHR$(128);CHR$(128);CHR$(161);CHR$(168);
36 PRINT@P+192,CHR$(128);CHR$(164);CHR$(169);CHR$(163);CHR$(163);CHR$(163);CHR$(163);CHR$(166);CHR$(168);CHR$(128);

Using P as the starting PRINT@ (0 for the top left of the screen), each line will print the ten CHR$() values of the ball, then the next line will print at “P+32”, making it the next line down, and so on.

0 REM BALLVDG.BAS
5 DIM TE,TM,B,A,TT
10 FORA=0TO3:TIMER=0:TM=TIMER
20 FORB=0TO1000
30 PRINT@P+0,CHR$(128);CHR$(161);CHR$(166);CHR$(172);CHR$(172);CHR$(172);CHR$(172);CHR$(169);CHR$(162);CHR$(128);
31 PRINT@P+32,CHR$(161);CHR$(168);CHR$(128);CHR$(128);CHR$(128);CHR$(128);CHR$(128);CHR$(128);CHR$(164);CHR$(162);
32 PRINT@P+64,CHR$(170);CHR$(128);CHR$(128);CHR$(128);CHR$(128);CHR$(128);CHR$(128);CHR$(128);CHR$(128);CHR$(165);
33 PRINT@P+96,CHR$(170);CHR$(128);CHR$(128);CHR$(128);CHR$(128);CHR$(128);CHR$(128);CHR$(128);CHR$(128);CHR$(165);
34 PRINT@P+128,CHR$(170);CHR$(128);CHR$(128);CHR$(128);CHR$(128);CHR$(128);CHR$(128);CHR$(128);CHR$(128);CHR$(165);
35 PRINT@P+160,CHR$(164);CHR$(162);CHR$(128);CHR$(128);CHR$(128);CHR$(128);CHR$(128);CHR$(128);CHR$(161);CHR$(168);
36 PRINT@P+192,CHR$(128);CHR$(164);CHR$(169);CHR$(163);CHR$(163);CHR$(163);CHR$(163);CHR$(166);CHR$(168);CHR$(128);
70 NEXT
80 TE=TIMER-TM:PRINTA,TE
90 TT=TT+TE:NEXT:PRINTTT/A:END

When this runs, you can SEE it PRINT the ball character-by-character! This is very slow. My benchmark took “forever” to run, reporting 26133 (at 60 ticks per second, that’s over 7 minutes to draw that 1001 times). If you take 26133 / 1001 (I really need to change that loop to be 0 to 999) you get 26.10 “ticks” per time. Divide that by 60 (per tick) you get .43. So it’s taking almost half a second to draw seven lines of ten characters each using CHR$() for each character. (Plus overhead of PRINT@ and such).

We need our ball to bounce faster than that.

We have discussed how switching from decimal to hex will speed things up, so let’s try that:

30 PRINT@P+&H0,CHR$(&H80);CHR$(&HA1);CHR$(&HA6);CHR$(&HAC);CHR$(&HAC);CHR$(&HAC);CHR$(&HAC);CHR$(&HA9);CHR$(&HA2);CHR$(&H80);
31 PRINT@P+&H20,CHR$(&HA1);CHR$(&HA8);CHR$(&H80);CHR$(&H80);CHR$(&H80);CHR$(&H80);CHR$(&H80);CHR$(&H80);CHR$(&HA4);CHR$(&HA2);
32 PRINT@P+&H40,CHR$(&HAA);CHR$(&H80);CHR$(&H80);CHR$(&H80);CHR$(&H80);CHR$(&H80);CHR$(&H80);CHR$(&H80);CHR$(&H80);CHR$(&HA5);
33 PRINT@P+&H60,CHR$(&HAA);CHR$(&H80);CHR$(&H80);CHR$(&H80);CHR$(&H80);CHR$(&H80);CHR$(&H80);CHR$(&H80);CHR$(&H80);CHR$(&HA5);
34 PRINT@P+&H80,CHR$(&HAA);CHR$(&H80);CHR$(&H80);CHR$(&H80);CHR$(&H80);CHR$(&H80);CHR$(&H80);CHR$(&H80);CHR$(&H80);CHR$(&HA5);
35 PRINT@P+&HA0,CHR$(&HA4);CHR$(&HA2);CHR$(&H80);CHR$(&H80);CHR$(&H80);CHR$(&H80);CHR$(&H80);CHR$(&H80);CHR$(&HA1);CHR$(&HA8);
36 PRINT@P+&HC0,CHR$(&H80);CHR$(&HA4);CHR$(&HA9);CHR$(&HA3);CHR$(&HA3);CHR$(&HA3);CHR$(&HA3);CHR$(&HA6);CHR$(&HA8);CHR$(&H80);

This looks a tiny bit faster. The benchmark reports 14790 (which breaks down to .24 seconds each time). That’s almost twice as fast (well, .24 to .44) but still not fast enough.

The only other thing we could do would be to remove all the in-between semicolons, since they aren’t actually needed to print the characters side-by-side (except for the last one, since we don’t want it to clear the rest of the screen line):

30 PRINT@P+&H0,CHR$(&H80)CHR$(&HA1)CHR$(&HA6)CHR$(&HAC)CHR$(&HAC)CHR$(&HAC)CHR$(&HAC)CHR$(&HA9)CHR$(&HA2)CHR$(&H80);
31 PRINT@P+&H20,CHR$(&HA1)CHR$(&HA8)CHR$(&H80)CHR$(&H80)CHR$(&H80)CHR$(&H80)CHR$(&H80)CHR$(&H80)CHR$(&HA4)CHR$(&HA2);
32 PRINT@P+&H40,CHR$(&HAA)CHR$(&H80)CHR$(&H80)CHR$(&H80)CHR$(&H80)CHR$(&H80)CHR$(&H80)CHR$(&H80)CHR$(&H80)CHR$(&HA5);
33 PRINT@P+&H60,CHR$(&HAA)CHR$(&H80)CHR$(&H80)CHR$(&H80)CHR$(&H80)CHR$(&H80)CHR$(&H80)CHR$(&H80)CHR$(&H80)CHR$(&HA5);
34 PRINT@P+&H80,CHR$(&HAA)CHR$(&H80)CHR$(&H80)CHR$(&H80)CHR$(&H80)CHR$(&H80)CHR$(&H80)CHR$(&H80)CHR$(&H80)CHR$(&HA5);
35 PRINT@P+&HA0,CHR$(&HA4)CHR$(&HA2)CHR$(&H80)CHR$(&H80)CHR$(&H80)CHR$(&H80)CHR$(&H80)CHR$(&H80)CHR$(&HA1)CHR$(&HA8);
36 PRINT@P+&HC0,CHR$(&H80)CHR$(&HA4)CHR$(&HA9)CHR$(&HA3)CHR$(&HA3)CHR$(&HA3)CHR$(&HA3)CHR$(&HA6)CHR$(&HA8)CHR$(&H80);

This removes the extra time it takes BASIC to parse (and skip) NINE semicolons on each line (times ten lines). That adds up, but removing them only increases the benchmark to 14542 — barely measurable.

I don’t see a faster way to do this using PRINT CHR$() over and over and over and over again.

Definition of insanity…

To avoid all the time it takes for BASIC to parse each CHR$() over and over and over and over, we can do that just once and store the result in a string and print that string instead. I’ll use one-letter string names, unique for each line, for speed. It would be “easier” to use an array (like BL$(7) or something) but I’ve previously explored that and found array access to be slower.

Since this is a demo, we’ll do it the silly way, like this:

A$=CHR$(&H80)+CHR$(&HA1)+CHR$(&HA6)+CHR$(&HAC)+CHR$(&HAC)+CHR$(&HAC)+CHR$(&HAC)+CHR$(&HA9)+CHR$(&HA2)+CHR$(&H80)

B$=CHR$(&HA1)+CHR$(&HA8)+CHR$(&H80)+CHR$(&H80)+CHR$(&H80)+CHR$(&H80)+CHR$(&H80)+CHR$(&H80)+CHR$(&HA4)+CHR$(&HA2)

C$=CHR$(&HAA)+CHR$(&H80)+CHR$(&H80)+CHR$(&H80)+CHR$(&H80)+CHR$(&H80)+CHR$(&H80)+CHR$(&H80)+CHR$(&H80)+CHR$(&HA5)

D$=CHR$(&HAA)+CHR$(&H80)+CHR$(&H80)+CHR$(&H80)+CHR$(&H80)+CHR$(&H80)+CHR$(&H80)+CHR$(&H80)+CHR$(&H80)+CHR$(&HA5)

E$=CHR$(&HAA)+CHR$(&H80)+CHR$(&H80)+CHR$(&H80)+CHR$(&H80)+CHR$(&H80)+CHR$(&H80)+CHR$(&H80)+CHR$(&H80)+CHR$(&HA5)

F$=CHR$(&HA4)+CHR$(&HA2)+CHR$(&H80)+CHR$(&H80)+CHR$(&H80)+CHR$(&H80)+CHR$(&H80)+CHR$(&H80)+CHR$(&HA1)+CHR$(&HA8)

G$=CHR$(&H80)+CHR$(&HA4)+CHR$(&HA9)+CHR$(&HA3)+CHR$(&HA3)+CHR$(&HA3)+CHR$(&HA3)+CHR$(&HA6)+CHR$(&HA8)+CHR$(&H80)

Now we can just print those strings and, instead of BASIC having to parse and generate seventy CHR$()s each time, it will just have to look up and print seven strings. This should be much faster!

I made some room in my BENCH.BAS program to fit this strings in at the top, and it now looks like this:

0 REM BALLVDG3.BAS
1 DIM TE,TM,B,A,TT
2 A$=CHR$(&H80)+CHR$(&HA1)+CHR$(&HA6)+CHR$(&HAC)+CHR$(&HAC)+CHR$(&HAC)+CHR$(&HAC)+CHR$(&HA9)+CHR$(&HA2)+CHR$(&H80)
3 B$=CHR$(&HA1)+CHR$(&HA8)+CHR$(&H80)+CHR$(&H80)+CHR$(&H80)+CHR$(&H80)+CHR$(&H80)+CHR$(&H80)+CHR$(&HA4)+CHR$(&HA2)
4 C$=CHR$(&HAA)+CHR$(&H80)+CHR$(&H80)+CHR$(&H80)+CHR$(&H80)+CHR$(&H80)+CHR$(&H80)+CHR$(&H80)+CHR$(&H80)+CHR$(&HA5)
5 D$=CHR$(&HAA)+CHR$(&H80)+CHR$(&H80)+CHR$(&H80)+CHR$(&H80)+CHR$(&H80)+CHR$(&H80)+CHR$(&H80)+CHR$(&H80)+CHR$(&HA5)
6 E$=CHR$(&HAA)+CHR$(&H80)+CHR$(&H80)+CHR$(&H80)+CHR$(&H80)+CHR$(&H80)+CHR$(&H80)+CHR$(&H80)+CHR$(&H80)+CHR$(&HA5)
7 F$=CHR$(&HA4)+CHR$(&HA2)+CHR$(&H80)+CHR$(&H80)+CHR$(&H80)+CHR$(&H80)+CHR$(&H80)+CHR$(&H80)+CHR$(&HA1)+CHR$(&HA8)
8 G$=CHR$(&H80)+CHR$(&HA4)+CHR$(&HA9)+CHR$(&HA3)+CHR$(&HA3)+CHR$(&HA3)+CHR$(&HA3)+CHR$(&HA6)+CHR$(&HA8)+CHR$(&H80)

10 FORA=0TO3:TIMER=0:TM=TIMER
20 FORB=0TO1000

30 PRINT@P+&H0,A$;
31 PRINT@P+&H20,B$;
32 PRINT@P+&H40,C$;
33 PRINT@P+&H60,D$;
34 PRINT@P+&H80,E$;
35 PRINT@P+&HA0,F$;
36 PRINT@P+&HC0,G$;

70 NEXT
80 TE=TIMER-TM:PRINTA,TE
90 TT=TT+TE:NEXT:PRINTTT/A:END

The benchmark now reports 3200! That’s a huge improvement from the original 26133. I think this is about as fast as we can get… at least using strings.

But, for this demo, I wanted to have several frames of animation. If I make a bunch of strings, that’s going to slow things down since there will be more strings to search through. Also, I’ll run out of single-character variables names and might have to do things like A1$, A2$, A3$, etc. for the first frame, and B1$, B2$, B3$, etc. for the second frame, and so on. While this would STILL be faster than doing a bunch of PRINT CHR$(), and I expect still faster than using arrays like F$(0) through F$(6).

If I was less impatient, I’d test that, and even try a double dimension array like F$(frame, line) which would be really easy and look really nice … but would probably be be slower than anything but PRINT CHR$()s…

Note to Self: Write an article about using multi-dimensioned arrays to do simple animation in BASIC.

But I’m impatient, so now let’s circle back to the start of this post where I mentioned the MC-10 being able to embed characters in its PRINT statements directly without needing variables.

We can’t type those graphics characters on the CoCo, but if we don’t mind cheating a bit, we can modify the contents of a program so that the quoted string contains special graphic characters. It makes lines that do that impossible to edit, and print (on most printers), but if it’s just a demo (or some program you write for people to JUST run and not mess with), it works.

Self-modifying BASIC code

Suppose we had a print statement like this:

10 PRINT "**********";

…and we wanted to change those ten asterisks to be a graphics character. If we knew where they were located in BASIC memory, we could POKE the values and change them from a 42 (ASCII for ‘*’) to something else, like a 128 for the solid black block graphics character.

As a kid, I did this in a pretty brute-force way, blindly PEEKing through program memory and changing values to what I wanted them to be. This sometimes had dangerous side effects if the value I was PEEKing for (like 42) appeared as part of a BASIC keyword token or something not inside the quoted string.

So, let’s try to be a bit smarter and scan through the program memory but only look for values between quotes.

If I recall, memory locations 25 and 26 contain the start of the BASIC program. You can get that address like this:

PRINT PEEK(25)*256+PEEK(26)

The end of the program is at 27 and 28:

PRINT PEEK(27)*256+PEEK(28)

It should be super easy (barely an inconvenience) to make a program that PEEKs memory between that range and looks for a 34 (the quote character) and then will start substituting our source character (42, the asterisk) for our target character (128, a black block).

10 PRINT "**********"
20 END
100 ST=PEEK(25)*256+PEEK(26)
110 EN=PEEK(27)*256+PEEK(28)
120 QF=0 'QOUTE FOUND FLAG
130 FOR A=ST TO EN
140 IF PEEK(A)=32 THEN IF QF=1 THEN QF=0 ELSE QF=1
150 IF QF=1 THEN IF PEEK(A)=42 THEN POKE A,128
160 NEXT

If you load this program and RUN it, it will print a line of ten asterisks.

Then if you RUN 100, it will do the search/replace looking for asterisks between quotes and changing them to 128s (black block).

One that is done, RUN again and you see it now prints a row of ten black blocks!

A self-modifying CoCo BASIC program.

From this point on, that line 10 has been forever changed. If you LIST it, you will see weirdness. In this case, line 10 says:

10 PRINT "FORFORFORFORFORFORFORFORFORFOR"

…because apparently that byte of 128 is the token for the keyword FOR.

If you try to EDIT LINE 10, BASIC turns the tokens back into ASCII text for you to edit. Thus, as soon as you edit, you are changing that line to say “FORFORFORFOR…” instead of the graphics characters.

Thus, don’t edit a line after you do this trick!

I think this is a good stopping point for today. My goal here is to switch from my ball print ASCII “X” characters to graphics blocks, and retain the speed of raw PRINTs rather than using a ton of variables that have to be looked up each time — and the more variables, the slower that lookup gets.

But there’s more ASCII fun to be had before I start doing this.

To be continued…

CoCo bouncing BASIC ball, part 4

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

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…
Visual Studio Code with the COLOR BASIC extension, loading in BASIC into the Xroar emulator.

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…

CoCo bouncing BASIC ball, part 3

See also: part 1 and part 2

Math versus DATA: FIGHT!

In the previous post, I showed the simple way I would bounce a ball around the screen by using X and Y coordinates and converting them to PRINT@ screen position, and then using an X Movement and Y Movement variable to control where the ball went next.

But, since this is a demo, we don’t actually need to calculate anything realtime. We could have all the positions stored in DATA statements, and just READ them as the program ran. This would also allow fancier movement patterns, such as bouncing with gravity.

Yes, it’s cheating. But is it faster? Let’s find out. Here is some code that repeatedly reads a location from DATA statements then displays an “*” at that position.

6 P=0
30 READP:IFP=&HFFF THENRESTORE:GOTO30
31 PRINT@P,"*";
1000 DATA&H1,&H2,&H3,&H4,&H5,&H6,&H7,&H8,&HFFFF

The above code is inserted in to my BENCH.BAS program.

In line 30, we read a value from the DATA statements. If that value is &HFFFF (65535), RESTORE is used to rewind the READ so the next time it happens it looks for the first DATA statement. The GOTO causes it to try the READ again (thus, restarting with the first bit of data when it runs out of DATA).

Line 31 just prints our ball at whatever position was in the DATA statement.

Pretty simple.

Running this shows that reading 8 data values then rewinding over and over again (1000 times total) takes about 768. That’s a huge improvement of calculating the X and Y each time (1842). Thus, we should be able to pre-calculate the ball positions and go from there.

Writing code that generates code

We can write some code that writes an ASCII (text) file to disk (or tape) that contains numbers lines of BASIC which could be loaded (or MERGED from disk) later. Let’s start by just PRINTing out the lines we’d want to generate:

5 X=0:Y=0:XM=1:YM=1
10 LN=1000
20 LN$=STR$(LN)+" DATA"
30 P=X+Y*32
40 IF LEN(LN$)<240 THEN LN$=LN$+"&H"+HEX$(P)
50 IF LEN(LN$)<239 THEN LN$=LN$+"," ELSE PRINTLN$:LN=LN+10:GOTO 20
60 X=X+XM:IFX<1ORX>30THENXM=-XM
70 Y=Y+YM:IFY<1ORY>14THENYM=-YM
80 GOTO30

When you run that, it starts printing out lines of DATA statements containing hex values:

1000 DATA&H0,&H21,&H42,&H63,&H84,&HA5,&HC6,
   &HE7,&H108,&H129,&H14A,&H16B,&H18C,&H1AD,
   &H1CE,&H1EF,&H1D0,&H1B1,&H192,&H173,&H154,
   &H135,&H116,&HF7,&HD8,&HB9,&H9A,&H7B,&H5C,
   &H3D,&H1E,&H3F,&H5E,&H7D,&H9C,&HBB,&HDA,
   &HF9,&H118,&H137,&H156,&H175,&H194

1010 DATA&H194,&H1B3,&H1D2,&H1F1,&H1D0,&H1AF,
   &H18E,&H16D,&H14C,&H12B,&H10A,&HE9,&HC8,
   &HA7,&H86,&H65,&H44,&H23,&H2,&H21,&H40,
   &H61,&H82,&HA3,&HC4,&HE5,&H106,&H127,
   &H148,&H169,&H18A,&H1AB,&H1CC,&H1ED,
   &H1CE,&H1AF,&H190,&H171,&H152,&H133,&H114

All we’d have to do is figure out how many positions we want, and then print these lines to an ASCII file on disk or tape instead of to the screen. For instance, if we start at position 0, maybe we generate values until we bounce back to position 0. (To make things easier, I’m going to start at 1,1 and end when it gets back to 0).

0 CLEAR1000
5 X=1:Y=1:XM=1:YM=1
10 LN=1000
15 OPEN "O",#1,"DATA.ASC"
20 LN$=STR$(LN)+" DATA"
30 P=X+Y*32
31 PRINTP;
35 IF P=0 THEN CLOSE#1:END
40 IF LEN(LN$)<240 THEN LN$=LN$+"&H"+HEX$(P)
50 IF LEN(LN$)<239 THEN LN$=LN$+"," ELSE PRINT#1,LN$:LN=LN+10:GOTO 20 60 X=X+XM:IFX<1ORX>30THENXM=-XM
70 Y=Y+YM:IFY<1ORY>14THENYM=-YM
80 GOTO30

This program will produce a text file called DATA.ASC containing all the positions the ball will be in until it loops back to the top left corner of the screen. This can then be loaded (LOAD”DATA.ASC”) into BASIC. (Disk BASIC allows MERGE”DATA.ASC” to merge those lines in with whatever BASIC program is already there, just as if they were typed in by hand.)

With this pre-calculated data, all we have to do is just read a position, then display the ball there.

10 CLS
20 READP:IFP=&HFFFF THENRESTORE:GOTO20
30 PRINT@P,"*";:GOTO20
5000 DATA&HFFFF

Note I needed to add the final &HFFFF, but I should have made the DATA generator program add that before closing the file.

Those lines and all the generated DATA statements make a blazing fast bouncing ball with no math involved – just the time it takes to READ a value from DATA statements.

With this proof-of-concept, the next step will be seeing if this can speed up printing a large block of text for a huge ball.

To be continued…

CoCo bouncing BASIC ball, part 2

See also: part 1

Math is hard, but some is easier.

Since it seems we might be needing math to move the ball around, let’s revisit some benchmarks on math to see which is faster. Using my BENCH.BAS program:

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

…let’s declare a temporary variable, and then see how fast it is to add different values.

6 Z=0
30 Z=Z+1

Adding decimal 1 gives us about 280.

Changing that to hex 1 (Z=Z+&H1) is basically the same.

BUT, adding 1 would just be moving on byte to the right. If we were moving down and to the right, that would be adding 33.

Z=Z+33 produces 355. It’s having to do much more work to convert two decimal digits.

Changing that to Z=Z+&H21 results in 278. It seems adding two hex digits is faster than adding one decimal digit :-)

Obviously, any math we want to do should be done using hex. But what math do we need?

Let’s start with a simple example that tries to “bounce” a single character around the screen.

Bounce this

As a kid, I would do this with an X and Y, which I would then convert to a screen position like this:

PRINT@X+Y*32,"*";

I would then use variables for “X Movement” (XM) and “Y Movement” (YM) and add them to X and Y each time:

X=X+XM:IF X<1 OR X>30 THEN XM=-XM
Y=Y+YM:IF Y<1 OR Y>14 THEN YM=-YM

There are problems with this approach (like, when it hits the bottom right of the screen, it scrolls up, and I’m also not erasing the “*”), but it’s good enough for a benchmark test:

6 X=0:Y=0:XM=1:YM=1
30 PRINT@X+Y*32,"*";
31 X=X+XM:IFX<1ORX>30THENXM=-XM
32 Y=Y+YM:IFY<1ORY>14THENYM=-YM

This produces 2047. If we change all the values to hex:

6 X=0:Y=0:XM=1:YM=1
30 PRINT@X+Y*&H20,"*";
31 X=X+XM:IFX<&H1ORX>&H1E THENXM=-XM
32 Y=Y+YM:IFY<&H1ORY>&HE THENYM=-YM

Note I had to add spaces after the &H1E and &HE since BASIC can’t tell that’s the end of a value before parsing the next keyword (“THEN”).

This one change improves the speed to 1842. A better way would be to eliminate the X and Y conversion completely, and just track one position (say, the top left corner). But without an X and Y, how do you know when you’ve hit the edge?

Since this is a demo, perhaps we don’t have to.

To be continued…

CoCo Cross Developing with MS Visual Studio Code

I just wanted to post a note here about Microsoft’s Visual Studio Code cross-platform editor. It is available for Windows, Mac and Linux, though I have so-far only used it on Mac and Windows:

https://code.visualstudio.com

It supports extensions and there are several CoCo-related ones available:

  • CoCoTools by Jason Pittman. This provides some level on integration with the Windows-based VCC CoCo emulator, as well as lwasm assembler, Toolshed CoCo disk tools, and cmoc C compiler. I just found this today and have not used it. It says it can do things like RENUM BASIC files, which could be useful.
  • Color BASIC by Tandy. By Tandy, you say? Yes, Tandy UK! This color-codes BASIC program listings. This is what I have been using for my Mac-based BASIC editing.
  • 6809 and 6309 Assembly by Tandy. This one color-codes assembly source.
  • 6×09 Assembly by Blair Leduc. This one also color-codes assembly source.

Visual Studio Code offers some IDE features, allowing extensions to launch compilers/assemblers and even run them. It looks like CoCoTools does this, so I look forward to trying it out soon.

Until next time…

CoCo bouncing BASIC ball, part 1

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

Jim Gerrie’s BASIC bouncing ball for the MC-10.

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…

Marc Andreessen (Netscape) was a CoCo user!

Over in the Facebook Color Computer group, Jerry Stratton discovered that Marc Andreessen, co-founder of Netscape, was a CoCo user! Jerry ran across an April 1987 issue where Marc wrote in looking for CoCo pen-pals!

April 1987 Rainbow Magazine.

Here’s that issue, scanned and searchable, if you want to see who else might have been writing in:

http://www.colorcomputerarchive.com/coco/Documents/Magazines/Rainbow%2C%20The%20%28Searchable%20image%29/The%20Rainbow%20Vol.%2006%20No.%2009%20-%20April%201987.pdf