How Things Work: Commodore 64 and Summer Games Edition

I’m always trying to convey a sense of the audacity and creativity of hackers of the early PC era, who made so much out of so little. I include amongst this group both the hardware hackers who created the machines themselves and the software hackers who took them to places even their creators never imagined. In that spirit, I thought today we’d look at how the Commodore 64’s hardware team managed to make it do some of what it could given the technical constraints under which they labored, and how the software team who created Summer Games at Epyx found ways to make it do even more than they had fully considered. So, much of this article is for the gearheads among you, or at least those of you who’d like to understand a bit more of what the gearheads are on about. If you’re a less technical sort, perhaps you’ll be consoled by learning about some of the softer factors that went into the Summer Games design as well. And if that’s not interesting, hey, you can still watch my wife and I (mostly I) fail horribly at various Summer Games events via the movie clips.

This is, by the way, my first attempt to make use of WordPress 3.6’s integrated video capabilities. You’ll need an up-to-date browser with good HTML 5 support to see the clips. Hopefully my site won’t choke on the bandwidth demands. We’ll see how we go.

While you’re waiting (hopefully not too long) for the videos to load, let’s consider the basic visual capabilities of the Commodore 64: a palette of 16 colors at a resolution of 320 X 200. Those capabilities are, to say the least, modest by modern standards, but they actually present a huge problem when paired with another key specification: the 64 has just 64 K of RAM memory. This is all there is to work with; there is no separate bank of video memory, as on a modern computer. Everything — programs, data, the contents of the screen, and miscellaneous other things like buffers for the disk drive — must draw from this pool.

Now, a modern programmer wishing to represent a 320 X 200 screen with 16 colors in memory would probably just store it as a series of pixels, with one byte devoted to each pixel and storing a value of between 0 and 15 to represent that pixel’s color. This approach, known as bitmap graphics, is straightforward and eminently flexible, but there’s a problem. Consider: a 320 X 200 screen has exactly 64,000 pixels. In other words, by devoting one byte to each pixel we’ve just filled our entire 64 K of memory with a single screen.

Let’s consider then. Even a modern programmer, if she’s a more efficient sort, might note that we only actually need four bits to store a number between 0 and 15, and could therefore, at the cost of a bit more confusing layout, pack two pixels into every byte. That reduces consumption to a little under 32 K — better, but it’s still untenable to devote half of our precious memory to the screen.

It’s because bitmap graphics are so demanding that only high-end machines like the Apple Lisa and Macintosh used them by default at the time of Summer Games‘s release. And, notably, even those 68000-powered machines only displayed black and white, which reduced the requirement from four bits per pixel to one — a simple on-off, black-or-white toggle. Let’s consider the alternative that the 64’s designers, as well as those of many other machines, employed in various ways: character graphics.

In its default mode, the 64 subdivides its screen into a grid of character cells, each 8 X 8 pixels. Thus there are 40 of them across and 25 down, corresponding to the machine’s standard text display. Elsewhere in memory are a set of up to 256 tiles that can be copied into these cells. A default set, containing the glyph for each letter, number, and mark of punctuation in addition to symbols and simple line-drawing figures, lives in ROM. The programmer can, however, swap this set out for her own set of tiles. This system is conceptually the same as the tile-graphics system which Richard Garriott used in the Ultima games, but these tiles are smaller (only the size of a single character) and monochrome, just a set of bits in which 1 represents a pixel in the foreground color, 0 a pixel in the background color. The latter color is set globally, for the whole screen. The former is specified individually for each cell, via a table stored elsewhere in memory.

So, let’s look at what all this means in terms of memory. Each cell on the screen consumes one byte, representing the number (0 to 255) of the tile that is placed there. There are 1000 character cells on a 40 X 25 display, so that’s about 1 K consumed. We need 8 bytes to store each tile as an 8 X 8 grid of on-off pixels. If we use all 256, that’s 2 K. Finally, the color table with the foreground color for each cell fills another 1 K. We’ve just reduced 32 K to 4 K, or just 2 K if we use the default set of character glyphs in ROM. Not bad. Of course, we’ve also introduced a lot of limitations. We now have to build our display, jigsaw-puzzle style, from our collection of tiles. And each cell can only use two of our total of 16 colors, one of which can be unique to that cell but the other of which must be the same for the entire screen. For someone wishing to make a colorful game, this last restriction in particular may just be too much to accept.

