Ed Fries Creates Halo for the Atari 2600 VCS!

Bill Loguidice's picture

Halo (Atari 2600)Ed Fries, who was vice president of game publishing at Microsoft during much of the Xbox's lifecycle and helped in the acquisitions of Ensemble Studios, Rare - and perhaps most importantly - Bungie Studios, has developed the unexpected--a version of the latter's hugely popular Halo series for the legendary Atari 2600 Video Computer System (VCS). Fries' recounting of the story is copied below. For more details, see the thread on AtariAge, where you can download the ROM for use in your favorite emulator or for transfer to your favorite flash cart for play on the real thing. There's also a browser-based emulator available, as well as an official Facebook page.

"Last fall I was in Philadelphia, speaking at a small video game conference. On the way to the airport I was talking about writing games for the Atari 800 in the early 80s and someone suggested that I read the book "Racing the Beam" about programming the Atari 2600. It sounded cool so I did.

After reading the book I thought it might be fun to play around with writing some of my own code for the machine. I hadn't written 6502 assembler in almost 30 years but it turns out it's pretty easy to pick up again since there are so few instructions. I wasn't sure what to write so I created a little Master Chief from Halo and made him run around the screen. Then I created an Elite for him to shoot at. At this point it wasn't my intention to make a full game. I was just screwing around.

The thing you need to realize about the Atari 2600 is that it is an incredibly limited machine. It has only 128 bytes of RAM and without bank switching the maximum program size is just over 4000 bytes. There are just two 8 pixel wide monochrome sprites, two one pixel bullets, a "ball" and a 40 pixel wide background (and even that is exaggerating...). There is no memory to store the screen image like any modern console or PC, instead it has to be drawn a line at a time by changing the values of the registers that control the sprites and background. The processor is so slow that only 76 clock cycles occur while a line of the screen is being drawn, and the simplest 6502 instructions take at least 2 clock cycles. So just to draw an image of the Master Chief is pretty tough. To create a complete game while living within these constraints is much harder.

Fortunately the Atari homebrew community has created a wealth of resources for the wanna be Atari 2600 programmer. There is a fine assembler and several excellent emulators that include all the debugging features any programmer would want. There are also hundreds of pages of example code and documentation to aid you on your quest.

As I became more familiar with the machine I thought it might be possible to make something that was actually fun to play. I also ran into some fans of classic games at the Game Developers Conference in March and they encouraged me to keep going and try to make a finished game. At first I had the player battling through a linear series of rooms. You had to kill all the enemies before it would unlock the walls and let you move to the next room. As you can imagine, this got dull pretty quickly. I was doing it this way because it was relatively easy on the Atari 2600 but what if, instead, I could make a 64 room map the player had to explore, kind of like the old atari game Adventure? To implement this would require that I make an "asymmetric playfield" so that some rooms might have a wall on one side but not on the other. It turns out that's pretty tricky to do on the 2600, at least while you are trying to drawn everything else you want to draw, but I managed to get it working.

I was still worried there wouldn't be enough variety so I created a completely separate kind of level where you were driving a Warthog (jeep from Halo) across a rolling terrain while Banshees circled overhead and dropped bombs. But as I progressed on this I realized it had two problems: First it was too large. I had given myself the limit of 4K for the entire game and my Warthog section was over 1K by itself and it wasn't complete. Second, it wasn't fun. So I cut the Warthog level and tried to focus on making the core game more fun.

To add variety I divided the map into 4 "zones": outdoor, covenant base, ice world, and final boss area. Each had a unique look and some unique enemies. I also played with the atari's ability to stretch and duplicate sprites to create some further surprises for the player. Then I added some pickups the player could find to help them on the way.

At the end of the map I wanted to have a Boss encounter. This posed several problems. First, bosses are supposed to be BIG. How to get that feeling across in my game? Second, it had to be exciting. How could I make the boss encounter different from the rest of the game? I solved the first problem by writing a special Boss kernel for the final room. The rest of the game has what is called a "two line kernel" which means that all pixels on the screen are two scan lines high. What if I switched to a one line kernel for the Boss encounter? That would make the Master Chief half as tall which would you feel like you just walked into a big room and the camera zoomed out to be able to show the boss. Of course this meant I had to do all the processing in one line (only 76 cycles...) instead of two, but I had written the Warthog section with a one line kernel so I knew it was possible for me to do it.

