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.

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

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.

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$")

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.

## One thought on “How did Compute!’s Automatic Proofreader Work?”