When I moved from my Commodore VIC-20 to a TRS-80 Color Computer, I spent much time going through the “Getting Started with Color BASIC” and “Getting Started with Extended Color BASIC” manuals that came with it.

If you had the original manual revision, you may have been taught things slightly different from later editions. For instance, clearing the screen. The CLS command can be followed by a number to fill the screen with a color.

But the early edition manual demonstrated this using parenthesis, which I’ve never seen done:

CLS(3)

It works. Try it :)

After a moment of thinking about this, I realized it’s just normal math grouping for numbers, like this:

PRINT 3*(5-1)

The parenthesis make sense there. But they sure look odd if you do this:

PRINT (42)

It works. Try it :)

And whoever wrote the manual was using them for CLS too. But why?

Not too long ago, I learned that the BASIC ROMs had other undocumented syntax. For instance, there is a Syntax for the PRINT command where you give a screen position using the @ symbol:

PRINT @96,"HELLO"

But the BASIC ROMs also look for (but do not require) the @ symbol after keywords LINE@, PAINT@, GET@ and PUT@. But I’ve never seen anyone code:

LINE@(0,0)-(255,191),PSET

It works. Try it :)

I expect there are other oddities in there, as well. One I recently discovered, just by trying it, had to do with device numbers.

Device numbers

I was surprised to find that the original Color BASIC manual did not cover all of the commands available. For example, printer listing with LLIST and PRINT#-2, or opening and reading/writing to/from cassettes. I expect later revisions may have added these, and maybe other, missing commands.

Folks using a printer learned that, while PRINT by itself goes to the screen, doing PRINT#-2 makes the output go to the printer.

#-2 is a device number. When accessing a cassette file, device #-1 is used:

OPEN "O",#-1,"TAPEFILE"
PRINT #-1,"THIS GOES TO THE CASSETTE FILE"
CLOSE #-1

Disk Extended Color BASIC added disk device numbers, and allowed opening up to ten files at a time using devices #1 to #10.

OPEN "O",#1,"DISKFILE.TXT"
PRINT #1,"THIS GOES TO A DISK FILE"
CLOSE #1

At some point, I became aware that device #0 was the screen. The use of it was optional, since PRINT by itself assumed screen.

PRINT "THIS GOES TO THE SCREEN"
PRINT #0,"SO DOES THIS"

It works. Try it :)

But, it was useful when creating a program that allowed the user to select output to screen or printer.

10 INPUT "OUTPUT TO S)CREEN OR P)RINTER";A$
20 IF A$="S" THEN DV=0
30 IF A$="P" THEN DV=-2
40 PRINT #DV,"THIS GOES TO SCREEN OR PRINTER"

I recall writing programs that would also allow outputting to a tape or disk file, so if one of those options was chosen, I would make sure to create the output file:

10 INPUT "OUTPUT TO S)CREEN, P)RINTER, T)APE OR D)ISK";A$
20 IF A$="S" THEN DV=0
30 IF A$="P" THEN DV=-2
40 IF A$="T" THEN DV=-1:OPEN "O",#-1,"TAPEFILE"
50 IF A$="D" THEN DV=1:OPEN "O",#1,"DISKFILE.TXT"
60 PRINT #DV,"THIS GOES TO... SOMEWHERE!"
70 IF DV=-1 THEN CLOSE #-1
80 IF DV=1 THEN CLOSE #1

Yuck. But you get the idea.

On a whim, I wondered what happened if you tried to CLOSE #0 (nothing). Or CLOSE #-2 (nothing). Then I wondered what happened if you tried to open those devices:

10 OPEN "O",#0,"SCREEN"
20 PRINT #0,"HELLO, SCREEN"
30 CLOSE #0

It appears BASIC just ignores OPEN/CLOSE to the screen device. And the printer:

10 OPEN "O",#-2,"PRINTER"
20 PRINT #-2,"HELLO, PRINTER"
30 CLOSE #-2

This means my multi-output program could have been made much, much simpler:

