Skip to main content

Double-checking Dawkins

I've been reading through Richard Dawkins' books and am currently half way through The Blind Watchmaker (2006 paperback edition) and on page 119 he writes:

In my computer's ROM, location numbers 64489, 64490 and 64491, taken together, contain a particular pattern of contents---1s and 0s which---when interpreted as instructions, result in the computer's little loudspeaker uttering a blip sound. This bit pattern is 10101101 00110000 11000000.

Of course, this piqued my curiosity. Did Dawkins just make that up, or is this really the contents of a specific bit of memory on a specific computer?

The book was first published in 1986, so I just had to figure out what it was. Starting with the instructions and converting to hex we have AD 30 C0. Now, considering the main processors around at the time there are three possible interpretations of these three bytes:

Z-80/8080 XOR L ; JR NC C0

6502: LDA C030

6809: JSR 30C0

The first didn't look at all plausible, but both the other two do. The 6809 looks like it could be calling a sub-routine at location 30C0 and the 6502 would work if C030 were actually memory-mapped I/O and a read was necessary to cause the blip.

I couldn't find any machine with a meaningful interpretation of the 30C0 location on a 6809 machine, but 6502 turned out to be a different story.

On an Apple ][ memory in the range C000-C0FF is mapped to various bits of I/O:

The memory space on the Apple II between $C000 and $CFFF was assigned to handle input and output. From $C000 to $C0FF the space was reserved for various soft-switches used to control the display, and various built-in I/O devices, such as the keyboard, paddles, annunciators, and the cassette port.

Poking around further I discovered that a read from C030 (known as SPKR) will blip the speaker on an Apple ][. So Dawkins is telling the truth and he's using an Apple ][.

So returning to the memory locations what program is he talking about? The three memory locations are FBE9, FBEA and FBEB. That turns out to be inside the Monitor ROM on an Apple ][ (the stuff that Woz wrote) and happily a complete ROM listing was provided with the Apple ][.

So looking in a scanned Apple ][ manual we find that those locations are inside the BELL2 routine. Specifically on page 163 of the manual we find the following:

FBE6: 20 A8 FC 598 JSR WAIT 1 KHZ FOR .1 SEC
FBE9: AD 30 C0 599 LDA SPKR
FBEC: 88 600 DEY
FBEF: 60 602 RTS2B RTS

The line in bold is exactly the code that Dawkins is referrring to.

So, while writing this famous text on evolution, Dawkins had time to poke around inside the Apple ][ ROM and write about it in his book.



Eli Bendersky said…
Nice post. Kudos on your research into this subject.
: Joseph j7uy5 said…
That's a nice bit of detective work. BTW I seem to recall that the NEC V20 also was in use around then...just a bit of trivia, your analysis is entirely correct.
Ben said…
Amazing. Bravo !

BTW: I knew it. R. Dawkins is a God.
Unknown said…
Big deal. Back in '86, if you were writing anything for Apple, Commodore, Atari, Trash 80...take your pick, the only way you could really do anything was to know what happened at every memory address. And since you were only working on 64K (or try the VIC-20 with about 3.5K usable RAM), you really didn't have to know that a whole lot. Don't get me wrong, I loved working on all of them, but it didn't take a Dawkins to get the speaker to chirp on any of them. Sorry.
Unknown said…
Sorry, but back in '86, if you were writing anything for Apple, Commodore, Atari, Trash 80...take your pick, the only way you could really do anything was to know what happened at every memory address. And since you were only working on 64K (or try the VIC-20 with about 3.5K usable RAM), you really didn't have to know that a whole lot. Don't get me wrong, I loved working on all of them, but it didn't take a Dawkins to get the speaker to chirp. It was just a way of life back then.
Tristram said…
Back in the early '80s I bought a Sharp MZ-80B microcomputer which came with a listing of its whole operating system in a little booklet. As phil says, this sort of detailed knowledge was common back then.
WWWWolf said…
Okay, one could say that Dawkins is wrong: The three bytes they refer to don't "cause" a "blip", they change memory contents which is a *part* of the blip-sounding process. But that's just technical hair-splitting. =)

