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.

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

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.

If you provide expected checksums, the script keeps track of the accumulated error, so that checkpoints that follow an erroneous checkpoint will be displayed with their correct error amount, or in green if that particular checkpoint has the “correct” checksum. That is, if, in the above MEMOCARD.BAS example, the checksum at 210 is 175 instead of 170, the script keeps track of the error, and will expect checkpoint 320 to be 14 and the end to be 172—that is, five above the listed checksum, since checkpoint 210 is five above its expected checksum.

I did this because I find myself typing either complete scripts or several columns, and so it’s nice to see all that green after one error. And I also occasionally put off looking for errors until later if I can’t find what I mistyped. By correcting for previous errors, the script makes it easier to check for errors in subsequent checkpoints without having to fix them in order.

Something you can’t see in that example is that the script also highlights good checksums with green text, and bad checksums with red. Here’s an example from Talking CoCo Cathead in the November, 1987 issue of The Rainbow:

Also, it will not show the end total if you give it a list of checksums and the highest line in the code is less than the highest line in your list of checksums; instead it will say “END: Not finished”, because, presumably, this cannot be the end total if there are still checksums to go.

While I updated the original code to include the --debug option, I never explained it. The --debug option is really only useful for debugging rcheck itself, although I did find it helpful for one program that had clearly been tokenized differently for The Rainbow than it was on my Color Computer. Le Lutin from the July 1987 Rainbow has apparently been compressed by removing spaces directly from the tokenized code. This makes the program impossible to type in as presented, because lines such as ONLGOSUB get tokenized as if LGOSUB were a variable.¹

I added the --shift option for that program, once I realized that all checksums after the offending code were off by the same amount once I fixed them. So that I was able to run

to get the checksums after line 28 to match the checksums in the magazine.

I added this before I knew what the problem was with the checksum, except that as hard as I looked I couldn’t find it. So I decided to put off dealing with it and just go on typing the rest of the program, using --shift to adjust the checksum to take into account the errors at the beginning. Fortunately, those special cases only appeared at the beginning, and I was able to complete typing the rest of the program without further problems. Once I tried to run the program, the reason for the checksum discrepancy became obvious.

Even when the error is mine rather than the magazine’s, however, it is sometimes helpful to give up for a while and just move on to the rest of the program. Errors sometimes become more obvious when I stop looking for them.

I mentioned the --rcheck option as a quick update to TRS-80 Color Computer RCHECK+ in Perl. Before rcheck+ calculated checksums, The Rainbow included an rcheck not plus that simply checked the amount of RAM that the program was using.

I’m not sure how many errors this would pick up that wouldn’t also be picked up just by looking down the right-most column of the listing. Errors that cause a BASIC statement to not tokenize would be picked up, as would extra or missing characters in the final subline of a BASIC line, since the final subline in a Rainbow listing doesn’t usually reach the rightmost (32^nd) column.

I also added a --verbose option to show checksums for all line numbers (this was originally part of --debug, but it tended to obscure the hexdump). This is rarely useful.

Other minor and not-so-minor fixes since I first announced the rcheck script are that the script now handles BASIC programs with spaces in their names correctly. It was a rarely-used feature, but Disk Extended Color BASIC didn’t care if programs had spaces—such as Le Lutin.

As a side note, the two characters after the line number that rcheck skips over, that I didn’t know what they were? I’m pretty sure now that they’re the hard address of the next line number in hexadecimal.