See Also: part 1, part 2, part 3, part 4 and part 5.

Making a maze of blocks look less blocky

Okay, where were we?

Right. We wanted to take this…

…and turn it in to this…

…while storing it like this…

DATA FFFFFFF0

To round or not to round…

If the maze were stored as bits representing blocks that were either set or unset (32×16 blocks will fit on the CoCo 32 column screen), we could make the program handle changing those blocks in to ones with “rounded” corners, or open areas in the middle or large blocks.

First, I needed to decide what the rules are for this, so I did some drawings.

For each corner (top left, top right, bottom left, bottom right) it seemed safe to round if the block above, beside, and diagonally from the corner were empty (empty red square). BUT, only round if the opposite sides were NOT vacant (red X). If that second part isn’t there, a single block with a path all around it would have all of its corners rounded. That’s fine on high resolution graphics (it would be a circle?), but when each block is made up of 2×2 mini squares, you can’t remove each corner or you’ll have nothin’ left!

As I found out.

Next, there are large areas made up of double blocks. On the Pac-Man maze these are larger “open” areas with thin walls around them, like the four along the top of the arcade Pac-Man game:

Don’t fill me in…

To figure out what the rules were for this, I did more drawings…

This one took me a bit longer to figure out. Above, each mini square of block is represented by the graph. Each white box is 2 blocks by 2 blocks.

After way too much trial and error, I worked it out that any corner that has an occupied square above, beside, and diagonally qualifies to be removed.

At first I tried to brute-force this in BASIC. It was way too long, and way too slow.

Then I decided as I was scanning each block location, I’d use variables to PEEK the contents of what was up, down, left or right from the blocks, as well as up-left, up-right, down-left and down-right from it. Using variables greatly sped things up (though they are still way too slow).

Once I had those variables, I could apply some simply logic.

I noticed that in both CORNERS and CENTERS, there is a need to check for an OCCUPIED block beside and either above or below. I started there, since I could do that check once, then dispatch to a second routine to determine if it was doing a corner, a center, or both.

I ran in to many bugs during all of things, and learned I had to pass each block through all the checks… Originally, I’d find a corner, remove it, and move to the next block. That would leave other corners that should have been removed, or center bits…

Finally, I came up with this (slow) proof-of-concept:

0 REM MAZEVERT.BAS

10 CLS:FOR I=0 TO 15:READ A$:PRINT@2+32*I,A$;:NEXT
20 BL=96
30 FOR M=1024 TO 1535
40 IF PEEK(M)=BL THEN 140
50 POKE M,175:V=175
60 IF M>1055 THEN U=PEEK(M-32):UR=PEEK(M-31) ELSE U=BL:UR=BL
70 IF M>1056 THEN UL=PEEK(M-33) ELSE UL=BL
80 L=PEEK(M-1):R=PEEK(M+1)
90 DL=PEEK(M+31):D=PEEK(M+32):DR=PEEK(M+33)

100 IF U<>BL THEN IF L<>BL THEN GOSUB 200
110 IF U<>BL THEN IF R<>BL THEN GOSUB 300
120 IF D<>BL THEN IF L<>BL THEN GOSUB 400
130 IF D<>BL THEN IF R<>BL THEN GOSUB 500
140 NEXT
150 FOR M=1024 TO 1535:IF PEEK(M)=96 THEN POKE M,128
160 NEXT
170 GOTO 170

200 ' UP and LEFT set
210 IF UL<>BL THEN V=V AND NOT 8
220 IF R=BL THEN IF DR=BL THEN IF D=BL THEN V=V AND NOT 1
230 POKE M,V:RETURN

300 ' UP and RIGHT set
310 IF UR<>BL THEN V=V AND NOT 4
320 IF L=BL THEN IF DL=BL THEN IF D=BL THEN V=V AND NOT 2
330 POKE M,V:RETURN

400 ' DOWN and LEFT set
410 IF DL<>BL THEN V=V AND NOT 2
420 IF U=BL THEN IF UR=BL THEN IF R=BL THEN V=V AND NOT 4
430 POKE M,V:RETURN

500 ' DOWN and RIGHT set
510 IF DR<>BL THEN V=V AND NOT 1
520 IF L=BL THEN IF UL=BL THEN IF U=BL THEN V=V AND NOT 8
530 POKE M,V:RETURN

999 GOTO 999

1000 DATA "XXXXXXXXXXXXXXXXXXXXXXXXXXXX"
1010 DATA "X            XX            X"
1020 DATA "X XXXX XXXXX XX XXXXX XXXX X"
1030 DATA "X XXXX XXXXX XX XXXXX XXXX X"
1040 DATA "X XXXX XXXXX XX XXXXX XXXX X"
1050 DATA "X                          X"
1060 DATA "X XXXX XX XXXXXXXX XX XXXX X"
1070 DATA "X XXXX XX XXXXXXXX XX XXXX X"
1080 DATA "X      XX    XX    XX      X"
1090 DATA "XXXXXX XXXXX XX XXXXX XXXXXX"
1100 DATA "     X XXXXX XX XXXXX X     "
1110 DATA "     X XX          XX X     "
1120 DATA "     X XX XXXXXXXX XX X     "
1130 DATA "XXXXXX XX X      X XX XXXXXX"
1140 DATA "          X      X          "
1150 DATA "XXXXXX XX X      X XX XXXXXX"
1160 DATA "     X XX XXXXXXXX XX X     "
1170 DATA "     X XX          XX X     "
1180 DATA "     X XX XXXXXXXX XX X     "
1190 DATA "XXXXXX XX XXXXXXXX XX XXXXXX"
1200 DATA "X            XX            X"
1210 DATA "X XXXX XXXXX XX XXXXX XXXX X"
1220 DATA "X XXXX XXXXX XX XXXXX XXXX X"
1230 DATA "X   XX                XX   X"
1240 DATA "XXX XX XX XXXXXXXX XX XX XXX"
1250 DATA "XXX XX XX XXXXXXXX XX XX XXX"
1260 DATA "X      XX    XX    XX      X"
1270 DATA "X XXXXXXXXXX XX XXXXXXXXXX X"
1280 DATA "X XXXXXXXXXX XX XXXXXXXXXX X"
1290 DATA "X                          X"
1300 DATA "XXXXXXXXXXXXXXXXXXXXXXXXXXXX"

