A followup from my previous post… This box, which appeared in Rainbow magazine, was called Rainbow Check Plus:
It first appeared in the February 1984 issue, and was even featured on the cover:
The article “Rainbow Check Plus for the CoCo and MC-10” appears on page 21, and was written by H. Allen Curtis. (Why is that name so familiar?) I did not realize it was available for the MC-10 as well. Here is the listing for the CoCo version:
10 CLS:X=256*PEEK(35)+178
20 CLEAR25,X-1
30 X=256*PEEK(35)+178
40 FOR Z=X TOX+77
50 READ Y:W=W+Y:PRINT Z,Y;W
60 POKE Z,Y:NEXT
70 IFW=7985THEN80ELSEPRINT"DATA ERROR":STOP
80 EXEC X:END
90 DATA 182,1,106,167,140,60,134
100 DATA 126,183,1,106,190,1,107
110 DATA 175,140,50,48,140,4,191
120 DATA 1,107,57,129,10,38,38
130 DATA 52,22,79,158,25,230,129
140 DATA 39,12,171,128,171,128
150 DATA 230,132,38,250,48,1,32
160 DATA 240,183,2,222,48,140,14
170 DATA 159,166,166,132,28,254
180 DATA 189,173,198,53,22,126,0
190 DATA 0,135,255,134,40,55
200 DATA 51,52,41,0But wait … there’s more. As I was looking into this, I learned that “Rainbow Check Plus” was a follow-up to “Rainbow Check” which appeared in January 1983. It seems the original “Rainbow Check” would not catch some key items:
- Incorrect line numbers. “300 CLS” and “390 CLS” would provide the same check value.
- Incorrect variables. It would not catch a wrong variable. The example given is that “F” would be the same as “E”.
- Incorrect command words. SGN or SIN would provide the same checksum.
Now I really wonder what it was doing to generate the numbers, if it wasn’t looking at the actual line data ;-)
The original version appeared on page 95 as part of the “Assembly Corner” column by Dennis L. Lewandoski. The column was called “Let’s End Those Typing Errors Once and For All.” This version appeared in the form of an assembly language program listing, as well as a BASIC loader with DATA statements.
Here is the BASIC program listing for the original 1983 “Rainbow Check” version:
10 CLS:IFPEEK(116)=127 THEN X=32688 ELSE X=16304
20 CLEAR25,X-1
30 IFPEEK(116)=127 THENX=32688 ELSE X=16304
40 FORZ=X TO X+77
50 READY:W=W+Y:PRINTZ,Y;W
60 POKE Z,Y : NEXT
70 IFW=5718 THEN80 ELSE PRINT"DATA ERROR":STOP
80 EXEC X:END
90 DATA 182,1,106,167,141,0,68
100 DATA 134,126,183,1,106,190
110 DATA 1,107,175,141,0,57,48
120 DATA 141,0,4,191,1,107,57
130 DATA 129,10,38,44,52,22,220
140 DATA 27,147,25,142,4,0,141
150 DATA 6,31,152,141,2,32,25
160 DATA 52,2,68,68,68,68
170 DATA 141,4,53,2,132
180 DATA 15,129,9,46,4,139,112
190 DATA 32,2,139,55,167,128,57
200 DATA 53,22,126,0,0Unfortunately, the assembly was not provided on Rainbow on Tape, so I would have to type it all in by hand.
I suspect I will have to do just that, as well as disassemble the 1984 version and see how both worked, which might explain the limitations of the original.
Until then…
I wrote a Perl script to perform both rcheck and rcheck+ on text files (it runs the text through decb to get a tokenized version). The original rcheck did very little. All it did was check the amount of RAM the program used. This of course wouldn’t catch line number errors. Because it’s running against tokenized code, it was surprisingly useful otherwise, although not nearly as useful as the checksum generated by rcheck+.
So the first version was basically just making sure I hit the same number of keys on the keyboard as the program listing had? ;-) I suppose if it checked memory, “PRINT” counts as one byte token, but “PRUNT” would count as five bytes. Better than nothing, I suppose, but I’m glad the better version came along.
Not quite the same number of keys—as you’ve alluded to below, that’s why they used 32-character lines in their listings. Not all of the magazines did, although I’d guess that whatever width they used would have been the same number throughout the listing. Not useful back in the day, but useful enough today. Otherwise, yes and yes: a typo on a keyword would cause a discrepancy. A typo that reproduced another keyword would not cause a discrepancy. So, definitely better than nothing, but no where near as good as the real checksum from Rainbow Check Plus.
That is a great writeup! The advantage of doing it that way, typing in a real editor (especially one that does 32 columns to match the program listing) and then being able to spot check at ANY line, is super nice. I really need to get into using Super BASIC. Your code looks soooooo much nicer.
I have several tools that help me catch errors. One is a script that allows me to hit return in any text editor. So in Rainbow, I just use my favorite macOS text editor and hit return at the end of each row of code; it should always be at 32 characters unless it’s the end of a BASIC line. The script (linked) checks for this, although of course it’s also easy to see visually. Of course, I’ve also beefed it up since I started using it to perform other less obvious checks, such as making sure that all GOTOs, GOSUBs, etc., refer to a line that actually exists. Even Rainbow Check Plus can’t tell the difference between GOTO 2415 and GOTO 2451.
It cannot??? So it is not actually doing a checksum on the tokenized BASIC code, then? Oh, wait, I answered my question. Those numbers are not tokenized… they are just the bytes “2” “4” “5” “1” so mixing the order makes the same checksum.
Wow.
Rainbow Check Plus was a lifesaver on those l-o-n-g listings The Rainbow seemed to cater a bit. I believe Falsoft made available the routine to other magazines if they wished to use it, not sure any publication picked up on the offer.
It would have been nice for all listing-publishers to at least do their own similar program. Programs loading DATA statements could certainly incorporate their own checksum type routines, but there is not much a BASIC program could do for itself otherwise, I wouldn’t think.
The ’84 version does a sum of the characters on each line of BASIC, and uses BASIC itself (
PRINT PEEK(734)) to print the result when you end a line. Pretty clever.Is 734 a Basic ROM memory location, or something Rainbow Check was using with its assembly?
Location 734 is, according to the Unravelled book, two bytes in to the BASIC line input buffer. I’m not sure why they used that location instead of an unused location in the direct page (bytes 0 to 255).
Now I need to go look into this. I wonder if the buffer is larger than what you can actually type. I know it cuts off around 240 or something, rather than 255 like I’d expect.
That’s 2 bytes in to the LINBUF bytes (250). That seems … wrong. But hey, it was in Rainbow, so it must be okay.