Episode 14: Wrapping it up

Since we were taking about experiences lately, it's time to wrap the project up and talk about the experience of programming the Atari VCS. — In short, it was great! Programming the VCS is fun and extremely rewarding! This may be due to the fact of having to deal with just minor problems, coding details of a few instructions, which become blown up large and macroscopic: programming in closeup, computing under the macro lens.

Wrapping up the VCS experience.

Maybe, programming the early instruction kit computers has been similar to this, but here it's all about visual stuff. Reward is instant, problems show instantly, may be observed in realtime. I never though of using or even needing any development tools like a debugger. (Although there is one integrated in the Stella emulator. But I'm just not the type for debugging tools. Most of the time, I'm quicker by just staring at the code than I would be firing up a debugger. — “Men who stare at lines of code”, soon in a theater near you.)

I also enjoyed coding in 6502 assembler much more than I did with last year's project for the PET 2001. It may be due to increasing experience, but it may be also due to the very machine itself. Because, whatever you think you knew about the VCS is wrong. Even, if you read up on it and thought, you would know what it is all about, you don't. You have to try it. It's an experience.

Mind that the VCS is probably the fastest 8-bit computer of its time. It runs at 1.18 MHz, about 120% the clock speed of the Commodore PET, the Apple II, or your beloved Commodore 64. It's faster than Atari's own 8-bit computers! Then, consider that all RAM and all device addresses are in the zero-page. Compare this with your C64, where all devices are in the high addresses and there are only 2 bytes of zero-page RAM, which are not dedicated to the operating system. If you do without Basic, there are about another 30 "safe", recommended addresses to use, normally occupied by various system buffers. Compared to this, 128 bytes of zero-page RAM are actually ample. I hadn't to ask for more, while most of the operations were sped up by a CPU cycle. (Which is, in terms of simple load and store instructions, another 30%.) The Atari VCS is by the far the fastest computer of the Holy 1977 Trinity — and it isn't even part of it!

(Yes, I do know a computer from a handsaw, when the wind is southerly. — Sorry.)

Still, the VCS is awe-inspiring slow, in relation to its very purpose, namely, keeping up with the raster beam of a CRT display. The latter one is an intimidating beast. However, this is, where the fun kicks in. It's all about small, well defined problems, code, which may or may not be run in a single raster scan line (worth 72 of the precious CPU cycles), about being there at the right time, knowing the layout of your memory by heart. It's this reduction of computing problems to the very principles combined with instant visual feedback, which makes for the fun part of VCS-programming. And, of course, you have to do it in assembler. Even, if you spent an hour in despair, maybe even for just a simple, tiny little typo, like a missing "#" (indicating an immediate operand as opposed to an address), the moment, the code simply works, is extremely rewarding. But only, if your have fallen into one of the traps, there are, before. Because, if all works of the box, it's just blant and boring.

However, programming the VCS doesn't feel like “riding the bare metal” either: Since the CPU is under the cooperative control of the TIA and any outside notions of its workings and accomplishments are channeled through the TIA exclusively, the Television Interface Adaptor feels a bit like an operating system in hardware. Similarly, all those writes (passing parameters) and strobes (void) feel a bit like system calls. The TIA is your friend. It may be a rather taciturn one, since it never returns anything on your “calls”, but he is your only friend anyway. This is, why you, the programmer are a vital part of the loop. Your code can't manage, what it has no chance to know. You are required, in person, as the interpreter of what is provided at the visual side of the feedback loop.

Personally, I didn't have a similarly rewarding experience, since putting up the first all-images in-browser game, back when changing images per JavaScript was new with Netscape Navigator 3.0, back in 1996. (Apparently, I'm becoming old enough for telling war stories.) Actually, trying to implement an arcady game in the slow browser engines of 1996 was not unsimilar to this. You had to come up with novel approaches, or, at least, approaches that were novel to you. There was a frontier, and there is still one to explore on the VCS. Programming isn't about discipline and engineering, it's about thinking outside the box, about finding hidden structures which enable you to do, what may not be done. And this is what the VCS is all about.

(If bored from writing yet another page of GitHub import definitions to import some libraries, you never were interested enough in to have a look inside them, to be used in a stack of frameworks and imports, you are intimitated by and actually not interested in, the VCS may bring back the fun.)

And, the best of it, this won't be a never ending side-project that is not to be finished. Thanks to the constraints and the limited resources of the VCS, there is no way you couldn't be done in a reasonable amount of time.

Give it a try!

*****

Postscript

We mentioned Pitfall! (David Crane for Activision, 1982) several times in these write-ups, both tongue in cheek as well as a serious reference, and it may be worth doing so a last time here again. Pitfall! is without doubt amongst the best known and praised Atari 2600 games, there are, and it may be well the most iconic of them all. What's interesting in context is that the game is to an astonishing extent self-referential: Jumping from crocodile mouth to crocodile mouth just at the right time is much like dealing with multiple instances of a sprite on the same scan line (compare the 6 digits scores), jumping over the logs is probably not that far from dealing with extra cycles, caused by the crossing of page boundaries, rippling through your display code in runtime, the detours to the underworld are much like a branch in the kernel, and attaching yourself to the liana for the great swing is maybe the ultimate metaphor for what has become known as "racing the beam". (According to David Crane the basic game design came into being by him jotting on piece of paper, starting from a basic idea, a sprite on a path, and what, according to his experience as a programer, could be done on the VCS. So it really shouldn't take much wonder that the resulting design reflects to a certain degree how this could and eventually would be done.) Moral of the story, if you played Pitfall!, you already know some about advanced Atari 2600 programming, you just didn't notice. And, well, there's always a pit for us to fall in, but this is part of the fun.

*****

That's all for now, see you next time, stay tuned …

What's coming next: Assorted VCS ressources, we encountered in the course of this project.

◀ Previous:   Episode 13: Sound (II) — Doing it

▲ Back to the index.

— This series is part of Retrochallenge 2018/04. —