10 INPUT "OUTPUT TO S)CREEN, P)RINTER, T)APE OR D)ISK";A$
20 IF A$="S" THEN DV=0
30 IF A$="P" THEN DV=-2
40 IF A$="T" THEN DV=-1
50 IF A$="D" THEN DV=1
60 OPEN "O",#DV,"OUTFILE"
60 PRINT #DV,"THIS GOES TO... SOMEWHERE!"
70 CLOSE #DV

The only extra thing one might want to do is name the file different if going to disk (adding an extension), though you can do that to a tape file without error:

OPEN "O",#-1,"TAPE.TXT"

For tape, the filename can be up to 8 characters, with no extension. So the name would be “TAPE.TXT”. But if you had done “OUTPUT.TXT”, the tape name would be “OUTPUT.T” (8 characters). Not pretty, but it works.

Maybe we take care of that with:

10 INPUT "OUTPUT TO S)CREEN, P)RINTER, T)APE OR D)ISK";A$
20 IF A$="S" THEN DV=0
30 IF A$="P" THEN DV=-2
40 IF A$="T" THEN DV=-1
50 IF A$="D" THEN DV=1:EX$=".TXT"
60 OPEN "O",#DV,"OUTFILE"+EX$
60 PRINT #DV,"THIS GOES TO... SOMEWHERE!"
70 CLOSE #DV

That would add an extension (“.TXT”) only for disk files.

Anyway, I thought it was interesting that BASIC allowed OPEN/CLOSE on printer and screen devices, and I expect if I looked at the ROM disassembly, I’d find extra code there that just returns (not doing anything) when those device numbers are used.

Oh, and there is also a device #-3 in Extended Color BASIC, but you can’t do anything with it. That device number seems to be associated with the DLOAD command (which was removed on the CoCo 3) and is just used internally. But that’s the subject of a potential future article…

Until next time…

Updates:

• 2022-06-30 – Added details about adding Mercurial and retrieving source that way. Also added notes about building Toolshed (currently does not work) and NitrOS9.

A quick tutorial on how to get the Lost Wizard LWTOOLS running under Windows. I have tested this under Windows 11.

To build under Windows, you will need to use a compatibility layer that makes Linux-style code work under Windows. Lost Wizard recommends mingw or Cygwin. This tutorial will use Cygwin.

Step 1: Download Cygwin.

Go to https://www.cygwin.com/ and download the current Windows installer. It is called “setup-x86_64.exe“.

Run the installer:

Click Next, then choose “Install from Internet”:

Click Next, then either use the default install location, or customize if you know what you are doing. Same thing for installing for “All Users” or “Just Me.” In my example, I am just using the defaults:

Click Next, then select where it will download files. I will just use the defaults:

Click Next, and just use the default Internet Connection settings unless you know what you are doing and need to change them:

Click Next, then select one of the download sites. It shouldn’t matter which one you choose, but since I used to read the old Maddox website hosted on xmission.com, I selected that:

Click Next, and it will retrieve a list of available packages. For building LWTOOLS, you need a C compiler and “make” utility. I went with the standard GCC compiler and standard make.

Expand the “All” then “Devel” items.

Locate the entry that says “gcc-core” (or use the Search box) and click on the “Skip” to the right of it. It should change from “Skip” to a version number (currently 11.3.0-1 as I type this).

Locate the entry that says “make” and do the same (currently 4.3-1 as I type this).

If you would like to download LWTOOLS (and other items) source directly rather than having to download “the most recent release”, you will also need to install “mercurial“. This will give you the “hg” command used to retrieve the latest source code for the projects. (And if you are doing all of this, might as well do this, too.)

Click Next, and you will see a list of all the required packages that will be download. (When you select an item, this installer will download any other items that are required for the one you selected.)

Click Next, and the download will begin.

When completed, you can click Next and then choose if you want to add a Cygwin icon on your Desktop and/or in the Start Menu. Since you will need to run Cygwin to build LWTOOLS, you may want one or both.

Click Finish. You now have Cygwin!

Step 2: Download and extract the LWtools source code.

