How did Compute!’s Automatic Proofreader Work?

After that work on MLX, the programs that Compute! and Compute!’s Gazette used to enter machine language programs, I figured I was done. There was the Automatic Proofreader, used to catch errors in typing in BASIC programs. But that program was written in the machine language of the 6502 line of microchip. I’ve never been much on machine language and figured I couldn’t figure out how it worked. And then on a lark I tried and saw. And it turned out to be easy.

With qualifiers, of course. Compute! and Compute!’s Gazette had two generations of Automatic Proofreader for Commodore computers. The magazines also had Automatic Proofreaders for the other eight-bit computers that they covered. I trust that those worked the same way, but — with one exception — don’t know. I haven’t deciphered most of those other proofreaders.

The October 1983 Compute!’s Gazette, with the debut of the Automatic Proofreader. It was an era for wordy magazine covers. Also I have no idea who did the art for that Oil Tycoon article but I love how emblematic it was of 1980s video game cover art.

Let me introduce how it was used, though. Compute! and Compute!’s Gazette offered computer programs to type in. Many of them were in BASIC, which uses many familiar words of English as instructions. But you can still make typos entering commands, and this causes bugs or crashes in programs. The Automatic Proofreader, for the Commodore (and the Atari), put in a little extra step after you typed in a line of code. It calculated a checksum. It showed that on-screen after every line you entered. And you could check whether that matched the checksum the magazine printed. So the listing in the magazine would be something like:

100 POKE 56,50:CLR:DIM IN$,I,J,A,B,A$,B$,A(7),N$ :rem 34
110 C4=48:C6=16:C7=7:Z2=2:Z4=254:Z5=255:Z6=256:Z7=127 :rem 238
120 FA=PEEK(45)+Z6*PEEK(46): BS=PEEK(55)+Z6*PEEK(56): H$="0123456789ABCDEF" :rem118

The start of The New MLX, introduced in the December 1985 Compute!’s Gazette, and using the original Automatic Proofreader checksum. That program received lavish attention two weeks ago.

You would type in all those lines up to the :rem part. ‘rem’ here stands for ‘Remark’ and means the rest of the line is a comment to the programmer, not the computer. So they’d do no harm if you did enter them. But why type text you didn’t need?

So after typing, say, 100 POKE 56,50:CLR:DIM IN$,I,J,A,B,A$,B$,A(7),N$ you’d hit return and with luck get the number 34 up on screen. The Automatic Proofreader did not force you to re-type the line. You were on your honor to do that. (Nor were you forced to type lines in order. If you wished to type line 100, then 200, then 300, then 190, then 250, then 330, you could. The checksum would calculate the same.) And it didn’t only work for entering programs, these commands starting with line numbers. It would return a result for any command you entered. But since you wouldn’t know what the checksum should be for a freeform command, that didn’t tell you much.

I’m delighted there’s a picture of what the Automatic Proofreader looked like in practice, because this saves me having to type in the Proofreader into an emulator and taking a screen shot of that. Also, props to Compute!’s Gazette for putting a curved cut around this screen image.

The first-generation Automatic Proofreader, which is what I’m talking about here, returned a number between 0 and 255. And it was a simple checksum. It could not detect transposed characters: the checksum for PIRNT was the same as PRINT and PRITN. And, it turns out, errors could offset: the checksum for PEEK(46) would be the same as that for PEEK(55).

And there was one bit of deliberate insensitivity built in. Spaces would not be counted. The checksum for FA=PEEK(45)+Z6*PEEK(46) would be the same as FA = PEEK( 45 ) + Z6 * PEEK( 46 ). So you could organize text in whatever way was most convenient.

Given this, and given the example of the first MLX, you may have a suspicion how the Automatic Proofreader calculated things. So did I and it turned out to be right. The checksum for the first-generation Automatic Proofreader, at least for the Commodore 64 and the Vic-20, was a simple sum. Take the line that’s been entered. Ignore spaces. But otherwise, take the ASCII code value for each character, and add that up, modulo 256. That is, if the sum is (say) 300, subtract 256 from that, that is, 44.

I’m fibbing a little when I say it’s the ASCII code values. The Commodore computers used a variation on ASCII, called PETSCII (Commodore’s first line of computers was the PET). For ordinary text the differences between ASCII and PETSCII don’t matter. The differences come into play for various characters Commodores had. These would be symbols like the suits of cards, or little circles, or checkerboard patterns. Symbols that, these days, we’d see as emojis, or at least part of an extended character set.

But translating all those symbols is … tedious, but not hard. If you want to do a simulated Automatic Proofreader in Octave, it’s almost no code at all. It turns out Octave and Matlab need no special command to get the ASCII code equivalent of text. So here’s a working simulation

function retval = automatic_proofreader (oneLine)
  trimmedLine = strrep(oneLine, " ", "");
  #	In Matlab this should be replace(oneLine, " ", "");
  retval = mod(sum(trimmedLine), 256);

endfunction

To call it type in a line of text:

automatic_proofreader("100 POKE 56,50:CLR:DIM IN$,I,J,A,B,A$,B$,A(7),N$")

Very optimistic subhead here considering the limits they acknowledged in the article about what the Automatic Proofreader could detect.

Capitalization matters! The ASCII code for capital-P is different from that for lowercase-p. Spaces won’t matter, though. More exotic characters, though, such as the color-setting commands, are trouble and let’s not deal with that right now. Also you can enclose your line in single-quotes, in case for example you want the checksum of a line that had double-quotes. Let’s agree that lines with single- and double-quotes don’t exist.

I understand the way Commodore 64’s work well enough that I can explain the Automatic Proofreader’s code. I plan to do that soon. I don’t know how the Atari version of the Automatic Proofreader worked, but since it had the same weaknesses I assume it used the same algorithm.

There is a first-generation Automatic Proofreader with a difference, though, and I’ll come to that.