Slashdot Mirror
Atari 2600 Game Development
gjb6676 writes "An article over at ExtremeTech is covering recent game development projects on the Atari 2600. The amount of cartridge space they have to work with is a sobering thought:
'A two-word file in Word 2002, for example, requires 20 Kbytes. "That's 20 Kbytes, five times the amount of (ROM) space developers had to work with in the 2600.'"
* 2D paddle motion
* horizontal or vertical brick orientation
* gravity in some modes
* "English" on the paddle/ball interactions
* single or dual player in competitive or cooperative simultaneous play
* sound effects (CPU generated)
* etc. etc.
Just before release, with 9 free bytes left, a bug was found. The initial fix would break the ROM barrier by 13 bytes. Yet another pass through the code doing the 4th or 5th optimization -- finally got it in and ended up with 11 free bytes.
Amazing what is possible in ASM but, boy, it was many 20 hour days!
So I understand those 'smallest executable' contests, but how much functionality does the executable really have? Or how much of the Word document is really information?
For most purposes, 355/113 is close enough.
It seems to me that the Programming for the Atari 2600 is like working a Chinese Puzzle. Previously, I've wondered why not write new titles for MAME? It's available on multiple platforms and probably not so hard to develop on since it's emulating newer architecture.
BTM
That was the turning point of my life--I went from negative zero to positive zero.
What's even more scary than the 4K ROM limit is the 128 bytes of RAM. Yes, 128 bytes. 6502 assembly is easy, and the Stella chip architecture was an amazing acheivement. Read the Stella Programmer's Guide (available here) to be truly amazed at what it took those guys to develop games.
In my game I'm just at the point where I have a playfield, a moveable player, and one missile I can shoot. And that took a lot of effort. You know you're doing hardcore software development when you have to count cycles to make sure you're not computing when the electron beam is actually being drawn. You have 2700 or so cycles to work with "above" the television image per screen for computation, and only about 48 for each scan line before you start messing up your game image because you're still doing computation. It's interesting because you're tied to the physical progression of the electron beam across the TV.
--- witty signature
Amen to that! I used to code x86 for demos and BBS intros, games etc and I was amused at the time to see simple C programs weighing in at 30-40 times the size to accomplish the same tasks ;-)
This is why I actually enjoy programming for mobile phones at the moment - some of them (eg the Nokia 7210) really force you to consider how best to utilise the available memory and CPU resources. Just try to allocate a back buffer and a couple of 128x128 images and you're looking at a crash. Memory fragmentation also comes in, as do memory block limits (some phones limit ANY object to 16K max due to the way allocation works). Swapping out stuff you don't absolutely need, and juggling data is required for anything beyond the simplest games. (Although some phones, such as the Nokia 7650 really spoil you with loads of RAM, I usually attempt to get things working on the worst case target before porting and adding the bells+whistles).
It's fun though!!
Code, Hardware, stuff like that.
I was the co-developer on the Atari 2600 versions of Jungle Hunt and Pole Position.
... but oh, what memories.
Yes, there were two players (8 pixel sprites) and two missiles (1, 2, 4, or 8 pixels wide, if memory serves.) And the "easy" way to set up a display line was to write the bitmap and position of the players and missiles during vblank.
However, there was an underhanded way of getting more than two players on a line, if they were separated by enough space (~12 pixels, if memory serves.) While the line is drawn, you keep track of where the "currently drawn pixel" is. When that location is just past the end of a player, you reposition the player to ~12 pixels ahead of the current position, and rewrite the bitmap. We (General Computer Company, a captive developer for Atari) could get up to 6 players on a line, if they were separated by enough distance.
Yes, I am dating myself
It's Linux, damnit! Pay no attention to renaming attempts by self-aggrandizing blowhards.
I hate people that talk about Word document bloat as if they know exactly what's going on when Word saves a document. "Look! A one word document takes 20KB! Word is crap!"
What people don't realize is that there's quite a bit of formatting information in there. Remember stuff like page size, margins, fonts used (sometimes fonts are compiled directly into the document - depending on your settings - so that when you send it to someone, they don't need those fonts to view it correctly). That's just global formatting. What about stuff like paragraph formatting? Font styles/sizes?
All of it can't come for 0 bytes, and maybe all of the above doesn't account for all 20KB, but I probably haven't touched on half the stuff that's there that people take for granted with a modern word processor.
You should never take life too seriously - You'll never get out of it alive.