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. :)

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.

Re:Good Article!

[StormReaver]

"It couldn't have a framebuffer even if it wanted to, unless you only wanted 16x8 resolution."

I wrote a lot of assembler on the 6809 (CoCo 3), and a few text-based games. The text-screen was 32x16, and most of my useful assembler programs that manipulated that screen came in well under 4K (2K was my average) and used well under 128 bytes for data storage.

The machine had a video generator that could be pointed to any point in memory within the machine, regardless of what that memory area was actually used for (data storage, program execution, stack -- didn't matter).

I empathize with the homebrew developers. Developing with limited machine capacity is very fun, and sometimes very frustrating.

The CoCo had floppy drive support, but the read/write timing had to be exact since the drive had no interrupt support. The result being that while data were being read/written, the machine was in a very tight waiting loop to the exclusion of all else. Even system interrupts had to be turned off to get the needed clock cycles.

Only the NMI (Non-Maskable Interrupt) could be left on (it was impossible to turn off, hence "non-maskable"), but it was attached to the "failure" mode of the drive (the only actual interrupt it used, but only if the hardware failed).

Those were the days. :)

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:This is passion at it's finest

[tomstdenis]

While it's true that HALs require space they are dynamically linked in both Linux and Windows. So there goes that theory.

In fact you can write GUI apps in Windows with menus, dialog, buttons that are smaller than a couple dozen KB.

A lot of bloat comes from huge MFC/C++/etc libraries that get linked in [all or nothing] and serve merely as another languages wrapper around a C API.

I recall from the Borland days [my first C compiler for Windows] a simple OWL based hello world application was 80KB lines of code [though it did count headers], was a few hundred KB in size, etc...

In the case of games most decent games have small executables and huge data files. At best they are storing things wrong [e.g textures as BMP, sounds as WAV] instead of using compression [JPEG, Vorbis, etc...].

So really a "game" merely has to dynamically link against the HALs. In a way this is provided in other platforms. For example, the Gameboys [all of them] have had hardware 2d graphics. You load tile memory, set a sprite register or two and voila on screen sprite. You didn't have to mess with the LCD driver directly, etc, etc, etc...

Tom

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

[ClippyHater]

Actually you could get *limited* colors at 320x200. I forget what the term for it was, but I remember coding a game in 320x200. It was a matter of alternating lit pixels. If you had a run of 8 pixels, and every odd-numbered pixel was lit, then you'd have one color. If every even-numbered pixel was lit, you'd have another color. And if every color was lit, you'd have white (every color).

Ok, ok, to it was only 4-color, but I remember creating a nifty (at the time) character-based game using those colors to pretty good effect (again, for the time). High res, and 4 color, 1337! Of course, then the Amiga came along and my efforts seemed pretty pathetic, but damn it was fun!

Anyone remember "De Rey Atari" book? I'm sure I got the spelling wrong, and the 3-ring binder with the book is stored in a garage in florida, so it's probably now bug-crumbs, but those were the days :)

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

Re:Doesn't the 2600 have a line buffer?

[Anonymous Coward]

Yes, it has some "line buffer", but it only has 20 bits which are displayed twice each line, giving only 40 pixel horizontal resolution.

Re:Strong Bad

[Paul Slocum]

Still working on it. Should be out sometime this Summer.

Re:2600 Games for sale now

[tuffy]

Unfortunately, the titles on the 2600-in-a-Joystick are ports/remakes of the originals rather than the genuine article. It would've been nice if they were properly emulated for accuracy, but I suppose it's better than nothing.