To make the encounter different I made a single large boss that moved up and down the screen. He uses the maximum sprite width to be wide and is 24 pixels tall compared to 12 pixels for my other sprites. I also wanted him to be able to shoot 3 missiles at once. Of course that was a problem because the atari only supports 2 missiles and I need one for the Master Chief to be able to shoot back. I solved this by "multiplexing" the enemy missiles which basically means if there are 3 missiles on the screen I draw one each frame for three frames. That has the effect of making them flicker a bit but it's not bad for fast moving missiles. The great thing was once this was working for the Boss I could also use it in the rest of the game. Up to this point only one enemy could fire at any time because there was only one bullet for them to share, but now they could each have their own virtual bullet and fire whenever they wanted to.

At this point the rough outlines of the game were complete but it needed a lot of polish. For one thing it was brutally difficult. One of my playtesters convinced me to add three lives instead of the original one. Another convinced me that running into trees shouldn't kill you, and another finally got me to make the walls not kill you if you accidentally ran into them. I added the title screen at this time but had some pretty spastic stars which another playtester finally convinced me to clean up. I also added sound effects and a bit of the Halo 2 theme song on the title screen.

All of these changes were made extra difficult because I was completely out of space. Every time I wanted to fix a bug or add a new sound effect I had to go back through the code and rewrite some part of it to do exactly what it was doing before but with fewer bytes of code. At first there were some pretty easy ways to save space but, as you might imagine, this become more and more difficult when I was staring at something I had already rewritten two or three times before.

When a playtester complained that there was nothing after defeating the boss, I added legendary mode, so that if you beat the game you can play all the way through it again with a few parameters tweaked to make it much tougher.

It's around this time that I discovered the existence of what I call "Magic Land". I was working on a bug with the boss encounter and accidentally found myself completely outside the 64 room map. I was wandering through memory that was never intended to be interpreted as part of the map but the code was doing the best it could to interpret what was being thrown at it. Strange, misshapen monsters attacked me in even stranger ways as I wandered through this bizarre land that I had unintentionally created. I left a bug or two in the final game to allow others to find and explore this strange landscape as I did.

One of the last changes I made has to do with the Atari 2600 HMOVE (horizontal move) register. Basically if you want to reposition a sprite horizontally while the screen is being drawn (something I was doing 3 times on every screen.) you have to store a value into HMOVE. You are supposed to do it as the first thing on a scan line and a side effect of doing it is an ugly black line about an inch wide on the left side of the screen. You'll see those black lines on almost all Atari games. In the old days it was kind of hard to see on a phosphor TV display, but on a modern TV or computer monitor it's quite clear. Some games hide it by having a black background (not something I wanted to do) or by doing it every single line so the entire left side of the screen is black (also not great for the look I wanted), so I had kind of accepted that it was inevitable and had learned to ignore it, but every time I showed the game to someone who wasn't familiar with Atari games, one of the first things they would ask me is "what are those ugly black lines?"

When reading through some documentation I noticed that it was possible to do an "early HMOVE" which involved storing to the HMOVE register a few clock cycles before the beginning of the scan line and that in that case it didn't act the way it was supposed to (things moved in a funny way) but if you could do it exactly on the right cycle (cycle 74 in my case) then the black line wouldn't ever appear on the screen. I wrote a simple test program with ducks moving back and forth on the screen to prove to myself that I could compensate for the crazy behavior caused by this early HMOVE, make the ducks move as I wanted them to, and never have to see that ugly black line. That gave me the confidence to go back into my main kernel and implement the early HMOVE in Halo 2600 to get rid of the black lines for good.

That's pretty much the story. I couldn't have made the game without the incredible resources available on AtariAge.com and the many websites it links to. All the work you see in the game is mine except for some of the sprites which were drawn by Mike Mika who was a great encouragement and aid throughout the process. Chris Charla, Colin Williamson, Tom Russo, Ian Bogost, and Albert Yarusso all helped me by playtesting and by trying to talk sense into me when I was being stubborn about not fixing some glaring issue.

I hope you have as much fun playing Halo 2600 as I had making it.

-Ed Fries"

Comments

Matt Barton
Matt Barton's picture
Offline
Joined: 01/16/2006
Wow! All that inspiration

Wow! All that inspiration from Racing the Beam. Now I really must get around to reading it!

n/a
Bill Loguidice
Bill Loguidice's picture
Offline
Joined: 12/31/1969
What I love in terms of Atari

What I love in terms of Atari 2600 game development is that it has among the best supported and certainly the most accessible programming environments for a classic console in batari Basic: http://bataribasic.com/ . Even though it's a BASIC-like language, it does in fact allow you to create commercial quality (by 2600 standards, of course) games (though of course Fries being old school went straighter to Assembly). Similar initiatives are being attempted on other classic platforms, but for the most part and certainly at present, you need to know C or Assembly language in order to program for them. In any case, I personally hope that someday I'll have the time to be able to create my own Atari 2600 game.

