After a while, magazines like Commodore Run and Compute started including a short program that would checksum each line as you entered it, so you could check that against a checksum in the magazine. Of course, you had to get that program typed in correctly first before you could use it to enter others.
This was wrapper around the BASIC interpreter that printed out a 2-character checksum of each entered code line.
The magazine printing also had an associated 2-character checksum for each line. Your job: make sure the checksums matched.
As a teenager who only had cassette-based storage (couldn't afford a disk drive) and was addicted to typing in programs from Antic! and ANALOG magazines, this was a lifesaver.
(ANALOG's checksum program wasn't quite as convenient, and, IIRC, required a disk drive?)
I took a look at the listing[1] and looks like it contains unprintable characters, maybe they were ASCII art of some sort?
The checksum algorithm is fairly simple: line 32150 sums the products of all character positions and character codes, and lines 32160-32180 does a modulus to convert them to printable characters. The multiply-by-position bit is clever because it allows the checksum to flag transposed characters. ISBN-10 uses a similar scheme[2].
Atari 8-bits were actually really cool computers, in that they let you do things like redefine character sets entirely (to create custom character sets to effectively create tile-based displays), play with display-list interrupts, etc.
I guess Atari character set has enough overlap with ASCII, so I could get the checksum to match:
sum = 0
"32000 REM TYPO II BY ANDY BARTON".codepoints.each_with_index{|c, i| sum += (i + 1) * c }
print ((sum % 676) / 26 + 65).chr, (sum % 26 + 65).chr, "\n"
The code listings had a comment (rem) at the end of each line with a checksum number, when you used the checksum program it would display a checksum at the top of the screen that would match if you entered the line correctly.
I remember borrowing a book from the library, which had a type-in checksum program of this sort. It was done like was common for C=64 things of this kind - there's a BASIC FOR-loop iterating through a memory area, reading in bytes from DATA statements you've typed in and POKEing those bytes into memory, not completely unlike entering a program manually from the front-panel switches of an older computer.
So, after typing that in and probably SYSing (C=64 BASIC command for executing machine code from arbitrary memory location) to some address, it did print out a two-digit (eight-bit) hex checksum after every BASIC line I entered on the C=64 and the program listing in the book had the correct checksums for every line, so spotting errors was more or less instantaneous.
This stuff brings memories.
FOR I=40960 TO 49152:POKE I,PEEK(I):NEXT I
POKE 1,54
From top of my head; loop through the BASIC interpreter area, reading byte by byte with PEEK and POKEing those bytes back to the same addresses. Sounds nonsensical? Not so, because the C=64 does have full 64 kB of RAM, but some of it is overlapped by ROMs. What happens here is that you're reading from ROM but writes always go to RAM, so you're copying the BASIC interpreter from ROM to RAM. After that, the POKE statement turns off the ROM overlap and the interpreter is now run from RAM, so you can edit it live - and obviously cause all sorts of interesting crash situations.
It sure did help later with career in IT to have understood this kind of stuff at age of around ten.
You’d just get a big error message for the whole program.