Inside the Homebrew Atari 2600 Scene

angryflute writes "'Have you played Atari today?' was an ad jingle for the Atari 2600 VCS game console during its reign in the early years of the video game industry, from the late 1970s to early 1980s. That question that could apply even now, according to an O'Reilly Network article, thanks to the passion of programmers who've continued to make new Atari 2600 games for the past few years."

Comments

Skeleton +

[Neo-Rio-101]

One game that stood out from the Atari 2600 home brew scene was this 3D maze game called "Skeleton +", which could be best described as something about as close to DOOM as the Atari 2600 was likely to get!

Makes me want to dust off the Commodore 64 classic 3D "Layrinth" game and mod it into a no-frills Doom-like game.

Re:Skeleton +

[jsse]

Screenshot of Skeleton+ for Atari 2600. :)

If i ran a software firm...

[222]

i would make it a requirement to code an enjoyable 2600 rom :p
The ammount of work that goes into creating an entertaining title while only working with 4k of rom space and 128 bytes of memory is staggering. Mind you, most of my emails are larger than 4k....
I dunno, maybe im just being sappy, but it really brings a smile to my face to see coders throwing themselves into what i can only characterize as a digital bootcamp, simply for the love of the game.
Long live passionate programmers :D.

Oy

[NeoPotato]

What's with people ripping off the first paragraph and submitting it as their text? Do they just assume we're not going to read the article, and are therefore being clever, or are they just lazy? That whole submission, with the exception of six words, is ripped from the top paragraph of the article.

Re:Oy

[sporty]

Do they just assume we're not going to read the article...

You're new here, aren't you? ;)

This is passion at it's finest

[beacher]

"The system has no video buffer, the total code size cannot exceed 4K and can only use 128 bytes of RAM"... "the Atari 2600 requires 100 percent Assembler coding".. Wow. You gotta really love it or love challenges in order to constrain yourself so. In the age of bigger and faster machines, I think a lot of the bloat is due to the fact that people never understood or learned the inner workings of the processor and the code isn't as tight as it could be. I'm not recommending that assembly be required, but I think anyone that develops should be cognisant of what happens behind the curtain.

Still- Developing and making fun games from this tiny system is incredible. I have every platform I've ever owned since the 2600/Intellivision era and the 2600 has definately sat unused in the past few years... Maybe it's time to dust it off...

Re:This is passion at it's finest

[Stween]

A lot of "bloat" comes from increasing levels of abstraction away from the hardware, and numerous levels of interfaces between different system layers to allow for more modular code, more reusable code, and generally, safer code. Coding an application for a modern machine with all its fancy hardware would be pretty tricky without these interfaces already written for people. Sure, somebody has got to write the low-level interaction gubbins in the first place, but once it's done, it's done. If software houses wrote for the hardware to reduce bloat, we'd never see any games or software. Praise the bloat. The bloat be praised.

[That's not to say that an understanding of what the machine is actually doing with the code wouldn't help people when designing software systems, I agree that it would certainly be beneficial. It's just not necessarily where all the bloat comes from. The lack of understanding is probably more and more relevant as more and more layers of abstraction are added. And there's always room for one more layer of abstraction!]

Dedication or masochism?

[Xargle]

Do they code these games sitting on broken glass whilst being branded with hot pokers whilst listening to Celine Dion?

No accounting for taste, I suppose.

Good Article!

[Bender_]

Good Article, seems to be quite accurate on details. And yes, I did actually read it.

I also made some attempts on vcs2600 programming some years ago. It could not be any more different from your daily C/php/... hacking. Think of microcontroller programming with even more demanding timing.

The machine has 128bytes (yes, bytes) of ram and 4-6kb of ROM. No video ram, everything is generated on the fly. The CPU does not support interrupts, all the timing is done by active waiting.

Re:Good Article!

[JanneM]

Note that you have 4k of ROM, that in addition can be bank-switched. "All" you need the RAM for is for changing variables, really. Not that it's not a pretty demanding limit (seeing how apparently the 6502 stack needs to fit as well), but you do have a bit more margin to play with that it seems at first. Most microcontrollers today look similar, with what seems like a ridiculously low amount of RAM compared to ROM.

Compare to the Commodore VIC20 - precursor to the C64 (and a wonderful machine in many ways). You had 5k total, of which 1.5k went for the video buffer. That left you with about the same amount of total codespace to play with, and there were no shortage of really good games for that machine either. The defining limitation of the 2600 really seems to be the lack of a framebuffer far more than the low amount of RAM.

The book "Hackers"

[Henrik S. Hansen]

People interested in the early days of game hacking should read "Hackers: Heroes of the computer revolution" by Steven Levy.

It also has an accurate history of the early days of the MIT AI Lab (where Stallman and others started out), and the early days of BASIC.

It has several chapters about the birth of Sierra (then called On-Line Systems, IIRC). Great stuff, and should be required reading for anyone interested in the early days of computing. Truly great book.

Damn it

[Anonymous Coward]

I've already moderated some posts here, so I have to post as AC from another machine (or else my moderations are removed)

I've been coding some stuff on the Atari and it's an extremly cool machine.
You can actually build one yourself, if you have a little knowledge in electronics.

Most of my coding is done in the Atari 2600 emulator called "Stella":
http://freshmeat.net/projects/stella/

Worth a try if you love the 6502 and minimalism

Re:Damn it

[csirac]

