My experience using BASIC is something I cannot easily put into words. I had never been exposed to programming before, so at first I had a hard time understanding the concept. I started out slowly, playing around with some simple commands which were described in various issues of ANTIC magazine.

Actually, my first experiments were much simpler, consisting of just a single command being given to the interpreter. I loved being able to control the color of my background or make a bunch of erratic and tuneless beeping sounds through our television speaker. For the first time, I was in control of the machine, even if all the machine did was squeak and change colors. I didn’t learn about how the interpreter used line numbers until my father picked up a copy of Atari BASIC by Albrecht, Finkel, and Brown. It was during my sessions with this book that I also learned about control flow statements, looping, data types, and loads of new commands. It still took me a while before I learned how to save my creations to disk, but it was too late to go back by then. The bait had already been taken, and it wasn’t long before my parent’s saw what was happening: I was hooked and I was going to need funding for my new hobby.

For the most part, I learned most of my Atari BASIC programming skills through my father’s subscription to ANTIC. This magazine was devoted to the Atari 400/800 series of computers which were popular in the early to mid-1980s. Another popular magazine at the time was A.N.A.L.O.G., but I didn’t have access to as many of them as I would have liked. I enjoyed the latter because it had much more diverse and complex programming examples and articles. When I got my hands on our first copy, I wasn’t even pausing to read most of the articles, I just brought it straight to the computer and began entering the source code in by hand. Sometimes the process took hours and my code was often marred by spelling mistakes and missing commands. I eventually learned these mistakes were called bugs by people in the software world. Tracing through these programs taught me a lot about programming and debugging. Mostly, it taught me to be careful while typing, and began to practice my typing skills using another software program designed for this purpose. To this day, however, I am mostly a 3:4 finger typist; three being the typical number of fingers I use for my left hand, and four being the perfect number for my right.

My father eventually purchased a dot-matrix printer for the system. It was a Star NX-1000 II, and I absolutely adored this printer. I quickly learned how to use it in BASIC and began printing reams upon reams of code. I enjoyed debugging and enhancing my programs using the printed form. It was an excellent way to get a handle on the whole problem, since the environment in the interpreter prevented you from seeing the whole picture easily. The font was just too large and the software did not have the ability to manually scroll the view. In fact, the concept of a window wouldn’t be realized on desktop computers until a few years later. In order to examine a block of code, you needed to continually LIST the sections in chunks or just dump the whole thing at once and wait for the area you were interested in to come into view. The continuously scrolling source code was slow enough you could track it with your eyes, and once you saw the region of code you wanted, pressing the break key would stop the process.

Another great feature of the Atari’s BASIC language was the ability to examine and modify specific bytes in memory. At the time, I don’t think I fully understood the concept of a memory address, at least not the way I understand it now. It was more abstract for me than other concepts. I knew that writing certain integer values into locations identified by other integer values allowed me to play music and control the colors of fonts and backgrounds, but I didn’t associate these number values to a physical address in the machine. In fact, I’m not sure I even truly understood what memory did, other than the typical high-level rationalization: if you buy more RAM it will allow your computer to play this game or use that piece of hardware. I generally understood memory to be a good thing. The more you had, the better off you were.

It wasn’t until I started programming the Commodore 64 (C64) with a friend of mine that I began to understand its function and organization. A big part of that understanding came from a device called the Super Snapshot cartridge which could plug into a port on the Commodore computer. This miraculous device had a number of cool features, and one of those features allowed the user to interrupt a game (or whatever) and examine/modify the contents of RAM and then return as if nothing had happened. Initially, we used this device to cheat on games by changing the number of lives, strength, loot, whatever. All we needed to do was isolate the byte responsible for tracking these attributes in memory, modify the contents of the variable at that address, and voila! We were invincible, we could crush any opponent, or we could buy any item. Life was good. I believe the manual for the Super Snapshot explained a number of details about memory and how it was organized. This served as a great stepping stone for my next foray into the world of Atari memory.

The next big advance for me came after reading the book: Mapping the Atari by Ian Chadwick. It explained what all of those numbers meant and how they were used by the Atari. I was enthralled and began to experiment with earnest. Incidently, the commands I was using to read and write values to and from memory were called PEEK and POKE respectively. Loads of fun can be had with these commands and that great little book. As it turns out, this book became even more useful while dabbling with assembly language years later on the Atari.

Categories: Atari 8-bit, Programming, Reflections, Retro
1 Comment »