42 Astounding Scripts

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 programs 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.

asciiArt Viola.jpg --palette "BDAGECF " --save viola.png --bgcolor 1,1,1,0

A lot of choosing your palette for ASCII art is an art, because the distribution of pixels in each character matters as much as the number of them. Even resolution can matter: a densely packed character such as an asterisk might look darker than a sparsely packed character such as a thick letter O if there are only a few characters per row, but instead have the same effect if there are thousands of characters per row.

But a script can get you started. I wrote densitySort to help me put together the palettes I used in 42 Astounding Scripts^•.

The script is fairly simple. It creates an image of each character, calculates the darkness of the image, and then saves that darkness in an array.

Then, it sorts the array by darkness descending and prints out the sorted palette.

At its most basic, you can give it a palette and it will sort the palette using the Monaco font, because that’s the font I use in Terminal.

Say you want to use all of the letters that make up a musical scale in an ASCII image:

You can now use that palette to create, say, an ASCII art image of a guitar (or of a viola, as in the top image on this post):

Because some characters have special meanings on the command line, you’ll often need to surround the palette with apostrophes:

You can change the font using the --font option.

If you leave off the palette, it will provide the entire normal ASCII art character set for the font:

Those are all characters from ASCII character 33 (the exclamation) through 126 (the tilde).