I've been coding some stuff on the Atari and it's an extremly cool machine. You can actually build one yourself, if you have a little knowledge in electronics. From the article it says that the 2600 has a custom chip - the TIA. How do you substitute that? With an MCU/FPGA?

Re:Hmmmm.....time did advance, right?

[phozz bare]

Actually you could get *limited* colors at 320x200. I forget what the term for it was

Yes. It was called 'artifacting', and occurred when using high resolution monochrome modes. It looked terrible, different computer models and different TV's produced different colors, and you were still stuck with 160 pixels of resolution anyway because you had to turn on every other pixel to get a certain color (an ugly khaki green or, alternatively, a shocking sky blue. or at least that's what it looked like on *my* system, depending on whether you used even or odd pixels).

This mode wasn't available for the 2600 though, so not really on topic.

Oh, and it's De Re Atari, reproduced in full for your pleasure.

Slashdot is like Playboy, everyone skips the articles and goes straight for the juicy stuff.

I've done this!

[pngwen]

Of course my rom just flashes random colors and a line that remains constant going back and forth. Considering what the atari 2600 environment is like, I'm damn proud of this. It's not exactly like other architectures. Even if you are used to programming in assembly for embedded devices with tight memory constraints, the VCS is STILL a major wakeup call.

Here are some of the challenges that you will encounter:

• There is no interrupt vector system. System functions are accomplished by means of the stella chip, which looks like a section in RAM. writing and/or reading from certain memory locations triggers events (such as drawing to the screen and such)
• TIMING is YOUR responsibility! You have to count clock cycles while you program, and you have to write the code to redraw your screen scan line by scanline on each electron beam pass of the TV.
• Computation has to be performed mostly during the blanking and return phases of the electron beam. You know you have 72 clock cycles in which to operate your game logic before you have to begin drawing the screen again
• Once your program's timing gets off, you get something that looks nothing like what you intended. My moving line example had a line that stair stepped as it moved. It wasn't until I added a sufficient amount of NOPs that it lined back up.

All in all though, it is a rather ingenious system. Considering when it was made, and the maximum cost of each unit, I'd say kudos to those engineers! I hope to do some more meaningful stuff with it once I have more time. I've plans to hack hardware for it as well!

-Bob

True classics live forever

[Alwin Henseler]

Once it was thought that such old game classics, and the machines they were played on, would go out of use once the original hardware would die, waiting to be replaced by new platforms & remakes. Not so.

Development of both hardware & software simply continues as time goes on, no matter what. If an original manufacturer pulls the hardware of the market, and games go off the shelves, development slows down, but continues anyway. If the manufacturer/copyright holders try to prevent remakes, emulators, don't release ROMs, hardware info, schematics etc, that slows things down. But they can also promote this, and enjoy having an active community further developing these old designs, like in the Sinclair ZX Spectrum case. Given enough time, all there is to know about the inner workings of these old machines becomes known, and new things are done with it.

I think the appeal to enthousiasts results from the simplicity of these old systems. If you put in enough time, you can write code that uses every single part to the max, doing incredible things with minimal hardware.
One of my favourites is the Sinclair ZX81. 1 KB of RAM, no sound, no colour, and: no videoprocessor. About 3/4 of CPU time is spent on directly writing black&white dot patterns to the TV screen, using some simple logic to turn it into a video signal. With only the remaining 1/4 CPU time left for doing useful things.

With the arrival of quickly reprogammable hardware like FPGA's, the border between hardware and software blurs further, nice example is FPGA Arcade, where old games are rewritten in hardware circuitry. So instead of having a CPU eat through instructions coded in ROM, your joystick input directly affects the logic programmed into a FPGA. Very cool!

Why were there no analog joysticks?

[RenaissanceGeek]

Something that's always bothered me about the old "classic" video-gaming platforms (with exceptions like the Magnavox Odyssey 2) was that the joystick controllers were all digital, with either 8 directions or, sometimes, 16 (IntelliVision), but no control over the INTENSITY of the movement: any game that had you controlling a moving object in two dimensions (e.g. the aim-point in "Missile Command") had only one speed at which that point moved, making it difficult ot be either precise or fast in your positioning.

Now, what is a joystick, really? It's two potentiometers: one for horizontal (x-axis), and one for vertical (y-axis.) Atari 2600 joysticks aren't built like this, instead having on/off contacts only. But joysticks aren't the only controllers available for the 2600: there are also the paddles (and the keypads and the driving controller, but I digress.) And what is a Paddle? It's a potentiometer. And the Atari paddles are only available in PAIRS, which share a common connector to the 2600. This makes it possible to have four-player games like "Warlords" or "Video Olympics" by using two sets of paddles. Why did no one ever build the two potentiometers from the paddles into a single joystick? All of the necessary functionality is present on the 2600 side for analog 2D controls, so why not? (I'll grant that writing analog-control software on such a limited platform would be taxing, to say the least, but surely it's POSSIBLE.)

Heck, I've even soldered together a pair of capacitors into an adaptor-plug that lets you use PC joysticks on an Atari 5200 (using plans from the online Atari 5200 FAQ and an old Texas-Instruments calculator with the clicky keys for my keypad), surely such a project for the 2600 wouldn't be any harder?

So THERE's a challenge for the modern 2600 hacker: build a game that uses an analog joystick! (for a REAL challenge, make it two-player!) Heck, I'd even be willing to build a joystick adapter for the programmer who did it! (and gave me a ROM cart of it.) (OK, that's setting myself up, I know.)

Any takers?