Enter multicolor character mode. Here, we tell the 64 that we want each tile to be not monochrome but drawn in four colors. Rather than using one bit per pixel within the tile, we now use two, which allows us to represent any number from 0 to 3. One of these colors is still set individually for each cell; the other three are set globally, for the screen as a whole. And there’s another, bigger catch: because we still only devote eight bytes to each tile, we must correspondingly reduce its resolution, and that of the screen as a whole. Each tile is now 4 X 8 (horizontally elongated) pixels, the screen as a whole 160 X 200. Even so, this is easily the most widely used mode in Commodore 64 games. It’s also the mode that Scott Nelson (little brother of Starpath co-founder Craig Nelson) chose for Summer Games‘s flag selection screen.

But… wait, you might be saying. Surely the colorful screen shown above doesn’t always use the same three of the four colors within each tile. In fact, it doesn’t, and this introduces us to one of the keys to getting the most out of the Commodore 64: raster interrupts.

The picture on a cathode-ray-tube television or monitor is generated by an electron gun which moves across and down behind the screen, firing charged electrons at phosphors that coat the back of the screen glass. This causes them to briefly glow — so briefly, in fact, that the gun must paint the screen 60 times per second for televisions using the North American NTSC standard, or 50 times for the European PAL standard, in order to display a stable image without flicker. After painting each line of the screen from left to right, the gun must move back to the left to paint the next. This split second’s delay can be exploited by the Commodore 64 programmer. She can ask the machine to generate what’s known as a raster interrupt when the gun finishes painting a given line. She then has a few microseconds to make changes to the display configuration before the gun starts painting the next line. She can, for example, change one or more of the three supposedly fixed colors, as Scott Nelson does to generate the screen shown above.

But let’s say we don’t want to deal with trying to create a picture using tiles. The Commodore 64 actually does also offer a bitmap mode of sorts, albeit one with restrictions of its own that allow it to reduce the memory footprint from an untenable 32 K to a more reasonable if still painful 9 K. Here an 8 K chunk of memory is allocated to the bitmap, with each bit representing the status (on or off) of a single pixel. The foreground color represented by an “on” pixel is once again determined by a 1 K color table, with the colors still sorted into 8 X 8 pixel blocks. This leads to the most obvious oddity of the 64’s bitmap mode: the bitmap does not run all the way across the screen and then down, but rather across and down through each 8 X 8 cell that is assigned a given foreground color.

For those willing to trade resolution for colors, there is also a multicolor bitmap mode, which, like the multicolor character mode, treats each two bits as representing a single pixel of one of four possible colors. Horizontal resolution is accordingly reduced to 160 pixels. This mode is, however, more flexible than multicolor character mode in its choice of colors. Another area of memory, of 1 K, is allocated to a collection of color pairs for each cell, each pair packed into a single byte. Thus we can freely choose three of the four colors found within each cell without resorting to raster interrupts or other tricks. Total memory devoted to the display in multicolor bitmap mode amounts to 10 K.

That may not look like much at first glance, but for a programmer trying to shoehorn a complex game into 64 K it’s quite a sacrifice indeed. For this reason, and because its other restrictions could make it almost as challenging to work with as character mode, bitmap mode is not used as often as you might expect in Commodore 64 games. Summer Games is, however, a partial exception, employing bitmap mode in quite a number of places. For instance, Stephen Landrum’s opening-ceremonies sequence uses a multicolor bitmap. This sequence also demonstrates another critical part of the 64’s display hardware: sprites.

Doing animation by changing the contents of screen memory is very taxing on a little 8-bit CPU like the 64’s 6502, not to mention tricky to time so that changes are not made in the middle of screen paints, which would result in ugly jerking and tearing effects. Sprites come to the rescue. Indeed, their presence or absence is a good indication of whether a given machine from this era is pretty good at playing graphically intense games (the 64, the Atari 8-bit lines) or not (the Apple II, the IBM PC). A sprite is a relatively small graphical element which is overlaid onto the physical screen, but independent of the bitmap or tile map stored in memory. It can be moved about quickly at minimal cost, just by changing a couple of registers. The display circuitry does the rest.

