Racing the Beam : the Atari Video Computer System - Index of
Racing the Beam : the Atari Video Computer System - Index of
Racing the Beam : the Atari Video Computer System - Index of
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
hundred people. These teams are divided into strict roles: programmer,<br />
artist, voice actor, designer, producer. In <strong>the</strong> heyday <strong>of</strong> <strong>the</strong> <strong>Atari</strong> VCS, a<br />
single programmer would create an entire game. Until Imagic broke <strong>the</strong><br />
mold by having artist Michael Becker create <strong>the</strong> in-game graphics for<br />
its 1982 Demon Attack, an “artist” working in game development was<br />
<strong>the</strong> person who illustrated <strong>the</strong> box art or designed <strong>the</strong> game’s printed<br />
manual. 4<br />
One might imagine that VCS games were created by one individual<br />
just because <strong>the</strong>y were simple. But as <strong>the</strong> previous chapters suggest, <strong>the</strong><br />
machine was anything but simple to program. In <strong>the</strong> early days <strong>of</strong> <strong>the</strong> <strong>Atari</strong><br />
VCS, though, s<strong>of</strong>tware engineering for microcomputers and videogame<br />
consoles was not nearly as industrialized a practice as it is now. Commercial<br />
s<strong>of</strong>tware was usually developed by individuals or small groups. For<br />
example, in 1981, Micros<strong>of</strong>t bought exclusive rights to its fi rst Disk<br />
Operating <strong>System</strong> (DOS) from an individual coder and <strong>the</strong>n licensed it<br />
to IBM. 5<br />
Although it is possible for VCS programmers to share code, cartridge<br />
development for <strong>the</strong> system is not amenable to <strong>the</strong> engineering <strong>of</strong> individual<br />
titles by large teams. Even though programmers learned each<br />
o<strong>the</strong>r’s techniques (both by directly talking to one ano<strong>the</strong>r and by reverseengineering<br />
what o<strong>the</strong>rs had done), <strong>the</strong>ir work did not divide into neatly<br />
reusable subroutines. This does not mean that VCS programs were underengineered<br />
or poorly written—<strong>the</strong> precise timing required just to get <strong>the</strong><br />
screen to draw wouldn’t allow for much sloppiness in coding. But <strong>the</strong><br />
constraints <strong>of</strong> ROM and RAM usage, cycle timing, and logic timing <strong>of</strong>ten<br />
demanded unusual and unintuitive shortcuts.<br />
For example, in <strong>the</strong> early days <strong>of</strong> Activision, programmers would<br />
push up against various boundaries. They would <strong>of</strong>ten run out <strong>of</strong> ROM<br />
space. Most 6502 assembly instructions are two bytes: one for <strong>the</strong><br />
opcode and one for <strong>the</strong> operand. Saving space on ROM requires consolidating<br />
code—usually removing one line for every two bytes <strong>of</strong> space<br />
reclaimed.<br />
Assembler programs are composed <strong>of</strong> elementary instructions,<br />
not <strong>of</strong> higher-order functions. For example, <strong>the</strong> following assembly<br />
language instructions load a value from <strong>the</strong> top <strong>of</strong> RAM, add <strong>the</strong> value 8<br />
to it, and store <strong>the</strong> result in <strong>the</strong> TIA register that sets <strong>the</strong> background<br />
color:<br />
[102]<br />
LDA $80<br />
ADC #$08<br />
STA COLUBK