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:

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

The program is so useful that, even though I would much prefer to type BASIC code on a modern computer in a modern text editor with a modern keyboard, I didn’t.³ The values that RCHECK+ uses are the tokenized values, which means that GOTO is not G plus O plus T plus O, but rather the sum of hex 81 and A5, the tokenization of GOTO. But then I discovered that the decb program from the ToolShed suite can take a text BASIC listing and tokenize it to a standalone file.

Which makes it possible to write rcheck in Perl and run it on a text file created by decb.

There was a lot of trial and error getting this to work. I don’t have the listing for RCHECK+, so I can’t know for sure what the algorithm is. But poking at it on the CoCo by adding, removing, and altering strings, BASIC statements, and line numbers, and watching how the checksum changes, I’m pretty sure I have it. It certainly works on the BASIC code I’ve tested it on so far. But there are no guarantees.

Here’s what it looks like using it:

Clearly, I went south sometime after line 28.⁴

You don’t need to give rcheck the checkpoint lines. If you leave them out it will only report the final checksum, which is the behavior of the original rcheck+ in the Rainbow. I find being able to type through a full column without losing the checksums in between very useful, however.

You can create a profile that will set the background and foreground colors.

Save the script as rcheck. You may find my edit script for 42 Astounding Scripts useful for pasting this or any scripts into TextEdit or your favorite text editor.

As you can see, besides requiring that decb be installed on your computer, the only tricky part of the program is detecting where BASIC lines begin. CoCo BASIC uses the null character, character zero, to mark the end of a line. So I have the script look for character zero, grab (and sum) the line number, and then skip ahead to after the line number. This is probably not completely kosher, but it works so far. I’m ignoring two bytes that are probably important.

And, in order to successfully report on the first line, I set the counter to -1. Since there is no character at -1 in any string, it comes out as null, and the script thinks that the very first line is preceded by an end-of-line marker.

In the original RCHECK+, it was critical to verify the checksums every time you reached a checkpoint; it was difficult to see previous checkpoints. You had to delete lines of code. With this program, if you prefer to type in the whole program and then debug, you can do it. Just provide the checkpoints to the script, and then you can type as much as you want. Later, you can go through each checkpoint one at a time fixing any discrepancies in that section.

And, more importantly, set the width to the same width as the Color Computer listings in Rainbow.

One of the nice things about such a simple checksum is that the discrepancy is often a clue to what the problem is. Very often, I find that if I’ve checked and double-checked the code and the number still doesn’t match, it is because I left out a character, probably on the last line. Often, this is obvious. There’s a space at the end of a line which is of course invisible in the printed listing, and the checksum is 32 less than what it’s supposed to be.⁵

In BASIC, of course, the way to check which character is missing is to use CHR$(VALUE) where value is the discrepancy. While typing in TRENCH, I was going crazy thinking I had something wrong with the rcheck script, checking over and over and not finding anything wrong with the code. It was low by 41; because the script can provide the checksum on multiple checkpoints (a distinct advantage over the original RCHECK+), I decided to go ahead to the next checkpoint. It was still 41 low. It was very clear that the problem was not with the script but with my typing.

What is character 41? In Chipmunk BASIC:

The missing character was almost certainly a close parentheses.⁶ Since I clearly couldn’t be missing a close paren except on the last line—it would have been obvious from the 32-character width—I checked and found the error in less than a minute.

Yes, 32-character width. The other advantage to Rainbow listings is that they were 32-characters wide, and matched exactly⁷ what should be on screen. This is helpful enough that I emulate it on the Mac by using vi in the Terminal. I’ve created a special Terminal profile for 32-character width typing.

I tried to use my GUI text editors, but they all want to wrap intelligently, that is, at word boundaries. I couldn’t figure out how to tell TextEdit, Textastic, or TextWrangler to simply wrap at the end of the line regardless of word boundaries.

REMEMBER ALSO TO USE CAPS LOCK when typing but TURN IT OFF when done. It will make it a lot easier to find typos if your screen matches exactly what is in Rainbow magazine. But if you leave CAPS LOCK on while in VI’s command mode, the commands you get will not be the commands you expect.

You may also find the “+” key useful for moving to the beginning of the next line in vi. Just using the down arrow will move to the same location in the next line that you are in this line.

The only thing I haven’t figured out how to do is have a better visual or audio cue when the line wraps at 32 characters. When typing directly on the CoCo, the screen is big enough that even while looking at the listing in the magazine I can see the line wrap out of the corner of my eye—the entire screen shifts up one, after all. If I don’t see the shift out of the corner of my eye, I know that I typed too little (or, if the shift happens too soon, I typed too much). This effect is much less pronounced on a modern screen. Having a bell sound when vi wraps a line would be great, but I don’t see how to do it, or even if it’s possible. The problem is exacerbated by vi’s inability to partially scroll the top visible line. If the top line of code takes up four screen lines, then vi will scroll up by four lines. The next word wrap won’t even need to scroll.