The program has three phases:

1. Draw the ASCII maze (or at least what will fit on the screen for this test).
2. Scan the screen and convert non-blanks to semigraphics blocks, then check to see if a corner needs to be removed (because it is a corner or in the center of a larger group of blocks).
3. Scan the screen one more time, changing any blank space blocks to black.

The end result is this:

The whole process takes just over 40 seconds. It could be made faster by going in to double speed mode with POKE 65495,0 (or 65497,0 on a CoCo 3), but even then it would still be way too long for the user to wait for a game screen to draw.

Plus, this doesn’t even have the code to convert the less-memory hex string representation of the maze into the actual maze.

Which means we have more to do…

To be continued…

See Also: part 1, part 2, part 3, part 4 and part 5.

A maze of ideas

Ready to fall down a rabbit hole, exploring ways to represent a maze screen efficiently?

Neither was I.

Somewhere on this site is an article series I wrote about programming a simple maze type game on the CoCo. In it, I presented an ASCII version of the Pac-Man maze. The arcade maze looks like this:

And you can learn a ton about how the game works on the Pac-Man Dosier website. But basically, the game screen is a grid of 28 x 36 tiles. In the arcade original, each tile is 8×8 pixels. With the CoCo 1/2s text screen being 32×16, this means we could fit 28 tiles horizontally with room to space, but we’d be 20 tiles short vertically. (Pac-Man used a monitor mounted sideways to get this aspect ratio.) My solution was to scroll the maze up and down. I also removed the top and bottom rows that showed score and such, so this will be using only 31 of the games original 36 rows.

A portion displayed in ASCII text would look like this:

Though it wouldn’t look like the arcade, this is an accurate representation of the 28×36 tiles of the original game (well, 28×16 seen any any time). There are elements of Pac-Man that couldn’t really be recreated with this low resolution (such as the way Pac can hug to corners to go around them faster), but at least the maze layout could be accurate.

But ASCII is ugly, so we’d probably want to use the semigraphics characters (128-255). Using CHR$(175) for a blue block looks like this:

That’s better, but still a bit ugly. The background could at least be made black:

That’s more better, but it looks more reminiscent of blocky Atari VCS games like Adventure.

By taking advantage of the 64×32 resolution semigraphics, the corners could be at least “rounded” a bit (if round meant “still square”), and the centers of the areas could be opened up like the arcade original:

At this resolution, I’m not sure if we can really do any better than that ;-)

The maze data could be represented as ASCII strings, either directly PRINTed on the screen, or read from DATA statements to be PRINTed or POKEd:

This would make creating new mazes and levels as easy as typing. But storing 28 x 26 characters is 1008 bytes of memory. Imagine trying to do that on a 4K Color Computer or a 5K Commodore VIC-20. (The highest resolution graphics screen on a CoCo 1/2 takes up 6144 bytes, compared to the 512 bytes of the text screen.)

Here’s the ASCII DATA:

1000 DATA "XXXXXXXXXXXXXXXXXXXXXXXXXXXX"
1010 DATA "X            XX            X"
1020 DATA "X XXXX XXXXX XX XXXXX XXXX X"
1030 DATA "X XXXX XXXXX XX XXXXX XXXX X"
1040 DATA "X XXXX XXXXX XX XXXXX XXXX X"
1050 DATA "X                          X"
1060 DATA "X XXXX XX XXXXXXXX XX XXXX X"
1070 DATA "X XXXX XX XXXXXXXX XX XXXX X"
1080 DATA "X      XX    XX    XX      X"
1090 DATA "XXXXXX XXXXX XX XXXXX XXXXXX"
1100 DATA "     X XXXXX XX XXXXX X     "
1110 DATA "     X XX          XX X     "
1120 DATA "     X XX XXXXXXXX XX X     "
1130 DATA "XXXXXX XX X      X XX XXXXXX"
1140 DATA "          X      X          "
1150 DATA "XXXXXX XX X      X XX XXXXXX"
1160 DATA "     X XX XXXXXXXX XX X     "
1170 DATA "     X XX          XX X     "
1180 DATA "     X XX XXXXXXXX XX X     "
1190 DATA "XXXXXX XX XXXXXXXX XX XXXXXX"
1200 DATA "X            XX            X"
1210 DATA "X XXXX XXXXX XX XXXXX XXXX X"
1220 DATA "X XXXX XXXXX XX XXXXX XXXX X"
1230 DATA "X   XX                XX   X"
1240 DATA "XXX XX XX XXXXXXXX XX XX XXX"
1250 DATA "XXX XX XX XXXXXXXX XX XX XXX"
1260 DATA "X      XX    XX    XX      X"
1270 DATA "X XXXXXXXXXX XX XXXXXXXXXX X"
1280 DATA "X XXXXXXXXXX XX XXXXXXXXXX X"
1290 DATA "X                          X"
1300 DATA "XXXXXXXXXXXXXXXXXXXXXXXXXXXX"

If we tried to use numeric DATA statements to represent the screen blocks, it would be 4 times longer since every entry would be a three digit number with a comma:

