TRS-80 Color Computer Programming Tools

Jerry Stratton, May 9, 2020

The TRS-80 Color Computer is a fascinating old-school personal computer. It is based off of the Motorola 6809 chip, and was the second computer I owned.

Most of this is about Extended Color BASIC on the CoCo, which I didn’t use much back in the day except for typing in programs from Rainbow. Most of the work I did for myself, I did in Microware’s OS-9.

If you want to write BASIC programs for the CoCo but prefer more modern methods, consider superBASIC. It provides loops, longer variables, and more, to make your CoCo code easier to understand and modify.

If you want to type in old code from Rainbow, look at rcheck+. It implements Rainbow’s rcheck+ algorithm in Perl.

Both of these allow you to more easily create CoCo code on a modern computer.

September 7, 2022: Simple game menu for the Color Computer 2 with CoCoSDC

Two menu screens from MENU.BAS: some of my favorite games from The Rainbow, and some of my favorite text-based games typed in from various books.

For the true retro experience, you should, of course, access files from the command line, typing DIR to see the disk, interpreting the very abbreviated filenames, and then using RUN or LOADM to start the program. For the full retro experience, everything should be on cassette tape!

But your friends may enjoy the retro gaming experience without having any idea how to start up the games. You could, of course, put a coffee-stained sheet with helpful command-line hints next to the computer. Or, you could use this BASIC program, that leverages Darren Atkinson’s CoCo SDC floppy disk emulator to provide a simple interface to your favorite games (Zip file, 8.4 KB) saved on both the SDC’s flash slots and on .DSK disk files.

You can have as many screens as you want. The more screens, the longer it will take to load, and the more screens you (or your friends) will have to cycle through to see everything. I meant this as an easy means of showing off my favorite games; it is not meant as a comprehensive listing of everything. For a more complex file browser, see Guillaume Major’s SDC Explorer.

As written, MENU.BAS requires the SDC, but it should be able to be modified to use other solutions that store programs in ways that they can be accessed from a BASIC program.

The program attempts to respond to whatever the user might do to choose a game. If they pick up one of the joysticks, it will start following that joystick; if they use the up or down arrow keys, it will respond to them; SHIFT-up and SHIFT-down will move to the top and bottom, respectively. If they type the number corresponding to a game, the pointer will jump directly to that game.

Read the full post and comments

May 4, 2022: Rainbow Magazine preflight tool enhanced

I’ve been silently updating the Rainbow preflight tool (Zip file, 3.2 KB) over the last couple of years, but I just added a feature that I thought worth talking about. I was typing in Charles Husak’s “Quest of the Dragon’s Gold” from the August 1984 Rainbow and the line numbers are all over the place. But between pages 32 and 36 the line number jumps from 2790 to 2840, which seemed excessively odd even for this particular program.

I did a search on the obvious line numbers that might exist to see if there were any GOTOs, GOSUBs, or so on, to the potentially missing section, and didn’t find any. But given how uneven the line numbers were, that wasn’t a great check. It occurred to me that I could have the rainbow script keep track of (a) all of the line numbers in the listing, and (b) all of the line numbers referenced in the code, and then cross reference them.

This was fairly simple to do: there’s a subroutine to collect the line numbers, and a loop that provides a warning for every line number that doesn’t exist. Here’s the subroutine:

[toggle code]

