April 6th, 2009


Assembly Language for the Applesoft Programmer

Years and years ago, I learned to program on the family's Apple ][ personal computer. We had the early model which had Integer BASIC in firmware, but we also had floppies that would allow one to boot to Applesoft BASIC. The big difference between the two, at least to my young mind, was that Integer BASIC's random number generator returned a random integer, where Applesoft BASIC returned a floating point number between 0 and 1.

For a kid wanting to make a Dungeons & Dragons automatic die-roller, the random integers were slightly more convenient.

Having extracted much of what I could from BASIC, I itched to push the machine harder, and I found a book (at the Pacific Science Center's gift shop, if I recall correctly) titled "Assembly Language for the Applesoft Programmer". I begged Dad to buy me this book - the cover price reads $16.95, which doesn't seem like a lot right now, but it probably was something that Dad wanted to be sure I'd use. He sternly asked me if I would actually work through the book, entering the programs in it. I promised I would.

At the end of chapter 1, the authors warn the reader that really, if you want to write Assembly Language for the Apple, you need to buy an assembler. I was crushed, as it seemed like the options available went for $100 or so, which might just as well have been a zillion dollars, it was so far beyond my youthful budget. With regret, I set aside the book - perhaps I flipped through some of the later chapters, but I certainly didn't get as much out of the book as I might have.

A few years afterwards, Dad introduced me to Pascal and Forth, which each managed to tap into some of the power of the machine that I wanted to utilize. Not long after that, I went off to college and bought an IBM 286 and a C compiler, and have had little call for Assembly Language, much less assembling to the 6502 instruction set of the Apple ][.

I spent some time this weekend sorting through my library, and dusted off the lightly used copy of "Assembly Language for the Applesoft Programmer", and out of nostalgia, perhaps out of guilt, I decided to take another run at working my way through the book. There are many reasons to believe this isn't as important a project today as it would have been 25 years ago - the hardware's a footnote in history, and I seem to be able to make a living without this skill.

And yet, that kid at the Science Center made a promise, and Dad might not even remember it, but I do.

Over the weekend, I looked around for good emulators, and found a number of projects in various states of abandonment, but A2 Oasis seemed to be the best option. I also found disk images for the S-C Assembler, which is the one that the book recommends. I'd almost go so far as to call this an Integrated Development Environment (IDE), as it has an editor as well as the assembler, all in one piece. That's not so very strange, as the Apple ][ didn't have multitasking at the operating system level until later - and not really very good at that, if I recall.

I've worked my way through most of the example programs in chapters 1 and 2 using the cumbersome line-editor on the emulated 40-column screen. It's a little like camping - I'm doing without much of the tools that make me comfortable, and I'm getting the job done.

I'm not abandoning modern niceties out of sheer self-torture; I'd probably use a more modern text editor (well, Emacs) if I could find a good way to save text files onto the emulated disk in the appropriate format. I think I've turned up a few tools that might help me in that regard, but for the time being, the retro experience is good enough.

So far, I've transcribed a program that reads characters from the text screen frame buffer and writes them out right-to-left as a simple palindrome tool. I've transcribed a program that reads the paddle (remember when game design consisted of Pong?) and uses that to control the pitch of tones played by the speaker. Along the way, I've found a few bugs in the code. In particular, the palindrome program needs to add the following:

1145          DEY        DEC LINE1 INDEX

otherwise, the last letter of the input line gets printed out a bunch of times to the output, and the program doesn't terminate as intended. (It does terminate, but only after writing out 255 characters' worth of garbage.)

This isn't the only bug in their source code, and I cut them a bit of slack - it wasn't until years later that it became common practice (indeed, practical) to verify that the code in one's book actually compiled / assembled / ran.

And so I wonder how frustrated I'd have become as a youth with programs that almost worked - would I have been able to figure out the problems and solve them for myself? Would I have taken that as a challenge, or would I have become frustrated and walked away from it?

Next up: Section II: Fundamentals of 6502 Programming. Chapter 3: The Architecture and the Instruction Set.