There is a classic Commodore one-liner program that prints a maze. I have discussed it on this site several times in the past:
10 PRINT CHR$(205.5+RND(1));GOTO 10I converted it to use CoCo ASCII “/” and “\” characters:
10 PRINT CHR$(47+(RND(2)-1)*45); : GOTO 10I have since noticed that the 10 PRINT book even has a version for the CoCo in it:
https://10print.org/10_PRINT_121114.pdf page 55
Recently, Jim Gerrie posted a video of a new one-liner MC-10 version of the maze that truly fit on one 32-column line of the MC-10:
His approach of using MID$() looked much simpler than the CHR$ version of the Commodore original. I am pretty sure my VIC-20 had MID$ so surely the C64 had it as well. Why wasn’t it used? Perhaps this was an example of code obfuscation. “Type in this mysterious code and see what you get!”
Indeed, in a quick test, using MID$() is smaller and faster:
0 PRINTMID$("/\",RND(2));:GOTO
0 PRINTCHR$(47+(RND(2)-1)*45);:GOTONow, doing the MC-10 version with CHR$() would be longer on the CoCo since we can’t type those characters like the MC-10 allows. We’d have to use CHR$(140)+CHR$(138) embedded in the MID$ to make that work (and be much slower since it would parse those numbers for every byte of the maze it prints). But…
0 PRINTMID$(CHR$(140)+CHR$(138),RND(2));:GOTO…does work.
To make it faster, we’d need two lines and a string:
0 A$=CHR$(140)+CHR$(138)
1 PRINTMID$(A$,RND(2));:GOTO1Even with that, the GOTO is slower than the MC-10 version since it has to parse a number, and then has to skip a line each time. You could get around that by doing it like this, and starting it with “RUN 1”:
0 PRINTMID$(A$,RND(2));:GOTO
1 A$=CHR$(140)+CHR$(138):GOTOHow would you do it? Let me know in the comments.
Until next time…
You could use an infinite FOR loop instead of GOTO, as in:
0 A$=CHR$(140)+CHR$(138):FORZ=.TO1STEP.:PRINTMID$(A$,RND(2));:NEXT
You can also use an array instead of indexing the characters with MID$ (but I don’t know if it’s any faster).
0 C$(1)=CHR$(140):C$(2)=CHR$(138):FORZ=.TO1STEP.:PRINTC$(RND(2));:NEXT
The infinite FOR should be faster than the GOTO. Drats. I’m going to have to benchmark this one liner, aren’t I?
Have you already carried out a benchmark?
In this special case FOR-NEXT could lead to more overhead because of stack handling and turning around the parameters. FOR-NEXT is always deterministic, because it does not depend on the destination and the count of lines between program start and the destination.
However, it solves perfectly the problem to jump back in the middle of a single line.