DATA 175,175,175,175,175,175,175,175,175,175,175,175,175,175,175,175,175,175,175,175,175,175,175

But, if we were just using blocks and spaces, we could have a number represent eight of them. Each number could represent a byte (0-255) and each byte contains 8 bits, therefore each number could represent 8 character blocks.

In a DATA statement with numbers, the top row would look like:

1000 DATA 255,255,255,240

The storage space for “255,255,255,240” is 15 bytes which is less than the 28 string characters (plus quotes, if needed — like if the line started with spaces or had special characters in it like a comma or ‘ REM abbreviation, which this won’t).

I suppose we could use numbers representing 16-bit values (0-65535) and have only two numbers to represent that line:

1000 DATA 65535,65520

That brings us down to 11 bytes to represent the 28 block row.

The 4K CoCo BASIC did not have hexadecimal numbers, but on Extended BASIC machines we could convert to HEX:

1000 DATA &HFF,&HFF,&HFF,&HF0

…but that is 19 bytes. While that would be better than ASCII, it would be worse than two decimal values. Doubling up to 16 bit values results in:

1000 DATA &HFFFF,&HFFF0

That gets us down to 12 bytes so it looks like needing that &H at the start loses out — 65535 versus &HFFFF. Even worse when 1 has to be three times larger as &H1. Though 15 is only one by larger as &HF. But always larger.

Hex values could be written as a string without the &H, and that could be added by the READ routine:

1000 DATA FF,FF,FF,F0

…which gives us 11 bytes, matching the two decimal values. But reading those would require some extra code which might negate the savings:

READ A$:V=VAL("&H"+A$)

…versus just reading a decimal value…

READ V

Using hex without the “&H” requires an extra 15 bytes of code space (actually, maybe a little less, since the “VAL” keyword probably tokenizes in to one or two bytes).

But, we could also pack the hex values together:

1000 DATA FFFFFFF0

That would only take 8 bytes to represent a row. But even more code would be needed to parse that:

READ A$:FOR A=1 TO LEN(A$) STEP 2:V=VAL("&H"+MID$(A$,A,2)):NEXT

The code gets even longer. However, if we had enough data (and 36 rows of data probably is enough), the code space savings should be smaller overall. And clever programming could be done to have one massive hex string and decode it knowing how many bytes go to each line.

But this only gets us to displaying the maze in ASCII or as colored blocks. If we wanted to get that “rounded” corner look of a 64×32 display, we’d need twice as many bytes.

Or we could just make the computer do it for us.

To be continued…

Updates:

• 2024-01-07 – Fixed a value in one of the examples.

During #SepTandy2020, I posted a CoCo-related video each day of the month. A few of them dealt with bit operations in Color BASIC. This was when I fist learned that Color BASIC could not deal with more than 15-bit values. You can do AND/OR/NOT operations

These work:

PRINT 32767 AND 1
PRINT 32767 OR 1
PRINT NOT 32767

…but these will return ?FC ERROR:

PRINT 32768 AND 1
PRINT 32768 OR 1
PRINT NOT 32678

8-bits before 16-bits

8-bits is handled just fine. Here is an example program that will display an 8-bit value (0-255) as binary. It is very slow:

0 ' slow8bit.bas
10 FOR Z=0 TO 255
20 GOSUB 1000:PRINT
30 NEXT
40 END
1000 REM SLOW: 8-BIT Z AS BINARY
1010 FOR BT=7 TO 0 STEP-1
1020 IF Z AND 2^BT THEN PRINT "1"; ELSE PRINT "0";
1030 NEXT:RETURN

If you looked at TIMER, that one would count to 7339 (about 122.2 seconds). And here is a version that is substantially faster because it pre-calculates the AND bit values in an array:

0 ' fast8bit.bas
5 DIM BT(7):FOR BT=0 TO 7:BT(BT)=INT(2^BT):NEXT
10 FOR Z=0 TO 255
20 GOSUB 1000:PRINT
30 NEXT
40 END
1000 REM FAST: 8-BIT Z AS BINARY
1010 FOR BT=7 TO 0 STEP-1
1020 IF Z AND BT(BT) THEN PRINT "1"; ELSE PRINT "0";
1030 NEXT:RETURN

TIMER for that one would count to 1372 (about 22.8 seconds).

When I was recording those videos, I decided to make versions that handled 16-bit values. That is when I discovered you could not to that in Color BASIC.

16-bit workaround

Color BASIC seems to treat bit values as signed, so instead of 0 to 65535, it is really -32768 to 32767. That led me to a workaround where, if the high bit was set, I would subtract 65536 from the value and do the AND/OR/NOT on a negative value. And it worked!

0 ' fast16bit.bas
5 DIM BT(15):FOR BT=0 TO 14:BT(BT)=INT(2^BT):NEXT:BT(15)=-32768
10 FOR Z=0 TO 65535
20 GOSUB 1000:PRINT
30 NEXT
40 END
1000 REM SLOW: 16-BIT Z AS BINARY
1005 IF Z>32767 THEN Z=Z-65536
1010 FOR BT=15 TO 0 STEP-1
1020 IF Z AND BT(BT) THEN PRINT "1"; ELSE PRINT "0";
1030 NEXT:RETURN

The above version uses powers-of-two for the first 15 bits (1, 2, 4, 8, 16, etc.) then for bit 16 it uses -32768, which will work. When the value is passed in, if it is larger than 32767, it is turned in to a negative value which would be a 16-bit number with the high bit set, indicating negative.

I have no idea if this is “supposed” to work, or even be allowed (AND/OR/NOT on a negative), but it does.

And what about AND? (And OR, and NOT?)

For something I am working on, I wanted to use AND to get the most significant and least significant bytes of a 16-bit value. I could not, so I came up with various workarounds:

1. To get the MSB of a 16-bit value, shift the 16-bit value right 8 bits (divide by 256).
2. To get the LSB of a 16- bit value, subtract the MSB*256 from the original 16-bit value.

10 W=&HFFEE
20 M=INT(W/256)
30 L=W-M*256
40 PRINT HEX$(W),HEX$(M);" ";HEX$(L)

This worked fine, but required swapping variables around to preserve the original values.

In my project, I then wanted to clear the top 5-bits of the word, so I would clear them in the MSB value:

M=M AND &H07

…and then I could re-build the word variable using “W=M*256+B”.

Then I wondered: Could I somehow use the same trick I used for 16-bit binary numbers to make AND, OR and NOT just work on the value?

It turns out, yes. Yes I could.

I started with a subroutine that would take a 16-bit value in in Z and convert it, as needed, to a negative value that represented the desired bits. I did this this by manually looping through the bits and adding the appropriate bit value from the same array I used in the fast 16-bit routine shown earlier:

5 DIM BT(15):FOR BT=0 TO 14:BT(BT)=INT(2^BT):NEXT:BT(15)=-32768
...
1000 ' CONVERT 16-BIT Z TO ZC
1010 ZC=0:IF Z>32767 THEN Z=Z-65536 ELSE ZC=Z:RETURN
1020 FOR BT=15 TO 0 STEP-1
1030 IF Z AND BT(BT) THEN ZC=ZC+BT(BT)
1040 NEXT:RETURN

I could then set a value to Z and call this subroutine and then use ZC with AND/OR/NOT:

10 V=65535:A=&HFF00
20 PRINT V;"AND";A;"=";
30 Z=V:GOSUB 1000:VC=ZC
40 Z=A:GOSUB 1000:AC=ZC
50 Z=VC AND AC

Yuck. But it worked. Except, after I AND the two converted values, the value I get would be a negative if it was using more than 15-bits. If I wanted to display that as HEX, I’d get another ?FC ERROR because you cannot HEX$ a negative.

Thus, I needed a routine to convert such a 16-bit negative value back to a normal positive number:

1100 ' CONVERT ZC BACK TO Z
1110 IF Z<0 THEN ZC=Z+65536 ELSE ZC=Z
1120 RETURN

The end result was a multistep routine I could use to AND, OR or NOT and 16-bit value:

0 ' AND16.BAS
5 DIM BT(15):FOR BT=0 TO 14:BT(BT)=INT(2^BT):NEXT:BT(15)=-32768

10 V=65535:A=&HFF00
20 PRINT V;"AND";A;"=";
30 Z=V:GOSUB 1000:VC=ZC
40 Z=A:GOSUB 1000:AC=ZC
50 Z=VC AND AC:GOSUB 1100:PRINT ZC

999 END
1000 ' CONVERT 16-BIT Z TO ZC
1010 ZC=0:IF Z>32767 THEN Z=Z-65536 ELSE ZC=Z:RETURN
1020 FOR BT=15 TO 0 STEP-1
1030 IF Z AND BT(BT) THEN ZC=ZC+BT(BT)
1040 NEXT:RETURN

1100 ' CONVERT ZC BACK TO Z
1110 IF Z<0 THEN ZC=Z+65536 ELSE ZC=Z
1120 RETURN

And it works!

But is there a better way?

A better way

To avoid all the swapping with temporary variables, it might be easier to just make subroutines for AND, OR and NOT that handled two passed-in variables and returned the results in another.

I created a generic subroutine that would take V1 and V2, and convert V1 (if negative) and create a new value based on the bits of V2:

4000 ' CONVERT V1 AND V2
4010 IF V1>32767 THEN V1=V1-65536
4020 IF V2>32767 THEN V2=V2-65536
4030 ZZ=0:FOR BT=15 TO 0 STEP-1
4040 IF V2 AND BT(BT) THEN ZZ=ZZ+BT(BT)
4050 NEXT:V2=ZZ:RETURN

The program could set V1 to a value and V2 to a value for the bit operation, then GOSUB 4000. Then the program could do “V=V1 AND V2” or “V=V1 OR V2” or “V=NOT V2” to perform the operation.

Then, a GOSUB to 5000 would convert V back to the positive value (if needed):

5000 ' CONVERT V BACK, IF NEEDED
5010 IF V<0 THEN V=V+65536
5020 RETURN

This allowed a slightly less ugly way to do AND, OR and NOT on 16-bit values:

0 ' ANDORNOT16.BAS
5 DIM BT(15):FOR BT=0 TO 14:BT(BT)=INT(2^BT):NEXT:BT(15)=-32768

10 V1=&HFFFF:V2=&HFF00
20 PRINT HEX$(V1);" AND ";HEX$(V2),"=";
30 GOSUB 4000:V=V1 AND V2:GOSUB 5000:PRINT HEX$(V)

40 V1=&H8000:V2=&H0001
50 PRINT HEX$(V1);" OR  ";HEX$(V2),"=";
60 GOSUB 4000::V=V1 OR V2:GOSUB 5000:PRINT HEX$(V)

70 V2=&HF00F
80 PRINT "     NOT ";HEX$(V2),"=";
90 GOSUB 4000:V=NOT V2:GOSUB 5000:PRINT HEX$(V)

999 END

1000 ' AND 16-BIT V1 WITH V2
1010 GOSUB 4000:V=V1 AND V2:GOSUB 5000:RETURN

2000 ' OR 16-BIT V1 WITH V2
2010 GOSUB 4000:V=V1 OR V2:GOSUB 5000:RETURN

3000 ' NOT 16-BIT V1
2010 GOSUB 4000:V=NOT V2:GOSUB 5000:RETURN

