Slashdot Mirror

← Back to Stories (view on slashdot.org)

Inside the Homebrew Atari 2600 Scene

Posted by simoniker on from the creamy-retro-goodness dept.

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."

86 comments

  1. Skeleton + by Neo-Rio-101 · · Score: 4, Informative

    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.

    --
    READY.
    PRINT ""+-0
    1. Re:Skeleton + by jsse · · Score: 4, Informative

      Screenshot of Skeleton+ for Atari 2600. :)

    2. Re:Skeleton + by Anonymous Coward · · Score: 0

      The guy in the game looks like he needs to have a cookie.

    3. Re:Skeleton + by RenaissanceGeek · · Score: 2, Interesting
      That reminds me SO much of "Dungeons of Dagorath" for the Tandy TRS-80 CoCo2 (Color Computer 2)

      Screenshot of "Dungeons of Dagorath" for TRS-80 CoCo2.

      The interface was all key commands ( A L = Attack with whatever is in your Left hand) (P R WS = from your pack, Pull using your Right hand, the Wooden Sword.) However, the graphics were sufficiently detailed (using the faux-monochrome display method, and simple vector graphics.), and the game played a number of distinctive sounds at ascending volumes as enemies approached, so you could plan your defense (or retreat, as appropriate for the strength of the enemy and your own health) before you could even see your enemy. The variety of enemies (spider, ghost, knight, wizard, etc.) not only kept the gameplay interesting, but allowed strategies to deal with enemies stronger than yourself later in the game. Yes, I burned many hours playing "Dungeons of Dagorath." and it wasn't even my CoCo!

      There was even a sequel for CoCo3: "Castle of Tharogad", which had solid-color graphics and used a point-and-click graphical interface using the joystick (or mouse, if you had one.) Unfortunately, the graphical interface was actually slower to use than the old key-based one and, worse yet, the CoCo platform used the same hardware to do the D/A conversions for the joystick/mouse ports as it did for the audio, so the audio was lost as well. Too bad, really.

      --
      What is the difference between a small revolutionary change and a large evolutionary change?
    4. Re:Skeleton + by Keebler71 · · Score: 1

      Wow, it is a really good thing the author had a short name (Eric Ball)... can you imagine trying to make a title screen with "by Michael Rosenbaum" using 80x40 graphics?

      --
      "It takes considerable knowledge just to realize the extent of your own ignorance." - Thomas Sowell
  2. If i ran a software firm... by 222 · · Score: 4, Insightful

    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.

    1. Re:If i ran a software firm... by Anonymous Coward · · Score: 0

      Some new homebrews are even only 1K in size. Check the AtariAge forums and search for e.g. Splatform and Cave1K.

    2. Re:If i ran a software firm... by Blrfl · · Score: 2, Interesting

      I call it "getting back to the basics." Anybody who's successfully coding good games on the 2600 has a bright future in the embedded systems world, where limitations like that are commonplace. The current crop of small microcontrollers (PICs and the like) have similar constraints, and cleverly-designed software is landing them in all sorts of places.

      Don't take this personally, but that fact that people are staggered by things like this worries me. Limitations were what we had back then, and we dealt with it, in the snow, up hill, both ways. :-) The cheap and ever-expanding supply memory and disk is, I think, one of the reasons software has become as bloated as it is. We went to the moon on systems with less combined horsepower than a 1996-model Palm Pilot, and I think it would do wonders for this business if more people understood what made the machines they programmed tick at the lowest levels.

  3. Oy by NeoPotato · · Score: 5, Insightful

    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.

    1. Re:Oy by sporty · · Score: 5, Funny
      Do they just assume we're not going to read the article...


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

      -
      ping -f 255.255.255.255 # if only

    2. Re:Oy by Anonymous Coward · · Score: 0, Funny
      All your "new heres" belong to SOVIET BSD is YOU FAIL IT!

    3. Re:Oy by Anonymous Coward · · Score: 2, Funny

      No, but he is!

    4. Re:Oy by NanoGator · · Score: 1

      "What's with people ripping off the first paragraph and submitting it as their text?"

      If I were the type to submit stories, I'd do that too for the simple reason that I have read a NUMBER of articles where the submitter of the story really didn't get the point of the article at all. Is it really so bad? (I'll concede, though, that they should at least give credit to where they got the text...)

      " Do they just assume we're not going to read the article, and are therefore being clever, or are they just lazy? "

      Maybe they're covering their butts in light of the eventual Slashdotting?

      I guess the real question here is, what's the BFD? Why are you complaining?

      --
      "Derp de derp."
  4. My first Atari game by jabbadabbadoo · · Score: 1, Funny

    Those were the simple days... here's my first game. I called it "Watch the aliens locking down your Atari" 10 PRINT " -^- " 20 GOTO 10

  5. This is passion at it's finest by beacher · · Score: 4, Interesting

    "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...

    1. Re:This is passion at it's finest by Stween · · Score: 5, Insightful

      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!]

    2. Re:This is passion at it's finest by Anonymous Coward · · Score: 0

      What is all the portability for? In the end 99,9% of the products end up running on Wintel. I think that it would still be nice to have software developped in Assembly language, and it would even be profitable, but this goes against current market practices, that require cheap programmers (even if they are not too skilled), and short development periods. If the product is just rubbish it does not matter because publicity will do its job and it is not expected to last beyond next Christmas when it will be replaced by another similar product. The problem is that this same philosophy is being used when developing business products, that affect the productivity of working people, and the results are quite obvious. But this is how Gates became one of the richest men on Earth, so this must be the way to go.

    3. Re:This is passion at it's finest by tomstdenis · · Score: 2, Informative

      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

      --
      Someday, I'll have a real sig.
    4. Re:This is passion at it's finest by Anonymous Coward · · Score: 2, Insightful

      Well, since it's so limited, you only need to write 4K of code to make a game. This very limitation makes 2600 game development a more reasonable hobby than development on anything more modern... For one, there's lot less code to write so you do not have to spend much time on a complete game. Second, since it's a challenge to make everything fit, even the boring parts of the game become challenging as you simply have to optimize them for size. Thus, you get a limited amount of highly challenging thinking, and yet the end result can be a truly amazing game by the standards of the platform.

    5. Re:This is passion at it's finest by Richard_L_James · · Score: 1

      The bloat problem as I see it is that disk/memory now appear to now be so plentiful that many developers think nothing of throwing Mb's of GFX and FMV into a game usually at the expense of gameplay. Am I the only person who remembers when programmers were taught to implement functionality/gameplay first and worry about tarting the user interface up later?? What happened?

      The very active C64 development scene is one place where I don't think dust has ever had a chance to settle.... amazing stuff. If you have a S60 mobile then I recommend checking out Hannu Viitala's excellent Frodo S60 port of Frodo works suprisingly well on a Nokia 3650 :-)

    6. Re:This is passion at it's finest by Anonymous Coward · · Score: 0

      Portability?

      There are many titles that are released for multiple systems. These systems just happen to be the various gaming consoles and the generic Wintel systems.

    7. Re:This is passion at it's finest by IncohereD · · Score: 3, Insightful

      What is all the portability for? In the end 99,9% of the products end up running on Wintel. I think that it would still be nice to have software developped in Assembly language, and it would even be profitable, but this goes against current market practices, that require cheap programmers (even if they are not too skilled), and short development periods.

      Optimize last?? Hello?? Have you taken any programming courses?

      How real, optimized engines are written (i.e. Quake, Doom, Unreal) is by:
      - writing it first in a 'high' level language (probably C, which isn't high any more, but you get the picture)
      - making sure it works
      - finding out what parts are slow
      - optimizing these in assembly, and making sure they get the same results as the slower, easier to debug version.

      Writing the whole thing in assembly would just be ludicrous. Did you ever use the first version of wordperfect for windows?? Written in assembly, and boy was it buggy. And not noticeably faster than anything else.

      If you optimize first you will never get anywhere meaningful.

    8. Re:This is passion at it's finest by LWATCDR · · Score: 1

      " What is all the portability for? In the end 99,9% of the products end up running on Wintel."
      Why do you want portablilyt??? Do you want to have to check to see if you your game will support you video card and sound card? Yes there was a time when you had to make sure that a game you bought would work with your video and sound card. And I do not mean will they be fast enough but will they work period! It was a major pain in the rear that still has not gone completely away.
      As to developing in assembly. That is one of the truly bad ideas. It is much harder to debug, add new features, and support Assembly. It is also not needed for the most part. Compilers do a great job at code generation. I would bet they are better than most "good" assembly programers not as good as the great ones but still very good. Yes assembly is useful for thing like the embedded market and for small time critical parts of systems. It is not how you should go about developing any large system.
      If you want to safely program down on the hardware then go into console development or embedded systems.

      PS more than .1% of computers out there run MacOSX or Linux. If you are talking about games then the PC is an even smaller part of the market when you take in account all of the PS/2s, Gamecubes, and GBAs.

      --
      See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
    9. Re:This is passion at it's finest by ClosedSource · · Score: 1

      What I find interesting is that today's more capable hardware makes Atari 2600-style programming impossible. For example, a cache will increase average performance, but destroys timing consistency. The ability to determine exactly how many cpu cycles a section of code will use is critical to progamming the 2600.

      Today, real-time software is a fading art. The good news is that the real-time stuff has migrated to hardware so even OS's with non-deterministic timing like Windows and Unix/Linux can particpate in at least modest real-time applications.

    10. Re:This is passion at it's finest by Orien · · Score: 1
      You have a point, but I have to agree with ESR when he said:
      "To behave like a hacker, you have to believe that the thinking time of other hackers is precious -- so much so that it's almost a moral duty for you to share information, solve problems and then give the solutions away just so other hackers can solve new problems instead of having to perpetually re-address old ones."
      Original reference here. I think this is the whole foundation behind the kind of abstraction that software development takes today. For example, the low-level details behind network communication, and making a socket connection to a database server -- all of that has been worked out, tested, debugged, secured, re-done, etc. by other developers already so that we can focus on the task at hand and just issue a command like mysql_connect(); It doesn't make any sence to be constantly re-inventing the wheel when you write software. If we did, we would spend too much time solving the old problems to make any real progress. For the security benifits alone it is worth it. Every layer of computer action can open it's own security holes, and if you re-use someone else's code you don't run the risk of opening up a hole that was already found and patched by someone else. There is something to be said about fighting bloat, but I am definately a fan of abstraction.
      --

      SCO.com uses Linux

    11. Re:This is passion at it's finest by LocalH · · Score: 1

      Depends on what the software is.

      For example, Steve Gibson codes in ASM. But the stuff he codes isn't tied to hardware.

      For games, and C64-style demos, ASM on the PC is useless. There's too much hardware, and too many different CPU speeds, to utilize such tricks as counting cycles, hitting the hardware at just the right point on the screen, etc.

      I'd like to see some more homebrew shit done on the Genesis. It's got good hardware, a decently fast CPU, and a very nice FM part that gives 6 FM channels, or 5 FM channels and a DAC.

      --
      FC Closer
  6. Dedication or masochism? by Xargle · · Score: 4, Funny

    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.

    1. Re:Dedication or masochism? by Anonymous Coward · · Score: 1, Funny
      No accounting for taste, I suppose.

      your the one who mentioned Celine Dion.

  7. Good Article! by Bender_ · · Score: 5, Informative

    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.

    1. Re:Good Article! by bsDaemon · · Score: 2, Funny

      and that is no different than php hacking?

    2. Re:Good Article! by csirac · · Score: 2, Insightful

      Obviously... it has no framebuffer, that's incredible. It couldn't have a framebuffer even if it wanted to, unless you only wanted 16x8 resolution.

      And I thought C64 coding was hardcore... 128 bytes of total RAM? Just writing a character generator would be challenging, let alone a game!

    3. Re:Good Article! by JanneM · · Score: 5, Informative

      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.

      --
      Trust the Computer. The Computer is your friend.
    4. Re:Good Article! by csirac · · Score: 1

      Most microcontrollers today look similar, with what seems like a ridiculously low amount of RAM compared to ROM.

      That's true, but the only MCUs I've worked with that have this little RAM is the PIC 16F/16C, and I couldn't have imagined driving a TV with one of those.

      The current MCU I'm working with is a MC9S12 with 12KiB SRAM/256KiB FLASH... I feel so dirty :-)

    5. Re:Good Article! by StormReaver · · Score: 3, Informative

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

    6. Re:Good Article! by Emil+Brink · · Score: 2, Interesting

      I couldn't have imagined driving a TV with one of those.
      Imagine harder! ;)

      --
      main(O){10<putchar(4^--O?77-(15&5128 >>4*O):10)&&main(2+O);}
    7. Re:Good Article! by Anonymous Coward · · Score: 0

      Don't forget that you also had a quite large BIOS inside the VIC.

    8. Re:Good Article! by ClosedSource · · Score: 1

      The bank-switching capability was not part of the 2600 design. It was a feature that was added to the cartridge hardware toward the end of the 2600 era. Each big-game vendor created their own unique implementation. Bank-switching was required for games larger than 4K due to the fact that the 6507 only had 13 address lines and 1/2 of the address space was reserved for hardware devices (note also that all ROM was in the cartridge, the 2600 unit has 128 bytes of internal RAM and 0 bytes of internal ROM).

      Some of the big-game cartridges contained RAM as well as ROM and those had to bank-switch on 2K boundries since 1 address line had to be used to differentiate reads from writes (no R/W line was brought out to the cartridge port). This sometimes led to some interesting bugs because an incorrectly formed address could read bad data and write bad data in a single instruction.

      I agree that the lack of a framebuffer was the defining limitation, but its implications are very broad. About 90% of your code and processing time in the 2600 was dedicated to drawing the screen with only 10% for gameplay. Horizontal positioning was based on time rather than position. Your display routine had to have consitent timing or the picture would roll. The implications go on and on.

  8. The book "Hackers" by Henrik+S.+Hansen · · Score: 4, Informative
    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.

  9. I want an OLED for my Atari Lynx by Anonymous Coward · · Score: 3, Funny

    The resolution is great but so flickery bright that it hurts my eyes. I sure would like to have a screen upgrade to OLED so I can play it again, it would also increase battery lifetime.

    Why? Well two-player Lemmings sucked on my Atari ST, it's not available for my 2600. Wait that would also mean that I need a Lynx bluetooth module as I can't be bother to hook up wires :-)

    Dennis

    1. Re:I want an OLED for my Atari Lynx by kiddygrinder · · Score: 2, Insightful

      If you want to play 2 player lemmings, get an amiga, it's the only way to play

      --
      This is a joke. I am joking. Joke joke joke.
  10. Damn it by Anonymous Coward · · Score: 5, Informative

    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

    1. Re:Damn it by csirac · · Score: 4, Interesting

      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?

    2. Re:Damn it by Peale · · Score: 1

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

      They get removed anyway. Even if you post as an AC. Unless you delete your /. cookie.

    3. Re:Damn it by Anonymous Coward · · Score: 0

      Nope, read that again: "From another machine". No cookie.

    4. Re:Damn it by 8tim8 · · Score: 1

      They get removed anyway. Even if you post as an AC. Unless you delete your /. cookie.

      Wow, the cookies will follow me from machine to machine, somehow knowing that it's me that's posting? Slashdot coders are amazing!

    5. Re:Damn it by Peale · · Score: 1

      D'oh! Missed that. *inserts foot into mouth to keep from speaking*

  11. MOD PARENT UP! by Anonymous Coward · · Score: 0

    Moderators on crack!

    How the fuck is the parent off-topic??! For your information, moderators: Sierra made Atari games back when they started.

    Get a fucking grip, and stop modding something down you obviously don't know a goddamn thing about!

  12. If you ran a software firm... by Anonymous Coward · · Score: 0

    You would be chapter 11 in 6 months

  13. Hmmmm.....time did advance, right? by mousse-man · · Score: 2, Interesting

    If a machine has 128 Bytes of RAM, I'm wondering how one can even program a game that is remotely fun by yesterday's (1985) standards. Let's see - 1 frame on TV needs:

    - 320x240 pixel or 76800 pixels. Let's say every one of these pixels has 2 bits (acceptable by 'yesterdays' standards. So alone to hold one frame in an accepatble resolution and color depth, one needs some 19200 bytes of RAM. If one looks at the 2600, we're far away from that, even if we say we can divide that by four since the Atari most probably had some area-drawing commands like any other hardware.

    I have a C64 which at least capable to display that. OTOH, there are people who are complete minimalists and will be able to think that an Atari 2600 is fun, and since Atari games look even worse than C64 games and have less gameplay, they can live with even less resolution.

    1. Re:Hmmmm.....time did advance, right? by Anonymous Coward · · Score: 1, Insightful

      That's what the ROM is for.
      You can bank-switch roms to get more than 4kb too.

    2. Re:Hmmmm.....time did advance, right? by phozz+bare · · Score: 1
      - 320x240 pixel or 76800 pixels. Let's say every one of these pixels has 2 bits...

      320 pixels width? Area-drawing commands? You did read the article, right? Sheesh.

      The Atari 2600 does not have a display buffer! Everything is generated on-the-fly, as in, while the TV raster scanner is doing its thing. It's also apparently impossible to get anything better than 40 pixels of resolution for the "playfield" graphics (as opposed to the sprites which are finer resolution).

      Where did your "320" value for horizontal resolution come from? Even the Atari 800, which was light years ahead of the 2600, could only do 160 pixels across in color.

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

    3. Re:Hmmmm.....time did advance, right? by ClippyHater · · Score: 2, Informative

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

    4. Re:Hmmmm.....time did advance, right? by phozz+bare · · Score: 4, Informative
      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.

    5. Re:Hmmmm.....time did advance, right? by Zak3056 · · Score: 1
      RTFA.

      The amount of RAM one would need for a framebuffer is immaterial: the 2600 doesn't have one. Everything is generated on the fly.

      Besides the 2600's limited amount of memory, homebrew game developers say that the most difficult aspect about writing software for it is dealing with its display kernel. Since the system lacks video RAM, each scanline must be programmed directly. The picture on the screen has to be drawn in synchronization with the video beam, which can be a tricky feat to pull off, and there are only 76 CPU cycles per scanline. The game code must also control vertical synchronization, repositioning the electron beam at the top of the screen to start a new frame.


      --
      What part of "shall not be infringed" is so hard to understand?
    6. Re:Hmmmm.....time did advance, right? by Anonymous Coward · · Score: 0

      "Fun" == "screen resolution"?

      Damn kids these days.

    7. Re:Hmmmm.....time did advance, right? by Trevin · · Score: 1

      Actually it wasn't so much that different TV's produced different colors, but different *TIA chips produced different colors. Specifically, some early Atari demos (I forget which one - it displayed an image of the Atari 800 and monitor) and games (Choplifter, Beneath the Pyramids) were written expecting the artifacting colors to be orange and cyan (or red and blue), which was the case on the CTIA chip. Later on Atari replaced the CTIA with GTIA, whose luminance signal differed from the former chip by 90 degrees, resulting in artifacting colors of green and magenta. I have detailed notes about this at http://www.xmission.com/~trevin/atari/video_notes. html.

  14. Color pictures could revolutionize the 2600 market by Anonymous Coward · · Score: 1, Funny

    I know the 2600 market collapsed in the eighties but there is a bright light on the horizon. If you read the article you'll learn that in 2003 they found a way to display color pictures on a 2600! By flickering three dithered bitmaps your eyes will blend the the red green and blue lines into a color picture. Do you know what that means? Strippoker could be released on the 2600, and we all know which industry drives sales of computer inovations!

    Color pictures will revolutionize the 2600 market. I can't wait for the Hilton Cartridge, this will be so much better than that hentai stuff on the NES.

    Dennis

  15. I've done this! by pngwen · · Score: 5, Informative
    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
    --
    I am the penguin that codes in the night.
  16. Strong Bad by Xenographic · · Score: 1

    Speaking of good Atari games, wasn't there a Slashdot story about a Strong Bad Atari game recently?

    What ever happened with that? Last I knew they were still only a demo...

    Heh, I still remember that Mario game on Atari where you hit that POW! block to knock enemies over and there was a 2-player mode vs. each other. That was always one of my favorites (at least, among the original non-homebrew games). Ironically, when I got it, I thought that it was the same Mario game as on the NES (which I didn't have yet) and so I was surprised... :]

    1. Re:Strong Bad by Paul+Slocum · · Score: 2, Informative

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

    2. Re:Strong Bad by LocalH · · Score: 1

      It WAS the same Mario game as the NES - called Mario Bros. There were several versions of Mario Bros., notably for the C64 and even the Apple II. And also an arcade version (of which the second, German-only NES release even bested).

      Of course, if you were thinking of SUPER Mario Bros., then you're right.

      --
      FC Closer
  17. Atari Age by future+assassin · · Score: 1

    AtariAge.com

    --
    by TheSpoom (715771) Uncaring Linux user here. I have nothing to add to this but please continue. *munches popcorn*
  18. *sniffle* by atari2600 · · Score: 2, Funny

    I've been waiting for this article for years and now it is finally up, i am at a loss for words *sniffle*

  19. Doesn't the 2600 have a line buffer? by baywulf · · Score: 3, Insightful

    I thought the 2600 had a line buffer. Basically a 40 or 80 bit shift register into which the pixels are written and then they are written to the video screen. This is my recollection from a presentation that the creator of the 2600 (the same guy who did the Amiga I think) had on the hardware internals.

    1. Re:Doesn't the 2600 have a line buffer? by Anonymous Coward · · Score: 2, Informative

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

  20. i grew up playing and loving the 2600 by kraksmoka · · Score: 1
    but when i read lines like:

    "There's nothing like playing a game on the real hardware using real controllers -- emulators can only get you so far," says Grand.

    Get you so far where? ? ? ?

    I mean, I'm a guy who owns a damn apple newton and a next cube (anyone wanna buy a next cube?) and at least i had minorly practical reasons for getting each way past their prime, and have even gotten some use out of the newton (cube is a Damn Fine Paper Weight)

    sorry, but if it sounds to me too much like the geek version of sucking a tit, so sue me.

    i'm really not trying to troll, and this is my first post to /. in a few months, but come on guys! I even agree that gameplay suffers when games have more eyecandy than fun, but. . . . . . . . . .

    --
    "You never want a serious crisis to go to waste." - Rahm Emanuel
    1. Re:i grew up playing and loving the 2600 by 0racle · · Score: 1

      I'd like that NeXT system.

      --
      "I use a Mac because I'm just better than you are."
    2. Re:i grew up playing and loving the 2600 by kraksmoka · · Score: 1

      send me some email. it works just fine, fires up and runs. just don't have space for it any more. grant(nospam)@grantstern.com

      --
      "You never want a serious crisis to go to waste." - Rahm Emanuel
  21. True classics live forever by Alwin+Henseler · · Score: 4, Interesting
    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!

  22. I made JoustPong 2600 and "2600 101" link by kisrael · · Score: 2, Insightful

    I actually made (and published through AtariAge) my own Atari homebrew, JoustPong -- Pong with a Flap Button. I kept a developer's journal of the experiece.

    I also made a newbie's tutorial, linked to at the end of the O'Reilly article: 2600 101. And currently I'm (slowly) working on 2600 cookbook...O'Reilly fans should find the format very familiar.

    Overall, that's a great techie introduction to the hobby.

    --
    SO YOU'RE GOING TO DIE: The Comic for Dealing with Death
  23. 2600 Games for sale now by Zachary+Kessin · · Score: 1

    I was in the Office Depot in the Jerusalem Mall the other day, and I saw what looked like an original 2600 joystick. It appears like they took an old 2600 system put it on the joystick base with a few of the old games and are selling them as is. I think it was about 150 NIS (~$3) but as I don't have TV to hook it to, and don't play many games anyhow I didn't look to closely/

    --
    Erlang Developer and podcaster
    1. Re:2600 Games for sale now by tuffy · · Score: 2, Informative

      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.

      --

      Ita erat quando hic adveni.

  24. Why were there no analog joysticks? by RenaissanceGeek · · Score: 4, Interesting
    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?

    --
    What is the difference between a small revolutionary change and a large evolutionary change?
    1. Re:Why were there no analog joysticks? by ps_inkling · · Score: 1
      There was a console system with analog joysticks -- the Atari 5200.

      However, they were quite horrible to use, keep centered, and had a fairly short usage period. Now, if you can get ahold of a Wico 5200 joystick (and the Y-adaptor cable to use the 5200 controller's keypad), the console was much nicer.

      In most cases, it's possible to simulate the analog movement (slow, then faster in the same direction) using digital controls and not-terribly sophisticated timing loops.

      Reading two paddle values on a 2600 means taking time out of your drawing loop to check if the capicator has dischaged through the variable resistor yet. For the games which you would like an analog joystick (flight simulation, sports movement, etc.), it would mean less cycles for setting up and displaying complex graphics.

      For the game Indy 500, a special driving controller was made which used a two-bit Hamming code to sense the position and direction of the controller.

      By the way, here's one game that can use an analog joystick. Control a marble in a labyrinth.

    2. Re:Why were there no analog joysticks? by ps_inkling · · Score: 1
      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.)
      Already done. Even has two-player mode.
    3. Re:Why were there no analog joysticks? by RenaissanceGeek · · Score: 1
      Interesting: can you give me a link to more info on the functionality of the driving controller?

      (My Google-fu is low, and all I can think of is a 4-bit encoder: 16 possible positions, which would be lousy.)

      --
      What is the difference between a small revolutionary change and a large evolutionary change?
    4. Re:Why were there no analog joysticks? by ps_inkling · · Score: 1
      Interesting: can you give me a link to more info on the functionality of the driving controller?

      Quadrature Encoding (complete with picture)

      The signals from the controller make it look like the user is pressing left, then left-down, then down, then off. In fact, in a pinch you can use the joystick to simulate a driving controller (not recommended).

      In the game, you keep the previous state of the left and down bits and compare with the current state. If the states are different, and table lookup gives the direction the user rotated the controller. At 60 times / second, it's fairly accurate.

      A four-bit encoder would have been possible, but the manufacturing tolerance would have been more expensive to implement.

      Searching Google for '2600 driving' returned this link in the top 20.

  25. Re:Obligatory Troll by Anonymous Coward · · Score: 0

    When would I get my cartridge with Doom III?
    sheesh!
    don't you already have it??

  26. Mmmm, speaking of homebrew 2600... by ghost1911 · · Score: 2, Interesting

    I don't know if it's emphasized clearly enough in the article, but Homestar Runner has commissioned a few homebrew 2600 coders to make their own game... Imagine the precedence that this could set, IMHO, this is along the same lines as the Counterstrike modders getting published by Sierra (err Valve?)..

    Imagine... homebrew people getting paid for their hobby... I think that wired magazine's mention of this makes it a little more interesting: homebrew games are becoming available on a grander scale than just for those in the scene.

    --
    .: 2+2 = PI SQRT(1+N) :. All together now, what is n?
  27. There's nothing wrong with by jolajolajola · · Score: 1

    sitting on broken glass whilst being branded with hot pokers.

    --

    --
    The trouble with pedants is that they're always right.