See also: part 1, part 2, part 3 and part 4.
Awhile back, I discussed the famous Commodore 10 PRINT one-line program, inspired by a YouTube video from 8-Bit Show and Tell.
Although most computers could do the same program in BASIC, unless your system had those wonderful diagonal graphics characters, the result could be a bit lacking.
On the CoCo, using the 2×2 block graphics characters was not an improvement, either.
But perhaps if you used a 4×4 block it might look more like a maze. This allows 16 maze characters across by 8 down (versus a Commodore VIC-20 with 22×23).
Well, it works, but takes up much more than one line. How small can you make it? Here is my version:
0 ' BIGMAZE.BAS 10 C=2 20 B$=CHR$(128) 30 L$=CHR$(128+16*C+9) 40 R$=CHR$(128+16*C+6) 50 M$(0,0)=B$+R$:M$(0,1)=R$+B$ 60 M$(1,0)=L$+B$:M$(1,1)=B$+L$ 70 P=512-32*2 80 M=RND(2)-1 90 PRINT@P,M$(M,0);:PRINT@P+32,M$(M,1); 100 P=P+2:IF P>479 THEN PRINT:GOTO 70 110 GOTO 80
Make it smaller. Make it faster. Share your work. And someone tell Jim Gerrie since he probably has already done this…
Until next time…
Welp, everything up to line 60 can be mashed into a single line. Since it’s all setup and none of it is performance critical, you can dispense with the variables and just set the M$ array directly. More typing, but it keeps the variable table smaller. Or define P right at the start so it’s the first variable in the table which would give you a speedup all on its own since the lookups to find P will be faster.
I suspect that if you put the PRINT statement from line 100 at, say, the start of line 70 and have “THEN 70” instead of “THEN PRINT:GOTO 70”, you might get a bit of a performance gain there, especially in the false case where that gives a handful fewer bytes to skip over.
There might be some sort of trick involving FOR/NEXT that can be used to improve the main loop but I think the overhead of setting up a FOR loop will be more than the saving in this case, especially if the setup lines are combined into a single program line.
On a side note, and this won’t improve the speed any, you could put a DIM M(1,1) at the start to avoid the implied DIM M(10,10). That saves a bit of memory, though I don’t think that’s even an issue for this program even on a 4K machine. But it is 585 bytes nevertheless.
Pingback: 10 PRINT big maze in Color BASIC – part 2 | Sub-Etha Software