The 64 offers eight sprites to the programmer, each exactly 24 pixels wide by 21 tall. The image for each is stored in memory as the usual grid of on/off bits, for the modest total of 64 bytes used per sprite. An on bit represents the sprite’s color, of which each has exactly one; an off bit represents transparency, so that whatever is on the screen behind shows through. This means that the 24 X 21 pixel size is not so arbitrary as it may first appear; a smaller sprite can be displayed simply by turning off the unneeded pixels.

There is also the inevitable multicolor sprite, which gives us three foreground colors to work with at the expense of half of our horizontal resolution. In this mode, the sprite is effectively just 12 X 21 pixels, but each pixel is now twice as wide as before, resulting in the same physical width on the screen. As in multicolor character mode, the second and third colors are fixed across all sprites in this mode.

A sprite can be pointed to different addresses in memory for its image between screen paints, creating the possibility of making animated sprites which cycle through a sequence of frames, page-flip style. Likewise, single- and multicolor sprites can be placed together and moved in lockstep to create larger or more complex onscreen figures. In the sequence above, the runner is made from three single-color sprites, each of which cycles through 14 frames of animation. (If you’ve played Impossible Mission, he may look familiar to you: he is in fact the same sprite as your avatar in that game, which Dennis Caswell happily shared with his colleagues.) The flames are four multicolor sprites, each with four frames of animation. And each of the eight doves is a single single-color sprite of eight animation frames.

But… again, wait. That’s far more than eight sprites in total, isn’t it? As you may have guessed, Landrum uses raster interrupts to reconfigure and thus reuse sprites as each screen paint proceeds. With the addition of such tricks the 64’s effective limit becomes not eight sprites in total but no more than eight sprites horizontally parallel with one another.

Let’s take another example, this time one showing an actual, interactive event in action: Stephen Landrum’s pole vault. I have my usual mediocre performance in the clip that follows, but my wife Dorte kicks some ass and actually demolishes our old world record.

The screen you see here is another multicolor bitmap. The vaulter is made up of three single-color sprites, which cycle through seven frames of animation as he runs and are then changed appropriately to reflect his state after he goes airborne. The pole is three single-colored sprites and the crossbar is a single multicolored sprite, as is, surprisingly and cleverly, the stationary top of the nearer (right-hand) upright. To understand this last, we have to understand the 64’s concept of sprite priority. Sprites are numbered from 0 to 7. If two sprites overlap one another, the sprite with the lower number is drawn on top of the one with the higher number. Landrum uses this property to easily create the illusion of the jumper passing behind the nearer upright as he soars through the air.

You might have noticed that the pole, the crossbar, and the upright are all quite large. This is down to yet another feature of the 64’s sprite system. It’s possible to expand a sprite vertically or horizontally or both, doubling its size (but not its resolution).

The pole vault is not quite as polished as most of the events, which may be a sign that, as one of the later events completed, it was a bit rushed. There’s some odd artifacting in the pole, for instance. And there’s a wonderful bug that lets you vault under the crossbar on its highest setting, creating a world record for the ages.

The two swimming events, which were started by Randy Glover but finished by Landrum following the former’s abrupt resignation, are the most complex in Summer Games. They’re largely an exercise in rhythm; you have to press the joystick button as your swimmer’s arms enters the water, then release it when they emerge. I’m awful at it, but Dorte is pretty good.

The clock at top right is formed from six single-color sprites, each swimmer from four. The rest of what you see here may begin to illustrate how crazy you can get with raster interrupts. Each paint begins with the 64 in single-color bitmap mode. This allows the text (“Ready… Set… Go!”), which is drawn and erased directly into the bitmap, to be rendered in the higher resolution. But then, just as the electron gun reaches the top of the stands, the screen is changed to a multicolor bitmap.