n/a
Matt Barton
Matt Barton's picture
Offline
Joined: 01/16/2006
It's actually a pretty fun

It's actually a pretty fun game!

It seems like one issue with homebrew is purity. I'm sure there must be a lot of discussions out there about whether using modern tools and hardware is really cheating. I was noting that some of the homebrew carts contain more memory or such that start to beg the question of whether it's really something that would have been possible or feasible back then. If that's not an issue, then why bother with the vintage hardware at all? I'm having a hard time articulating what it is that's bothering me, but if you set out to make an Atari 2600 game, I'd try to limit myself as much as possible to what was available at the time period.

n/a
Bill Loguidice
Bill Loguidice's picture
Offline
Joined: 12/31/1969
Jack Handy Response
Matt Barton wrote:

It's actually a pretty fun game!

It seems like one issue with homebrew is purity. I'm sure there must be a lot of discussions out there about whether using modern tools and hardware is really cheating. I was noting that some of the homebrew carts contain more memory or such that start to beg the question of whether it's really something that would have been possible or feasible back then. If that's not an issue, then why bother with the vintage hardware at all? I'm having a hard time articulating what it is that's bothering me, but if you set out to make an Atari 2600 game, I'd try to limit myself as much as possible to what was available at the time period.

Well, it would be foolish not to use modern development tools to make homebrew games. The bottom line is is that the original developers did this as their living, whereas homebrewers do it as a spare time hobby, so they need every advantage they can get, including "unlimited" time.

Ed Fries Halo creation is straight up old school, meaning it was developed in a fairly standard way and only requires a 4K cartridge, which was nothing special even by early 1980's standard, so in the case of that, you should have no particular ill feelings.

It's true that depending upon the platform, the cartridges can contain more RAM or storage space to make games that wouldn't have been financially feasible back in the day (the homebrew Pac-Man games for either the Fairchild VES or ColecoVision is a good example). However, it still requires a tremendous amount of talent to code for these systems, and the best homebrew developers today would likely have been superstar developers then. Today's homebrew developers are standing on the shoulders of those who have worked on these platforms since the early 80's (or in some cases, mid- to late-70s), and have learned many, many lessons as a result. Time can be an enemy, but in some cases like these, it can be a friend, particularly in regards to knowledge gained.

The best way to look at it is if these platforms never really went away. Compare, for instance, an Atari 2600 game from 1987 to an Atari 2600 game from 1977. It's like they're two different systems. Part of that is that it was too costly to make larger than 2K games in 1977, and part of it was simply gaining experience with the platform. Now imagine that the Atari 2600 wasn't discontinued in the early 90's. Imagine that it was kept on the market and new games were continuing to be made for it. Wouldn't the games in 1997 be technologically better in some ways than the games from 1987? Of course, through both a combination of learning MORE tricks and access to more memory. So if you have a psychological barrier to modern day homebrews that have advantages like mature dev tools, years of prior works to refer to, and unlimited time, consider that they also deal with the disadvantages of working on this on the side and without any type of financial backing. Consider also that even the most successful homebrews only sell a few hudred copies. That's a far cry from the hundreds of thousands or even millions that sold in the past. So yeah, it's different, but the underlying ideas and concepts are the same.

What *is* debatable, are the expansions that are pending for both the Atari 7800 and ColecoVision, for instance, each of which gives their respective platforms enhanced capabilities and will feature homebrew games that are ONLY practical with the expansions. Now that does in fact encroach on the purity of the original hardware, but again, if you're working from the idea that the crash never happened and these platforms continued to evolve and remain on the marketplace, these are STILL the types of things you would have seen. There's something special about technology of a certain vintage (say, pre-16-bit systems), and certainly I see nothing wrong with keeping that alive through maximizing the original hardware, something that just doesn't come across in emulation.

n/a
Matt Barton
Matt Barton's picture
Offline
Joined: 01/16/2006
Homebrew Purity
Bill Loguidice wrote:

The best way to look at it is if these platforms never really went away.

That is a good way to look at it and makes a lot of sense. I also see your point about the expansions. I guess there's a point where it's just a fiction that you're still somehow making games for a vintage platform--if it takes modern hardware to do it, I don't see how that's authentic. I don't claim to know what I'm talking about regarding the hardware and cartridge limitations, but again it makes more sense to me to do what Ed did. If you can't put the finished game on a regular cartridge (that is, a cartridge that would have been feasible while commercial games were still being made for the system), it seems little more than an exercise.

I could see myself making a game using Commodore 64 basic and then using emulator features to give me unlimited memory, warp speed, etc. However, that's obviously not authentic.

