In early 1984 (or possibly late 1983), my parents enrolled me in a programming course at Keyin Technical College, figuring it'd be something I'd enjoy. It turned out that they were right! It was a short (8-week?) course for children where we learned how to do some simple BASIC programming on Commodore PET machines. I excelled at it and yearned for more, so once that course was over I borrowed a Commodore VIC-20 from a neighbour for a couple of weeks. I excitedly delved into writing a program much larger and more complex than anything I was able to accomplish in the confines of the course. However, it didn't take me long to hit the memory limitations of the VIC-20. I ran out of memory before being able to complete even my first program. Shortly after that, my parents decided to buy a Commodore 64 (from Zellers, I believe), complete with tape drive, Commodore 1702 monitor, and Commodore Computer desk. And a few months after that, on Christmas 1984, we completed the computer system with a Commodore 1541 disk drive and a Commodore 1526 printer. This was ostensibly the family computer, but I was the one whose fingers were glued to its keyboard. And its arrival ushered in a new era of my life. I developed a passion for exploring the capabilities of the Commodore 64, and spent many hours a week on it. What follows is a summary of just a few of the many things I fondly remember doing on or with the Commodore 64.
One of my earliest hobbies on the Commodore 64 was typing in computer programs from magazines. We were subscribed to a few computer magazines, with "Run", "Compute's Gazette" and "Transactor" standing out the most in my memory. Each of these monthly magazines often had one or more computer program listings that could be typed in and run. These programs (some in Commodore BASIC V2.0, and some in hex-encoded machine-language bytes) often spanned multiple pages, and of course one had to be careful when typing them in, because one wrong character could cause the whole program to go awry. Because of this, the magazines usually supplied simple proofreader programs that could be run first and would provide checksum numbers for each line that was typed. These checksum numbers could be compared against those that were printed next to the listing so that typing errors could be detected. I spent many hours typing in programs this way. When I first got the computer it was a very slow process because I had to arduously hunt for every key on the keyboard. But I eventually got faster as my fingers learned where to go. Typing in computer programs this way, especially the BASIC ones, also taught me some early programming techniques and gave me some ideas for things I could try myself.
Occasionally I'd find things going missing from the top of my dresser in my bedroom. And of course I blamed my sister, whether or not she was actually the culprit. One day I decided I had enough of it, and built a security system using my Commodore 64. On the door frame of my bedroom I placed a piece of metal (probably a pop tab or a piece of aluminum foil), and on the door itself I placed another piece of metal, such that the two made contact when the door was closed. From each of those pieces of metal I ran a thin wire (from an old pair of earphones) to the phone jack in my bedroom. I had to get the signal downstairs to the computer somehow. We had phone service, but only one of the two pairs of phone wires running through our house was in use (because we only had one phone line), so the other pair was sitting dormant. I tapped into that spare pair. Then, I tapped into the same pair of wires in the phone jack in the basement next to the computer. I had long since figured out how Commodore 64 joysticks sent their signals to the computer, so I cut the connector off of an old no-longer-needed joystick and soldered one of the wires to pin 6 ("fire") and the other to pin 8 ("ground"). I then plugged that connector into joystick port 2. Then I wrote a computer program that monitored bit 4 of memory address 56320. As long as the value of that bit was 1, it meant my door was closed. But the moment it flipped to 0, it meant my door was opened. So my program monitored this bit many times a second, and the moment it saw a 1 it played a loud alarm sound and recorded the intrusion to a file on disk. Furthermore, if I programmed in a phone number, it would call that number with the modem. The idea was that I could be at one of my friends' places, and if they got a phone call with a screeching modem at the other end, then I would have caught my sister red-handed!
To pull this off, I had to tackle another technical challenge. The modem we had at the time (a 300-baud Taihaho TH-002 modem) was capable of picking up and hanging up the phone (given the right instructions to its serial channel), but not capable of dialing. But I knew that pulse dialing on a telephone system was nothing more than hanging up and picking up quickly in the appropriate sequence. So I experimented with the timing, etc., and soon implemented my own pulse auto-dialer.
I never really used this security system more than a handful of times, and I don't think I ever caught my sister sneaking into my room with it. But the system worked, and I was proud of it!
Our first printer was a Commodore 1526 (a.k.a. MPS-802) dot matrix printer. We chose it over the more-common MPS-801 printer because it had higher-quality text output (complete with true descenders) and it printed faster. However, its Achilles' heel was that it was unable to print graphics. While pouring over the user manual for it, however, I discovered that there was one ASCII character whose 8x8 glyph could be redefined once per line. I also discovered that you could arbitrarily control the line advancement after a carriage return. Notably, it could be set to advance exactly one character height (without any gaps), or even to no advancement at all (i.e., a carriage return without a line feed). I excitedly realized that this opened up the possibility of eking out full graphics-printing capability! I could break up my desired graphic into an array of 8x8 glyphs and print one glyph at a time. After every glyph I could perform a carriage return without a line feed, set up the next glyph, advance the print head to where it needs to be printed, and print it. Then, at the end of the 8-pixel-high row I could perform a carriage return with a single-character line feed and do the whole thing over for the next row. It was physically a very awkward process and took forever, but it worked!
As proof of concept, I wrote a program that printed Christmas labels. On the left side of each label I was able to print a graphic image of Christmas bells that was 48x48 pixels (i.e., 36 separate glyphs) in size, and to the right of that I printed "To:" and "From:" in standard text. We had awesome home-printed Christmas labels that year.
A couple of years later we got an Epson FX-80 printer, connected through a Xetec Super Graphix interface. That was a much more capable printer, so such a hack was rendered unnecessary.
This one is more something Dad did, but I still enjoyed being a part of it. The first word processor that Dad and I used on the Commodore 64 was called Script 64 (by Richvale Telecommunications). Even in the early days, we knew the value in making backup copies of software in case a disk goes bad or missing. Script 64 presented an extra challenge in this regard because it required a physical dongle to be plugged into joystick port 1 in order to run. Since we legally purchased the software, we had the dongle, but we only had one of them. What if we lost that? Dad saw this as a fun challenge. He took out his multimeter and went to work figuring out the electrical characteristics of the dongle. He discovered that it was quite simple and could be reproduced with little more than a couple of resistors. He had no problem getting those resistors, but of course we needed a joystick-port plug to wire up with them. We looked around, but the cheapest we could get them for was about $10 - not an economical solution. But then one day we were walking through K-Mart (or possibly Zellers), and found a whole stack of Atari 2600 Star Raiders cartridges that were on a clearance sale for $1.99 each. Star Raiders was an interesting game in that it required a 12-button keypad to use. And since typically no Atari 2600 owner had this keypad (because it never caught on as an input device outside of this game), the game came bundled with a keypad. And at the end of that keypad is the joystick-port plug that we needed! So we bought half a dozen of them, clipped the joystick-port plugs off of the ends of the keypads and threw everything else out. Dad wired them all up as backup dongles, and they worked like a charm!
In an effort to help my younger sister with her math, and also for the challenge of it, I wrote a BASIC game called Math Mania. It had a fancy splash screen (complete with horizontally-scrolling credits), and offered you the choice of operation (addition, subtraction, multiplication or division) and difficulty level (easy, medium or hard). It then took you through 20 math problems, giving you six seconds to answer each one. The faster you provided the correct answer, the more points you got. There were even some simple sound effects. It also kept track of the high score (for as long as the program was running), encouraging you to keep playing to improve on your score.
I'm not sure how much my sister actually used this program; it probably wasn't a lot. But I had fun writing it!
My friend Marcus Rahmel also had a Commodore 64, and while he wasn't nearly as into programming as I was, he had a flair for creativity. So together we developed the Pomakarahmel Adventure series of games ("Pomakarahmel" being a portmanteau of our last names). The first game we developed was called "Fiduciary: Back To The Future II", a simple choose-your-own adventure style game where you jumped around in time a bit and usually died after the first jump or two. He wrote the storyline and I coded it. The second game in the series was called "Escape From Alcatraz: First Blood Part 3". I coded a super-fancy intro to the game, and Marc said that this time he was actually writing the game code himself. But eventually it became obvious that he had lost whatever code (if any?) he had written, so the game itself was never completed. That didn't stop us, though, from working on the next game in the series, called "The Passage Of The Four Doors". Like the first game, it was a simple menu-driven game where you select what you want to do next. And again, Marc wrote the storyline and I coded it. I got fancy with the sound effects in this one, and included a full minute of movie-style end credits.
The fourth and final game in the Pomakarahmel Adventure series was called "The Golden Bagle" (sic). This one was a solo effort by me. As I was writing it, I perceived it to be my magnum opus. Instead of being menu-driven, it was a full-fledged text adventure game with some fairly clever text-parsing abilities. I had several rooms coded and a few more mapped out ready to code. I kept getting sidetracked adding more and more ad-hoc abilities to the text parser, and each room was separately coded, so it was a lot of work and ballooned pretty quickly. Before I knew it, the code had grown so large that I was risking running out of BASIC RAM. (In hindsight, my coding of this game was atrocious. But this was before I had any formal education in software development, so I forgive myself.) In the end, I never got around to completing the game. I was entering my first year of university which started stealing away my free time. The annoying part is that I think the last thing I was doing was hunting down a bug involving eating a sandwich in the game. That bug still probably exists, and there's no way I'd be able to understand the code well enough to fix it now.
I wasn't the only one programming on our Commodore 64. Dad took up the challenge as well. Despite his programming skills being weaker than mine, the programming projects he took on were larger and more serious than the majority of mine. My approach was mostly just random experimental programming sometimes evolving into something cool, fun or useful, whereas his approach was to envision an end product and then build it piece by piece, learning along the way.
One of Dad's hobbies was being an amateur magician, so his first big project was to write a software program called "Max The Mindreader" which performed a magic trick for any unwitting guest he sat in front of the computer. I think he got the idea (and general outline of how it worked) from a magic magazine. Not content to write it in BASIC (which he probably could have done because it wasn't a computationally intensive program), he rose to the challenge of writing it in assembly language using the PAL assembler. He knew very little about programming in assembly, so he read a few articles in "Transactor" magazine to get himself started. He also learned a lot from me, occasionally asking me how to do such-and-such, and I was happy to provide him with mini programming lessons. But he did all of the coding himself. The only other thing I provided was the loading screen graphics (which I was quite proud of). Dad started the product from the ground up with marketing and selling it in mind. He even devised a rudimentary copy-protection mechanism to thwart piracy. In the end, I don't think he really sold any copies though, except perhaps to a friend or two.
Another one of Dad's hobbies was watching "Wheel Of Fortune", which he did religiously. So his second big project was to write a "Wheel Of Fortune" game, also in assembly language. Every time he watched it on TV he wrote down each puzzle that was played, so he ended up amassing hundreds of puzzles from the actual game show, which he organized into auxiliary data disks that the game could read (in addition to the puzzles that were bundled with the game disk). I provided the loading screen graphics for this program as well. Like "Max The Mindreader", he had envisioned marketing and selling the game. As such, he made sure to obfuscate the data files so they weren't easily readable. And as a ruthless copy-protection measure, he had the game silently wipe the disk if the write-protect notch wasn't covered. He was hoping to sell it to a games company like Electronic Arts, but somebody beat him to it.
Most people who had a Commodore 64 in the 1980s had it to play games. Its capabilities were well beyond those of the other home videogame systems of its time (most notably the Atari 2600, ColecoVision and Intellivision). As such, there was an extensive collection of videogames available for it, with more games hitting the market every week. With the exception of a few piddly games typed in from magazines, etc., most games were sold commercially, usually for $20-$60 per game. But with the great power of the Commodore 64 came the ability to easily make pirated copies of most software. The videogame industry kept implementing more and more sophisticated copy-protection measures, but the piracy industry was always hot on its tail introducing countermeasures, usually just weeks later.
Most copy-protection measures consisted of placing specific types of errors on the game disk that regular copy programs would be unable to duplicate. When a game loads, it checks for this error and only runs if the error is present. Given this, there were two main ways to pirate games (or any software really) on the Commodore 64. The first was to copy the game disk using a piece of software called a "nibbler", which would not only copy the contents of the disk verbatim to another disk, but would also detect these specific types of errors and reproduce them on the destination disk. The second was to "crack" the game by adjusting it to bypass the error-checking code, allowing it to then be copied by any old copier. The people who did this (the "crackers") often added their own splash screen to the game to advertise themselves.
Most people who collected games for the Commodore 64 had an assortment of nibblers ("Ultrabyte", "Fast Hack'em", "Kracker Jax", "Maverick" and "Renegade", to name just a few), allowing them to copy just about anything as long as the nibbler was of a recent-enough version. But the preference was for cracked software, because it could be copied more easily and because it allowed for multiple games to be stored on one disk.
This was all so easy to do that pirating was the main way people got software for the Commodore 64. It's a wonder the software industry (especially the videogame industry) survived through that.
I was one of the multitudes who happily engaged in such piracy. A few of our earlier games (e.g., "Jumpman Junior" on cartridge, "Falcon Patrol" on cassette tape and "Flight Simulator II" on disk) and utilities (e.g., the "Script 64" and "Paperback Writer" word processors, the "Pal 64" assembler and ironically the "Ultrabyte" disk nibbler) were legitimately purchased, but the vast majority of what we owned was pirated.
In most cases I got this pirated software from friends (who got it from their friends), and then passed it on to other friends in due time. It was a common activity to have a friend come over with their newly-acquired games, or for me to go over to their place with my newly-acquired games, and then spend an hour or so copying the new loot onto a fresh batch of floppy disks.
I was a bit more of a stickler for quality control than most of my friends were when it came to my games collection. Sometimes games would get copied around without even checking whether or not they work, and then when it's discovered that a game doesn't work, it's often left on the disk anyways as dead software taking up useless space. I took care to ensure that my collection was cleaner than that. After getting a new haul of loot from a friend, I'd take a second pass through it, meticulously making sure it all worked and deleting the things that didn't. I'd also rearrange the games to fit more efficiently on the disks, etc.
One issue that arose as this collection became larger and larger was the physical storage space necessary. Each floppy disk could only hold a maximum of 164KB (measured as 664 "blocks") of data, so I could usually only fit between one and six games per disk (with some larger games spanning multiple disks). To help organize my disks and help carry them around, I had a few disk storage/carrying cases, each of which could hold either 50 or 100 disks. I also made extensive use of a well-known secret: the disks were all rated to be single-sided and the Commodore 1541 disk drive only utilized that one side of the disk, but the second side of the disk was technically capable of holding data as well. All it took was a disk notcher (or even a paper hole puncher would do) to notch out a write-protect tab on the other side of the disk, and the disk could be put into the drive upside down. Voila - double the capacity! Disks used in this way were often called "flippies", but I don't think I used that terminology at the time.
Then there was the problem of keeping track of it all. I tackled this problem in three different ways. First, I labelled each and every disk in my collection with the same type of label (that I got in packs of 50 from Grand & Toy). I'd draw a vertical line in the middle of the label, and print (always uppercase in blue ink) the contents of side A on the left and side B on the right. This consistency made it very easy to quickly flip through a set of disks.
Second, whenever a disk had more than one game on it, I always made sure that the first item on the disk was a program called "MENU". This was a small BASIC program that I wrote that simply presents a menu of the games that are on the disk and then loads the selected game. This also effectively solved another problem. Not every program for the Commodore 64 is loaded and run the same way. My menu was hand-crafted per disk to load and run each game the appropriate way.
Third, to keep track of my entire collection, I wrote a program called "GAMES MANAGER", which I had readily available as the first program on a utility disk. It stored the name, disk and side (A or B) of each game in an auxiliary data file, and allowed me to list the games and their locations to either the screen or the printer, allowing me to specify a pattern so that, e.g., I could list the only games that start with "SUPER". It also allowed me to add and remove games to and from the database. And it could pick a random game for me. (As an interesting side note, I was proud of myself for cleverly coming up with two different ways of sorting the list of games during the development of this program. It was only years later in university that I learned that I had "invented" bubble sort and insertion sort.)
The Commodore 1541 disk drive was notoriously slow, and left to its own devices (no pun intended) would often take more than a minute or two to load a game. To address this issue, we, like many other Commodore 64 owners, got an Epyx Fastload cartridge. This did some magic to allow the average program to load about five times faster. It also provided a few handy keyboard shortcuts. For example, pressing the C= and Run/Stop keys together would automatically load and run the first program on the disk. This worked really well with my disks, whose first program was usually a menu (or the games manager itself). We later upgraded to a Super Snapshot cartridge, which loaded things faster still and included all kinds of other fun goodies that I have to avoid the temptation of detailing here.
Given all of the above, I prided myself on the ability to load a game within 20 seconds of a friend naming one at random. I'd pop in the games manager disk, quickly load the games manager, type in the first couple of letters of the game to find what disk it's on, put in that disk, quickly load the menu, select the game, and bam, five seconds later it's up and running.
I had over 600 games in my collection by the time I stopped collecting them shortly after starting university.
Oh, I loved so many of the games. Here are a few of my favourites (in alphabetical order because they're so hard to rank): Archon II, Aztec Challenge, Battle Through Time, the Beach-Head series, BC's Quest For Tires, Chilly Willy, David's Midnight Magic, Dino Eggs, Flight Simulator II, Ghostbusters, Gyruss, Hacker, Hard Hat Mack, Hitchhikers Guide To the Galaxy, Impossible Mission, Jumpman Junior, Little Computer People, M.U.L.E., Miner 2049'er, Munchy, Pegasis, Pitstop II, Pogo Joe, Qix, Raid On Bungling Bay, Raid Over Moscow, River Raid, Snokie, Space Taxi, Spy Hunter, the Spy VS. Spy series, the Summer Games series, Super Pipeline, and Winter Games.
But by far the two games that I got the most enjoyment out of were "Exodus: Ultima III" and "Quest Of The Avatar: Ultima IV", both by Origin Systems. I spent the majority of the summer of 1985 playing the former and the majority of the summer of 1986 playing the latter. I filled several notebooks with notes, spells and dungeon maps, etc. It took me several months to reach the end of each of these games and claim victory. I became intimately familiar with the various musical scores of these games, and can still recall them all clearly to this day.
A game that I'll give an honourable mention to is Strip Poker, not because I spent a lot of time playing it, but because it was one of the games I had fun hacking. My impatient 16-year-old self looked through the source code and figured out how to adjust it to get the game to bypass the intermediate graphics and jump right to showing the fully-naked girls. It's funny that I remember exactly what to do to this very day: go to line 6070 and change the "1" to a "5".
No discussion of home computer systems in the 1980s would be complete without a description of the BBS (bulletin board system) scene. Starting in late 1985, I joined several local bulletin board systems. Some catered specifically to Commodore 64 users (offering colour text, etc.), while others welcomed users of all computer types (including the TRS-80 and the Apple II, etc.).
The first BBS that I became an active user of was Noparity (709-753-0196). This BBS ran on a Commodore 64 and was implemented from scratch by a guy named Joseph Dawson who was also the sysop (system operator). It was optimized for a 40-column screen and was only capable of 300 baud, but that was okay, because that was all I could do anyways.
A couple of years later, Joseph and a few others replaced Noparity with an all new BBS called BitStop. It was implemented from scratch again, this time on an Amiga 2000 computer. Being more modern, BitStop was optimized for an 80-column screen (but still worked well with 40 columns) and could operate at speeds of up to 2400 baud.
At about this time we upgraded our modem to a Commodore 1670 modem, which was capable of 1200 baud. While this obviously improved my BBSing, it took a while to get used to. 300 baud was just the right speed for reading, so there was never any need to pause or page output. But 1200 baud was way too fast to read, so I had to learn a new paradigm of interaction.
To interact with a BBS, you had to run a piece of software called a terminal program. There were many terminal programs available for the Commodore 64, but for the first couple of years I often used one that I implemented myself called KEITH-TERM. It had two terminal modes, one that used Commodore ASCII (PETSCII) for use with the colourful Commodore-specific BBSs, and one that converted between standard ASCII and Commodore ASCII for generic BBSs. It could also auto-dial (even with my 300 baud modem which wasn't natively capable of auto-dialing). Being written in BASIC, though, it could only operate in 40-column mode and could barely manage 300 baud. Later I switched to using an awesome terminal program called VIP XL. The thing I liked the most about that terminal program was that it had a good 80-column mode (which it managed by rendering surprisingly-readable 4x8 characters in hi-res-graphics mode). The main thing I didn't like about it was that it took a long time to load. But I solved that problem by using my Super Snapshot cartridge to create a single-file snapshotted version of the program with my preferred settings already selected, etc., and then using a program called Vorpal to save it to disk in such a way that it could be loaded 25 times faster. In conjunction with the keyboard shortcuts provided by my Super Snapshot cartridge, I could have it up and running in mere seconds. I called this custom version of VIP XL "SuperVIP".
But I digress. Back to the BBSs. Another BBS that I frequented was called The Amateur BBS (TABBS). TABBS was a modified version of some off-the-shelf BBS software, maintained and sysoped by a guy named Doug Cuff. I think it ran on an Apple II computer.
A BBS that deserves an honourable mention was the PCUG BBS. It was the official BBS of the Pleasantville Commodore Users Group (more on that later), and while I didn't use it nearly as often as the BBSs mentioned above, it was fun to occasionally dial into because it made use of Commodore ASCII and therefore was in colour. Plus, since I was an active member of PCUG, I took my turn hosting the BBS and being its sysop.
After I moved from Newfoundland to Nova Scotia after graduating from high school, I sought out the BBS community there and stumbled across the Happyface Inc. (902-835-6976) BBS, running a version of the Ivory BBS on a Commodore 64 and sysoped by a guy named Blain Checkley (aka "Microfuse"). I eventually became a co-sysop of this BBS (as "Moondog").
All of the BBSs that I mentioned were single-call only, meaning only one person could be connected to it at any one time. They all had between 40 and 90 users, and allowed the users to communicate with each other via private e-mail and public newsgroups. They also all had a download area where users could share programs, music and graphics, etc., although some were more strict about not allowing copyrighted material than others. Many of them offered a few online-playable games, both solo and interactive with other players. But the biggest thing that all of these BBSs offered was a sense of community. I still keep in touch with many of my fellow BBSers from these systems to this day, almost 40 years later.
Throughout high school and my first year of university, I completed most of my essay assignments on the Commodore 64 using the FontMaster II word processor. I also joined the school newspaper staff in grades 11 and 12 and again used FontMaster II to assemble, lay out and print the school newspaper. (For a lot of this work I used the Commodore 128 computers, in Commodore 64 mode of course, that were available in the school's computer lab.) In addition, I was in Junior Achievement (forming a company called "Plex-Tiles"), where I continued to offer my FontMaster II word processing skills by being the editor of the shareholders' report.
When I was still in grade 12, a friend of mine, John Palfrey, was going to MUN (Memorial University Of Newfoundland), and he gave me his login credentials for the university Unix system there, garfield.mun.edu, so that I could read the rec.arts.startrek newsgroup. I quickly learned that there was so much more to Unix and this new communications network called the "internet" than just newgroups. But my gateway to it all was dialing into it from my trusty Commodore 64 using VIP XL. Once I got my own Unix account on ug.cs.dal.ca at Dalhousie University, I was old hat at it.
Dad and I joined the Pleasantville Commodore Users Group (PCUG) sometime circa early 1985. It was a computer club that was primarily for Commodore computer owners (which was mostly Commodore 64 owners, but the Commodore 128 and Amiga became more popular as the years progressed). It was called such because the meetings were in an area of St. John's called Pleasantville. We met once a week on (I think) Tuesday evenings. It was a great way to meet like-minded people with a shared passion for all things Commodore. It was here that I met many people who I maintained friendships with for many years, including John Palfrey, John Russell and Sean Huxter. Sometimes we'd lug our equipment to the meeting so that we'd have some hardware to use when we wanted to show something off. I was a regular participant in the activities of the club. I was the club librarian for a few months (meaning I was in charge of holding and lending out the club's small collection of software disks), and was also the sysop of the PCUG BBS for a while.
While Dad was learning assembly language in order to write "Max The Mindreader" and "Wheel Of Fortune", he wanted to share the learning experience with others, so he wrote a series of thirteen weekly(?) articles for the PCUG newsletter entitled "Understanding ML".
The largest project undertaken by PCUG, and one that I was proud to be a part of, was a weekly TV show in 1987 called "Computer Connection" which aired on a local television station called Avalon Cablevision (Channel 9). We worked with producer/director Bart Fraize, but otherwise did all of the work ourselves, including preparing the foam backdrop artwork. We even did all of our own camerawork. I took my turn as cameraman for two or three of the episodes. One of the club members prepared an awesome opening sequence for the show using clips from various Amiga demos. I was on camera for two segments. In one segment I gave a review of a Commodore 64 drawing program called Doodle with my friend Craig Stacey, and in another segment I gave a review of an Amiga game called Marble Madness with my friend Ed Reddy. I believe we filmed seven episodes (consisting of two or three segments each). However, only six of them aired. The unaired episode included an awesome segment of Dad introducing assembly-language programming (or was it demoing a word processor? I can't quite remember). It was a shame too, because Dad did an awesome job with it; he was a natural in front of the camera.
Although I had my Commodore 64 system set up and was using it as late as 1997, I saw the writing on the wall. I knew that one day I would no longer have a working system. But I didn't want to lose everything when that day came. Emulation of the Commodore 64, through software emulators such as VICE, was starting to prove itself as a way of keeping the magic going past the life of the hardware. These emulators loaded Commodore 64 software through 1541 disk images called "D64" images. A D64 image is simply a raw linear dump of every track and sector of a 1541 disk, all 174,848 bytes of it. So in the spring of 1997 I set out to make D64 images of my most important disks. I found instructions on the internet for how to make the appropriate cable, so I collected the cable and ends that I needed, and soldered it all together. I also found some MS-DOS software that someone wrote that would do the transfer from a 1541 disk drive to a PC through this cable. So I went out and bought an old PC. The next challenge was that the software was very sensitive to the speed of the system. Through trial and error I discovered that it would only work if I had the "turbo" button on the PC turned off so that the machine would run at the 4.77Mhz clock speed of the original PC. Fortunately the PC I bought had this button.
At the time I was doing these transfers, I had no access to any emulators. (I merely knew of their existence.) So the only test I could do to verify that the disk images were being captured cleanly was to do two transfers of each disk and do a full binary comparison between them. To my frustration, most of the time the transfers differed, but usually only by a couple of bytes here and there. My solution to that was to do *three* transfers of each disk, and to write a program which did a three-way binary diff between them and construct a hopefully-correct image by keeping, for each byte, the values that agreed and tossing the inconsistent value. Doing this I managed to make D64 images of 358 of my disks. I decided to only grab images of 66 of my games disks, for two reasons: 1) most of the games beyond these didn't mean that much to me; they were mostly collected just to grow my collection, and 2) many of my games disks beyond these had copy protection on them, and my D64 transfer mechanism couldn't handle those disks. But I most certainly copied most of my favourite games and utilities, as well as all of my programming projects (well, the ones that managed to survive my initially haphazard organization of them), essays and artwork, etc.
I then decided that it would be nice if I could access the contents of these disk images. So I used my knowledge of the way the contents of 1541 disks are structured and wrote a C program that could list the directory of a D64 disk image in a way similar to how LOAD "$",8 : LIST shows it on a real Commodore 64. That same program could also be given a filename, and it would extract the contents of that file.
That allowed me to access any file, but most files were useless without being decoded in some way. Translating simple text files from Commodore ASCII (PETSCII) to standard ASCII was pretty straightforward, but BASIC program listings were more of a challenge because of the way Commodore 64 tokenizes its BASIC programs, etc. Still, with the aid of the Commodore 64 Programmer's Reference Guide, I was able to write a C program to decode and list Commodore 64 BASIC programs without too much difficulty.
My final challenge in this respect was to be able to extract and view the many Commodore 64 graphics that I had saved on many of these disks. The graphics I'm referring to are full-screen (320x200) images using a palette of the 16 colours available on the Commodore 64. I created many of these graphics myself (despite my very limited skills as an artist), and also have a few created by friends, as well as a bunch of more-professional stock graphics that I collected over the years. But such graphics are not simply any-colour-can-go-anywhere images. Due to the limitations of the VIC chip, these graphics had to be in one of two modes: hi-res (such as what could be created and output by software such as "Doodle") or multicolour (such as what could be created and output by software such as "KoalaPainter"). Each mode came with its own set of restrictions as to how the pixels and colours could be laid out, and they each had their own quirky organization of these pixels and colours when serialized in a graphics file. Fortunately, I was well acquainted will all of this, and so was able to write a C program that could read and convert both hi-res and multicolour graphics to SUN Raster file format (a simple graphics format that was popular on Unix machines in 1997, and that could later be easily converted again to GIF or PNG format). Part of the challenge was coming up with a colour palette to use. Through trial and error, I painstakingly determined the set of 16 RGB values that I thought most closely resembled that of the Commodore 64 colour palette. Of course even with a perfect conversion, these graphics don't look quite right on a modern display because the aspect ratio of a pixel on a Commodore 64 is 3:4 while the aspect ratio of a pixel on modern displays is 1:1.
After I did all of my transfers and conversions, my Commodore 64 system was essentially retired and put into storage. For a while I had a pipe dream that maybe someday when I had kids, I could pass the system onto them and have them experience the magic the same way I did as a kid. But as the years went on I eventually came to terms with the reality that the next generation would have very little interest in such an antiquated computer. Eventually I decided that it would be better to sell the system to someone with a genuine interest in it rather than having it sit in a closet and eventually die of old age. So in the spring of 2009 I sold my entire system (minus the disks with my own personal data on it) to an enthusiastic university student for $90. It was very hard to let it go, but at least I was comforted by the fact that it would likely get some more use.
A few years later, for whatever reason, my interest in programming on the Commodore 64 was rekindled, and I somewhat regretted selling my system. Buying a new fully-working system didn't seem like a reasonable thing to do (especially since working Commodore 64 systems were becoming quite rare). But as luck would have it, in 2020 a company called Retro Games Ltd. released an emulator console called "TheC64" that matches the look and feel of a real Commodore 64. I placed an order for it the moment it was available, and it didn't disappoint! It doesn't have an actual Commodore 1541 disk drive of course, but emulates one by reading D64 images from a USB flash drive. And it doesn't have a Commodore 1702 monitor, but connects to a TV via an HDMI cable. I got a couple of joysticks for it, but the joysticks also connect via USB, so I had to settle for a pair of clunky joysticks that apparently are very similar to the original Commodore joysticks (rather than the Kraft joysticks that I used to own and absolutely loved). But other than these things and the fact that you can invoke a menu that provides access to a few dozen built-in games, it provides an experience that's very similar to using a real Commodore 64. I especially like the fact that it has a proper Commodore 64 keyboard (which software-only emulators painfully lack).
Using the TheC64 emulator, and making use of a cross-assembler on my Linux computer, I spent the next couple of years geeking out with a few new Commodore 64 programming projects. I focused on learning new techniques and challenging myself to achieving results that I lacked the skill set for (and that would have impressed the hell out of me) back in the 1980s. And I had a lot of fun doing it.
It's safe to say that my early experiences with the Commodore 64 sparked a passion in me that ended up defining my whole career path. I was ecstatic when I discovered that one could actually have a career in software development. Many of my computing science courses in university seemed second nature to me because I was often able to understand things by correlating them to concepts I was already familiar with on the Commodore 64. And when I got into the work force, I almost felt like I was somehow cheating because I was getting paid to do things that I actually enjoyed doing. Even now, as I'm nearing retirement, that passion hasn't faded. I suspect that I'll challenge myself with more Commodore 64 assembly language programming adventures in the coming years.
NB - To this day, I'm still using the Commodore Computer desk that my parents bought with our original Commodore 64 system in 1984, and it's still in as good a shape as ever!