Glover and Landrum use a technique known as double buffering to make the scrolling as smooth as possible. There are actually two bitmaps in memory, one of which is always being displayed and the other of which is being updated by the CPU for the next step in the scroll. When the time comes, the two are swapped, as the 64’s VIC-II graphics chip is pointed to the other in the pair. Well, it’s almost that simple. Complications arise because the poor 6502 just doesn’t have time to completely redraw a screen in memory for every pixel of scroll. Luckily, it doesn’t have to. The VIC-II also has what are known as horizontal and vertical fine-scrolling registers. They allow the programmer to shift the bitmap that appears onscreen by from 1 to 7 bits to the right (as in the swimming events) or down. Since this will create an ugly empty zone at the edges of the display for which the computer has no pixel data to display, another register lets the programmer expand the size of the border slightly to cover these cells — the width of the screen is reduced from 40 to 38 columns, or the height from 25 to 24 lines. Now it’s possible for Glover and Landrum to scroll the screen eight pixels before having to swap to the alternate bitmap, giving the CPU time to make said bitmap. Double buffering is rather unusual to find on the 64, as it’s horrendously expensive in memory. And indeed, the swimming events use virtually every last byte.

But that’s probably enough tech talk for today. Just for fun — and because if you got through all that you’ve earned it — let’s look at the other events in somewhat less exhaustive (exhausting?) detail.

The two running events have their origin in Starpath’s old Supercharger decathlon project, but were brought to the 64 and completed by Brian McGhie. Like virtually everyone at Epyx, he had no particular knowledge of or burning interest in Olympic sports. He therefore relied on a stack of old Sports Illustrateds to try to get the look of his runners and the stadium right. The events are very similar in appearance, but unlike the swimming events very different in execution. The 100 meter dash is a notorious joystick killer. You have to move the stick back and forth as quickly as possible — nothing more, nothing less. The 4 X 400 meter relay, by contrast, is the most cerebral of the events, a game of energy conservation and chicken. I’m unaccountably good at both, much to Dorte’s frustration.

Interestingly, the scrolling in these events is implemented in an entirely different way from that in the swimming, illustrating how very much Summer Games is really a collection of individual efforts brought together under one banner. McGhie uses a multicolor character screen, and rather than using double buffering updates the hidden border areas on the fly to… but I promised to stop with the tech talk, didn’t I?

The diving event is yet another of Landrum’s. The diver here rather disconcertingly never surfaces after entering the water, simply because Landrum ran out of time.

Skeet shooting was a joint project of John Leupp, Steve Mudry, and Randy Glover prior to his departure. They originally planned to show the shooter on the screen, as in all of the other events, but found it difficult to work out a practical way of implementing the event from that perspective. So skeet shooting received the only first-person perspective in Summer Games, and the poor shooter was left out entirely.

Finally, there’s the gymnastics event — really just a vault — by Mudry. In an example of the, shall we say, casual approach to box art that was so rife in this era, the Summer Games box shows someone doing a handstand.

If nothing else, this article has hopefully conveyed what a tricksy machine the Commodore 64 is, full of hidden capabilities and exploitable quirks. Learning to make it dance for you requires considerable time even if you have examples to follow. If you don’t… well, small wonder that its games were just beginning to come into their own in 1984, the year it had its second birthday. And Epyx and companies like it were barely scratching the surface. In a couple of years Summer Games would look downright quaint.

You can download the original Commodore 64 Summer Games and its manual from here if you like, for use in the emulator of your choice (I recommend VICE). Unlike most of the disk images floating around the Internet, this one is pristine, with the original set of world records, so you and your friends and/or family can make your own records — which is about 20% of the fun of playing Summer Games — rather than be shamed by the performances of obsessed teenagers from two or three decades ago.

We’ll continue to observe the Commodore 64 scene with interest in future articles. But next we’ll check in with a group of Atari 8-bit loyalists: the backwoods savants of Ozark Softscape.

(This article draws again from the Epyx retrospectives in the July 1988 and August 1989 issues of Commodore Magazine. Technical details of Summer Games were drawn from the Commodore 64 design case study which appeared in the March 1985 IEEE Spectrum. I also lifted the diagram showing the 64’s unusual bitmap mode from there. For what it’s worth, my favorite 64 technical reference is Mapping the Commodore 64 by Sheldon Leemon. And if I may be forgiven a blatant plug, do check out my book on the Amiga if you’re interested in the sort of technical details I’ve delved into in this post. Some of what I go into in the book actually apply equally to the 64, and I explain basic concepts, starting with what a bit and byte actually are, much more fully there.)