Some time in the month of September 2020 I dug out the old Commodore 64 that my Dad bought for himself in 1983. It quickly migrated its way into my room and stayed there until 1993 when I joined the Navy. Someone in my family, probably Mom, carefully packed it back into its original box and put it into storage. Despite its many years of use/ abuse by a messy teenager, it's in surprisingly good condition, 38 years later. (You're old.) Back then, I had attempted some programming on it, but I had the patience and focus of your typical suburban kid. Over the years I've thought about the many hours I spent on that machine (remember when computers lasted more than a single year?) and as a seasoned developer I began looking at the computer and seeing more potential than I was able to realize as a kid.
Modern software is very powerful. Unfortunately, if you program with it long enough, it stops feeling "real." It's like learning to fly on Microsoft Flight Simulator, versus taking private pilot lessons to actually control and fly a real aircraft. My experience with flying actual planes prepared me to recognize the distinction that afternoon in September when I pulled out my old machine. I had the idea that if I could get closer to the bites, I could become a better programmer.
And if that didn't work, I could at least have fun with it. (nostalgia is a hell of a drug.)
My assembly journey started just a few months ago. It's fresh in my mind so I hope sharing some of the things I've learned can be useful to others. There isn't really a central place to get started doing something like this. Finding resources that were helpful and relevant wasn't easy. I had owned a copy of the programmer's reference guide in the 80's, but don't remember ever opening the thing. In fact, I ended up buying two "new" physical copies on Ebay.
The first step was to figure out what I was going to start development on. I was peripherally aware that there are assemblers that you could run on the Commodore itself. When I started, I had no idea how to do that, and assumed that I would have to do cross-assembly, as there are several modern assemblers actively being maintained. I started compiling a list of things that would work for me. Here are some options:
- Vice with the built in monitor
- Forever64 (Vice on Windows with a nice virtual keyboard)
- Real vintage hardware. This is my personal choice and I'm fortunate to have a REAL 64C, a 128, and the C64 Bread-bin from my childhood bedroom.
- "The64" from RetroGames. This also gets heavy rotation as a development machine. The video output is near perfect and because it's not 40 years old I don't let the back of my mind worry about wearing out a vintage machine if I leave it powered on all day.
Machine Code Monitor: My preference is Super Snapshot. This works great on any of the emulated platforms including "The C64" and can be loaded on an EasyFlash, Kung Fu, or Ultimate II on "real" Commodores. If you find a real vintage Super Snapshot cartridge, let me know. I want it.
I've found having a C64 near me all the time (even an emulator on my MacBook) to be helpful. As the great Earl Nightingale said, you tend to become what you think about. Keeping a powered on, Blue on Blue screen allows me to noodle quite a bit during conference calls and such.
I have also been writing "scripts" and visuals that I would normally do in Python on the Commodore in BASIC. This further reinforces the "always thinking about it" idea.
There are no shortcuts
The older I get, the more I realize that shortcuts are generally a bad idea. This is especially important when you're doing something like 6502/10 Assembly programming.
Let's be honest, it's hard, but that's part of the appeal. Why would you want to shortcut something you're doing that's hard on purpose?
Learning machine code and the basics of Assembly up front is like learning musical scales when you sit down at a piano for the first time- it's tedious. And also important. I can't say enough good things about Jim Butterfield's Machine Language book. I'm fortunate to have found a paper copy, but it's available online. Spending the time to go through this fairly short book (the second HALF of it is appendices) is well worth your time.
This book is the basics, and you can not skip the basics. Get it.
I've purchased the full set of courses from 64bites.com. This is VERY thorough, but I have two things to point out about it that have kept me from using it, despite the several hundred dollars I spent to acquire it.
I have a hard time with cross assembly. It's a layer of abstraction and the real reason I'm doing Commodore 64 Assembly is to be close to the hardware. Coding on my MacBook and then running on an emulator just doesn't do it for me. I'm ABSOLUTELY NOT looking down my nose at anyone who does this. You do you, Boo. Seriously. I recognize that the way I am doing it is much harder. This is for fun, so whatever you find fun and/ or useful is what you should do.
Enter Robin Harbron
At some point in 2020, I stumbled on the work of Robin Harbron at @8BitShowandTell. I watched every one of his videos. And then I watched them again. Robin introduced me to Turbo Macro Pro, and if it wasn't for his videos, I probably would have given up and found something else to obsess over for the winter.
Robin takes being in love with the Commodore 64 to a new level. (and that really can't be over-stated.) He's written games and even songs about it. His explanations and code walkthroughs are worth watching several times.
Decide to make something
I've been a software developer for many years. Whenever learning a new system or language, I've always been the most successful when I think of something I want to use a particular tool to make. For me, it should be slightly difficult, but not so involved that I wont be able to finish it in a month or two.
I decided to make a program to implement One Time Pad encryption. This was both an exercise in learning One Time Pads and Assembly at the same time. Was it easy? Not even a little.
For comparison's sake, I did a version in Python first. It look me about an hour and came in at just over 100 lines of code.
My Assembly language version took a couple of hours every evening for all of October and November and clocks in at about 1100 lines of code, most of which is probably inefficient and poorly implemented.
But it works. And I'm considerably more proud of it than I am of the Python version I wrote on a lunch break.
The only software I really need is Turbo Macro Pro because I had settled on doing hardware development on vintage hardware. (This is also Robin's preference.) In addition, I use a machine code monitor built into the Super Snapshot cartridge. I've written a Cheat Sheet for both Turbo Macro Pro and the Super Snapshot functionality I use most.
There are MANY great books that are out of print, but available on Archive.org for free. My must have books are:
- Programmer's Reference Guide
- Programming the Commodore 64
- Mapping the C64
- Complete Commodore Inner Space Anthology
- Machine Language for the Commodore 64
The web can be hit or miss on some things, but DuckDuckGo is your friend. Some sites I have bookmarked are:
Just Keep Swimming
It's January 2021 and I'm at work on a new project. I've been building an airplane for a couple years now and I've got this idea to put a Commodore in it somewhere. I don't have the heart to cannibalize a vintage Commodore, so I'll be using the C64 Mini and a joystick so that passengers can play a themed game of my design that features the plane we'll be flying in. (It distracts them long enough to stop the screaming. See? I do have a strategy here.)
Get out there and start playing around. Despite being around for 40 years, there are still countless new frontiers on the Commodore, or anywhere, for that matter.
I'd love to hear about your journey.