2024-01-09 – Corrected a PMODE 1 size typo from 8×18 to the correct 8×16, and a 16×17 typo.
Here is a quickie…
I did not know this was possible “back in the day,” and do not think I have ever tried it until now.
In Extended Color BASIC you can use “GET” to get a block of memory from the screen and store it in array memory. You can then “PUT” it back on to the screen.
But, if you know where the array memory is (using the VARPTR function) you can POKE bytes directly in to the array and then just PUT it without ever needing to GET.
10 ' GET/PUT ARRAY (2 ENTRIES) 20 DIM B(1) 30 ' PRE-ALLOCATE VARIABLES 40 DIM A,D,L,V 50 ' 256x192 (32X24 OF 8X8 CHARS) 60 PMODE 4,1:PCLS:SCREEN 1,1 70 ' GET ADDRESS OF ARRAY DATA 80 V=VARPTR(B(0)) 90 ' POKE 8X8 DATA IN TO IT 100 FOR L=V TO V+7:READ D:POKE L,D:NEXT 110 ' PUT THE DATA ON THE SCREEN 120 PUT(0,0)-(7,7),B 130 GOTO 130 140 ' BOMB DATA 150 DATA 24,24,60,118,122,126,126,60
This demo puts an 8×8 bomb on the top left of the screen. The bomb was one of the characters from my VIC-20 game Factory TNT.
VIC-20 Factory TNT character set in CBM prg Studio.
It does not look like you can use a multi-dimensional array got GET/PUT (does anyone know if this is possible?). Pity. If that were possible, I had something I wanted to try.
How much array memory do I need?
To know how many DIM array elements you need for an object, run this program:
0 REM pmodes.bas 5 CLS:INPUT "W,H";MW,MH:PRINT 10 FOR M=0 TO 4:READ M$ 20 PRINT "PMODE";M;"(";M$;")" 30 NEXT 40 PRINT 50 PRINT "M W X H W X H PXLS BYT E" 60 PRINT "- -- -- -- -- ---- --- --" 70 FOR M=0 TO 4 80 W=MW:H=MH 90 PRINT USING "# ##X##";M;W;H; 100 PRINT" -> "; 110 IF M<4 THEN W=W/2 120 IF M<2 THEN H=H/2 130 P=W*H 140 B=P/(8-4*(M AND 1)) 150 E=INT(B/5+.5) 160 PRINT USING "##X## #### ### ##";W;H;P;B;E 170 NEXT 180 IF INKEY$="" THEN 180 190 GOTO 5 999 GOTO 999 1000 DATA "128 X 96 X 2" 1010 DATA "128 X 96 X 4" 1020 DATA "128 X 192 X 2" 1030 DATA "128 X 192 X 4" 1040 DATA "256 X 192 X 2"
Type in the width/height and it shows you the memory requirements for that object on each PMODE screen. If it says it needs two elements, that is a DIM X(1) because DIM starts at 0. DIM X(3) would give you four — X(0), X(1), X(2) and X(3).
PMODE width and heights
Be aware that all PMODE screens use coordinates of 256×192, and scale to whatever resolution is being used (128×96, 128×192 or 256×192).
On a PMODE 4 screen (256×192), doing LINE(0,0)-(7,7),PSET,B draws a box that is truly 8 pixels wide by 8 pixels tall.
On a PMODE 2 or 3 screen (128×192), the same command would draw a box that was 4 pixels wide and 8 pixels tall.
On a PMODE 0 or 1 screen (128×96) would be drawing a box that was 4 pixels wide by 4 pixels tall.
If you truly wanted an 8×8 object on a PMODE 0 or 1 screen (128×96) screen, you would have to draw it as 16×16. An 8×8 object on a PMODE 2 or 3 screen (128×192) would be drawn as if it was 8×16.
Here is a short program that draws a 16×16 pixel box on each of the five PMODE screen types. It adjusts the width and height based on the mode to know how big of a box it has to draw which would appear as 16×16:
10 FOR M=0 TO 4 20 W=16:H=16 30 PMODE M,1:PCLS:SCREEN 1,1 40 IF M<4 THEN W=W*2 50 IF M<2 THEN H=H*2 60 LINE(0,0)-(W,H),PSET,B 70 LINE(0,0)-(W,H),PSET 80 LINE(W,0)-(0,H),PSET 90 IF INKEY$="" THEN 90 100 NEXT 999 GOTO 999
And that is not confusing at all ;-) But it did mean that you could draw anything as if it were a PMODE 4 screen and then draw it on any lower resolution screen without changes — you could just lose detail.
But I digress. It looks like I should write a new article series…
If I would have told my teenage-self that one day I would be corresponding with Radio Shack ROM-Pak game programmer, Rick Adams, I would have not believed myself. Rick became a very well known name in the CoCo community, and I remember seeing his name in the title screen of Radio Shack ROM-Paks. Temple of ROM was one I played at Radio Shack, but never owned. I just recall thinking it was like a fancy version of my all-time favorite Atari VCS game, Adventure.
But I digress…
It started with a message containing a screen shot:
Rick had simplified the program by breaking up the pattern in to sections he could GOSUB to and print a few lines. It was simple, and smaller than printing the whole thing.
“Why line 2046?” I asked. Apparently, the PDP-8 BASIC he was using had that as the highest line number. This was one of many restrictions this version of BASIC had. Through our chat, I learned it had a limit to the length of a string, and could not do things like MID$(A$,1,1)=”A” which were methods I had been toying with.
The next thing he sent me was optimizing this pattern further, breaking it up in to just one part of the diamond shape:
1 DIM A$(4) 10 FOR I = 1 TO 4 20 READ A$(I) 30 NEXT I 40 FOR I = 1 TO 4 50 PRINT A$(I);A$(I);A$(I) 60 NEXT I 70 FOR I = 3 TO 1 STEP -1 80 PRINT A$(I);A$(I);A$(I) 90 NEXT I 300 DATA " * " 301 DATA " * * " 302 DATA " * *" 303 DATA "* " 2046 END
This proof-of-concept code worked by loading this pattern in to an array. It can print the top array string three times across the screen, then continue through the pattern. Then, for the reverse diamond, print the array backwards. This version was clever, though it left off the right-most asterisk of the bottom/middle row, which could be handled by adding an extra IF/PRINT for those lines. Neat!
But, even when packing everything together (the PDP-8 BASIC has its own way of combining lines using a backslash), it did not look like it would be the smallest approach to this challenge.
A bit later, I received this screen shot:
This, my friends, is what a programmer comes up with when they are tired of typing in Microsoft BASIC. Rick has a front-end (pre-processor?) that allows him to write nicely readable (for BASIC) code and then have it converted to Microsoft BASIC for loading on a CoCo.
I typed that in (well, not literally) to a CoCo and saw that it worked. But what is it doing? Let’s look at a packed CoCo version of this code he provided (adjusted to work on the 40 column screen):
This looks like a similar approach that Jason Pittman had mentioned he was working on — drawing the pattern as if it was two asterisks that just get further apart as they move down the line (then closer together as it continues).
Rick’s version appears to work by starting with an empty string – generated using the STRING$(20,32) for a string of 20 CHR$(32) spaces. As it goes forward through the loop, it changes the character in the string at position J+I to be an asterisk, then the character at position J-I to be an asterisk . At the top/bottom of each diamond, the offset is 0, so it is just putting the asterisk on top of itself.
Let me break this apart, closer to his original pre-preprocessed source. I will put some extra spaces in to space out the loops:
1 GOSUB 100 2 FOR K=1 TO 3 3 FOR I=1 TO 3 4 GOSUB 100 5 NEXT I 6 FOR I=2 TO 0 STEP -1 7 GOSUB 100 8 NEXT I 9 NEXT K 10 END 100 A$=STRING$(20,32) 101 FOR J=4 TO 16 STEP 6 102 MID$(A$,J-I)="*" 103 MID$(A$,J+I)="*" 104 NEXT J 105 PRINT A$ 106 RETURN
Line 100 – The subroutine creates an A$ of 20 space characters.
Line 101 – The FOR loop of 4 TO 16 STEP 6 will produce values of 4, 10 and 16. That matches the top spacing of the peak of the diamond shapes in the pattern:
Line 102 – at position J-I (I is set by a FOR loop before it GOSUBs to this routine) will be places an asterisk at that location inside the A$. The outer FOR I loop is 1 TO 3, calling this routine each time, so it would look like this:
I=1, J=4, 10, 16 (producing 4-1, 10-1 and 16-1 ... 3, 9 and 15). "..*.....*.....*....."
I=2, J=4, 10, 16 (producing 4-2, 10-2 and 16-2 ... 2, 8 and 14). ".*.....*.....*......"
I=3, J=4, 10, 16 (producing 4-3, 10-3 and 16-3 ... 1, 7 and 13). "*.....*.....*......."
Line 103 – this line does the same thing, but uses the position of J+I so the asterisk moves to the right each time:
I=1, J=4, 10, 16 (producing 4+1, 10+1 and 16+1 ... 5, 11 and 17) "....*.....*.....*..."
I=2, J=4, 10, 16 (producing 4+2, 10+2 and 16+2 ... 6, 12 and 18) ".....*.....*.....*.."
I=3, J=4, 10, 16 (producing 4+3, 10+3 and 16+3 ... 7, 13 and 19) "......*.....*.....*."
Since these two lines are adding asterisks to the same A$, the results actually look like this:
Line 104 – is the NEXT for the FOR/J, so it goes through all three entries (4, 10 and 16).
Line 105 – prints the modified string.
Line 106 – returns back to the main code.
You will notice that calling this routine like this misses the top line. Let’s look at the start of the program to see how it gets there:
Line 1 – This initial GOSUB to 100 is what draws that top line. When the program starts, all variables are zero. So the routine enteres with I set to 0, which would make J+I and J-I just be the J value, putting an asterisk at the 4, 10, and 16 positions:
"...*.....*.....*...."
Well. That’s clever.
Line 2 – This is just a FOR loop to draw the pattern three times.
Line 3 – This is the FOR loop that draws the top part of the diamond, but since I always starts at 0, it doesn’t draw the “top” row — that was done by LINE 1, and then when it draws the reverse/bottom of the diamond it will finish that pattern, which is the last row and start of the next diamond. (Confused yet?)
Line 4 – Draw the line for the top part of the diamond (inside the I loop of 1 to 3).
Line 5 – This is the NEXT for the top-to-bottom I loop.
Line 6 – This is a second I loop, that goes from 2 to 0.
Line 7 – Calling the GOSUB routine, so now it will be drawing like this:
I=2, J=4, 10, 16 (producing 4+2, 10+2 and 16+2 ... 6, 12 and 18) ".....*.....*.....*.."
I=1, J=4, 10, 16 (producing 4+1, 10+1 and 16+1 ... 5, 11 and 17) "....*.....*.....*..."
I=0, J=4, 10, 16 (producing 4+0, 10+0 and 16+0 ... 4, 10 and 16) "...*.....*.....*...."
And the second part of the GOSUB doing the right side of the pyramid shape:
I=2, J=4, 10, 16 (producing 4-2, 10-2 and 16-2 ... 2, 8 and 14) ".*.....*.....*......"
I=1, J=4, 10, 16 (producing 4-1, 10-1 and 16-1 ... 3, 9 and 15) "..*.....*.....*....."
I=0, J=4, 10, 16 (producing 4-0, 10-0 and 16-0 ... 4, 10 and 16) "...*.....*.....*...."
I have to admit, this year’s Logiker challenge stumped me. I had a few “clever” ideas on how to reproduce the pattern, but the code was larger than just printing out the pattern from arrays of strings.
Meanwhile, Jason Pittman kept posting revisions of his concept in the comments. In a response to part 2, he shared this:
This is the last attempt I came up with. It uses the same “-3 to 2 … ABS()” from the other example I sent on part 1. I think one potential trick here is to treat it as if you are holding a rubber stamp that stamps out three asterisks that are six spaces apart. You want to make this pattern by stamping it twice on each line. You’re keeping track of a starting position on each row (1027 + 32 for each row) and an offset to add and subtract to the starting position for each row. On the first line, the offset is zero, so you stamp it twice on top of itself at the starting position. On the next line, the offset is 1, so you stamp it twice, but one time you add -1 and the other time you add +1 to the starting position. Does this make any sense?
This was an optimization of his original approach, but it had one limitation that might prevent it from solving the challenge: The CoCo’s 32×16 screen is too small to display the entire image, and POKEing characters on the screen would be limited to just 16 lines of text. He was aware of this, and his program does POKE the full image, but it is POKEing past the end of the visible screen. Would this count? RUNning the program displays the pattern over and over again (which was done to avoid having a new line with an endless loop GOTO):
POKEing past the visible screen works here because I am emulating a Disk Extended BASIC CoCo, and the memory after the text screen is reserved for four pages of PMODE high resolution graphics. But, I suspect, if I ran this on a cassette based CoCo, it might be POKEing in to memory used for the BASIC program itself.
Perhaps the CoCo 3 could help, since it has 40×25 and 80×25 text modes? Jason tried that:
I may play around with LPOKE. This should get it on the 40 column screen. I bet there is a crafty way to (a) not do the last line manually outside of the loops (b) remove one of the FOR loops (c) Shoot, there’s probably some crafty wizard way to do it in one FOR loop with logical operators, but I wouldn’t ever find it.
In this version, Jason uses LOCATE(x,y) to position the cursor. That is what the CoCo 3 used instead of PRINT@ for text positioning. And it works!
It also feels better to use built-in BASIC text commands versus POKEing in to memory.
But he wasn’t done! He added this version:
10 WIDTH 40 20 FOR S = -15 TO 33 STEP 6 30 FOR X = 0 TO 18 40 IF S+X < 19 AND S+X >= 0 THEN LOCATE S+X,X:PRINT "*"; 41 IF S-X >= 0 AND S-X < 19 THEN LOCATE S-X,X:PRINT "*"; 50 NEXT X 60 NEXT S 70 GOTO 70
This one draws the same pattern, but in a very different way. It draws diagonal lines going down from the points at the top. Try it! It’s cool!
And, then this odd one, which creates the pattern by drawing the asterisks RANDOMLY, eventually getting them all on the screen.
…seems like it should be simple. Three asterisks, then six, then six, then four, then six, then six, then three… Spaces that go five, three, one, zero and then back up. Unhelpful.
But, it’s also just one pattern repeated across the screen three times…
* * * * * * *
And then it’s reversed, so I think if we can do the above, we can do the whole pattern. We see spaces of three, two, one, zero on the left, and zero, one, three, and five in the inside.
Color BASIC does not have a SPC() option (my VIC-20 did, I think) for outputting spaces, but TAB() will go to a specific column. Maybe we can figure out which column the asterisks should be in:
This gives us 4, 10 and 16. Then 3 and 5, 9 and 11, and 15 and 17. Then 2 and 6, 8 and 12, and 14 and 18. Finally, 1 and 7 and 13 and 19. I don’t know why, but I kind of like thinking about it as tab positions.
10 FOR SP=3 TO 0 STEP-1 20 PRINT TAB(SP);"*";TAB(6-SP); 30 IF SP<3 THEN PRINT "*"; 40 PRINT 50 NEXT
That would give us one of the pyramid shapes. To complete the bottom, we’d do another FOR/NEXT loop. At least, that’s what I would do. BUT, in a comment to part 1, Jason Pittman had a smarter idea:
Awesome! I’ve got an idea on this one but I’m not going to jump ahead this year and I’m just going to follow along.One thought here is that you could combine the two print loops on 100 and 110 by coming up with a series that goes “0 1 2 3 2 1”. I did it by replacing 100 and 110 with this: “100 FOR A=-3 TO 2:PRINT A$(ABS(ABS(A)-3)):NEXT”
Or, you could shorten that a little if you reverse the direction of the array (so that it looks like “VVV”) and use “100 FOR A=-3 TO 2:PRINT A$(ABS(A)):NEXT”
– Jason Pittman
I could print one diamond like this:
10 FOR A=-3 TO 3:SP=ABS(A) 20 PRINT TAB(SP);"*";TAB(6-SP); 30 IF SP<3 THEN PRINT "*"; 40 PRINT 50 NEXT
That prints almost the entire diamond, except for the final asterisk. Because, if I wanted to print three of them, I’d do this in a loop, then print the final asterisk row at the end.
Unfortunately, as I start going down this rabbit hole, I find the code of loops and such ends up looking larger than some much simpler approaches, like one shown to my by Rick Adams. His code was written for a PDP-8 BASIC, which lacks things like ELSE and MID$. His technique was to have strings representing parts of the pyramid:
" * " " * * " " * *" "* "
…then to print each string three times across the screen. This produced:
" * * * " " * * * * * * " " * * * * * *" "* * * "
…and then do it backwards. There is a missing “*” on the right, that gets printed with an “IF”. In a chat, we bounced around some ideas to shrink the code, but looking at his approach, it seems everything I try to do gets larger:
Try “run length encode” where DATA statements represent the spaces. Print that many spaces, then an asterisk, and repeat.
Try DATA statements showing the positions of the asterisks. DATA is large than a string.
Try simulating a “SET(x,y)” to draw it, but using PRINT@ on the CoCo. Alas, the CoCo 32×16 screen is too small to fit the whole pattern, so even if this was smaller, it would still require extra code at the end to scroll the screen and print the final few lines (as the top portion scrolls off). BUT, using a CoCo 3 40/80 column screen would work using LOCATE x,y instead. But still, larger.
Is there an elegant solution to this challenge that doesn’t involve just PRINTing strings?
This image is 19×19, so while it will fit on a Radio Shack Color Computer 1/2 screen width-wise, it’s a bit too tall to fit height-wise. The challenge allows for it to scroll off the screen, which is something we had to do for past challenges.
Logiker 2023 Challenge pattern.
I can think of a number of ways to approach this.
The pattern is made up of only four unique lines, so you could print them A B C D B C A B C D and so on. There’s probably a simple way to do that with a FOR/NEXT loop and an array of those four lines.
10 CLS 50 A$(0)=" * * * 60 A$(1)=" * * * * * * 70 A$(2)=" * * * * * * 80 A$(3)="* * * * 90 FOR I=1 TO 3 100 FOR A=0 TO 3:PRINT A$(A):NEXT 110 FOR A=2 TO 1 STEP-1:PRINT A$(A):NEXT 120 NEXT 130 PRINT A$(0) 333 GOTO 333
If we had a larger screen (like the 40 or 80 column screens on the Color Computer 3), we could use LOCATE x,y to plot the pattern using some line drawing type math.
We could try the RLE (run length encoding) compression from past years to see if we could compress it down to spaces and characters.
We could try using math to figure out a pattern.
These all seem fun.
I hope to find some time to experiment. I don’t plan to “enter,” since one of the asks for the challenge is to not share your work until after the challenge ends.
VAL() takes a string and converts it in to a floating point numerical variable. The value of “1E39” is a number in scientific notation, and this appears to cause a problem.
In Microsoft BASIC, the notation “1E39” represents the number 1 multiplied by 10 raised to the power of 39. This is also known as scientific notation, where the “E” indicates the exponent to which the base (10 in this case) is raised. So, “1E39” is equal to 1 * 10^39, which is an extremely large number:
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 10
I converted it to use CoCo ASCII “/” and “\” characters:
10 PRINT CHR$(47+(RND(2)-1)*45); : GOTO 10
I 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:
https://www.youtube.com/watch?v=7FQ_ht5u2y4
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:
Now, 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:
Even 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”:
Awhile back, I posted a note about some weird behavior with DATA statements in Color BASIC. The issue was that you really couldn’t have anything else on a line after the DATA keyword other than data.
I recently mentioned this to Alex Evans so he could make sure his BASIC utilities were not combining DATA statements together. He mentioned something to me that demonstrated this issue even more:
100 DATA 1,2,3:PRINT "FOO"
110 DATA -1
If you RUN that program, it should print “FOO” and do nothing else, proving that the interpreter does scan the entire line looking for things after a DATA statement.
BUT, if you try to USE that DATA, it will continue reading after the 3 and error out, since the data it finds is not an ASCII number:
Above, the “?SN ERROR” is caused by trying to read a numeric variable from what is NOT a string (the token value for PRINT followed by FOO in quotes). Altering the program to use A$ instead of A (and print one item read per line) shows this a bit better:
Alex explained it like this:
Basically, for the purposes of READ everything after the DATA keyword is part of the data statements, but the interpreter executes the line properly.
– Alex Evans
You can see it appears to treat the colon as a DATA separator, since it does not appear as part of the read DATA.
This is a quirk I do not expect many of us ever encountered, since most of us probable grouped all our DATA together, without mixing commands in with them:
100 DATA 1,2,3,-1
I bet all of this was discovered and covered back in the 1980s in various CoCo magazines and newsletters, but the behavior surprised me when I stumbled upon it so I guess I never saw it.
The later model CoCo 2s used an upgrade MC6847 video display generator chip. This chip provided an updated font with true lowercase, as well as the ability to change the border color and inverse the video.
The original 6847 had a hardware pin that could inverse video, and I recall taking the VDG out of my CoCo 1 to pull up a pin then re-insert it. That gave me the nice inverted display I often use in the XRoar emulator:
In the nearly-forty years since I did that modification I had forgotten that it could only be done in hardware. I thought there was probably a POKE or something, since many programs I had used the inverted video mode.
I couldn’t figure it out, and the bits that made the updated 6847T1 show inverse video did not work on the original 6847.
I wrote a program to go through the 6847 T1 VDG text modes, which includes lowercase, changing the border, and inverting the screen.
I’ve seen programs on the CoCo (like GRABBER) that invert/reverse the screen in software, but the bits to do that on the T1 don’t seem to do anything on the 6847.
Does anyone know of a reference that would show me how to do this? Thanks, much!
There is an inverse video pin on the chip. But it is not hooked up. I think.
– tim lindner, 2/15/2023
With that in mind, I decided to do some quick tests. This test PRINTs every possible visible character on the screen:
10 CLS:PRINT
20 FOR C=32 TO 255:PRINT CHR$(C);:NEXT
30 GOTO 30
I skipped the first line and I started printing with CHR$(32) (a space) because the values below that are non-visible characters.
BUT, if you POKE to the screen, you get more characters. Here is an update that will POKE the values 0-255 to the bottom half of the screen:
10 CLS:PRINT
20 FOR C=32 TO 255:PRINT CHR$(C);:NEXT
30 FOR C=0 TO 255:POKE 1280+C,C:NEXT
40 GOTO 40
Comparing the PRINT versus POKE characters, you can see PRINT has 64 ASCII-printable characters starting at 32-96. After that are 32 inverted characters. There are 32 characters that you cannot print in inverse.
When you POKE, values 0-63 represent the inverted full ASCII character set, and 64-127 are the uppercase.
PRINT POKE
------- -------
32-96 64-127 Space to Left Arrow
96-127 0-31 Inverse "@" to Inverse Left Arrow
32-63 Inverse Space to Inverse "Left Arrow"?"
From that table, you can see it’s impossible to PRINT thirty two of the available inverse characters in the 6847, but you can POKE them.
I thought it might be fun to write a routine that would PEEK through the screen memory and invert all the characters. Since there are 32 non-inverted characters from 32-96, and 32 inverted characters from 96-127, it seems all I needed to do is PEEK each location and if it was from 96-127, subtract 64 and POKE it back.
We start with this slow program, complete with some benchmarking timing code:
10 ' FILL SCREEN WITH STUFF
20 CLS:FOR C=32 TO 255:PRINT CHR$(C);:NEXT
30 TIMER=0
40 FOR L=1024 TO 1536
50 V=PEEK(L):IF V>63 AND V<128 THEN POKE L,V-64
60 NEXT
70 PRINT TIMER
This prints 631 for me. One of the first speedups we can do is change the decimal numbers in line 50 to hex.
10 ' FILL SCREEN WITH STUFF
20 CLS:FOR C=32 TO 255:PRINT CHR$(C);:NEXT
30 TIMER=0
40 FOR L=1024 TO 1536
50 V=PEEK(L):IF V>&H3F AND V<&H80 THEN POKE L,V-&H40
60 NEXT
70 PRINT TIMER
That simple change takes the time down to 490. And, since variable lookups (when there aren’t a ton of variables) is faster than parsing a hex number in source code, we can change those values to variables and make it even faster:
10 ' FILL SCREEN WITH STUFF
20 CLS:FOR C=32 TO 255:PRINT CHR$(C);:NEXT
25 X=&H3F:Y=&H80:Z=&H40
30 TIMER=0
40 FOR L=1024 TO 1536
50 V=PEEK(L):IF V>X AND V<Y THEN POKE L,V-Z
60 NEXT
70 PRINT TIMER
This drops to 475.
And, any time you use “IF this AND that”, it can be sped up by doing “IF this THEN IF that”. Let’s try that…
10 ' FILL SCREEN WITH STUFF
20 CLS:FOR C=32 TO 255:PRINT CHR$(C);:NEXT
25 X=&H3F:Y=&H80:Z=&H40
30 TIMER=0
40 FOR L=1024 TO 1536
50 V=PEEK(L):IF V>X THEN IF V<Y THEN POKE L,V-Z
60 NEXT
70 PRINT TIMER
In this case, it really did not change anything — I see 474. Okay, that was a fail. I guess it doesn’t always help.
Since the math we are doing is a subtract 64, we should see if we can do that by using AND to remove the bit that represents 64. We don’t want to do that if it is a graphics character (128-255) so we’ll need to retain on IF:
10 ' FILL SCREEN WITH STUFF
20 CLS:FOR C=32 TO 255:PRINT CHR$(C);:NEXT
25 X=&H3F:Y=&H80:Z=&H40
30 TIMER=0
40 FOR L=1024 TO 1536
50 V=PEEK(L):IF V<Y THEN POKE L,V AND &H3F
60 NEXT
70 PRINT TIMER
That shows 367 for me. Better!
I did test to see if checking for the 8th bit (V AND 128) was faster than just comparing a value (A > 127) and the “>” check was faster, so we’ll stick with that.
At this point, the routine to inverse the screen while leaving graphics characters alone is getting close to twice as fast as the original version.
Can we do better? At least a bit, by removing spaces and combining lines (and even though it only parses the FOR values once, I’ll switch them to hex):
10 ' FILL SCREEN WITH STUFF
20 CLS:FOR C=32 TO 255:PRINT CHR$(C);:NEXT
25 X=&H3F:Y=&H80
30 TIMER=0
40 FORL=&H400 TO&H5FF:V=PEEK(L):IFV<Y THENPOKEL,V AND&H3F
50 NEXT
70 PRINT TIMER
That prints 356. (There were a few spaces that could not be removed due to needing them so the BASIC parser knows where a variable ends and a keyword begins.)
Now we could make a subroutine that would invert the screen, slowly.
While it might be a neat “effect” for a title screen to watch it painting the screen, it’s not fast enough to use in a program that you want the output to always be inverted.
Some thoughts…
If no semigraphics characters were being used, the check for them could be removed:
10 ' FILL SCREEN WITH STUFF
20 CLS:FOR C=32 TO 127:PRINT CHR$(C);:NEXT
25 X=&H3F:Y=&H80
30 TIMER=0
40 FORL=&H400 TO&H5FF:V=PEEK(L):POKEL,V AND&H3F
50 NEXT
70 PRINT TIMER
That prints 304 — twice as fast as the original, though it will corrupt semigraphics blocks by changing them.
Another approach might be to only do the portion of the screen that has been PRINTed to by changing the range that the L loop scans. For example, you could call a routine to invert just the last line of the screen every time something is PRINTed there.
Or, perhaps a custom “print reverse” routine might make more sense. We’d also want a special CLS routine that cleared the screen to inverse spaces.
10 CLS
20 GOSUB 1100
30 P=0:A$="This is in REVERSE video!":GOSUB 1000
40 P=32:A$="And this one is, too.":GOSUB 1000
50 P=480:A$="Hello, bottom line!":GOSUB 1000
999 GOTO 999
1000 ' PRINT@ REVERSE
1010 L=&H3FF+P:FOR I=1 TO LEN(A$)
1020 V=ASC(MID$(A$,I,1)):IF V>95 THEN V=V-96 ELSE IF V>64 THEN V=V-64
1030 POKE L+I,V:NEXT:RETURN
1100 ' CLS REVERSE
1110 P=0:FOR L=&H400 TO &H5FF:POKE L,&H20:NEXT:RETURN
To use the function set P to the PRINT@ location, assign the string to A$, then GOSUB 1000. Not much to it.
Handling scrolling the screen would be more work (and slower), but could also be done. Perhaps the routine could track the PRINT@ position internally, so every time you print it increases P by 32 (next line) and if it gets to the end of the screen, it could scroll everything up… slowly…
10 CLS
20 GOSUB 1200
30 A$="This is in REVERSE video!":GOSUB 1000
40 A$="And this one is, too.":GOSUB 1000
50 A$="PRINT;":GOSUB 1100
60 A$="NEXT TEXT":GOSUB 1100
70 P=480:A$="BOTTOM LINE":GOSUB 1000
80 A$="AND THIS":GOSUB 1000
999 GOTO 999
1000 ' PRINT@ REVERSE
1010 GOSUB 1100:P=P+32-I+1:IF P<512 THEN 1050
1020 ' SCROLL
1030 FOR L=&H400 TO &H5E0:POKE L,PEEK(L+&H20):NEXT
1040 FOR L=&H5E0 TO &H5FF:POKE L,&H20:NEXT:P=P-32
1050 RETURN
1100 ' PRINT@; REVERSE
1110 L=&H3FF+P:FOR I=1 TO LEN(A$)
1120 V=ASC(MID$(A$,I,1)):IF V>95 THEN V=V-96 ELSE IF V>64 THEN V=V-64
1130 POKE L+I,V:NEXT:P=P+I-1
1140 RETURN
1200 ' CLS REVERSE
1210 P=0:FOR L=&H400 TO &H5FF:POKE L,&H20:NEXT:RETURN
To clear the screen, GOSUB 1200.
To do a normal PRINT, set the string in A$ and GOSUB 1000.
To do a PRINT with a semicolon at the end, set the string in A$ and GOSUB 1100.
To simulate a PRINT@, set P to the screen position then GOSUB 1000 or 1100.
This program does NOT handle printing past position 512 at the bottom right of the screen.
IT CAN POKE PAST SCREEN MEMORY AND CAUSE A CRASH!
A simple check could be done before line 1130 to see if L+I is going to be past the end of screen memory (1536) and adjust accordingly.
If there is any interest (leave a comment), we can look at how we might do that in a future article.
Is this useful?
If we really wanted to use inverse video in BASIC, I guess it would be useful. Can you make it faster in BASIC? What would you suggest? Leave a comment.
But, doing inverse text would be a simple thing for some assembly language routines that could be called easily from BASIC.
OR, perhaps there would be a simple way to just hook in to the output vector used by Color BASIC and do it there.
This is a poor example because PRINTing a variable is generally faster than printing a number due to the BASIC interpreter needing to parse all the TEXT digits of the number and convert it to a string to PRINT. To my surprise, when I ran this test, I found they were basically the same speed. The overhead of processing a line and converting a string of digits seemed to offset the time saved of the loop that was printing a variable that doesn’t need parsing. (FOR/NEXT loop fast, PRINTing variable fast versus a bunch of lines that might be faster but have slower parsing for the text digits.)
However, if the series of individual PRINT lines were printing a variable (“PRINT X”) it would be more than twice as fast.
10 PRINT X
20 PRINT X
...
1000 PRINT X
Apples to apples (difficult to do in this example), blasting out a ton of lines is faster than doing them in a loop. I’ve heard assembly language programmers refer to this as “loop unrolling” and it can work in BASIC as well.
A better example might be how you draw a background screen. Consider a 32 column text screen that is cleared to black, and a border is printed around it:
Here is some code that would do this:
10 CLS 0
20 PRINT CHR$(128);STRING$(30,207);CHR$(128);
30 FOR I=1 TO 14
40 PRINT CHR$(207);STRING$(30," ");CHR$(207);
50 NEXT
60 PRINT CHR$(128);STRING$(30,207);
70 GOTO 70
Or, you could do it using loop unrolling and change that loop of 14 steps to be 14 PRINTS:
When I time those two, there is a teeny speed improvement in the second version (around 1/60th of a second). Is that enough to justify the overhead of the extra memory needed? Probably not in this example, but it might be if it was in code that was redrawing a screen for a game or something.
Side Note: Of course, we could speed this up by pre-generating the strings and the PRINTing them. That would avoid all the parsing of CHR$() and the numbers and building temporary strings over and over and over.
10 CLS 0
20 PRINT CHR$(128);STRING$(30,207);CHR$(128);
25 L$=CHR$(207)+STRING$(30," ")+CHR$(207);
30 FOR I=1 TO 14
40 PRINT L$;
50 NEXT
60 PRINT CHR$(128);STRING$(30,207);
70 GOTO 70
That is about 40% faster than the original, and it could be made even faster, but that’s not the point currently.
Inlining
Another way to speed things up is eliminate as many GOTOs and GOSUBs as you can. Every GO has to search either forward, line by line, looking for the target line (if going to a line after the current one), or start at the very first line and search forward (if starting at an earlier line).
A 10,000 line program will find it quite slow to be on line 10000 and type GOTO 9999. Likewise, line 1 saying “GOTO 10000” will be quite slow.
If there is enough memory, inlining subroutine code will speed things up every time the code is used. Consider this subroutine from my old *ALL RAM* BBS:
15 BR$="*==============*==============*"
...
25 A$="Welcome To *ALL RAM* BBS!":GOSUB1055
...
50 'New User
55 A$="Password Application Form":GOSUB1055
...
100 'Main Menu
105 A$="*ALL RAM* BBS Master Menu":GOSUB1055
...
150 'Call Sysop
155 A$="Calling the Sysop":GOSUB1055
...
200 'Goodbye
205 A$="Thank you for calling":GOSUB1055
...
250 'Userlog
255 A$="List of Users":GOSUB1055
...
1050 'Function Border
1055 CLS:PRINTBR$:PRINTTAB((32-LEN(A$))/2)A$:PRINTBR$:RETURN
The routine at line 1050 takes a string in A$. It will clear the screen, print a border string, print the A$ centered, then print the border string again and return.
The time it takes to run this code should be the same no matter where it appears in the program, but the time it takes to get to this code will vary depending on where it is called from. If you were calling it from line 1040, it would be quite fast. If you were calling it from line 20, it has to scan forward through every line from 20-1050 to find it, which would be slower. At least, because it is a GOSUB routine, it will return quickly. (That’s a big advantage of using GOSUB over GOTO.)
This routine could be inlined in to the code, and each use would be slightly faster.
15 BR$="*==============*==============*"
...
25 A$="Welcome To *ALL RAM* BBS!"
26 CLS:PRINTBR$:PRINTTAB((32-LEN(A$))/2)A$:PRINTBR$
...
50 'New User
55 A$="Password Application Form"
56 CLS:PRINTBR$:PRINTTAB((32-LEN(A$))/2)A$:PRINTBR$
...
100 'Main Menu
105 A$="*ALL RAM* BBS Master Menu"
106 CLS:PRINTBR$:PRINTTAB((32-LEN(A$))/2)A$:PRINTBR$
...
150 'Call Sysop
155 A$="Calling the Sysop"
156 CLS:PRINTBR$:PRINTTAB((32-LEN(A$))/2)A$:PRINTBR$
...
200 'Goodbye
205 A$="Thank you for calling"
206 CLS:PRINTBR$:PRINTTAB((32-LEN(A$))/2)A$:PRINTBR$
...
250 'Userlog
255 A$="List of Users"
256 CLS:PRINTBR$:PRINTTAB((32-LEN(A$))/2)A$:PRINTBR$
...
Again, this is a pretty poor example, but if this routine was something that required speed (a game, animation, etc.) every little bit would help.
Other time-saving techniques
I have covered many other optimizations to code, such as using “&H” hex numbers rather than decimal and using “.” instead of 0, and all of these things can combine to make a dramatically faster program — at the expense of code size. (A=9 takes three bytes, while A=&H9 is faster but takes four bytes.)
But if we were back in 1980 and trying to program on a 4K CoCo, perhaps we would have more things to worry about than speed.
Size matters
On that 1980 4K CoCo, a “PRINT MEM” on startup shows 2343 bytes free for a program. If you didn’t plan to use any strings or string functions, a CLEAR 0 would give back 200 bytes for a total of 2534 bytes free. You probably won’t be doing any loop unrolling or inlining in this environment.
Instead, focusing on the smallest way to do something makes more sense.
Subroutine everything!
If any bit of code is used more than once, it may make sense to make it a subroutine as long as the overhead of having to add “GOSUB xxx” and “RETURN” do not take more than the duplicate code would.
10 X=0:Y=0:P=(Y*32)+X:PRINT@P,"HELLO"
Above, some X and Y coorindates (representing the CoCo’s 32×16 text screen) are converted to a PRINT@ screen position (0-511). This is the type of code that might appear many places where something is printed at the screen. This makes it a good candidate for being a subroutine:
Each time “P=(Y*32)+X” is used, that takes 10 bytes. The overhead for “GOSUB 1000” is 8 bytes, then the subroutine itself adds 5 bytes for the line overhead and 2 bytes for “:RETURN”. That’s 15 bytes extra we just added, but if it were used more than a few times, it starts saving memory. (See note below about line numbers and how you can make this save even more.)
And, if the routine was using X/Y to a P position to print something, you might as well put that in the subroutine as well and eliminate the P variable completely:
With just a bit of reworking code, many bytes can be saved.
But that’s not the best example of saving bytes, because “GOSUB 1000” takes up a lot of memory. Let’s look at how to make it take up less.
Small line numbers save bytes
When a program is tokenized (keywords like PRINT replaced with one and two byte tokens representing the command), the line number is changed in to a two-byte representation of the line. It doesn’t matter if you are at line 5 or line 55000, the line number will take up two bytes of the tokenized line.
But, when you have a line number in the line itself, such as as the target of GOTO, GOSUB if an IF/THEN, those digits will be stored in full just as you typed them:
10 GOTO 10
20 GOTO 100
30 GOTO 1000
40 GOTO 10000
Above, line 20 will take up one more byte than line 10, because “100” takes one more byte than “10”. Because of this, using shorter line numbers will save space. Instead of this:
In this example, you have immediately added extra overhead by having line 0, but as long as you save enough to offset that, the program will be smaller. In this example, the three “GOSUB 10000” were turned in to “GOSUB 1” saving four bytes every time they were used.
As a bonus, having the subroutines at the start of the program will make them faster, since every GOSUB will be to a higher number, and BASIC will just start at the first line and scan forward, finding the subroutine much quicker. Smaller and faster!
And, of course, don’t forget to number your program by 1 — or, if using Extended Color BASIC with the RENUM command, you can do this:
RENUM newline, startline, increment Renumbers a program. newlineis the first new renumbered line. If you omit newline, BASIC uses 10. startlineis where the renumbering starts. If you omit start/ine, BASIC renumbers the entire program. incrementis the increment between each renumberedline. If you omit increment, BASIC uses 10. Note: RENUM does not rearrange the order of lines.
– Getting Started With Extended Color BASIC (1984 edition), page 58
RENUM 0,0,1
That will renumber the program to start at line 0, beginning at line line 0, and incrementing by 1s. If you started with:
100 PRINT
200 PRINT
300 PRINT
400 PRINT
…a RENUM 0,0,1 will give you:
0 PRINT
1 PRINT
2 PRINT
3 PRINT
You may save a few bytes every time a GOTO/GOSUB or IF/THEN is used.
Side Note: I believe it was Alex “Basic Utils” Evans who recently pointed out to me that GOTO and GOSUB each used two bytes. They are actually three token words — GO, TO and SUB. You can even write them separated with a space like “GO TO 100” or “GO SUB 100“. I hadn’t seen that since I was first learning BASIC back in 1982 or so, in some books a schoolmate was loaning me.
Avoid gratuitous use of lines
Every line in Color BASIC has five bytes of overhead. If you typed in a line that was just:
10 A
…you would see memory goes down by six bytes. Five bytes for the line overhead, and one byte for the “A”.
Side Note: Those five bytes are a 2-byte address of the next line, a 2-byte line number, and a trailing 0 terminator at the end of the line. In the above example, the bytes would look like “[xx][xx][yy][yy][A][0]” for that line.
Because of this, writing things out on separate lines consumes more memory, and is also slower since BASIC has more line number data to parse (included when doing a GOTO/GOSUB).
[xx][xx][yy][yy][print_token][:][print_token][:][print_token][:][print_token][:][print_token][:][0] <- 15 bytes total
In Color BASIC, the input buffer will allow you to type up to 249 characters for one line, so you can really pack a lot of commands together and save space (and speed).
Side Note: In Extended BASIC, the EDIT command can be used to get a few extra characters on a line. If you type a long line that features BASIC keywords up to the max of 249 characters, then press ENTER, the line gets tokenized and words that took up five characters like “PRINT” get turned in to one or two byte tokens. This can free up enough space to allow doing an EDIT on the line, then an Xtend to go to the end of the line, and type a few more characters. “When every last byte matters…”
Other space-saving techniques
REM – If space matters, leave out any REMarks in the code as they both take up extra space and slow the program down. I would sometimes comment my programs pretty heavily, then save the commented version out, and then delete the remmarks and save out the smaller version.
Spaces – Removing any unnecessary spaces (“GO TO 1000” becomes “GOTO1000”) helps.
Semicolons – A semi-colon is only required at the end of a PRINT line if you want to avoid having the carriage return printed, or when separating variables that BASIC cannot tell apart form keywords. For example, “PRINT A;B;C” is obviously needed because “PRINT ABC” would be a different variable. But, the semicolon is assumed between items you can print such as “PRINT VAL(A$);B$;CHR$(128)” which works just fine as “PRINT VAL(A$)B$CHR$(128)”. Heck, even when printing string variables like “PRINT A$B$C$D$” the semicolons are not needed. BUT, you still need it if BASIC can’t tell. If you wanted to print A$, B (number) and C$, you would need “PRINT A$B;C$” since BASIC needs to know where the B non-string variable ends.
Trailing Quotes – If a line ends in a quote, the quote can be left off. This goes for things like PRINT”SOMETHING” or even A$=”SOMETHING”. BASIC will figure it out when it gets to the end of the line.
Parenthesis – There are times when parenthesis are required to make math work (order of operations), but sometimes it is just done to make the code easier to read (like spaces and splitting up one instruction per line). In my X/Y example, I used “(Y*32)+X” but the parens don’t matter. The multiplication will happen first, then the addition, so “Y*32+X” will save two bytes. TEST FIRST! Some things look like they should work, but will require parens. (“1*256+1 – 1*256+1” feels like it should be zero, but it will be 2. For this you do need “(1*256+1)-(1*256+1)”.
And, of course, figuring out how to reduce code and combine things is always part of the process.
See also “Carl England’s CRUNCH program” which will do those steps for you.
There are many other tips and tricks for optimizing BASIC for speed or size, but hopefully these examples get you started in experimenting.
