There’s nothing like a _ or \ to indicate “continued next line”. I’m assuming they inserted LF’s or CR’s into the code, and that the scanner just ignores these. Or maybe this is something the printer or driver itself is doing?
I’d like to keep these as close to the original format as possible, but I’m not sure what to do with these. It’s not the only example, I’ve seen it in a couple of other listings.
As I understand it, this is DEC BASIC, meaning, this should support lines of up to 250 characters.
I guess, the layout is for ease of input and, in practice, you would just enter the individual commands consecutively. You could add spaces for a convenient wrap, but this may depend on the terminal and its columns per line settings.
In the HTML source the continued lines have some kind of trailing whitespace. Downloading and inspecting with xxd, I see normal lines end with 0d0a and the special lines end with 0a0d. Not sure if that helps at all.
those are long lines with spaces in them that are wrapped in the display. Probably on the original display width they would have wrapped to make the MID$'s align with each other.
It curious that all the wrapped lines seem to end in comma (or in other words, wrapped at commas), so looks almost like the parser (such as it is for BASIC) is actually kind of indicating line continuation there with commas.
On the main site it says that that was converted by David Ahl.
It’s exactly the way like in the book with 2 columns per page (landscape).
Not sure if this was really a printout (can’t be with 2 columns) or maybe manually fixed for the book layout. There were also similar spaces on his other listings. Probably for better readability.
In some editions it was explained a bit. He used a Teletype 43 printer, not a large one.
This was also my guess, that it would have been adjusted for readability and the purpose of the publication. (A terminal line is an unknown quantity, it could be 80 or 132 CL, or actually about anything.)
It appears most of the listings were sent in from the original authors in paper form, and then simply cut apart and pasted onto a sheet and then copied. You’ll find completely different printers were used for the different programs. So yeah, I’m definitely leaning towards the whitespace being inserted by whatever program they used to print the listing before they sent it in.
Some of the printers/programs didn’t automatically do a CR when reaching the end of the line, so those ones just printed all the remaining characters on top of each other. That’s fun to figure out! In some cases you can see those lines in the sample runs, and in one I found the equivalent line in BCG, so I think I was able to re-construct them correctly, but I’m not sure what someone with a copy of this book was supposed to do.
And then of course there’s the ones that don’t even have the code in the book at all, like bunny and snoopy.
I’m up to hangman now, so I’m hoping to get the collection out by the end of the month.
You forgot the pinup girls.
How to run the programs might be useful too,
as finding a basic is rather hard after 50
years. Mr Gates refuses to sell it.
So, as I continue through the book, I can see that the weird line wrapping does indeed appear to be “real”, and not a side-effect of the printer. So so much for my last post!
The one that convinced me was line 900 of HEX, which is a comment line describing how he stores items in a string - it’s clearly been hand-aligned.
I think I could solve this if someone has the original assembler… I’m guessing their scanner works by looking after every NL for a number, at which point it considers it a new line, otherwise it just keeps going with the last line.
I own 2 books but German editions. The listings were completely rewritten and translated. Used was Microsoft BASIC and only one printer. At least one run is scaled down even more (less than the 64%) a card game to have all 4 hands of cards in one column, game Oktrix, book 2.
Some few listings have lowercase characters. At a first sight there aren’t these spaces.
Game titles were also translated, and I haven’t found them all yet. Bunny is called Häschen (but still has BUNNY in the printout image).
Some games were also released on disks.
There were more editions (mine is the Microcomputer edition) maybe it’s of interest to check them all.
11 games were written by Ahl himself. Not sure which ones.
The source of these (both credited to Kay R. Fisher) aren’t tremendously interesting since they are really only PRINT statements. But if you must, here they are from the PiDP-8/I software archive:
Snoopy is missing at least in the Microcomputer editions.
That depends on the edition. I think one could just type it without the spaces.
The PDP-8 (OS8) SPACWR listing in the PiDP-8 archive is also different not having the spaces and using SEG$ instead of MID$. But both aren’t the original 1972 game anyway.
That’s not surprising, as the PDP-8 didn’t use ASCII: “@” is 0, “A” is 1, “Z” is 26, “]” is 29, “!” is 33, “0” is 48 and “9” is 57.
They’re billed as books of games. Printing something to the screen that wouldn’t even fit on most machines isn’t much of a game.
The PiDP-8 BASIC archive isn’t exclusively from the DEC book. There’s a table in the README that gives the provenance. Its SPACWR uses SEG$ because that’s what PDP-8 BASIC uses. It doesn’t claim to hold the original.
It looks like ampersand is used as an alternative for the print statement in the linked program. Not impossible for it to have both meanings, but it seems more likely to be different BASIC variants.
