On the CoCo mailing list, Ciaran (author of the Xroar emulator), said this:

FWIW this is the bodge I have saved out for doing PCLEAR0 without such
ROM patching:

POKE183,PEEK(183)-6:POKE188,PEEK(188)-6:PCLEAR1:POKE183,PEEK(183)+6:POKE188,PEEK(188)+6

Annoyingly verbose, but should account for DOS, and works on the
Dragon too.

..ciaran

– https://pairlist5.pair.net/mailman/listinfo/coco

This topic came up because of Juan Castro‘s experiments with updating HDB-DOS to add new functionality on a CoCo 1 and 2 (but that is a discussion for a dedicated blog post sometime). Juan had recently “fixed” Extended Color BASIC to allow using “PCLEAR 0” to remove all graphics memory and give more RAM to BASIC. I have discussed PCLEAR 0 in the past…

This mysterious line performs a PCLEAR 0 without needing to load and run program of assembly code!

POKE183,PEEK(183)-6:POKE188,PEEK(188)-6:PCLEAR1:POKE183,PEEK(183)+6:POKE188,PEEK(188)+6

And it works!

But … how does it work!?!

Ciaran, you’ve got some ‘splainin’ to do…

Until then…

Us humans (this is not an A.I. post, bleep bloop) have a tendency to try to find patterns in randomness. For example, when asked to pick a number between 1 and 10, a magician/mentalist will know that statistically humans are more likely to choose certain numbers. There is alot of “human nature” that makes us somewhat predictable.

In a deck of 52 playing cards, if you were asked to predict what card is on the top of a shuffled deck, you probably wouldn’t say Ace of Diamonds, but that card is just as likely to be there as any other. No matter which card you guess, you have a 1 in 52 chance of being correct.

Call it in the air…

When it comes to a coin toss, do you always call heads? Always tails? Or do you alternate?

When a gambling casino game presents a grid of squares and asks you to pick four squares, do you “randomly” pick various squares, or do you just click the first four on the top row?

If it is random, either should have the same outcome.

And don’t get me started on picking lottery numbers. While we do not often see the picked numbers be “1, 2, 3, 4, 5 and 6”, that sequence should be just as likely as any other.

If it is random.

So let’s play a game in BASIC with a coin toss. Heads or tails will be represented using CoCo’s Color Basic RND() command. Doing RND(2) will produce either a 1 or 2 result.

NOTE: This is not random. This is psuedo random. I have discussed this previously, but for the sake of this blog post we will pretend it truly is random.

Would calling heads every time produce a better result than calling tails? Or would randomly choosing heads or tails each flip be better?

Let’s try…

0 'COINFLIP.BAS
5 'POKE 65495,0
10 W1=0:W2=0
20 FOR A=1 TO 1000
30 V=RND(2)
40 IF V=1 THEN W1=W1+1
50 IF V=RND(2) THEN W2=W2+1
60 NEXT
70 PRINT "ALWAYS GUESSING 1:";W1
80 PRINT "GUESSING RAND 1-2:";W2

This program will “randomly” flip a coin 1000 times and count how many times it landed on heads (1) versus how many times it matched a randomly (1-2) chosen value. At the end, it will print the results:

As you can see, in this “random” test, neither method really proved to be that different. We could also alter the output to print how many times guessing tails (2) would have worked (1000 clips minus how many times it was heads, 511 in this example, so 489 if my math is correct).

But it still feels better thinking we have some “control” over things and guessing rather than always choosing the same guess.

Alphabetically speaking…

Let’s modify the program to select a random letter, A-Z (represented by 1-26). We will now always guess A, versus randomly guess a letter (1-26):

0 'COINFLP2.BAS
5 'POKE 65495,0
10 W1=0:W2=0
20 FORA=1TO1000
30 V=RND(26)
40 IF V=1 THEN W1=W1+1
50 IF V=RND(26) THEN W2=W2+1
60 NEXT
70 PRINT"ALWAYS GUESSING 1:";W1
80 PRINT"GUESSING RND 1-26:";W2

And here is what I get…

Maybe this perspective will help you “always choose tails” or “always guess Aces of Spades” in the future.

And speaking of the future, there is another “random” test I want to experiment with, coming soon.

Until then…

See Also: Forbidden Variables and how to use them.

Updates:

• 2025-05-14 – Updating the list, and organizing by where they became forbidden.