n/a
Bill Loguidice
Bill Loguidice's picture
Offline
Joined: 12/31/1969
What is your thought then on

What is your thought then on a game on a "super" cartridge that you could transport back in time to say, 1977, and would work without modification on the 1977 platform? Would that still be cheating? Not necessarily. It's still using the original platform and its inherent capabilities. You're not adding anything to it.

Even in that case, though, so what if you added capabilities on the cartridge? It's not like there wasn't precedent for that when these systems were mainstream. For instance, Pitfall II for the Atari 2600 included a custom DPC chip in the cartridge that allowed for four part harmonies. That was in 1984. Super Mario Bros. 3 (1988), one of the NES's most iconic games, included the Memory Management Controller 3 (MMC3) ASIC, which among many other enhancements, contained extra RAM that allowed for better diagonal scrolling. The NES and many other consoles were DESIGNED from the get-go to access extra registers via the cartridge port, making enhancements via cartridge a design feature. Anyway, those are just two of the more popular systems as examples--there are examples of that for nearly EVERY console system that accepted cartridges.

So again, just because homebrew authors have larger palettes to work on and sometimes better dev tools, it doesn't make what they're doing any less authentic. It's just the modern day way to keep these classic systems in new software...

n/a
Matt Barton
Matt Barton's picture
Offline
Joined: 01/16/2006
Comparison to Car Enthusiasts
Bill Loguidice wrote:

What is your thought then on a game on a "super" cartridge that you could transport back in time to say, 1977, and would work without modification on the 1977 platform? Would that still be cheating? Not necessarily. It's still using the original platform and its inherent capabilities. You're not adding anything to it.

I could compare it to the folks who love antique cars and such. I've known several of them, and there are at least three different kinds. One type insists on using nothing but actual vintage parts, made during the era when the actual car was produced. Another type will use modern recreations of vintage parts as long as they are accurate. The last, and I bet most common, type will use any compatible parts as long as they don't significantly change the look of the car. Thus you could end up with a car from the 30s with all of the conveniences of a modern car. I'm not saying any of these approaches is wrong or immoral, though there might be some debate from a historical perspective about authenticity and accuracy.

I could see applying similar logic to homebrew. You had mentioned some homebrewers who used actual recycled cartridges, for instance. I don't see anything wrong with using the advancements you described, either. But, yeah, if the technology didn't exist or wasn't feasible during the run of the machine, it strikes me as inauthentic, rather like putting a modern engine in an old Deuce coupe and bragging about how much better acceleration it gets than the coupes of the era. You see the point, I'm sure.

There's also a fun analogy I've heard in cases like this--consider an axe. If you release the blade, is it the same axe? What if you replace the handle? What if your place both? There is obviously a sense in which it is still the same axe, but it definitely a conundrum.

n/a
Bill Loguidice
Bill Loguidice's picture
Offline
Joined: 12/31/1969
I'm not sure that analogy

I'm not sure that analogy holds in the case of videogames. You can, in theory, JUST play the games that were made when the console was actively sold by the original manufacturer, just use the original controllers that it came with, just use the RF switchbox that originally came with it, and play it on an a TV created in that era. In the Atari 2600's case, that was roughly from 1977 - 1992, and if you stuck strictly to stuff from that time period, you'd be "authentic". However, that's presuming that videogames are "solitary" and "static" items, like your Deuce coupe. That might apply to a home Pong console with built-in games - it can only play, and was designed to only play the games it has built-in - but not to a device designed to play an infinity of new games and have things (typically controllers) plugged into its "expansion" ports.

Bottom line, new homebrews (and this applies to both software and hardware), no matter how they're made or with what materials they're designed, if they work on an original, unmodified system (in the 2600's case, going all the way back to 1977), then they're completely authentic, no matter how much they might relatively be tricked out. The development tools/environment don't matter either, because each company had their own setups anyway (again using the 2600 as an example), be it using terminals accessing mainframes, or even Apple II's. There's no "right way" to do it.

n/a
TripHamer
TripHamer's picture
Offline
Joined: 07/31/2010
Excellent!

Downloaded and going to check out.

n/a
Bill Loguidice
Bill Loguidice's picture
Offline
Joined: 12/31/1969
Pre-orders for a new batch of

Pre-orders for a new batch of "Halo 2600" cartridges are now being taken: http://www.atariage.com/forums/topic/167142-halo-2600-pre-order/

n/a

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Lines and paragraphs break automatically.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Images can be added to this post.
  • You may quote other posts using [quote] tags.

More information about formatting options

By submitting this form, you accept the Mollom privacy policy.