• sub collectLineReferences {
  • my $lineNumber = shift;
  • my $lineText = shift;
  • $existingLines[$#existingLines+1] = $lineNumber;
  • while ($lineText =~ m/(GO *TO|GO *SUB|THEN) *([0-9]+)/g) {
    • $lineReferences[$#lineReferences+1] = [$lineNumber, $1, $2];
  • }
• }

And here are the warnings:

[toggle code]

• #verify that all line number references go to a line that exists
• %existingLines = map { $_ => 1 } @existingLines;
• foreach $lineReference (@lineReferences) {
  • ($lineNumber, $referenceType, $referencedLine) = @$lineReference;
  • if (!exists($existingLines{$referencedLine})) {
    • print STDERR "\t$referenceType to non-existent line $referencedLine in $lineNumber\n";
  • }
• }

Read the full post and comments

May 12, 2021: BASIC tokenization examined

If you’re in the habit of transferring BASIC files from old computers to modern ones, you might discover strange characters in the files. They’re like a strange combination of text and binary. This is not a compiled program, however. In old-school BASIC, there was a difference between compilation and tokenization.

Compilation converted BASIC code to machine code, and compiled files would usually be stored with a file extension indicating that the code should be run directly rather than interpreted. Often, this extension was some variation of “.BIN”. On personal computers at least, compilation usually required third-party software to convert the BASIC statements to machine code.

Compiled programs were no longer BASIC. They were machine code. They couldn’t be listed or edited, at least in BASIC. It generally wasn’t possible to convert a compiled BASIC program back to the original BASIC. Like any other compiled software, if you wanted to recompile it you needed to keep the source code on hand.

The default BASIC on these personal computers were also not saved as straight ASCII. While saving to text was usually an option, the default for most BASICs was to tokenize programs both in memory and on disk. Tokenized files were usually saved with some variation of a .BAS file extension—often the very same extension used for straight ASCII, non-tokenized files. Whether a file was tokenized or non-tokenized was a bit in the directory listing for that file, not in the file itself.

Unlike compiling a program, which translates code statements and functions into machine language, a tokenized BASIC program is still BASIC. In the computers I used, tokenization was mostly, if not completely, a one-to-one translation of BASIC statement/function to the one- or two-byte token for that statement or function. This saved space on the system. Both disk space and RAM were limited on older personal computers. But it also made it much easier for the system to run the code on the fly—interpret it—and made the interpretation much faster.

Read the full post and comments

April 7, 2021: What are the 8 bits in 8-bit computing?

Why? Where do these results come from?

On the Facebook CoCo group, someone recently asked about how I handled bit-checking in a question I asked on the Retrocomputing StackExchange about the joystick. They didn’t phrase it as a question about bits because they didn’t know that their question was about bits.

It’s not surprising. I don’t know about other computers, but Radio Shack tended to hide the bitwise nature of their 8-bit computers. The only BASIC functions that worked with bits were the logical operators AND, OR, and NOT¹, and they weren’t explained as bitwise. The first two are given a page in Getting Started with Extended Color BASIC, page 78, where they’re explained as if they’re the English words AND and OR.²

But these operators do not behave as the English words do, or as the explanation implies they do. Here’s an example. Go into your CoCo or an emulator such as Xroar, and type:

• PRINT 3 AND 5
• PRINT 3 OR 5

The first should give you 1 and the second should give you 7. In most modern programming languages, both would give you true, which, depending on the language, might be a boolean value or it might be the integer 1. It might even be one of the two values, the 3 or the 5, because of short-circuit evaluation.

How does Extended Color BASIC arrive by its return values? The answer is that AND and OR are bitwise operations. These are 8-bit computers. They describe their numbers in 8 bits³. Here are the bits for the numbers 3 and 5:

byte value	8 bits
3	00000011
5	00000101

The logical operators do not compare bytes. They compare individual bits at matching bit locations. What AND does is, if the bit in the same location in each byte is 1, the bit in the resulting byte is 1. If either of the two bits are zero, the bit in the result for that location is zero. What OR does is return 1 if either of the bits are 1, and zero only if both bits are zero. So here’s what AND and OR do when comparing 3 and 5:

Read the full post and comments

February 13, 2021: Color Computer binaries from decimal values

At the end of my post on the first version of cocobin, I wrote:

It’s also likely that some binaries were provided as decimal instead of hexadecimal numbers.

And only a few weeks later, here I am. I found a really nice Galaxian/Space Invaders-style game by Rodger Smith in the February 1985 Hot CoCo.¹

He used decimal numbers for his DATA statements, so I added that feature to cocobin. If a file or BASIC program contains decimal rather than hexadecimal numbers, add the option --decimal to the cocobin command line.

Also as expected, adding this feature also highlighted another common custom of the era: the DATA items often included a marker to denote the end of the data. Most commonly, as I recall, this was the word “END”, or (for machine code) a negative 1. Smith used the number 999. So I’ve added the ability to recognize “END”, “999”, or “-1” at the end of a line of DATA in a BASIC program. If the program sees any of those key words at the end of a DATA line, it assumes that that is the end of the data to be read.

Either of those keywords not at the end of a DATA line will still be seen as an error, since none of them represent valid POKEable numbers.

Download Zip file (2.2 KB)

The script now accepts the following arguments:

load address	decimal or hex address for location of binary data in CoCo RAM
exec address	decimal or hex address for starting execution; defaults to load address
filenames	file[s] to pull data from; data can also be piped
--basic	the text is a BASIC file; pull hex values from DATA lines
--columns <column count>	verify that each line contains a specific column count
--decimal	the numbers are decimal numbers, not hexadecimal
--help	print this text
--quiet	do not output bin data
--verbose	provide information about the binary program

Also, while this is not a change, I did finally verify that the script works when used with multiple files. Charles Husak’s “The Little Runner” from the March 1984 Rainbow uses three BASIC programs to POKE the binary into memory. This command line worked to create a working binary from those three files:

• cocobin --basic 13000 RUNNER*.BAS > RUNNER.BIN

Read the full post and comments

February 10, 2021: Read BASIC out loud

In my continuing quest to make it easier to successfully type programs from books and magazines, I had the great idea of having my Macintosh read the code out loud, freeing me to look solely at the original text while verifying the code. This is useful not just for finding errors that rcheck+ says must exist but also errors in code that doesn’t have checksums such as the one- and two-liners in The Rainbow.

The readBASIC script (Zip file, 3.6 KB) is especially useful for the 1984 run of The Rainbow, which uses an rcheck that simply adds up memory used instead of performing a rudimentary checksum, and Hot CoCo, which has no validation at all unless you count the 32-character lines. I recently acquired several issues of Hot CoCo and I pretty much run readBASIC on all of the programs I type in from that magazine. Whether an error shows up on testing the program or not, I almost certainly mistyped something on any program of any reasonable length. Those bugs are likely to trigger when I least need them.

It turns out I’m not the only person to think of having the computer read code back to you. In the October 1987 issue of The Rainbow, there’s an article by Bob Roberts that does the same thing. Of course, his is more complicated since it has to fit in memory around the BASIC program it’s reading. It doesn’t read the files (although, technically, there’s no reason it couldn’t) but rather reads the actual BASIC program from RAM. Nor is it a machine language program invoked with a special keystroke, like the rcheck+ program. Instead, it’s literally a BASIC program running above the real BASIC program, starting at line number 60000.

Of course, a BASIC program on an eighties computer required special hardware to generate speech. Roberts’s required Radio Shack’s Speech/Sound cartridge. Modern computers have speech built in. You can play around with it on the Macintosh command line using the say command. I go over this command in more detail—how to use the voices of various languages and accents—in the Diversion About History section of 42 Astoundingly Useful Scripts and Automations for the Macintosh.

My first attempt at having the iMac read BASIC code out loud was simply to send each line of BASIC to the say command. Given the lack of spaces in most old-school code, you won’t be surprised to learn that this did not work well.

Read the full post and comments

December 30, 2020: Create Color Computer binaries from hex values

The December 1987 issue of Rainbow has a very interesting program from John Mosley that purports to be “a four-voice music and graphics program” that works with the CoCo 1 and 2. It consists of a short BASIC program to create the graphics, and a shorter BASIC program to allow the reader to type in the hexadecimal values for the music, one value at a time.

Screw up one number, and you have to start over, this time not screwing up elsewhere. Or you have to understand POKEing enough to rePOKE just the numbers you screwed up, and know where they are—probably by writing a BASIC program to display values in memory and ask you if they’re correct, one by one.

It seemed more reasonable to type all of the hexadecimal numbers into a text file, and then use a script to create the BIN file; if there’s an error, fix only that error in the text file instead of retyping everything.

The format of BIN files turns out to be fairly simple. From Walter Zydhek’s Disk BASIC Unravelled II, there is a preamble and a postamble, both five bytes long. The preamble contains the length of the data and the address the data should be loaded to:

Byte	Value	Purpose
0	00	Preamble flag
1-2	XXXX	Length of data block
3-4	XXXX	Load address

The postamble contains the execution (EXEC) address:

Byte	Value	Purpose
0	FF	Postamble flag
1-2	0000	Dummy value
3-4	XXXX	Execution address

The script accepts the following arguments:

load address	decimal or hex address for location of binary data in CoCo RAM
exec address	decimal or hex address for starting execution; defaults to load address
filenames	file[s] to pull data from; data can also be piped
--basic	the text is a BASIC file; pull hex values from DATA lines
--columns <column count>	verify that each line contains a specific column count
--help	print this text
--quiet	do not output bin data
--verbose	provide information about the binary program

Read the full post and comments

November 11, 2020: New, improved rcheck+ for Rainbow Magazine code

This, from Le Lutin in the July 1987 Rainbow, was a very annoying and time-consuming error to debug just using rcheck. It was obvious once brought into Xroar.

I’ve added a few new features to the rcheck script to make it more useful for typing in code from The Rainbow.

--debug	provide a hexdump of the tokenized BASIC file
--rcheck	use the original rcheck rather than rcheck+
--shift <x>	shift all checksums by x
--verbose	show checksums for all lines
[xxx]	show checksum for line xxx
[xxx:yyy]	verify line xxx against expected checksum yyy
[:yyy]	verify checksum yyy at the end of the code

rcheck+ for macOS (Zip file, 2.5 KB)

The big, important change is that you can now specify the expected checksums on the command line. You can continue to use rcheck as before, and its behavior will not change. But if you add “:yyy” to a line number, it uses “yyy” as the expected checksum. For the final line, you can use simply “:yyy” or “yyy”.

• ~/bin/rcheck MEMOCARD.BAS 130:15 210:170 320:9 :167
• 130: 15
• 210: 152 238 (-18); possibly a 4 where there should be an F?
• 320: 247 238 (-18)
• END: 149 238 (-18)

When a checksum does not match the expected checksum, the script shows the difference. This is extremely helpful, because often merely knowing that the checksum is off by, say, 32, tells you what the likely problem is—a missing or extra space, or an incorrectly-cased letter. In fact, some errors are common enough that I’ve put a check for them in the script, as you can see in the example.

• The dash is right next to the equals on my keyboard, so that’s a common mistake.
• I’ve no idea why I often type 4 where I should type F, but I do.
• Ditto with typing a dash instead of an equals sign.
• Also, very commonly spaces will not be obvious and so will not be typed when they appear in a remark, especially when they appear (I suspect) at the end of a remark.
• Multiples of 32 can be the result of case issues, since the difference between upper and lower case characters is 32 in ASCII, or multiple missing/extra spaces.
• Every once in a while, not only can’t I find the supposed error, but the very next block of code is also off—by the inverse of the amount the previous block was off. I suspect that these are typos in the Rainbow checksum block.

Read the full post and comments

August 12, 2020: Hunt the Wumpus: Conditional code and include files in SuperBASIC

Uh oh… never bump a wumpus.

I never played Hunt the Wumpus back in the day. I bought my computer in the summer of 1980, and by then the game had become legendary both in its fame and in its obscurity. I never saw a copy of 101 BASIC Computer Games nor did I have access to the college computer networks that were its lair. So when I saw a version of it in the Best of Creative Computing Volume 1^•, I decided to type it in and see how it works.

It’s clearly designed for what would have been considered a wide output format a few years later. The longest string that gets printed is 56 characters long, “BOTTOMLESS PITS - TWO ROOMS HAVE BOTTOMLESS PITS IN THEM”, from the instructions.

That string, surprisingly, would have fit just fine on my first computer, a TRS-80 Model 1. The Model 1 had 64-characters per line. But most home computers used an unmodified television for output. That many characters per line would have been unreadable on those computers, so they had widths usually ranging from 32 to 40¹ characters per line.

Coming about two years before the first mass market home computer, this program was probably meant for university computers, and may well have used a teletype or printer for its output. Such output devices usually had 80 characters per line, but common printers did exist with 64 characters per line, and of course room was needed for margins. If you assume ten character margins, that leaves 60 characters for output, which comes very close to the 56 character maximum.

Also interesting: the listing was meant for much younger eyes than mine. The 227 lines of code are all on one page. You can see it on page 250 of the book at the Internet Archive.

Like most programs of its era, following the logic is like following a strand of spaghetti, although it’s not nearly the mass of text that programs like it would become when memory became limited.

Read the full post and comments

July 8, 2020: Reversi in SuperBASIC on the Color Computer

Download Zip file (18.9 KB)

Reversi is a fun game to write on an early computer. I suspect one of the reasons it was so popular in early BASIC books is because it’s also an easy game to write on early computers. It’s very easy to get a version that basically works, even if it doesn’t work well.

I took the logic for this game from Tim Hartnell’s^• Giant Book of Computer Games. It was a fun game, but it didn’t handle everything it really ought to have. That was Hartnell’s style: provide a basic structure, and let the reader learn by adding to it. Among the things that needed to be added were:

• Require a move by the human player if one is available.
• Recognize more quickly that the game is over when the game is over¹.
• Disallow a move by the human player that doesn’t flip any pieces.
• Recognize that the game is over if one player has no pieces. Sadly, I have lost all of my pieces while playing this not particularly smart game. My excuse is that I was often playing the game while distracted by programming the game.

And of course there were a lot of other changes I wanted to make so that the game would play better on the Color Computer.

I decided it would be even easier to learn by adding to it, if I first rewrote it completely in superBASIC to make the logic easier to understand. As written, the game uses all of the block types currently possible in superBASIC: loops, switches, and both if/endif and if/else/endif. It’s a very good example of how to use superBASIC to write an old-school BASIC program.

Read the full post and comments

June 10, 2020: Convert PCBASIC code to TRS-80 Extended Color BASIC

One of the nice things about the older strategy games is that it’s easier to win…

I recently found Tim Hartnell’s^• really nice Giant Book of Computer Games^•. Hartnell strikes exactly the tone I was looking for with 42 Astounding Scripts. Breezy, informative, and filled with useful code.

While he writes his book for “Microsoft BASIC on an IBM PC” he specifically avoids anything that might make it unusable on other computers, “no PEEKs and POKEs, no use of graphic character sets, and no use of such commands as SOUND or PLAY. I’ve assumed you have access to READ and DATA, and that your screen is around 32 to 40 characters wide”.

This makes it very suitable for customizing for any of the old 8-bit computers such as the TRS-80 Color Computer line. The changes that need to be made to get these programs to run on the CoCo are somewhat rote, and mostly easily automated. So of course I wrote a script for that (Zip file, 6.0 KB).

Read the full post and comments

May 30, 2020: A manual for superBASIC

Download Zip file (18.9 KB)

Because I like printed manuals, I’ve written a short manual for superBASIC. It’s available in print on Amazon.com^•, currently, for $5.99. It makes a useful reference if you use superBASIC; I use it all the time. It’s also available as a free ebook on most of the usual sites.¹

I’ve also made some changes to how code generation works. I have changed the format of the DATASET macro, or dynamic constant. I’ve renamed %DATASETS! to !DATASETS%. I did this because I can envision having string constants as well, and I wanted to use the same format I use for variables, that is, ending in a dollar sign. So now a variable always begins with a percent, and a constant always begins with an exclamation.

The only visible change to the generated code is that I’ve standardized how blank lines get added around blocks and remarks. This greatly improves the readability of the resulting old-school BASIC.

Also, remarks no longer break on forward slashes, as these are common in URLs, which are common in the top comments I put in any program I write.

Internally, I’ve completely rewritten block generation. It generates the same code as before, but it is much easier to manage and view block types. This means that SWITCH/CASE is now the same kind of block as LOOP and IF/ELSE. LOOPs and IF/ELSE can be embedded in CASEs. Even SWITCHes can be embedded in CASEs.

This should make it easier to add an ELSEIF to IF/ELSE when needed, and to add a SWITCH ON to generate ON x GOTO statements. I probably won’t be adding any sort of FOR/NEXT loop because this turns out to be unnecessary on the Color Computer. All of the FOR loops that I’ve been wanting to BREAK out of are in subroutines, and the BREAK would have returned immediately from the subroutine. It turns out that returning from a subroutine clears out the FOR stack.

Read the full post and comments

March 18, 2020: SuperBASIC for the TRS-80 Color Computer

The CoCo, like most computers of its era, did not have lowercase built in.

Even when it had it built in, it didn’t have it built-in! This mode was only available in the tail-end models, and only through POKE.

• Latest superBASIC code. (Zip file, 18.9 KB)
• Latest superBASIC downloadable manual
• Latest superBASIC print manual^•

There are a lot of things I’m nostalgic for about the early era of home computers. The cameraderie. The home-brew spirit. The assumption that we were going to control the computer rather than the computer control us—there were so many cartoons making fun of the Pavlovian response to computer notifications that seem sadly prophetic today. One thing I am not nostalgic for is programming in the BASIC of the era. I wrote a lot about that in Learning to program without BASIC. BASIC programs then were a sludgy melt of undifferentiated words and numbers.

But I have an old computer, and I want to program it. It is the Tandy Color Computer 2, and it is not an easy computer to write programs on. Even the TRS-80 Model 1 could show 1,024 characters at a time, 16 lines of 64 characters. The Color Computer had half that, at 16 lines of 32 characters each. There is no holding anything but the simplest subroutine onscreen intact.

That’s part of why I wrote basicize, to help me write programs for emulators using a modern text editor on a modern computer. Not having to deal with line numbers was also a major impetus, and labeling made it a lot easier to see where the code was going. But I mainly use basicize for modifying existing code. I’ll take the code, organize it into sections, and label them. This does not help structure the code, nor does it make the code self-commenting. The variables are still one to two characters and there are no loops other than FOR/NEXT and GOTO.

Read the full post and comments

January 8, 2020: Rainbow Magazine BASIC program preflight tool

Vicious Vic appears to be a variation on Robot War, with vikings in place of robots.

There are a lot of typing mistakes I make that are easily detectable: extra characters from fat fingers, mistyped parentheses, and even mistyped numbers. In an attempt to make typing BASIC programs from The Rainbow easier, as well as improve my ability to use Textastic with rcheck, I wrote this script. I wrote it somewhat haphazardly, adding new checks when I noticed that an error was detectable.

The basic idea is that since each line wraps at 32 characters, when I hit the end of the line in the Rainbow listing, I hit return. The script detects whether a line in the text file is a continuation of the previous line or a new line by looking for the line number. This solves the problem of finding a text editor that wraps at 32 characters.

But it also opens the possibility of doing some preflighting. If a line in the text file is not the final subline in a BASIC code line, it must be 32 characters long. If it isn’t, I mistyped something. And with my fat fingers, this is the most common typo. Most typos are discovered merely by making sure that each subline except the final one is exactly 32 characters.

There are also warnings, things that are probably a problem but might not be. These do not halt the program, and are displayed at the bottom of the results. They are not piped to a file, so they appear in the terminal if you’re piping.

For example, if the full BASIC line is longer than 249 characters, I probably mistyped something. That’s the maximum number of characters you can type on a new BASIC line on the Color Computer. It’s a warning, not an error, because it is possible to get more characters into a line, and it occasionally happens with the one-line and two-line contest winners, since they’re specifically trying to stuff as much into a line as possible. More than 255 characters is an error. I haven’t seen anything longer than that.¹

It also checks the line number. If it isn’t greater than the previous line number, I mistyped something.²

Read the full post and comments

November 20, 2019: TRS-80 Color Computer RCHECK+ in Perl

The only text editor I could find that would wrap exactly at 32 characters was vi in the Terminal.

I may be the only person who still enjoys typing in code from old books and magazines, but I do enjoy it, and enough to have written a modern version of those old books, 42 Astoundingly Useful Scripts and Automations for the Macintosh. I recently acquired a TRS-80 Color Computer 2, so I’ve been typing in old code from The Rainbow.

One of the big advantages of The Rainbow over other magazines of its era is the program RCHECK+. It’s a machine-language program that you load into memory before typing the code, and when you press the down arrow, it calculates a very simple checksum from the code you’ve typed.¹ The listing in the magazine contains a series of checkpoints, such as this for TRENCH in the July 1986 issue of The Rainbow:

checkpoint	checksum
7	208
15	178
20	102
28	28
37	83
51	188
END	180

After typing line 7, the checksum should be 208; after typing line 15, it should be 178; and after typing in the entire program, it should be 180.

It turns out that this is a very simple checksum. All it’s doing is adding up the ASCII values of the code in RAM, cycling back to zero after a sum of 255. So the checksum is always from 0 to 255.²

Read the full post and comments

1. <- Photograph titles
2. Text to image filter ->

About Mimsy

• Archive
• Next Senate election
• Jerry Stratton