4000 ' CONVERT V1 AND V2
4010 IF V1>32767 THEN V1=V1-65536
4020 IF V2>32767 THEN V2=V2-65536
4030 ZZ=0:FOR BT=15 TO 0 STEP-1
4040 IF V2 AND BT(BT) THEN ZZ=ZZ+BT(BT)
4050 NEXT:V2=ZZ:RETURN

5000 ' CONVERT V BACK, IF NEEDED
5010 IF V<0 THEN V=V+65536
5020 RETURN

It still ain’t pretty, but it still works. (Though has not been extensively tested, so your milage may vary.)

Until next time…

In a comment to my recent article about VARPTR, Rogelio Perea chimed in…

Still learning something new about the CoCo even after all the years, excellent article!

Would there ever be one about DEFFN? :-)

–  Rogelio Perea II, 7/19/2022

Challenge accepted.

DEF FN: Definitely Fun?

There are many features of Microsoft Color BASIC that went right over my head when I was learning to program as a junior high school kid. DEF FN was certainly one of them.

My first CoCo came with Extended Color BASIC, and that was required to use DEF FN. But what is is? According to Getting Started with Extended Color BASIC:

Extended Color BASIC has one numeric function, DEF FN, that is unlike any others we’ve talked about so far. DEF FN lets you create your own mathematical function. You can use your new function the same as any of the available functions (SIN, COS, TAN, and so on). Once you’ve used DEF FN to define a function, you may put it to work in your program by attaching the prefix FN to the name you assign to the new function. Here is the syntax for DEF FN:

DEF FN name (variable list) – formula

name is the name you assign to the function you create.
variable list contains one “dummy variable” for each variable to be used by the function.
formula defines the operation in terms of the variables given in the variable list

Note: Variable names that appear in formula serve only to define the formula; they do not affect program variables that have the same name. You may have only one argument in a formula call; therefore, DEF FN must contain only one variable.

You may use DEF FN only in a program, not in the immediate mode.

– Getting Started with Color BASIC, page 177.

I think my work here is done.

Until next time…

Okay, maybe not.

DEF FN: Define Function

There are commands in BASIC, such as PRINT and GOTO, and then there are functions that return values, such as SIN, ABS and INT.

PRINT SIN(42)
-.916521549

X=-42
PRINT ABS(X)
42

X=4.2
PRINT INT(X)
4

DEF FN allows you to create your own function that returns a value.

A simple example

We start with a simple example. What if you wanted a function that added 42 to any value you passed in? I will call this function “UA” (for “Ultimate Answer”) and define it as follows:

10 DEF FNUA(N)=N+42
20 PRINT FNUA(10)

If I run that, it will print 52. The new “function” FNUA(x) returns whatever you pass in with 42 added to it. Tada!

Function names seem to follow the same rules as variable names so you can have one or two letters (A to Z, AA to ZZ) or a letter and a number (A0 to Z9).

In the parens is a parameter that also follows the same rules of a variable. The parameter is just a placeholder so you have something to use in your new formula on the right of the equal sign. If you did DEF FNA(X) then after the equal you’d have whatever you want to happen to X. When the user calls it with FNA(123) then 123 goes to where the X was in the formula after the equals… Neat.

It’s kind of like a C function with only one parameter, now that I think about it/

// fnua(n) - return n plus 42
int fnua(float n)
{
    return n+42;
}

int main()
{
    float x = fnua(10);

    printf ("x = %f\n", x);

    return EXIT_SUCCESS;
}

You can have DEF FNA(X) or DEF FNZZ(AB) or any combination.

What can you use it for?

The manual gives an example of doing math with a long floating point value so you don’t have to have that value in your code everywhere you want to use it.

7 DEF FNR(X)=X/57.28577951
6 AA=FNR(AA): AB=FNR(AB): AC=FNR(AC)

At least I’m not the only one with code snippets that don’t really do anything.

Of course, for something like this you could have placed that number in a variable which would be faster than parsing a long number (in most cases). Still, if the formula itself is big, it could save typing, I guess.

Benchmarks, anyone?

I was curious if it would be any faster for other types of maths…

Suppose I want to use PRINT@ to put a character on the text screen, but want to use PEEK to see if it “hits” another character on the text screen. I would use the PRINT@ positions of 0-511, but I’d want to PEEK the screen memory locations of 1024-1535.

10 CLS:P=0
20 FOR I=1 TO 20:PRINT@RND(511)-1,"X";:NEXT
30 PRINT @P,"*";
40 A$=INKEY$:IF A$="" THEN 40
50 IF A$="W" THEN NP=P-32:GOTO 90
60 IF A$="A" THEN NP=P-1:GOTO 90
70 IF A$="S" THEN NP=P+32:GOTO 90
80 IF A$="D" THEN NP=P+1
90 IF NP<0 THEN 40
100 IF NP>510 THEN 40
110 IF PEEK(NP+1024)<>96 THEN 40
120 PRINT @P," ";
130 P=NP
140 GOTO 30

Above is a program that will clear the screen and put X characters in random positions. The player is an asterisk in the top left of the screen. Using the keys W (up), A (left), S (down) and D (right) will move the asterisk around the screen. Checks ensure you cannot go off the top or bottom of the screen, or run in to an X.

Line 110 does the conversion from PRINT@ position to PEEK position. Maybe we can do this:

0 ' defusr2.bas
10 CLS:P=0
15 DEF FNP(X)=X+1024
20 FOR I=1 TO 20:PRINT@RND(511)-1,"X";:NEXT
30 PRINT @P,"*";
40 A$=INKEY$:IF A$="" THEN 40
50 IF A$="W" THEN NP=P-32:GOTO 90
60 IF A$="A" THEN NP=P-1:GOTO 90
70 IF A$="S" THEN NP=P+32:GOTO 90
80 IF A$="D" THEN NP=P+1
90 IF NP<0 THEN 40
100 IF NP>510 THEN 40
110 IF PEEK(FNP(NP))<>96 THEN 40
120 PRINT @P," ";
130 P=NP
140 GOTO 30

The behavior is the same, and now I get the benefit of it not having to parse “NP+1024” each time. Parsing decimal values is slow. On Extended BASIC I could have replaced 1024 with hex &H400 and that would have been faster. For more speed, I could have used a variable and had “NP+S” or whatever.

But is it faster?

0 ' defbench1.bas
5 P=0
10 TIMER=0
20 FOR A=1 TO 1000
30 Z=P+1024
40 NEXT
50 PRINT TIMER

Doing “P+1024” 1000 times prints 481.

0 ' defbench2.bas
5 P=0
6 DEF FNP(X)=X+1024
10 TIMER=0
20 FOR A=1 TO 1000
30 Z=FNA(P)
40 NEXT
50 PRINT TIMER

That version prints 603. Not faster. The overhead of FN seems to be more than just doing it directly. In a way, this makes sense because in-lining code in assembly or C is faster than calling it as a subroutine/function.

But let’s try more… We could also include other things in the function, like the PEEK itself.

0 ' defbench3.bas
5 P=0
6 DEF FNP(X)=PEEK(X+1024)
10 TIMER=0
20 FOR A=1 TO 1000
30 Z=FNP(P)
40 NEXT
50 PRINT TIMER

That one prints 690, and if you had just done “30 Z=PEEK(P+1024)” it would have been 572.

Cool, but definitely slower. I believe this is because it’s still storing that formula in a buffer somewhere and executing it as if you’d just typed it in. Indeed, if you change the formula to use hex:

0 ' defbench3.bas
5 P=0
6 DEF FNP(X)=PEEK(X+&H400)
10 TIMER=0
20 FOR A=1 TO 1000
30 Z=FNP(P)
40 NEXT
50 PRINT TIMER

…it prints 480, which means it’s parsing that formula each time instead of converting it to a number when you define it.

Pity. It would have been really cool if this had been a way to bypass the detokenizer stuff in BASIC and speed up routines like that.

FN Conclusion

DEF FN is slower. I don’t see any example where it speeds anything up. With that said, I expect I’d use DEF FN if…

• I had a custom function I used in multiple places, and wanted to maintain it in just one spot. This would be more efficient, perhaps, than making it a GOSUB subroutine.
• I needed to save some bytes of BASIC memory.
• I wanted to write an example that fix things on small lines on the screen, just for appearances.

For anything else, I think I’d just put it in and make the program a bit faster.

Where else might one use this?

More examples

Sebastian Tepper commented to another post with a more useful example for DEF FN. There are many times when we use two PEEKs to get a 16-bit value from two bytes in memory:

V=PEEK(25)*256+PEEK(27)

Sebastian mentioned using DEF FN for this:

DEF FNP(AD)=PEEK(AD)*256+PEEK(AD+1)

V=FNP(25)

That’s very cool, and something I could see myself using. I wish I had thought of that when I was doing all my “Color BASIC memory location” articles, since I typed the double PEEK lines over and over and over…

But that’s not all…

The defined function can also use other variables. You can only pass one in, but any variable that is declared at the time the FN is used may be used. You could do this:

10 DEF FNA(X)=X*Y
20 Y=10
30 PRINT FNA(Y)
RUN
50

Above, you pass in a value for “X” and it returns the value multiplied by whatever Y is at that moment. You could create more complex formulas that way, but it kind of defeats the purpose.

Speaking of defeating the purpose, here are more silly examples. Using it to replicate PEEK:

10 DEF FNP(X)=PEEK(X)
20 PRINT FNP(1024)

How about returning if something is true or not? Like, is a memory location outside screen memory?

…but that sure looks like it would be really slow. Still neat, though. You could do:

IF FNL(L) THEN PRINT"NOT IN SCREEN MEMORY"

It does make the code look neater — especially if something is being checked multiple times (such as checking four ghost in Pac-Man or whatever).

What other examples can you think of? Leave a comment.

Until next time…

See also: part 1 and part 2.

In the first part, the following Color BASIC program was shared:

5 CLEAR 100*255
10 MX=99
20 DIM A$(MX):AL=0:DL=-1
30 SZ=RND(255):SZ=255
40 A$=STRING$(SZ,"X")
50 GOSUB 1000:GOTO 30
999 END

1000 REM
1001 REM ADD NEW STRING
1002 REM
1010 IF AL=DL THEN GOSUB 2000
1020 GOSUB 3000:IF Z<1024 THEN GOSUB 2000
1030 PRINT "ADDING";LEN(A$)"BYTES AT";AL;Z
1040 A$(AL)=A$
1050 AL=AL+1:IF AL>MX THEN AL=0
1060 IF DL=-1 THEN DL=0
1070 RETURN

2000 REM
2001 REM DELETE OLD STRING
2002 REM
2010 PRINT ,"DELETING";DL
2020 A$(DL)=""
2030 DL=DL+1:IF DL>MX THEN DL=0
2040 GOSUB 5000
2050 RETURN

3000 REM
3001 REM GET FREE STRING SPACE
3002 REM
3010 Z=(PEEK(&H23)*256+PEEK(&H24))-(PEEK(&H21)*256+PEEK(&H22))
3020 RETURN

5000 REM
5001 REM PAUSE
5002 REM
5010 PRINT"[PAUSE]";
5020 IF INKEY$="" THEN 5020
5030 PRINT STRING$(7,8);:RETURN