You can either download the source code and build that, OR you can use Mercurial to retrieve the latest version of the source (which currently includes a bug fix that is not in the release archive yet). Plus, it saves all the steps of extracting the gzipped tar file in 2b ;-)

For either way, you will want to run “Cygwin64 Terminal” that is now installed. This will open up a console prompt.

You will need to change directories to where you plan to download the LWTOOLS source code. Cygwin translates the Windows directories like “C:\Users\huffm\Downloads” to a Unix-style directory path like “/cygdrive/c/Users/huffm/Downloads” on my system. If you know how to change directories from a Windows Command Prompt, instead of going to “C:\whatever” you would change backslashes to forward slashes, and start with “/cygdrive/c/whatever”

Use the change directory (“cd”) command and change to where you downloaded the LWTOOLS .gz file.

An easy way to get this path is to type the change directory command in the Cygwin terminal window, followed by a space, (“cd “) and then drag the “Downloads” folder from a Windows Explore window IN to the Cygwin Terminal. It will type out the path to whatever folder you drag and drop there:

Press enter, and you should now be in the directory where you downloaded the LWTOOLS file. The Cygwin prompt will change to show you what directory you are in. Mine looks like this:

huffm@Allen-LT /cygdrive/c/Users/huffm/Downloads
$

2a. Use Mercurial to get the latest source.

From that location, enter this mercurial (“hg”) command:

hg clone http://lwtools.projects.l-w.ca/hg/ lwtools

That will retrieve the latest source and place it in a subdirectory called “lwtools” from here you are. Once complete, proceed to Step 3.

2b. Download and extract the latest release.

OR, if you want to manually download the latest release…

Go to http://www.lwtools.ca/ and download the latest version (currently 4.19 as I type this). Save it to wherever you chose, above.

The download will be a gzipped .tar file, so you will need some tool to extract it. You can find something in the Windows Store, or just use a command line utility from Cygwin. For this tutorial, we will use the command line.

From this terminal, many Linux-style commands are available, including gzip (which we will use to extract the LWTOOLS .tar file) and tar (which we will use to un-tar that file).

Extract the .gzip file by typing “gzip -d” (for decompress) followed by the lwtools filename:

gzip -d lwtools-4.19.tar.gz

This should extract the “lwtools-4.19.tar” file in to that directory. Now un-tar that file by typing:

tar -xf lwtools-4.19.tar

