I’ve had the opportunity in the past couple of weeks to listen to two podcasts in which game designers were interviewed. (I recommend you listen, also – ANTIC, The Atari 8-Bit Podcast #4 has an interview with Chris Crawford, who wrote games for the Atari 2600, Commodore PET, and Atari 400/800; No Quarter classic arcade podcast #52 has an interview with Brian Collin, who helped create the arcade game Rampage.) It brought back to mind similar stories like the making of Wolfenstein 3D for the Apple IIGS. In all of these situations the programmers had a limited space in which to do their work. They were limited in graphics abilities or limited in memory, or both, and yet they managed to create (or duplicate) games that were considered to be state-of-the-art in their day.

It brings to mind the problem on modern computers with what has been called “bloatware” – code that is large, takes up a lot of space in memory or storage or both, and often does only a little more than its predecessors.

The advantage of the small memory footprint and simpler processors in the micros of the 1970s and 1980s is that it was necessary to write compact, efficient code. The graphics had specific limitations that had to be honored. These programmers had to come up with tricks to get around those limitations, to push the boundaries to achieve the desired effect.

The programmers mentioned in the above three examples sometimes had to buck the accepted knowledge that said what they wanted to do was not possible. Brian Collin overcame memory limitations on Rampage by re-using the graphics layout for one of his monsters to create another one. Eric Shepherd had to almost re-invent how the graphics of Wolfenstein 3D were implemented in the Apple IIGS, in order to make it work. And Chris Crawford, like all who made games for the Atari 2600, had a tiny memory footprint in which to put the game itself as well as its graphics.

This limitation did not only apply to games. AppleWorks’ creator Rupert Lissner created memory management techniques that made a 64K or 128K computer and made it look like a much larger computer.

With modern computers, the programmer has exponentially more power available in which to implement his vision. The advantage is the ability to create things that could not happen in a classic microcomputer or game system. The disadvantage can be wasted resources and processor cycles. The programmer does not necessarily have to be efficient; he has a lot of space in which to work, and the operating system can take up the slack.

I have always maintained that Apple’s neglect of the Apple II platform actually resulted in the hardware being pushed to its full limits in ways that would not have been possible if they had taken the proper approach and evolved it, rather than continuing to invent successors. I admire and applaud the programmers who found their way around the limitations of the Apple II and were able to bend it to their will.

Every so often, a new bit of Apple II trivia comes my way. I was recently sent a message asking about whether Bell & Howell had made a beige version of its computer. David Bohrman had pictures of this, and informed me so. I asked for some clarification, and he kindly sent me several pictures (which I have placed in the photo Museum here).

With further photos, Bohrman discovered that what he had was a product made by Bell & Howell for their black Apple II computer that made it more useful for schools, but one that had been made to match the color of a standard beige Apple II.

This backpack was actually a great add-on to the Apple II, and would have been a good device for Apple to have included as an option to sell to customers. As uncommon as this item is, I suspect that Bell & Howell did not sell too many.

This shows the media plugins on the left (as seen from the back).

And this is the power center on the right side.

See the entry in the Museum for a couple more pictures. Thanks to Mr. Bohrman for this interesting bit of history!