The program allocates enough string space to hold 100 strings of 255 bytes each. It then starts adding line after line until it detects string memory is getting low. When that happens, the oldest line is deleted (set to “”). The process continues…

The “gut feeling” was that this program should have been able to hold 100 full sized strings, but since it did use a temporary A$ (created to be 255 strings line, and the string we would be adding to the array), it seemed logical that it would have to start purging lines maybe a few entries before the end.

But instead, it starts deleting lines at around entry 47. And, the memory usage being printed out shows it drops by 510 byes each time instead of 255.

510 is an interesting number. That is 255 * 2. That makes it seem like each time we add a 255 byte string, we are using twice that memory.

And we are!

Strings may live again to see another day

The key to what is going on is in the main loop starting at line 30. We create a new A$ and set it to a string of 255 X’s. That string has to be stored somewhere, so it goes in to string memory. Then we do the GOSUB and add a string to the array, which copies our A$ in to the array A$(AL) entry.

When we go back to 30 for the next round, we create A$ again. The old copy of A$, in string memory, is deallocated, and a new A$ is created at the current string memory position. BASIC does not see if the old string space is large enough to be re-used. It just moves on to a new allocation of string space.

It looks like this… And note that strings fill from the end of the memory and move lower. Let’s say we have 16 bytes of reserved string memory (just to keep things fitting on this screen).

FRETOP points to where reserved string memory begins. MEMSIZ is the end of string memory. If we had done CLEAR 16, then FRETOP would be MEMSIZ-16.

STRTAB is where the next string will be added. It looks like this:

FRETOP                                     MEMSIZ
 |                                            |
[.][.][.][.][.][.][.][.][.][.][.][.][.][.][.][.]
                                              |
                                           STRTAB 

Let’s say we create a 4-byte A$=STRING(4, “X”) (“XXXX”) that we plan to add to an array. It will be stored in string memory:

FRETOP                                     MEMSIZ
 |                                            |
[.][.][.][.][.][.][.][.][.][.][.][.][X][X][X][X]
                                  |
                               STRTAB 

Later in the code, we assign that to the array, such as A$(0)=A$. Now A$(0) gets a copy of A$, and it looks like this (using lowercase ‘x’ to represent the copy of A$ that was put in A$(0)):

FRETOP                                     MEMSIZ
 |                                            |
[.][.][.][.][.][.][.][.][x][x][x][x][X][X][X][X]
                      |
                   STRTAB 

When we go back to do this again, a new A$ is created, and it gets stored next. The old string data is still there, but A$ has been updated to point to the new entry.

FRETOP                                     MEMSIZ
 |                                            |
[.][.][.][.][X][X][X][X][x][x][x][x][X][X][X][X]
          |
       STRTAB

…and so on. As you can see, the way this loop was written, it is creating a new A$ every time through, copying it to the array (a new entry for that) and so on. That is why we see 510 each time through instead of just 255.

Now, if the string was short, we could have done A$=”XXXXXXXXXXXXX”. If we did that, the string would exist in program space and not in string memory. But we wanted a 255 byte string, and you can’t type a line that long in BASIC so STRING$() was used instead, which requires putting the string in string memory.

However, since in THIS version we are just using the same 255 character A$ over and over again, let’s make one change so we don’t create it every time through the loop. Just change the GOTO 30 in line 50 to be GOTO 50:

30 SZ=RND(255):SZ=255
40 A$=STRING$(SZ,"X")
50 GOSUB 1000:GOTO 50

Now the program will create one A$, which will store at the start of string memory, and then loop over and over just making new entries in the array.

That small change will instantly change the results to be more like we might have expected. Now we get all the way to entry 94 before any string deleting happens:

And, from looking at that screen, each number is dropping by 255 bytes as we expected.

By the time it reached line 94, it saw that there were less than 1024 bytes of free string space left. 1024 would have held another four 255 byte strings, meaning actually had enough memory to have gotten to line 98 — just one line short of our max 99 before it rolls over. And that memory is where the initial 255-byte A$ is stored.

Tada! Mystery solved.

But wait! There’s more…

The reason I chose 1024 as a threshold was to allow for other temporary string use in the program. Things like LEFT$, MID$, STRING$ all make temporary strings. When you add two strings together it creates a third string that combines the first two. Be sure to check out my string theory article for more details on this — I learned quite a bit when researching it. I also learned that some things required strings that I did not expect to. Fun reads. Helps put you to sleep.

If I modify line 1020 to check for 255 bytes remaining instead of 1024, then re-run, I get this:

…and that is as perfect as it gets. Array is filled with strings 0-98, plus the temporary string, which is a total of 100 strings of 255-bytes each — and that is how much memory we set aside with CLEAR!

Now how much would you pay?

And because this program is self-aware when it comes to knowing how much string space is there, it can actually operate with much less string space. It will just delete old strings sooner.

You can change the CLEAR in line 5 to something smaller, like 2000, and it will still work. But, 2000/255 is 7, so it has room for the A$ plus six array entries. I expect it would DELETE every 6 lines. Let’s try…

Bingo! After lines 0-5 (six lines) it deleted and old one, then since everything was now full, it had to delete every time it added something new.

And the point is…?

Well, let’s just say I wish I knew about this back in 1983 when I wrote my cassette-based Bulletin Board System, *ALLRAM*.

I always wanted to write version 2.0.

Until next time…

See also: part 1 and part 2.

This program demonstrates Color BASIC’s string garbage collection. As strings are manipulated, string memory used will continue to grow until BASIC decides to clean up the string space and move things around a bit.

The program creates a string array and fills each entry up with string data. Using code that checks how much string space is remaining, it will delete old strings if string memory is low.