That will finally leave you with a directory called “lwtools-4.19” (or whatever version you downloaded.

Step 3: Build and install LWTOOLS

Change directories in to the “lwtools-4.19” directory (or, if you downloaded with Mercurial, in to “lwtools” or whatever you called it):

cd lwtools-4.19

Once you are there, all you need to do is type “make” to begin the build process.

Once complete (it may take awhile), the binaries have been built, but they aren’t located where Cygwin can run them yet. To copy them over in to the proper location, type “make install“:

You now have some new command line programs available from within Cygwin. To verify that they worked, you can try typing them to see if they bring up their usage display. Try typing:

lwasm --usage

If you get back a “Usage:” message, you should now be ready to use LWTOOLS to compile 6809 assembly language for the CoCo.

4. Other things you may want to install

Toolshed is a series of commands for copying files from your PC in to disk image files used by emulators or things like the CoCoSDC.

NOTE: Currently, this will not work. Some rules have changed in the compiler and it will error out. There are about 12 places in the source that can easily be fixed to make it build, but I’m going to wait and see if the Toolshed maintainers have a solution.

hg clone http://hg.code.sf.net/p/toolshed/code toolshed
cd toolshed
make -C build/unix install
cd ..

NitrOS9 is a 6809 (or 6309) operating system based on Microware OS-9/6809.

hg clone http://hg.code.sf.net/p/nitros9/code nitros9
cd nitros9
make dsk

BONUS: Building a simple program.

As a simple test, use a text or code editor to create the following “helloworld.asm” file. You will need to know where you save this file, since you will be typing that on the command line to build it. On my system, I have all my .asm files in a directory, and I just “cd” to that directory from the Cygwin terminal.

* helloasm.asm

    org $3f00

    ldx #message
loop:
    lda ,x+
    beq done
    jsr [$a002]
    bra loop
done:
    rts

message fcc "HELLO WORLD!"
    fcb 13
    fcb 0

This simple program will display the message “HELLO WORLD!”. It does this by using the Color BASIC “CHROUT” ROM call. This code starts by loading X with the address of a text message that is a series of characters, followed by a 13 (carriage return) and a 0 to mark the end of the message. The main loop loads the A register with whatever is at X, and if it is zero it ends. Otherwise, it calls the CHROUT routine indirectly by jumping to the location stored at $a002 in the ROM. It will repeat this until it gets to the 0 at the end of the message.

LWTOOLS can build .bin files that can be transferred to a CoCo (or emulator) on a disk image (using other tools), and then you can LOADM that file and EXEC it:

lwasm helloasm.asm -fdecb -ohelloasm.bin

Above, that takes the input file “helloasm.asm” and compiles it in format “decb” (a .bin binary) and calls the output file “helloasm.bin”. (You’d probably want all uppercase for filenames on the CoCo.) That should give a LOADM-able file to try.

But, a nifty feature of LWTOOLS is the ability to generate a BASIC program that loads the assembly language. Use the format “basic” and make the output file a “.bas” instead:

lwasm helloasm.asm -fbasic -ohelloasm.bas

That will create a text file called “helloasm.bas”:

10 READ A,B
20 IF A=-1 THEN 70
30 FOR C = A TO B
40 READ D:POKE C,D
50 NEXT C
60 GOTO 10
70 END
80 DATA 16128,16155,142,63,14,166,128,39,6,173,159,160,2,32,246,57,72,69,76,76,79,32,87,79,82,76,68,33,13,0,-1,-1

I like to use the XRoar emulator, since it lets me load a text file as if it was a cassette file. You can run XRoar, then use Ctrl-L (or File->Load) then select the “helloasm.bas” file. After that is done, typing “CLOAD” in XRoar will load this text file as if it was coming from tape!

Then you can “RUN” the program and load your assembly in to memory. For this example, the address of $3f00 was specified in the source codes “org” address (16128 in decimal) so that is where the code would load. After the “RUN”, you should be able to type “EXEC &H3f00” (or EXEC 16128 if not using Extended Color BASIC) and see the program run:

Have fun!

Until next time…

Updates:

• 4/26/2022 – Added note about IF/ENDIF via comments. Added link to YouTube video of the segment.
• 4/27/2022 – Updated screen shots with images taken from the YouTube video (linked in this posting).

With the season four of Stranger Things coming to Netflix soon, I have been re-watching the first three seasons.

Season one is set in 1983, and one of the characters (Joyce Byers, played by Winona Ryder) is shown working at a local general store. We see that there is a Radio Shack next door to it. We also see Radio Shack walkie talkies featured in the episodes.

In Season two we meet Joyce’s boyfriend, Bob Newby (played by Sean Astin). He works at that next-door Radio Shack. There is even one scene that shows him at work, though the environment is unlike any Radio Shack I ever saw.

In season two episode eight (“The Mind Flayer”), there is a need for them to restart a computer system. Radio Shack Bob says someone needs to know BASIC to do this. (Oh, really, writers?) This leads to a scene where Bob gets the system going by … typing in a BASIC program.

Here is the clip that someone posted to YouTube. (It starts around the 15:57 mark of the full episode.)

https://youtu.be/2bRAvxSSzEU

Here is a screen shot of the code:

It is some form of BASIC I am unfamiliar with. It allows defining variables as types (INTEGER in this case) and also appears to support functions with parameters similar to C. I am unsure if this is just Hollywood hookum or if there was actually a BASIC like this that existed in 1984 when Season 2 is set.

Here is a close-up of the code taken from the YouTube video (and apologies for the camera photo of a TV screen — Netflix blocks taking screen shots in their apps).

Update: Did you notice the end of line 70? You can see the lettering of the last word on TOP of the frame of the monitor. I never noticed that when watching it in full speed. The screen was probably added later as a special overlay effect and they didn’t take time to crop it in fully. But I digress…

Either the programmer used a bunch of memory typing in all the spaces to make it look nice, or this version of BASIC has pretty-output like Microware BASIC09 does.

I typed it in, trying to replicate the spacing…

10 DIM FourDigitPassword:INTEGER
20 FOR i = 0 TO 9
30     FOR j = 0 TO 9
40          FOR k = 0 to 9
50                FOR l = 0 TO 9
60                      FourDigitPassword = getFourDigits (i,j,k,l)
70                      IF checkPasswordMatch(FourDigitPassword) = TRUE THEN
80                              GOTO 140
90                      END
100                NEXT l
110          NEXT k
120     NEXT j
130 NEXT i
140 PRINT FourDigitPassword
150 END

Looking at this, I can now say it was a programmer adding the spaces. They do not follow a consistent tab value. Line 30-40 tabs in 5 spaces, then line 40-50 tabs in 6. My OCD is unhappy.

Line 10 creates a variable called FourDigitPassword. This tells us that this BASIC allows mixed case variable names. It also either support long variable names, or is like Microsoft Color BASIC where you can type them in, but the interpreter only honors the first two characters (or however many this version of BASIC supports).

This variable is declared as an INTEGER, whatever data type that is. Since an integer is a number, this four digit password must be like a PIN, consisting of numbers only. Since 0000 to 9999 is to big to fit in a byte (0-255), we’ll say INTEGER is a 16-bit value (0-65535).

Update: The Microsoft BASIC I am used to treat every numeric variable as a floating point value. I now recall that Commodore 64 had a way to declare a variable as an integer (non floating point). Perhaps that is what this is? (Though, they should have also declared I, J, K and L as INTEGERs too since none of this uses floating point values…)

Lines 30-50 are four FOR/NEXT loops using variables i, j, k and l. that cycle through 0-9 for each variable, representing each of the four digits of the password. Note that these variables are not declared in a DIM statement. Perhaps the default variable data type is a BYTE unless you otherwise specify?

In line 60, a function “getFourDigits” is called with each of the four variable values, returning something to variable “FourDigitPassword.” This looks like it would take four values like 1, 2, 3 and 4 and return them as an integer of 1234. So far, so good.

Line 70 is where things get strange. It calls a function “checkPasswordMatch” passing it this newly created integer value. If the function returns TRUE, it is intended to GOTO line 140 and print out the valid password, then end. However, since the GOTO is on a line starting with a new line number, I expect it would at the end of line 70 since nothing is after the THEN.

Let’s assume this weird BASIC will just continue parsing for more tokens on the next line, treating it as the “THEN” clause. If the compare was not valid, though, what would it do? Skip the next line? This is problematic.

Line 90 has an END, which would be problematic in BASIC. At this point, after the first unsuccessful check, this code would stop running.

Update: As noted in comments to this article by William A. and Lee, there were BASIC variants that used IF and ENDIF. If we treat that END to be intended as ENDIF, this code makes sense (but would still be a typo that would stop the code from running as presented

Conclusion: This program cannot work.

Line 100-130 are the NEXTs for the FOR loops.

Assuming functions work the way they appear and do what I assume they are meant to do, this appears to be a brute for password cracker, trying every combination of 0000 to 9999.

Make BASIC less strange…

Let’s make a real version! Here is my edit for Microsoft Color BASIC:

0 REM STRANGE.BAS
10 DIM PW
15 TP=1234
20 FOR I = 0 TO 9
30 FOR J = 0 TO 9
40 FOR K = 0 TO 9
50 FOR L = 0 TO 9
60 PW=I*1000+J*100+K*10+L
70 IF PW=TP THEN GOTO 140
100 NEXT L
110 NEXT K
120 NEXT J
130 NEXT I
140 PRINT PW
150 END

I had to change all the variables to UPPERCASE, and then shortened “FourDigitPassword” to just PW. I could have called it FOURDIGITPASSWORD since BASIC would still honor the first two letters (FO), but I find that a bad practice since it can lead to hard to track down errors latter (say, if you later used a variable called FOREVER or anything else that started with FO, thinking it was a unique variable while BASIC thought it was the same as FOURDIGITPASSWORD).

Since I do not have functions, I decided to just make a target password variable (TP) that will be the password to try to guess. I added this in LINE 15.

Line 20-50 are the same as the original program, just without the tabs (since my CoCo’s screen is only 32 characters wide and it would look messy).

In line 60, instead of calling a function that creates FourDigitPassword (PW) from four separate variables, I just build it myself. I multiply each digit out to turn 1,2,3,4 in to 1*1000 + 2*100 + 3*10 +4 (which is 1234).

Line 70 just compares the generated PW variable to the target TP variable. Again, no functions, so I just do it manually. I moved the “GOTO 140” to the end of that line (but it didn’t actually need the GOTO keyword after THEN).

I removed line 80 and 90 (since 80 is now at the end of 70).

Lines 100-150 are the same as the original program, except using uppercase and shorter variable names. Here is what it looks like, perfectly fitting a 32×16 CoCo screen. (I’ll even use the INVERSE VIDEO mode in tribute to Stranger Thing’s “upside down”):

If I run this, it will grind away for quite some time before finally cracking the password and printing “1234”…

It would take far longer if the target password had been 9999, but hey, it works!

Make BASIC less slow…

There are some simple ways this could be sped up, such as combining lines, and removing the variables after each NEXT (so BASIC doesn’t have to look them up each time). And, the use of a variable for each of the four digits and creating an integer seems a bit pointless, since the function that checks for a match just does so with a single integer value. This whole thing could be turned in to…

0 REM STRANGE.BAS
10 DIM PW
15 TP=1234
20 FOR I = 0 TO 9999
70 IF PW=TP THEN GOTO 140
130 NEXT I
140 PRINT PW
150 END

Since I cannot resist a BASIC benchmark opportunity, I set the target password to 9999 and ran the first version. I cleared the timer (TIMER=0) at the start and printed it out just after it prints the result. The first version shows 12609.

Then I did the same with the second version, and it shows 277. (And that could be made a bit faster by removing spaces and combining lines — down to 263 in a quick test I did.

Poor Bob could have saved alot of time with that trick. It might have even saved his life ;-) (Do I need to give a spoiler warning for a show that aired in 2017? If so, spoiler warning!)

Until next time, stay strange!

When I loaded YouTube recently, one of the suggested videos was entitled “How To Solve Google’s 25-Horses Interview Question” by MindYourDecisions. The video cover image contained the text:

“What is the best way to find the 3 fastest horses? You can race 5 horses at a time, but you do not have a watch.”

– MindYourDecisions on YouTube

I did not watch the video since I thought this might be a fun exercise in BASIC. Instead, I fired up the excellent XRoar emulator and began writing a simple program that raced horses.

I started with an array big enough to hold the speed of 25 horses:

DIM H(24)

In Color BASIC, arrays are base-0, so that represents H(0) to H(24).

Next I initialized the array with a unique speed value by simply going through the loop and assigning each horse a speed of 0 to 24:

FOR I=0 TO 24:H(I)=I:NEXT

My next step was to randomize the entries, so I looked back on an earlier article I posted about Random BASIC shuffling. I implemented the suggested from James Jones to swap values in this array:

FOR I=0 TO 24
IF I/5=INT(I/5) THEN PRINT
J=I+INT(RND(25-I)-1)
T=H(I)
H(I)=H(J)
H(J)=T
PRINT H(I);
NEXT

Now I had an array of 25 horse speeds — H(0) to H(24) — that contains a random selection of values 0 (slowest) to 24 (fastest).

If you wanted to just find the fastest horse, you could simply scan the array and remember the fastest entry you found. At the end of the scan, you know the fastest horse. Something like this:

FH=-1:FS=-1
FOR I=0 TO 24
IF H(I)>FS THEN FH=I:FS=H(I)
NEXT
PRINT "FASTEST HORSE IS";FH

…but since this question requires racing no more than five horses at a time, I had to split that up in to code that would run five races of five horses, then a sixth race that raced the winners of each of the five races.

This is not the solution to the question, but it was a fun exercise. Here is the messy program I came up with. It will first print out the speeds of all 25 horses (five per line, matching how they will be raced) and then run the five races and final race of the winners:

0 ' HORSES1.BAS
1 '
2 ' 25 horses
3 ' Race up to 5 at a time
4 ' Find the fastest horse
5 '
10 ' H(x) - horse speed
15 DIM H(24)
20 '
21 ' Initialize each speed
22 '
25 FOR I=0 TO 24:H(I)=I:NEXT
30 '
31 ' Randomize
32 '
35 FOR I=0 TO 24
40 IF I/5=INT(I/5) THEN PRINT
45 J=I+INT(RND(25-I)-1)
50 T=H(I)
55 H(I)=H(J)
60 H(J)=T
65 PRINT H(I);
70 NEXT
75 PRINT:PRINT "RACE!"
100 '
101 ' Find fastest horse
102 '
105 DIM FH(4)
110 '
111 ' Race five sets of five
112 ' FH(x) - fastest horse
113 ' FS(x) - and its speed
114 '
115 FOR R=0 TO 4
120 FH(R)=-1:FS=-1
125 PRINT R;"-";
130 FOR I=R*5 TO R*5+4
135 PRINT I;
140 IF H(I)>FS THEN FH(R)=I:FS=H(I)
145 NEXT
150 PRINT "=";FH(R)
155 NEXT
160 '
161 ' Race the five winners
162 '
165 FH=-1:FS=-1
170 PRINT " F -";
175 FOR I=0 TO 4
180 PRINT FH(I);
185 IF H(FH(I))>FS THEN FH=FH(I):FS=H(FH)
190 NEXT
195 PRINT "=";FH
200 PRINT "WINNER IS HORSE";FH
500 END

And the result (also messy) looks like this:

But this isn’t the solution we are looking for.

The question was what is the fastest way to find the fastest three horses. I found the fastest by running six races. I expect the solution is simple, but I do not know it.

I thought I’d share this here and see if anyone else wants to work on it.

Any takers?

It seems like only yesterday that you had a dozens of choices in what computer you could buy. Most were not compatible with the others — and we liked it that way. Software companies, however, probably didn’t. To reach the largest market, they had to write their program multiple times for different systems. My Radio Shack Color Computer, sadly, did not get many of these official ports.

Side note: For a nice list of some of the official ports we actually did get, see this listing by Curtis Boyle.

Many things we take for granted today — such as sending text from one computer to another (via e-mail, text, etc.) — were not as simple back then. Not all systems used an industry standard character set, meaning the numeric code that represented a character on one system, might represent a different character on another.

The CoCo used ASCII – “American Standard Code for Information Interchange.” The defined numeric values represented the following characters in this clear and easy to understand chart:

If that chart doesn’t help, you are not alone. Just know that characters 0 to 127 were all defined to represented a standard set of letters, numbers, punctuation, symbols and control codes (such as 8 being BACKSPACE, 13 being CARRIAGE RETURN, etc.).

System like the Atari 400/800 and Commodore PET/VIC-20/64/etc. included non-ASCII graphical symbols in their character set. Each of these systems came up with their own standard — PETSCII from Commodore (which originated on the Commodore PET in 1977), and ATASCII from Atari (which originated on the Atari 400/800 in 1979).

Before WWW there was BBS

One of the first things I ever did with a computer was use one with a modem to dial other computers over a land line telephone. (Kid’s, ask your parents…) Folks would run Bulletin Board System software that let others call their computer and post messages for other folks to read who called in later.

This presented a problem. If the character sets were different between computers, how could an ASCII CoCo user dial in to an Atari ATASCII system or a Commodore PETSCII system?

To solve this problem, some BBS programs on the non-ASCII computers would first ask you if you wanted ASCII or ATASCII (or PETSCII or whatever). For ASCII users, the BBS would then translate the character codes.

Not all systems did this, of course. There were plenty of Commodore-only and Atari-only systems that made use of the extended character set to draw fancy menus and screens that ASCII computers couldn’t view.

However, the modem “terminal programs” that non-ASCII systems ran usually had an ASCII translation mode built in. Thus, a Commodore or Atari user could call any ASCII BBS. While I am sure they existed, I never did see a terminal program for my ASCII CoCo that let it call an ATASCII or PETSCII-only system. (TwilightTerm by SockMaster is similar, allowing a CoCo 3 to view the IBM PC ANSI character set and colors.)

When I lived in Lufkin, Texas, one of the local BBSes was running on an Atari 800 (via BBS Express software) and allowed ASCII systems to call in. This was how I first learned about the differences in ATASCII versus ASCII.

Here is what ASCII characters 32-127 looked like on the CoCo 1 and 2 (characters 0-31 are control codes and such):

And here is the same set of characters on a CoCo 3 40-column screen with row and column numbers (since I had more screen room):

From wikipedia, here is what ATASCII looks like:

I think this table is much easier to read that the ASCII one, as long as you know hexadecimal.

Starting at character 32 (0x20) is a space, followed by special characters and the alphabet. Although there are some symbol differences (like the ^ on CoCo being a diamond on the Atari), the main letters, numbers and symbols are the same.

But, if I were to write up a text file and send it to the Atari BBS so they could post it, it would not work. ASCII uses 13 (CR, carriage return) as a line ending, but ATASCII uses 155 (ATASCII CR). If I translated line endings, and avoided using things like ^, brackets (or curly braces), etc., I could then have a text file the Atari BBS could use.

The amazing ASCII to ATASCII Convert program!

So I wrote a simple ASCII to ATASCII converter:

0 REM ASCII TO ATASCII CONVERT
1 REM BY ALLEN HUFFMAN
2 REM (09/02/87)
3 REM
5 CLEAR1000
10 CLS:PRINT@3,"ASCII TO ATASCII CONVERTER":PRINT@40,"BY ALLEN HUFFMAN":PRINTSTRING$(32,131)
15 PRINT@96,"ASCII FILE TO CONVERT:":LINEINPUT">";F1$:IFF1A$=""THEN15
20 PRINT@192,"NAME OF NEW FILE:":LINEINPUT">";F2$:IFF2$=""THEN15
25 PRINT@289,"CONVERTING ASCII TO ATASCII...":OPEN"I",#1,F1$:OPEN"O",#2,F2$
30 LINEINPUT#1,A$:PRINT@320,A$:PRINT#2,A$+CHR$(155);:IFEOF(1)=0THEN30
35 PRINT#2,CHR$(26);:UNLOAD
40 PRINT@422,"CONVERSION COMPLETE!":END

In line 15, it asks for an INPUT filename (F1$).

In line 20, it asks for an OUTPUT file name (F2$).

In line 25, it opens the first file as input (“I”) and the second file for output (“O”).

In line 30, it loops reading a raw line from the first file, displaying it on the screen (so the user can see what is going on), then writes the text out to the output file with a CHR$(155) at the end and NO ASCII carriage return (by using the semicolon). If end-of-file is not reached, it goes back to 30 to process the next line.

In line 35, it writes out a final CHR$(26) (control-Z) to the ATASCII output file — but I do not recall why. It then uses the UNLOAD command to close any open files.

I had to look up UNLOAD, as I had forgotten this existed. The description reads:

“Closes any open files on the disk in the drive you specify. If you do not specify a drive number, the com­puter uses Drive 0 (or the drive you specified in the DRIVE command).”

Disk Extended BASIC manual

Not much to it, but it worked and it let me write bulletins and such that I could upload to the Atari BBS.

I thought I would share this code in case any CoCo user out there needs to upload some text files to an Atari BBS.

Until next time…