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

How to write a successful blog post

First, a quick clarification of 'successful'. In this instance, I mean a blog post that receives a large number of page views. For my, little blog the most successful post ever got almost 57,000 page views. Not a lot by some other standards, but I was pretty happy about it. Looking at the top 10 blog posts (by page views) on my site, I've tried to distill some wisdom about what made them successful. Your blog posting mileage may vary. 1. Avoid using the passive voice The Microsoft Word grammar checker has probably been telling you this for years, but the passive voice excludes the people involved in your blog post. And that includes you, the author, and the reader. By using personal pronouns like I, you and we, you will include the reader in your blog post. When I first started this blog I avoid using "I" because I thought I was being narcissistic. But we all like to read about other people, people help anchor a story in reality. Without people your bl

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

The Elevator Button Problem

User interface design is hard. It's hard because people perceive apparently simple things very differently. For example, take a look at this interface to an elevator: From flickr Now imagine the following situation. You are on the third floor of this building and you wish to go to the tenth. The elevator is on the fifth floor and there's an indicator that tells you where it is. Which button do you press? Most people probably say: "press up" since they want to go up. Not long ago I watched someone do the opposite and questioned them about their behavior. They said: "well the elevator is on the fifth floor and I am on the third, so I want it to come down to me". Much can be learnt about the design of user interfaces by considering this, apparently, simple interface. If you think about the elevator button problem you'll find that something so simple has hidden depths. How do people learn about elevator calling? What's the right amount of