Back in the day computer mags had 20-liner competitions. The objective was to cram as much functionality into 20 lines of BASIC and people did amazing stuff with that.

To use the space as best as possible lines were filled to brim and BASIC commands abbreviated. PRINT was ? and other command abbreviations contained PETASCII characters that don't even have a Unicode equivalent[1].

The Commodore 64 particularly had square[2] 8x8 pixel characters and a line on the screen was 40 of them in a row. A logical line from the BASIC interpreter's perspective was still 80 characters long though, which made the program effectively 40 screen lines high.

You see, where this is going. The perfect 20-liner was close to a 40 by 40 square of character salad.

[1] They were one letter and a shifted letter, which could be displayed as symbol depending which mode you were in. They were printed expanded when listing the program. Everything was a bit complicated.

[2] Almost. Pixels were not perfectly square, with the aspect ratio depending on PAL or NTSC.

Current submission title “Print, a one-line BASIC program” is not great. Title from the page:

  10 PRINT CHR$(205.5+RND(1)); : GOTO 10

Could also be something like “10 PRINT: a book about a one-line Commodore 64 BASIC program” (taken from the first sentence with “is” changed to a colon).

My first summer job was a $2/hour "Night Operator" at Transdata, a Phoenix timesharing company. They shut down their timesharing service at night, so after running a few batch jobs, I had the SDS Sigma 5 all to myself.

We had a few one-card programs, some fun, some useful. A single card held 80 bytes of machine code.

The Sigma 5 had a small speaker on the front panel that you could toggle between two states to move the cone in or out. How often you toggled it determined the pitch of the sound.

One card was called BIRDS. It toggled the speaker to make it sound like several birds chirping at each other.

A more useful one was PRINT. You put it in front of a deck of cards, ran the deck through the card reader, and it would print the deck.

It was a bit slow, because it used a single memory buffer:

  1. Read card 1
  2. Print card 1
  3. Read card 2
  4. Print card 2
  5. Read card 3
  6. Print card 3
  etc.

In other words, at any moment either the card reader or the printer would be operating, not both.

I studied the code and found there were just enough bytes left out of the 80 to implement double buffering by flipping a buffer pointer at each step:

  1. Read card 1 into buffer A
  2. Print card 1 while reading card 2 into buffer B
  3. Print card 2 while reading card 3 into buffer A
  4. Print card 3 while reading card 4 into buffer B
  etc.

Twice as fast!

There is a 10-byte assembler (Intel) port of the same program:

https://trixter.oldskool.org/2012/12/17/maze-generation-in-t...

For those that don’t know ascii off the top of the head, it prints either a forward or backward slash repeatedly, which in the c64 font creates a pretty art piece like the graphic at the bottom of the screen.

This is indescribably beautiful. Thanks for sharing it! It went straight to the top of my reading queue.

I tried this on all the basic interpreters available on Ubuntu (yabasic, sdlbasic, basic256 and bwbasic), couldn't get it to work on any of them.

In a couple cases the only remaining issue was the lack of a RND() function definition

The referenced book was so good until the “considered harmful” sections. As it indicates, GOTO is basically JMP, and I’m sorry if someone is offended by BASIC, but it’s not only the subject of the book but was the promoted language to the masses for early microcomputers, such that people would buy the related BASIC book at the store, along with the computer.

See also https://youtu.be/34CXQr5OLas