Loadstar 222/222.d81/t.atari2600

Text File | 2022-08-26 | 7KB | 218 lines

u
             A DISCUSSION
                of the
       ATARI 2600 and PITFALL!

           By Robin Harbron


    The Atari 2600 has a 6507
processor, which is nearly identical
to the 6510 in the Commodore 64. It
lacks the extra I/O ports which the
C-64 uses to map memory and talk to
the datasette (locations 0 & 1). It
can only address 8k of memory, rather
than the 64k the 6510 can see. And it
has no facilities for accepting
interrupts, while the C-64 has both
NMI and IRQ -- and we programmers love
them, once we understand how to use
them!

    In all other respects, the 6507
and 6510 are identical, meaning if you
know how to program in assembly on
one, you can do it on the other.

    While the 6507 can address 8k, the
designers of the 2600 thought 4k was
plenty for game code, and all the
earliest games were stuck with this
limit until bank switching schemes
were developed on newer models of game
cartridges. The other 4k is sparsely
populated by the video and sound and
input/output chips -- and the 128
bytes of RAM that are at the
programmer's disposal.

 [DAVE'S INTERRUPTION]: Did he say 128
BYTES of RAM? Obviously, all the code
was in ROM Cartridges. But only 128
bytes of RAM! Golly!


    The Atari 2600 has a very simple
video chip -- technically inferior to
the VIC-II in the C-64 in every way
save one -- it can display it's 16
colours in 8 different shades each,
giving a total of 128 colours. But
where the C-64 has 8 sprites that are
24 bits wide, the 2600 has 5 sprites,
2 of which are 8 bits wide, 3 of them
are just 1 bit wide. The C-64 has a
320 pixel wide hi-res screen, the
Atari only a 40 bit screen (and only
20 of them are directly programmable
without tricks!)

    It doesn't end there! You can set
various registers and memory locations
in the C-64 once, say to print some
text on the screen and put up a
sprite, and expect the display to
continue until you tell the computer
to do otherwise. On the Atari 2600,
it can only remember one rasterline at
a time, and it's up to the programmer
to keep changing those graphics every
scanline (say, 200 scanlines for every
frame, each frame lasting 1/60 of a
second on an NTSC system) -- if you
don't keep changing the graphics,
you'll just get vertical stripes down
the screen!

    The code that handles this screen
drawing is typically called a kernal,
and it's this kernal that decides what
the game can and can't do graphically.
 You have a maximum of 71 cycles per
raster line to do as much as possible
- do you move a couple sprites in that
time? Redefine the sprite graphics?
Change colours? You don't have time to
do everything!

    But it's exactly this flexibility
that made so many Atari 2600 games so
amazing -- instead of being tied to
doing exactly what the hardware
demanded, programmers thought of how
they could make these limitations work
for them, instead of against them.
This same spirit still exists today in
Commodore 64 demo coders, and the few
that are still making new Atari 2600
games.

    Looking at Pitfall! (I add the "!"
because it was part of the name on the
original Atari 2600 cartridge) you can
see how Atari 2600 limitations shaped
the design of the game. Although it's
not true on the C-64, on the original
Atari 2600 version the background (the
trees) was always either mirrored or
duplicated, left half to right half,
since only the first 20 bits of the 40
bits for the background were
programmable -- the other 20 were
either duplicated or reflected.

    The surface that Pitfall Harry
runs on is always symmetrical -- one
pit in the middle, or three evenly
spaced pits, or the symmetrical holes
that disappear and then expand.
There's just one 8-bit sprite on the
surface besides Harry (well, sometimes
there's two or three, but they are all
duplicates -- the 2600 would do that
automatically, create 1 or 2 identical
sprites to the right of the "real" one
if you asked it to). The scorpion only
shows up on levels where there isn't
an underground wall to use up the one
available 8-bit sprite.

    One other interesting thing about
Pitfall! is the way the levels are
generated. Pitfall! has 256 levels --
the 20 minute limit isn't long enough
to see all of them (that's why you
need to go underground to finish the
game in time - you actually "warp"
ahead 3 levels each time you go
through an underground level). And 4k
surely doesn't seem to be enough room
to hold all these levels! David Crane
says he used something called an 8-bit
"polynomial counter" to generate the
levels.

    A regular 2-bit counter, for
example, would simply count 0,1,2,3
and then repeat. A 2-bit polynomial
counter could count, for example, like
this: 2,0,1,3 and then repeat. Back to
the 8-bit counter, David Crane then
decided that, for example, the first
bit would represent one of two tree
line styles. Then perhaps the next two
bits would decide which (if any)
creatures would appear on the level.
Then perhaps the next bit would decide
whether there would be any ladders on
this level. And so on. He then played
with different combinations until he
found one that was playable all the
way through all 256 levels - but he
didn't need several 256 byte tables
that would use up valuable ROM space -
just a couple short routines to work
through the polynomial counter.

    I used these same ideas in my two
minigames that I entered in the 2001
and 2002 mingame competitions,
allowing me to squeeze a 24k game map
in my 2k Minima game, and 9 large
platform levels in my 1k Splatform
game.

    For more facinating tales about
these early days of video game
development, try to locate the
excellent "Stella at 20" video
documentaries, produced by Cyberpunks
Entertainment in 1999 - David Crane
and many other alumni are featured.

 RH

[DAVE AGAIN]: I have always believed
that "limitations" are "opportunities"
for those who understand the reason
behind the limitation. Of course, most
computer users in the United States
(at least) believe that limitions are
reasons to build or buy a bigger,
faster computer.

Programming by limitation -- as with
the polynomial bit-logic bytes -- is a
nothing less than excellent
programming. We who love the C-64
platform have a hard time explaining
that love to others, because they
simply do not "get it!"

Robin's excellent explanation of the
innards of the 2600 help make sense of
the C=MOS engineers' desire to create
the Ultimate Video and Sound chips --
the VIC II and SID. Atari needed them
to move to the next level.
Unfortunately, in 1981, the Atari
cartridge market was reaching over-
saturation. And Atari was looking to
make its own real computer.

Anyway, thanks, Robin. Now we know.

 DMM