The past few weeks I have been diving into the world of assembly language programming on the Apple ][ computer. My interest in the topic stems from the recent book release of a compilation of articles on assembly language programming called Assembly Lines: The Complete Book. The articles were written by Roger Wagner and originally published in Softalk magazine back in the early eighties. This edition was edited by Chris Torrence and is available for download and purchase from a number of locations.
Now, I am pretty familiar with Applesoft Basic programming, but I was always in awe of commercially released software on the Apple ][ that ran so fast, had fancy hi-res graphics and used sounds other than the system beep. What was the secret of these mythical programs that required you to type "BRUN" in order to get them to load? The secret was machine language.
This image shows you just how intuitive and user-friendly machine code is. It's almost like it was written by the Terminator himself (just after he finished cutting out his eyeball with an Xacto knife). Despite the seeming impenetrability of machine code, in the past I made a few attempts to learn it. I would get a few chapters into Apple Machine Language and then the endless diversions into binary math would addle my art-school trained brain. It never really clicked for me.
The first hundred pages or so of Assembly Lines has been very informative and I have dutifully typed in many of the example programs. At one point I had a pretty nice "ah ha!" moment when I was messing around with creating tones. I created a small program that generated an annoying high pitch noise and decided I would further enhance the interactivity by outputting a stream of numbers to the screen showing the paddle positions. Before I got very far beyond just reading the paddles I noticed that I could use the joystick to change the pitch of the sound. I had no idea why this would change the pitch so I decided to look at the machine code in the built-in paddle routine. To my surprise, I was able to see that it got the paddle value by using a count down loop. The longer the count down, the lower the tone. I couldn't really say why this was the case, but at least I was starting to be able to decipher that wall of hex values.
Now, back in the late eighties I got my hands on an issue of Compute! magazine. Kids nowadays with their fancy iWatches and download services may not believe this, but in the olden days there would be program listings in computer magazines. Readers could carefully type in the program and, "Voila!", you had new software to use. This issue contained a listing for a game called Space Dodger, with a separate listing for just about every machine available at the time. Most were written in basic, but the one for Apple ][ was pure machine code. I had no idea what any of it meant, but I dutifully typed every line into my Apple's monitor. The result was a pretty slick little arcade game:
You moved your ship to avoid the space junk which flew by from right to left at varying speeds. However, playing the game in emulation, I noticed a slight problem: the ship movement was mapped to the wrong joystick axis.
And now we get to my second assembly language "Ah ha!" moment. I now know the memory address where the paddles are read. I just needed to search the code listing for 00 1E FB and it would just be a matter of changing the 00 to 01. I found the values at $706B, made my edit and, magically, the joystick now worked correctly!
I still have no clue as to what the other 99% of the code does, but this was a breakthrough. Assembly language... I think I can do this. In the meantime, download Space Dodger and play it in your favorite emulator.