Peter Latimer conducted an e-mail interview with me about JoustPong and Atari 2600 Homebrew Development
for the British hobbyist magazine Retro Gamer...you
can see the brutally condensed final version
(kindly scanned by Al of Atari Age fame after I wasn't able to locate a copy of that issue) but
here is the much longer initial Q+A exchange...
Hey there...
I answered the "education' stuff here....I started with the "real"
questions but have to split for now, so I'll send answers to the 2nd
part later....hopefully I'm not being too long winded for your own
good...
On Mon, 08 Nov 2004 20:44:30 +0000, Peter Latimer wrote:
> Thanks again for answering a couple of questions. If this is too much,
> just leave out the parts you don't have time for. Note - I would intend
> to credit you with any information and quotes I use resulting from this,
> so make sure you tell me if you'd prefer to remain anonymous!
Heh, of course not, I have a tremendous ego and love the attention.
If it makes sense to work it in, I wouldn't mind a reference to my
website http://kisrael.com -- but if it doesn't fit in or detracts,
don't worry about it. That's besides the usual
http://alienbill.com/2600/101/ which is also freely publishable.
BTW, did you see http://alienbill.com/joustpong/ which was a
developer's notebook I kept...
> Section 1 - My education
> -------------------------
> The following questions are born out of me trying to get a very, very
> high level understanding of how a 2600 game flows. I'm no assembler
> programmer, so apologies if the questions are stupid. Direct quotes will
> probably not be used from this section, unless of course you something
> particularly cool in your answers...
Okeedoke.
Full disclosure: I'm really not THE sharpest tool in the 2600
programming shed. I was never one of the gurus, and everything might
be a tad rusty at this point, but I'll try to point out when I might
be out on a limb.
> 1.Is it correct to say that the 2600 was designed with a very specific
> intention - 2 players or of some kind, 2 missiles of some kind and a
> ball of some kind. Each element could take whatever form you wished but
> if you wanted anything which didn't fit that basic model, you are
> immediately into using tricks and workarounds to achieve it?
I'd say that's largely correct if you include "a background of some
kind". It seems like they set out to make a machine to play "Combat"
(Or rather, "Tank" as the arcade version was known) but then decided
to use cartridges get a few additional games going.
> Can you
> give me a couple of tricks for getting around this limitation? Either
> from you own experience, or others you've heard of.
(Obviously checkout Atari Age for screenshots or ROMs...)
The most common trick is flickering...one frame you show one thing,
another frame you use the same "object" to display another. You can
see this in "Adventure" (hence the epileptic fit when many items are
on screen at once) or Wizard of Wor.
Another is to subtley arrange it so that two things that are using the
same "object" don't appear on the same scanline. "Tron Deadly Discs"
is a great example...one of my favorite games growing up but I never
noticed that the enemies running around in the open arena were never
quite at the same vertical level.
Then you get into some seriously weird stuff...look at "Super
Challenge Baseball"...every outfielder that's not active is actually
the "missile" graphic at various widths...narrow head, break for the
neck, wider torso, narrow for the legs again. (Which is also why the
players are arranged so they don't overlap vertically, and then tend
to "pop" back into place when deactivated)
Another trick is to take advantage of this built-in Atari trick of
doubling, tripling, and/or widening the players and missiles. For
example, the 6 enemies across of "Space Invaders" were almost
undoubtedly the 2 players in "triple" mode. One particularly
brilliant hack/use of these was Paul Slocum's idea for my very own
JoustPong...when I added the Pteradactyl, I was planning on letting
things flicker a bit, but Paul Slocum pointed out I could take one
player graphic, shove it to the right hand hand side, then duplicate
it. The duplicate is then shoved all the way to the left side of the
screen. Then he wrote me a "kernal" that "rewrote" what was in the
player graphic JUST IN TIME, off the side of the screen before it
started the next line, to show what the left player was doing. He's
brilliant, and I don't I think I could've gotten the timing quite
right.
> 2. Here's a quote from 2600 101 -
>
> "each scanline is drawn, you have to determine if a missile or ball is
> "on" for this line, and turn it on if so. You also have to determine if
> the "player" is on this line, and if so, what line of graphics should be
> drawn on this line to represent the player."
>
> Are you saying that for every line on the screen you have to, in some
> sense, ask the following the questions -
>
> Is player 1 on? If so, what needs to be drawn for player 1 on this line?
> Is player 2 on? If so, what needs to be drawn for player 2 on this line?
> Similar questions for missiles and ball.
That's about right. Often time games use a "two line kernal" which
means it's doing one set of thinking for every two scanlines rather
than for every one, but the basic idea is the same.
> Ultimately then, is that how, at its most basic, the 2600 gameloop
> works, with the answer to each of the above questions being determined
> by the logic being run 'between' the scanlines, and thus your game is
> created? (I make it sound so simple...)
Yeah...it's not so much "between" the scanline as "on the edges of the
scanlines"....very akin to how we use the space "above" and "below"
the picture to do the "thinking", but in a much stricter time frame.
> 3. It seems that a 2600 game really works with two very high level
> components - the frame level where you get two vertical blank periods to
> perform your game logic and then, within that, the scanline level where
> you get just 22 cycles which will be mostly concerned with turning
> things on and off. So, while I appreciate you can chop up your 22 cycles
> as you wish, normally you'd expect the vertical blank time is all you
> have to figure out what's going on in your game.
Pretty good summary there.
For all but the most ambitious games, the vertical blank and overscan
(the same thing, roughly) is plenty of time to do the "thinking" about
what will be shown this frame. In fact, JoustPong just used the
VBLANK, and marked time for the Overscan. The VBLANK etc is usually
thinking "what is being drawn this frame", the kernal is "now how the
hell do I draw it on THIS line"
> Would you say those
> rigid limits are among the most challenging aspects of programming for
> the 2600?
Sure. The tricky part is the "kernal", when things are being
drawn...22 cycles is about 4-8 instructions, which really isn't much,
though you do have the option (almost requirement) of doing more
calculation even as things are being drawn. So for example, if you
have a player that's only ever on the right half of the screen, you
can feel free to reset its graphic anytime while the left side of
screen is being drawn.
> What happens if you stray outside the limits? If you did 24
> cycles worth of processing in one scan line? Would you simply fall
> behind the tv's beam and leave 'holes' in the screen?
"Holes in the screen" isn't quite the right way of thinking about
it...see, the Atari is gonna draw SOMETHING, ready or not...the
question is, can you get to draw the right thing for your game? So
often the effects of a mistimed kernal are weird. Stretched out
players or players still showing what was in the player graphic on the
previous line are pretty common, or players with a "venetian blind"
effect...
> 4. This might be a stupid question, but is the vertical blank time in
> reality the borders of the screen which the 2600 doesn't normally use?
> If so, is it technically possible to draw in these areas? Has anyone
> ever made a game which uses these areas and still manages to pull
> together its logic?
It's not a dumb question. Atari did a LOT of research to make a system
that was compatible with all brands of color TVs that were out
then...the recommended procedure is to follow their guidelines of when
to turn the screen on and off and when to use the vertical synch. You
might be able to draw on more of the screen if you push the envelope,
especially w/ newer TVs that are sometimes pretty liberal about what
they'll display, but you risk things like the picture rolling.
> 5. If some screen elements are stationary, how much effort has to go
> into them for each frame? In a multi-screen game like Adventure, did the
> programmer have to think about drawing every screen element in every
> frame or did this always form the 'playfield' and not need quite the
> same attention?
Take a look at http://www.qotile.net/minidig/disassembly/adventure.asm
and if you scroll to about 2/3 down you can see how the "boards" are
coded into memory. In the case of adventure, stuff like the gates and
bridge are still "objects", but yeah, in general, the logic for
shoving a static background playfield is simpler than for the player
graphics...still, you don't get anything for "free" in atari land,
your kernal has to make time for the background updates as well.
> Section 2 - A few questions about your involvement and the scene in
> general
>
> (direct quotes likely to be used here)
>
> 1. What on earth possessed you to become a homebrew Atari 2600
> programmer? What kind of programming had you done before?
I've been an Atari fan for a long time. When I was a kid, I was
blessed by stumbling into a large collection of Atari games...this was
right after the "Great Crash" of 1984 and some retailers were bailing
out of this "fad" as fast as they could. I had a much bigger
collection of cartridges than most of my friends thanks to some
connections my parents had...I think I liked how each game was a
microcosm that set up its own little world, from the cute little
critters of Cosmic Ark to the amazing fully 3-D environment of
"Battlezone".
Through the years, then, I kept up my interest in video games on
various systems...the old 8-bit home computers, the NES, even the PC
And when I got to college, I hooked up with an online community of gamers,
people posting to the Usenet group "rec.games.video.classic". I found
some saved posts that indicate I was reading that group as early as
1993, and while my heart is now with the message boards at AtariAge,
I still check into r.g.v.c. every once in a while. There are a lot of
people there for the collecting aspect...they love making finds in
thrift stores and flea markets and what not. I've always thought of
myself as more of a general game historian and philosopher.
In terms of programming, I got my start on the old 8-bit computers,
generally in BASIC: the Atari 800XL, the Commodore 64. Those machines
were great, I think there's something fantastic about a computer that
booted into a programmable environment, it really encouraged kids to
start tooling around and see what they could do. Then in college I
started taking some computer science, mostly to avoid a difficult math
class...a plan which backfired when I added a Computer Science major
to my English major, but has left me in a pretty good place
career wise. I've been programming professionally since graduating in
1996, mostly stuff on the web, or with a strong business component.
I had written some little toys in Visual Basic and Java, however...in
fact, both of those languages had a version of JoustPong well before I
thought I could actually do it on the Atari.
Most tellingly, all the programming I had done had been in what are
considered high level languages, where most of the nitty gritty is
handled for the programmer and he or she can think at a higher and
more abstract level. But when I saw Joe Grand at Philly Classic,
manning the booth for his homebrew "SCSIcide", it made me think "hey,
maybe I could do this". of course, it turns out he writes low-level
code for a living and can write a device driver about as easily as I
can sneeze, so it's probably good I didn't realize how my previous
instincts of "writing an Atari game is impossibly difficult" were more
on target than I knew.
So in terms of wanting to be a 2600 programmer...it's a way of
impressing the heck out of my youthful self, and really, there aren't
that many ways of making a game that can be played on a real TV.
> 2. You wrote '2600 101', a fun guide to the first steps of 2600
> programming. How many people do you think have used your guide to get
> started? It's surprisingly easy to follow - is there going to be a more
> advanced level follow up?
Well, the 2600 homebrew community is pretty small, and heck, a big
chunk of the folks in it were doing this well before I was...but every
once in a while I'll get a note from someone who said they got their
start with 2600 101, and also Andrew Davie's "2600 Programming for
Newbies" tutorials message board. But still, come to think of the
audience is probably less than 100 people in all. Sometimes I think
by trying to establish a "standard" starting guide, it'll be a
resource when [stella], the SURPREMELY helpful mailing list,
is no longer active, so some future lonely geek with a weird,
even-more-retro outlook starts on his project he won't be quite as
alone.
I started a followup document called "2600 Cookbook"....the format of "recipes"
for various tasks has been tremendously helpful to me in O'Reilly's
Java and Perl Cookbooks, and I was trying to write down many of the
tricks and "best practices" that the [stella] list had come up with.
The 2600 Cookbook is kind of stalled however, like so many other
projects in the hobby...only about 7 entries, but there's some good stuff there.
> 2. You've completed your first game. Can you tell me about your next
> 2600 project?
Well, everything is still in that lame "I should get to that
someday..." stage. My best idea is for an odd kind of existential
project: "Albert Camus' The Myth of Sisyphus". It might not be much of
a game I'm afraid...the rock always wins.
I also have a few idea for some 4-player games, using the
paddles...but it would be a huge challenge.
> 3. Tell me a little about the game 'JoustPong'? I'm guessing you weren't
> expecting the 2600 to make you rich, but it seems that a significant
> amount of people are interested in buying it. How many copies has it
> sold to date? Did that come as a surprise? How do you feel about the
> hassle you've had over the naming of your game? Do you think this kind
> of action is stifling the homebrew scene? Is it worse on the 2600 than
> other systems?
JoustPong as a concept got its start on rec.games.video.classic...some
random marketdroid asked the group about the future of gaming, and a
guy using the moniker "Otter" said "The future of gaming can be
summed up in two words -- Pong and Joust" That led to some riffing on
how the games could be combined, and is where the basic idea of the
game was formed. You can dig up the original posts using Google's Groups search.
Atari programming is really a labor of love, and then a bit of retro
geek street cred. JoustPong sold out its initial run of about 50, and
maybe 10 or 20 beyond that. I worked with the website Atari Age to
get the physical carts made...they have great production values, and
without them JoustPong would probably have just been something to
download and run on an emulator. And the 50 is pretty much par for
the course, as far as I can tell, and I made a smallish royalty on
each one. I had the bundled T-shirts printed up myself, however.
The hassle over the name "JoustPong" is annoying...actually, I thought
it was the theme of "Joust" that was going to get me in trouble, not
"Pong", which I thought was pretty generic. I know that companies
have to defend their intellectual property or risk losing it, but
still...pages of pages of Google hits before you get to anything
related to the current incarnation of Atari, it's pretty much a generic
popculture concept at this point. And the mechanic of JoustPong is
pretty unique
and not like other Pong games...
But more damaging than having to drop the name "JoustPong" for something cutesy
like "FlapPing" is the way their repressing some other really nifty stuff...
a 5200 version of the Arcade and 2600 classic
"Warlords", a sequel to Adventure, and a ton of what are called
"Hacks"..the hacks are really cool, variants on old Atari games...some
were mere graphics changes, but other ones are really
impressive...adding voice to Berzerk, enhancing and stretching
the gameplay of various classics--and now they can't be sold as real carts,
for use on real Ataris...And it's really too bad. I can see wanting
to watch out for things that are going to cut into current sales of
emulated compilations and other things, but
come on...no one's going to say "Gee, I'd buy this Atari Greatest Hits
pack, but I can get Asteroids where it's all Borg ships, I'd much
rather buy that..." So they're just irking the hardcore fanbase, and
reminding everyone about how much less cool they are in their current
Infogrames incarnation...
> 4. What is the single most bizarre thing (if anything) about the
> hardware design of the 2600? The thing that makes you wonder 'what in
> the world were these guys thinking?'
Well, really it's more admiration, how they did so much with so
little...and of course, the generations of software programmers that
came after, how they pushed the system so much...but with the initial
hardware, they really put a lot of thought into keeping the system as
open as possible.
Two things come to mind, however. One is the way it generates music.
Until you realize the math behind it, the choice of notes it provides
seems very weird and arbitrary.Admittedly once you see the basic
division it's doing, it actually makes a little more sense than the
math behind the regular 12-note scale. It still sounds kind of odd,
however.
The other "simgle most bizarre" thing is this odd little geeky detail of
how the playfield, the thing that makes the big clunky backgrounds, is
set up in memory.
It's 20 bits, so 2 1/2 bytes, that is then repeated for use on both the
left and right sides, either repeated or used as a mirror image. And
the order of the 2 1/2 bytes is odd, it uses the left 4 bits of the
first memory location in backwards order, then all the bits of the
second memory location in forwards order, and then the bits of the
final memory location in backwards order again. I ended up making a
web-based tool in javascript so I could paint what I wanted it to look
like and the get all the bits and bytes listed up.
Now sometimes I realize that there might be some deep technical reason
for that bit-ordering thing...something dark and arcane about
transistor layout or circuit timing...other times I think, well, early
Atari had so much weed, it's almost surprising you don't shake a
cartridge and have stems and what not fall out, and maybe that
explains it better...
> 5. If you could change just one thing about the way the 2600 is
> programmed, what would it be?
Huh. You know, part of the joy of 2600 programming is that it's so
set in stone, that new coders get to step up to the plate and see what
THEY can do with the limitations that the previous generations had to
deal with. But if I had some kind of wishlist for the hardware, I
really wish it had 4 or more Player/Missile sets rather than just the
2...it's really hard to do the kind of multiplayer stuff (more than 2
players) with the limitations as they are
Or, given a more literal interpretation of "the way the 2600 is
programmed"...the hobby could really use a good debugger, one that
made it easy to see what's going on at any given moment of the game.
There's one out there, PCAEWin, but it's actively user hostile, and
the best emulators for playing/testing games only have the most
primitive facilities for that kind of introspection.
> 6. I know in 2600 101 you mention (slightly sarcastically) a couple of
> the 'friendly' features of the 2600. What's the most unexpectedly
> friendly aspect of the 2600?
I'd say it's really easy to tell when one object is hitting any other
object, it has a lot of special registers for detecting those
collisions. And that's terrifically useful; a lot of more modern
systems I worked with didn't have that kind of collision detection,
but it's something that you need all the time when you write a game. I
had to write special routines to see if two objects overlapped, and
hopefully that was good enough.
That kind of specialization was a hallmark of early computer hardware;
they knew people would be playing games and what not, so the systems
had special features to make it easy to make good graphics and sound
and gameplay. The pinnacle of that kind of thinking was probably the
Atari ST and the Amiga; when PCs became more dominant it was a huge
step backwards, going from lovely color graphics and great sound to 4
color CGA and a buzzy speaker. It took years for PC-compatibles to
catch up, and there are still some people who swear by a trusty Amiga
for video editing or an even more trusty Atari ST for working with
MIDI-based electronic instruments.
> 7. What's the finest piece of 2600 programming you've ever seen?
I've never become really good at reading other people's code, so I
have the same view of other people's programming as any "civillian"
does, from just getting in there and playing the game, though now I
have a stronger idea of what limitations any given programmer had to
overcome.
So from back in the day, the 2600 port of Battlezone blew me away
then, and it still amazes me now. It models a true 3D environment
(without restricting everything to strict 90 degree turns) like no
other game on the Atari...you can hear an enemy tank that's behind you
fire right you, throw it into reverse, and see the bullet arch
harmlessly ahead of you. Combine that with some lovely graphics,
(tank treads that move "properly"), fighting 2 enemies at once, a
functional radar screen, and the coolest "transmission breakup"
explosion effect when you get hit...it's just astounding.
For the homebrew scene, many people think of Thomas Jentzsch's port of
the C=64 game "Thrust" as the pinnacle of programming, and I have no
reason to disagree. It's quite a feat.
> 8. What are some of the best (playability-wise) games you've played? And
> the worst?
Let's see...I'm a big fan of games for 2 or more players, so even
"Combat" (or one of its descendents "Armor Ambush") stands out. Along
of course with "Warlords", one of the ultimate four player
games...hampered only by this weird issue where one of the players is
much more likely to get lucky ball bounces when guarding his castle.
And we used to play endless games of Activision's "Ice Hockey" in
college.
At the risk of being a total egotist...I think "JoustPong" actually
turned into a very good and playable game, though a lot of people find
it difficult to control at first, but I really put in work to make it
a good head-to-head match, along with making a good but not perfect
computer opponent.
Worst...well, the whole Swordquest series wasn't so great. And all the
Mythicon games are legendarily bad, though not quite as awful as
people make out.
There was also this sequel that Activision made, "River Raid
II"...very ambitious, lots of neat stuff in it, but I think it just
tried to hard, and the difficulty in the control (some weird thing
combining the throttle with the altitude control) made it totally lose
the charm of the original.
> 9. Any time I read about 2600 programming it's always mentioned how the
> developers spent so much time circumventing the standard limitations of
> the console using all kinds of tricks. What's the most impressive trick
> you've heard of?
No "legends of Atari programming" come immediately to mind...but I
know the most impressive trick I had first hand experience with. Paul
Slocum, a member of the [stella] list and a great 2600 programmer,
realized that when I added the pterodactyl to JoustPong, I didn't have
to make everything flicker to display 3 things when I only had 2
memory locations to play with...by using the Atari's built-in ability
to "double up" a single object, I can move the player all the way to
the right and double it...its twin will show up on the left side, and
there's enough time to fiddle with the memory so it correctly shows
the left player instead. That leaves the remaining object available
for the pterodactyl, which really added some nice chaos to the typical
Pong-ish gameplay. It's a great bit of coding that Paul pretty much
handed to me on a silver platter, and I'm very grateful for it.
> 10. Anything else you want to say about 2600 101, your game or the
> homebrew scene in general?
Well, I'm very grateful for all the help the homebrew scene gives up
and coming programmers, and 2600 101 was my attempt to give back to
the community.
The [stella] list was a huge help...it's an incredibly generous and
helpful mailing list full of some of the cleverest people I know.
AtariAge as a website is a great force for good in the community as
well...really dedicated to keeping the Atari heritage alive as well as
supporting the homebrewers as they move it into the future.
And then, local homebrew groups are a lot of fun as well...the "New
England Classic Gamers" meet 3 or 4 times a year for a big trademeet
type event, along with some video game tournaments...that's where some
of the first public beta tests of JoustPong were ever held!
> Thanks again for your time - it's hugely appreciated.
You're welcome...I appreciate your interest, it's a great hobby.
--Kirk