Watching it run reveals some curious things…

The Program

On an Extended or Disk BASIC system, you will need to do a PCLEAR 1 to get enough memory to run it.

• Initialization
  • Line 5 – We CLEAR enough string space to hold 100 lines at their largest size of 255 characters. Note that when you use DIM to set an array size, it is base-0. Doing a DIM A$(99) gives you A$(0) to A$(99) — 100 elements. Thus, the CLEAR uses 100, but the DIM in the next line uses 99.
  • Line 10 – MX represents the maximum number of lines in the array.
  • Line 20 – DIM A$(MX) creates an array of 0-99 entries (100). AL is set to 0, and will be the line (array entry) we will ADD next. DL will be used to track the next line (array entry) we need to delete. DL is set to -1 for “nothing to delete yet.”
• Main Loop
  • Line 30 – SZ is set to the length of the string we want to add. It has an unused RND at the start, but then SZ is hard-coded to 255. The program was designed to test random lengths of strings, but for this demo, we will be overriding that and making every string the maximum size.
  • Line 40 – GOSUB 1000 goes to a routine that will ADD a line. Then we GOTO 30 to create a new line and do it again.
• Add New String subroutine
  • Line 1010 checks to see if the ADD line has caught up to the DELETE line. If it has, we GOSUB 2000 to handle deleting the delete line.
  • Line 1020 – GOSUB 3000 will return the amount of free string space in Z. If Z is less than 104, GOSUB 2000 is called to delete a string.
  • Line 1030 – It prints how long of a string is being added to which line, followed by the current free string space before the add.
  • Line 1040 – The string is added to the A$ array at position AL.
  • Line 1050 – AL (add line) is incremented by 1, moving it to the next line of the array. If AL is larger than the MX (max array entries), it will wrap around to entry 0.
  • Line 1070 – Returns.
• Delete Old String subroutine
  • Line 2010 – Print which line is about to be deleted (set to “”).
  • Line 2020 – The A$ entry at position DL is set to “”, releasing the string memory it was using.
  • Line 2030 – DL (delete line) is incremented by one. If DL is larger than MX (max array entries), it will wrap around to entry 0.
  • Line 2040 – GOSUB 5000 is a pause routine so we can see what just happened.
• Get Free String Space routine
  • Line 3010 – Z is calculated as the difference between the FRETOP (start of string storage) memory location and the STRTAB (start of string variables) in the reserved string area. This gives us how many bytes of unused string memory is available.
  • Line 2030 – Returns.
• Pause subroutine
  • Line 510 – Print the message “[PAUSE]” with no carriage return at the end.
  • Line 5020 – If INKEY$ returns nothing (no key pressed), keep checking.
  • Line 5030 – Prints a string of 7 CHR$(8)s (backspace character) which will erase over the “[PAUSE]” prompt.

Based on the intent, one might think that running this would fill strings up to around entry 100, and then it would start deleting the old string

But is that what it will do?

Let’s run it and find out.

5 CLEAR 100*255
10 MX=99
20 DIM A$(MX):AL=0:DL=-1
30 SZ=RND(255):SZ=255
40 A$=STRING$(SZ,"X")
50 GOSUB 1000:GOTO 30
999 END

1000 REM
1001 REM ADD NEW STRING
1002 REM
1005 IF AL=DL THEN GOSUB 2000
1006 GOSUB 3000:IF Z<1024 THEN GOSUB 2000
1010 PRINT "ADDING";LEN(A$)"BYTES AT";AL;Z
1020 A$(AL)=A$
1030 AL=AL+1:IF AL>MX THEN AL=0
1040 IF DL=-1 THEN DL=0
1050 RETURN

2000 REM
2001 REM DELETE OLD STRING
2002 REM
2010 PRINT ,"DELETING";DL
2020 A$(DL)=""
2030 DL=DL+1:IF DL>MX THEN DL=0
2035 GOSUB5000
2040 RETURN

3000 REM
3001 REM GET FREE STRING SPACE
3002 REM
3010 Z=(PEEK(&H23)*256+PEEK(&H24))-(PEEK(&H21)*256+PEEK(&H22)):RETURN

5000 REM
5001 REM PAUSE
5002 REM
5010 PRINT"[PAUSE]";
5020 IF INKEY$="" THEN 5020
5030 PRINT STRING$(7,8);:RETURN

Running the Program

After a PCLEAR 1 and RUN, the program starts filling lines and we can see string memory going down. When it gets to line 47, there is only 1275 bytes of string space left.

And if we check those values, the difference between each one isn’t the 255 we might have expected. We clearly added a new 255 byte string, but memory went from 7905 to 7395 (510 bytes less) and continued down to 1785 to 1275 (510 bytes less). It appears each time we add a 255 byte string, it takes 510 bytes of string memory.

As we get to line 47, we must have had less than 1024 bytes of string memory left and the DELETE LINE subroutine is called. It deletes the oldest line, which is currently line 0. That should free up 255 bytes of string memory.

After pressing a key, we see the next few entries:

After deleting 0, memory has gone from 1275 to 756 (5120 bytes), so DELETE is called again. This time it deletes line 1.

We press a key and let it scroll a bit more until the next DELETE:

Here we see that, at some point, some string cleanup was done and our free string space grew larger. The trend of reducing by 510 bytes for each ned 255 byte string added continues…

And the process repeats, until eventually we roll over at line 99.

From here on, things get a bit more predictable, with a DELETE happening almost every line — though sometimes every two lines.

Eventually things settle in to a pattern of basically DELETING for every line ADDED.

Is it broken? Is it just poorly implemented? Or is it behaving exactly like it is supposed to?

Tune in next time for the exciting conclusion…