Over on the CoCo Facebook group, in a discussion about “why is I always used for loops”, Rob R. left a comment that caught my interest:

“… I have a vague memory that (at least on the Mod I) there were one or two letters that weren’t usable since they could be tokenized to a command. At least some two letter variables would be verboten, like ‘TO.'”

– Rob R. on Facebook

This made me wonder: how many are there? Here are the ones that I think would be problematic:

Forbidden in Color BASIC and beyond

• GO – part of GO TO
• IF – as in “IF A=1”
• ON – as in “ON X GOTO/GOSUB” or on the CoCo 3, “ON BRK GOTO” or “ON ERR GOTO”
• OR – as in “IF A=1 OR A=2”
• TO – as in “FOR I=1 TO 10”

Forbidden in Extended Color BASIC and beyond

• FN – as in “DEF FNA(B)=B*42”

Forbidden in Disk Extended Color BASIC and beyond

• AS – in Disk BASIC, there is an “AS” keyword used for the file system. “FIELD #1, 10 AS A$”

Using any of these such as “TO=1” or “FN=3” will create a ?SN ERROR.

Are there others?

Also, some of these will work in Color BASIC that will not work if you have Extended or Disk BASIC:

• “DEF FN” was added in Extended, so on a Color BASIC machine you should be able to use FN as a variable.
• “AS” was added in Disk BASIC, so you should be able to use AS on Color and Extended BASIC.

I wonder how many folks wrote BASIC programs using variables that were not allowed when they later added the Extended BASIC ROM and/or Disk BASIC, and wondered why they stopped working?

Until next time…

There is something wonderful about having a poor memory. Whether I knew something before or not, I do not remember it now, so I get the pleasure of “learning something new” even if I previously knew the new thing.

In a reply to my Color BASIC and octal post, Juan Castro mentioned another quirk about how BASIC sees numbers represented as decimals versus hex or octal.

AND, OR, AND NOT demand signed 16-bit integers as input, whereas the &H/&O expressions (and consequantly my &B extension) return UNsigneded integers. That is VERY annoying:

PRINT &H8001 AND &H0007
?FC ERROR
OK

Come the %#&*£ ON!

– Juan Castro

I am unsure about this, since after the parser reads through the code, it turns any hex or octal or decimal value intothe internal 5-byte floating point representation of the value. “A=65535” turns into exactly the same type of variable as “A=&HFFFF”.

AND and OR should deal with them exactly the same way. In Juan’s example, decimal values will generate the same ?FC ERROR. But there is a workaround…

I stumbled upon this when playing around with using AND and OR to set or test bits. My Color BASIC and 16-bits and AND and OR and NOT article explains what I was trying to do, and how I ultimately ended up achieving it.

In Juan’s example, &H8001 is 32769 in decimal. &H0007 is 7. Having the “high bit” (bit 15) set of the first value effectively makes it a negative number:

1000000000000001 = &H8001 (32769)
^              ^
bit15          bit0

Any value with that bit set will not work with AND or OR, regardless if you represented it in decimal, hex or octal. You can go up to &H7FFF (32767) using AND or OR, but past that, you get the ?FC ERROR:

Juan has been working on some BASIC enhancements, adding new features (like a method of representing values in binary — which I would find quite useful). But seeing numbers in binary not work would be even more frustrating:

PRINT &B100000000000000 AND &H1
?FC ERROR

…at least, that is my assumption about what is “&B” binary representation would do.

Here is how to make Juan’s code work:

PRINT (&H8007-65536) AND &H0007
1

Any value that has that high bit set needs to have 65536 subtracted from it, then you get the results you would expect.

But unfortunately, you cannot use AND to test for that high bit to be set ;-) so instead you have to do silly things like this:

V=&H8007
IF V>&H7FFF THEN V=V-65536
PRINT V AND &H0001

And it’s just that easy!

Though, if you print V, you will see it is a negative number, as you might have guessed. If you don’t need to PRINT V, doing something as simple as this will let you AND and/or OR on values that have the high bit set.

Yuck.

“Come the %#&*£ ON!” is right.

Until next time…

And so it begins…

I want to visualize some playing card statistics, and the easiest way I could think of to do this was to write a program in BASIC. Of course.

There are many approaches I can take, so as I put figure it out I will “show my work” and experiments that help me figure out which one will work best.

For my task, I will greatly simplify a deck of cards by ignoring suits (I just care if it’s an Ace, a Five, a King or whatever). I figure I can store it as a 52-character string representing each card:

A123456789JQKA123456789JQKA123456789JQKA123456789JQK

I could “shuffle” this “deck” and end up with a string in “random” order. I believe I have touched on randomizing a list in the past, and had some great suggestions in comments on how to do it better. Forgetting all of that, let’s just say I end up with as string that gets randomized.

But I digress…

The next question will be: “How many Kings are left in the deck?”

Some of you will already see I am heading down a poor path for doing this, but let’s start there anyway.

One way of counting a specific character in a string is to loop through it and use MID$ to pull out an individual character. Something like this:

FOR A=1 TO LEN(A$)
IF MID$(A$,A,1)="S" THEN C=C+1
NEXT

That would count all the “S” characters that appear in the string. Since every time MID$ is used it has to build a new string representing that portion of the original string, this should be our slowest way to do this. On a system with tons of strings in use, string manipulation gets real slow. For such a simple program, this might be fast enough.

Another approach, which was originally shown to me during a word wrap article as a submission, would be to use VARPTR to get the memory location of the 5-byte string ID memory, and then go to the memory where the string bytes are stored and use PEEK to look for them. You can find details in my earlier article on VARTPR.

The memory location that VARPTR returns will have the length of string as the first byte (byte 0), then an empty byte (byte 1, always 0), then the next two bytes will be the address where the string is stored (bytes 2 and 3) followed by a zero (byte 4). Knowing this, something like this would do the same thing as MID$:

A=VARPTR(A$)
SL=PEEK(A)
SS=PEEK(A+2)*256+PEEK(A+3)
FOR A=SS TO SS+SL-1
IF PEEK(A)=ASC("S") THEN C=C+1
NEXT

And do it faster.

VARPTR is a legal BASIC function, but it still seems nasty to reach in to string memory to do this. Thus, I came up with the idea of using INSTR. This function returns the start location of a matching string in another string, or 0 if not found:

PRINT INSTR("ABCDEFG","D")

That should print 4, since a “D” is located at the 4th position in the string.

You can also add an additional parameter which is where in the string to start searching. Doing this:

PRINT INSTR(5,"ABCDEFG","D")

…would print 0, because it starts scanning at the 5th character (just past the D) of the string, and then won’t find anymore.

I could start using INSTR with a position of 1 (first character), and if it comes back with a value other than 0, I found one. That value will be the position of the found character. I could then loop back and use that position + 1 to scan again at the character after the match. Repeat until a 0 (no more found) is returned. That lets the scan for characters be done by the assembly code of the BASIC ROM and is even faster. It looks like this:

F=0
xxx F=INSTR(F+1,A$,T$):IF F>0 THEN C=C+1:GOTO xxx

And we put them all together in a benchmark test program…

10 ' COUNTSTR.BAS
20 A$="THIS IS A STRING I AM GOING TO USE FOR TESTING. I WANT IT TO BE VERY LONG SO IT TAKES A LONG TIME TO PARSE."
30 T$="S":T=ASC(T$)
40 '
50 ' MID$
60 '
70 PRINT "MID$:";TAB(9);
80 TIMER=0:C=0
90 FOR A=1 TO LEN(A$)
100 IF MID$(A$,A,1)=T$ THEN C=C+1
110 NEXT
120 PRINT C,TIMER

130 '
140 ' VARPTR
150 '
160 PRINT "VARPTR:";TAB(9);
170 TIMER=0:C=0
180 A=VARPTR(A$)
190 SL=PEEK(A)
200 SS=PEEK(A+2)*256+PEEK(A+3)
210 FOR A=SS TO SS+SL-1
220 IF PEEK(A)=T THEN C=C+1
230 NEXT
240 PRINT C,TIMER

250 '
260 ' INSTR
270 '
280 PRINT "INSTR:";TAB(9);
290 TIMER=0:C=0:F=0
300 F=INSTR(F+1,A$,T$):IF F>0 THEN C=C+1:GOTO 300
310 PRINT C,TIMER

And running prints:

Wow, using INSTR is six times faster than MID$? And four times faster than VARPTR. Nice.

Now you know a bit about what I need to do. I need to represent cards in a deck (and be able to “draw” cards from that deck) and calculate how many of a specific card remain in the deck.

Since I do not need to track or show the suits (hearts, spaced, clubs, diamonds), I figure I could use one byte in a string.

To be continued … but in the meantime, do you have a better approach? Comment away!