ASCII / (0x2f) and \ (0x5c) has three problems:
1. They're not as conveniently located (chr$(47+(rnd(1)*45) isn't quite as pretty)
2. They don't fill up character cell so there are gaps in the "maze"
3. PETSCII doesn't have a \ (0x5c is £)
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.
In the magazines I remember from my days cutting my programming teeth on an Acorn Electron, there were 10-liners and 1-liners. What some people could squeeze out of 252 bytes was very impressive, even without using extra features (extra graphics primatives for instance) found in other models like the Master series.
https://trixter.oldskool.org/2012/12/17/maze-generation-in-t...
In a couple cases the only remaining issue was the lack of a RND() function definition
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!
chrismorgan•2d ago
kstrauser•2d ago
10 PRINT is their official shortened version.
mryall•1d ago
When repeated across multiple lines, it looks like an intricate random maze. But it is actually just a visual representation of whatever PRNG is used on the platform, with the default seed as set by the BASIC interpreter.
https://sta.c64.org/cbm64pet.html
NKosmatos•1d ago
kristianp•1d ago
6581•1d ago