Hmm, seems that Apple was a weird system if you have to *read* memory (LDA) to make things happen - on C64 you, like, *write* to memory (STA) to make stuff happen.
Unknown said…
Dude are you sure he represented it from the MSB and not as a bit sequence sent out of the low order bits first (B5 0C 03)?

Hell of an analysis regardless
Unknown said…
Please disregard the above, it doesn't get more certain than finding it addresses the speaker port. Very very nice
John Smith said…
now i know i'm old. i used to program my apple ][e in assembler. 6502 assembly language is one of the easier ones to learn, and this was true for me even as a geeky grade-schooler.

how did i get into it? my older sister had just moved to cupertino to work for apple, and one of the first gifts she gave me was my apple ][e.

and yes, she was also the one who showed me the section of the dawkins book when it came out in 86. i thought it was pretty cool at that time that he was also into assembly programming, but then my sister reminded me that it was really easy to use the PEEK and POKE instructions in basic to manipulate memory contents, so he may not have been as cool as all that.

it took me a few more years to read dawkins on my own. thanks for the memories.
Ray said…
god didn't make little green apples or pc's
Mad Respect.
Anonymous said…
If Dawkins went to this much trouble on a totally trivial point, it seems reasonable that he could be creditable on other points, too.

Obviously, the man does his homework.
Unknown said…
Bottom Line: never doubt Dawkins.

Even if he had invented that stuff, the main point remains valid.

Now, on the other hand, what would have Richard written if the book's title were the "The Blind Assembler Language Coder" instead?

Popular posts from this blog

Your last name contains invalid characters

My last name is "Graham-Cumming". But here's a typical form response when I enter it:

Does the web site have any idea how rude it is to claim that my last name contains invalid characters? Clearly not. What they actually meant is: our web site will not accept that hyphen in your last name. But do they say that? No, of course not. They decide to shove in my face the claim that there's something wrong with my name.

There's nothing wrong with my name, just as there's nothing wrong with someone whose first name is Jean-Marie, or someone whose last name is O'Reilly.

What is wrong is that way this is being handled. If the system can't cope with non-letters and spaces it needs to say that. How about the following error message:

Our system is unable to process last names that contain non-letters, please replace them with spaces.

Don't blame me for having a last name that your system doesn't like, whose fault is that? Saying "Your last name …

All the symmetrical watch faces (and code to generate them)

If you ever look at pictures of clocks and watches in advertising they are set to roughly 10:10 which is meant to be the most attractive (smiling!) position for the hands. They are actually set to 10:09.14 if the hands are truly symmetrical. CC BY 2.0image by Shinji
I wanted to know what all the possible symmetrical watch faces are and so I wrote some code using Processing. Here's the output (there's one watch face missing, 00:00 or 12:00, because it's very boring):

The key to writing this is to figure out the relationship between the hour and minute hands when the watch face is symmetrical. In an hour the minute hand moves through 360° and the hour hand moves through 30° (12 hours are shown on the watch face and 360/12 = 30).
The core loop inside the program is this:   for (int h = 0; h <= 12; h++) {
    float m = (360-30*float(h))*2/13;
    int s = round(60*(m-floor(m)));
    int col = h%6;
    int row = floor(h/6);
    draw_clock((r+f)*(2*col+1), (r+f)*(row*2+1), r, h, floor(m…

Importing an existing SSL key/certificate pair into a Java keystore

I'm writing this blog post in case anyone else has to Google that. In Java 6 keytool has been improved so that it now becomes possible to import an existing key and certificate (say one you generated outside of the Java world) into a keystore.

You need: Java 6 and openssl.

1. Suppose you have a certificate and key in PEM format. The key is named host.key and the certificate host.crt.

2. The first step is to convert them into a single PKCS12 file using the command: openssl pkcs12 -export -in host.crt -inkey host.key > host.p12. You will be asked for various passwords (the password to access the key (if set) and then the password for the PKCS12 file being created).

3. Then import the PKCS12 file into a keystore using the command: keytool -importkeystore -srckeystore host.p12 -destkeystore host.jks -srcstoretype pkcs12. You now have a keystore named host.jks containing the certificate/key you need.

For the sake of completeness here's the output of a full session I performe…