42 Astounding Scripts

Why? Where do these results come from?

On the Facebook CoCo group, someone recently asked about how I handled bit-checking in a question I asked on the Retrocomputing StackExchange about the joystick. They didn’t phrase it as a question about bits because they didn’t know that their question was about bits.

It’s not surprising. I don’t know about other computers, but Radio Shack tended to hide the bitwise nature of their 8-bit computers. The only BASIC functions that worked with bits were the logical operators AND, OR, and NOT¹, and they weren’t explained as bitwise. The first two are given a page in Getting Started with Extended Color BASIC, page 78, where they’re explained as if they’re the English words AND and OR.²

But these operators do not behave as the English words do, or as the explanation implies they do. Here’s an example. Go into your CoCo or an emulator such as Xroar, and type:

The first should give you 1 and the second should give you 7. In most modern programming languages, both would give you true, which, depending on the language, might be a boolean value or it might be the integer 1. It might even be one of the two values, the 3 or the 5, because of short-circuit evaluation.

How does Extended Color BASIC arrive by its return values? The answer is that AND and OR are bitwise operations. These are 8-bit computers. They describe their numbers in 8 bits³. Here are the bits for the numbers 3 and 5:

The logical operators do not compare bytes. They compare individual bits at matching bit locations. What AND does is, if the bit in the same location in each byte is 1, the bit in the resulting byte is 1. If either of the two bits are zero, the bit in the result for that location is zero. What OR does is return 1 if either of the bits are 1, and zero only if both bits are zero. So here’s what AND and OR do when comparing 3 and 5:

At the end of my post on the first version of cocobin, I wrote:

It’s also likely that some binaries were provided as decimal instead of hexadecimal numbers.

And only a few weeks later, here I am. I found a really nice Galaxian/Space Invaders-style game by Rodger Smith in the February 1985 Hot CoCo.¹

He used decimal numbers for his DATA statements, so I added that feature to cocobin. If a file or BASIC program contains decimal rather than hexadecimal numbers, add the option --decimal to the cocobin command line.

Also as expected, adding this feature also highlighted another common custom of the era: the DATA items often included a marker to denote the end of the data. Most commonly, as I recall, this was the word “END”, or (for machine code) a negative 1. Smith used the number 999. So I’ve added the ability to recognize “END”, “999”, or “-1” at the end of a line of DATA in a BASIC program. If the program sees any of those key words at the end of a DATA line, it assumes that that is the end of the data to be read.

Either of those keywords not at the end of a DATA line will still be seen as an error, since none of them represent valid POKEable numbers.

The script now accepts the following arguments:

Also, while this is not a change, I did finally verify that the script works when used with multiple files. Charles Husak’s “The Little Runner” from the March 1984 Rainbow uses three BASIC programs to POKE the binary into memory. This command line worked to create a working binary from those three files:

Interesting little game!

In my continuing quest to make it easier to successfully type programs from books and magazines, I had the great idea of having my Macintosh read the code out loud, freeing me to look solely at the original text while verifying the code. This is useful not just for finding errors that rcheck+ says must exist but also errors in code that doesn’t have checksums such as the one- and two-liners in The Rainbow.

The readBASIC script (Zip file, 3.6 KB) is especially useful for the 1984 run of The Rainbow, which uses an rcheck that simply adds up memory used instead of performing a rudimentary checksum, and Hot CoCo, which has no validation at all unless you count the 32-character lines. I recently acquired several issues of Hot CoCo and I pretty much run readBASIC on all of the programs I type in from that magazine. Whether an error shows up on testing the program or not, I almost certainly mistyped something on any program of any reasonable length. Those bugs are likely to trigger when I least need them.

It turns out I’m not the only person to think of having the computer read code back to you. In the October 1987 issue of The Rainbow, there’s an article by Bob Roberts that does the same thing. Of course, his is more complicated since it has to fit in memory around the BASIC program it’s reading. It doesn’t read the files (although, technically, there’s no reason it couldn’t) but rather reads the actual BASIC program from RAM. Nor is it a machine language program invoked with a special keystroke, like the rcheck+ program. Instead, it’s literally a BASIC program running above the real BASIC program, starting at line number 60000.

Of course, a BASIC program on an eighties computer required special hardware to generate speech. Roberts’s required Radio Shack’s Speech/Sound cartridge. Modern computers have speech built in. You can play around with it on the Macintosh command line using the say command. I go over this command in more detail—how to use the voices of various languages and accents—in the Diversion About History section of 42 Astoundingly Useful Scripts and Automations for the Macintosh.

My first attempt at having the iMac read BASIC code out loud was simply to send each line of BASIC to the say command. Given the lack of spaces in most old-school code, you won’t be surprised to learn that this did not work well.

A quick note that I’ve just got the update of Safari from 14.0.2 to 14.0.3, and Quick Actions that replace text inside of Safari text fields are now working again.

I’ve removed the “Copy to Clipboard” workaround (so that I no longer erase text previously copied to the clipboard) from the three scripts that I use most often in Safari, and am having no problem editing and modifying text inside of text fields.

I was getting worried that this was a permanent change, and am very happy that it turned out to really be a bug and not deliberate. It’s more than a little disappointing that the bug didn’t get caught before it went out—as both a programmer and a writer, I find Services in Safari text fields extraordinarily useful. I use it often enough that I noticed it within a few hours of performing the update. In fact, I’m using it right now. When I’m done writing this short note, I’ll run my Markdown to Blog HTML service on the text to convert simplified Markdown to the simplified HTML I use for posting.

I don’t use all of my Services scripts on a daily basis, but I do use at least one of them every day.

This is with Safari on Catalina 10.15.7. I should be updating to Big Sur soon, for varying definitions of “soon”, but would expect (or hope) that it’s either also been fixed or was never a problem on Big Sur.