For years, software was distributed on cartridges, cassette tapes, or diskettes. While programs were available via modem from BBSes, downloading in general wasn’t as ubiquitous as it is today. As 8-bit microcomputers gained popularity, one of their big selling points, the built-in BASIC interpreter, eventually led to another avenue of software distribution: the type-in program listing.
BASIC Listing from Compute!
As a Commodore 64 user growing up, I was keenly aware of the type-in programs listed in magazines like Compute!, Compute!’s Gazette, and RUN. At first, it was my mom (who typed over 100 words per minute) who was responsible for entering the code into the computer for the games that tickled my fancy. But soon I was fumbling my way through translating the PRINTs, POKEs, and PEEKs into a complete game to be saved to disk. What I didn’t know at the time, but my mom had already figured out, was that I was learning to code without actually sitting down to learn.
One of the most obvious things that you pick up when you are transcribing a printed page to the computer is proofreading. While BASIC is known for using common words for commands, games would often have graphic elements. Entering this information either meant matching PETSCII symbols from the page to the characters printed on the side of each of the keyboard keys on the C64, or entering groups of comma-separated numbers that weren’t different enough to keep track of your position. Add to this the inevitability of “fat-fingering” any number of commands, and you were guaranteed to end up with a game that would either show glitchy graphics or would crash with a “Syntax Error”. At that point, it was time to start digging through the listing, comparing it with what I had typed, and see where I went wrong. As I became more experienced with entering listings, it became somewhat less of a hunting expedition. I started understanding what specific command sequences and routines did in these games, which made it more of a debugging session than a simple comparison exercise. The more listings I attempted, the more accurate I became. Fortunately, at least for listings in COMPUTE!’s Gazette, the magazine eventually released a proofreading tool that used a checksum at the end of each line to assist in finding typing errors. It was at this point that the next evolution of my coding began.
Let’s face it, the dream of creating your own programs on the 8-bit micros, at least for young gamers such as myself, was to make the games no one else was making, or at least the way you envisioned them. The manual that originally came with the Commodore 64 contained an in-depth explanation of BASIC programming on the computer. Still, it was up to the coders to squeeze every ounce of magic out of the machine. Once you understood the basics, well-documented listings and their accompanying articles were invaluable for piecing together your own projects. And while there were plenty of complete games that made it to the magazine’s pages, often what was published were smaller projects that showcased specific methods and ideas. One I remember was a method for displaying more than eight sprites on the C64’s screen at once, using a technique called multiplexing. Another listing was created by a programmer who lamented the lack of spinning toroids in the C64 version of Xevious, so he made a simple shooter to demonstrate that the animated effect could have been easily accomplished. Exercises like these became great jumping-off points for larger projects.
BASIC Listing for C64
Using methods I learned from other listings and some routines my mom (who became an extremely proficient C64 programmer) provided, I developed my own simple games. The concept of games as learning experiences, or edutainment, was very popular at that point in the ’80s, and that was the focus of my games. I created a pseudo-3D maze game that incorporated math and an exploration game that utilized historical facts. One thing that I never did, however, was to submit my games to the very magazines that had taught me the skills to create them. In retrospect, I should have.
One last thing that entering these program listings into the computer taught us was patience. The first programs that I attempted to enter were short, at most a column of text on the magazine page. But the more impressive games were often spread across multiple pages. These listings were daunting, to say the least. The first time I embarked on one, I thought I would never finish. With previous listings, I was able to enter and debug them in a couple of hours. But these longer ones took multiple sessions at the computer, often 2 or 3 days of typing after school to get everything in. Then the hard part began, because there was no chance that I wouldn’t make mistakes along the way. But let me tell you, when I got that game running on my Commodore 64, it was the most fantastic feeling of accomplishment imaginable. Knowing that the length of a listing was no longer an impediment for me made setting out on the next one more of a fun project and less terrifying.
I never delved into machine language programming as my mom did. My focus shifted to languages like PASCAL and COBOL. While neither was huge on the C64, they did prepare me for coding in modern object-oriented languages and for scripting in Python and PowerShell.
Of course, with the release of the new Commodore 64 Ultimate, I find myself revisiting the glory days of BASIC programming, where a couple of lines of BASIC were enough to say “Hello World!”, and you could call yourself a coder. Maybe these new retro systems will inspire the next generation of coders in the same way as they did us growing up.
The post Typing in Dreams: How a generation learned to code by accident appeared first on Old School Gamer Magazine.
