Creating a game for Atari 2600 in 2022
I was born in 1997, just a year before Atari corporation was defunct and merged with JST storage (later acquired by Hasbro), a merger that would officially mark the end of an era.
Despite the fact that I am a bit young to own or even to have ever played games in an original Atari console, my sincere interest for this primitive era of electronics, video games and early home computers intrigued me to start collecting some of these devices. Soon, both an original (and fully functional) Atari 2600 and its successor Atari 7800 came into my possession, unlocking a truly marvelous world for me. The nostalgia and awe that one feels while playing in an original Atari is definitely considerable.
After a couple of months and having bought dozens of game cartridges from other fellow collectors, I was curious enough to start looking into more technical details and specifications like what CPU is it running on, how many bytes of RAM does it have, etc.
Being a software developer by profession, soon some reasonable questions emerged: How were Atari 2600 games programmed back in the days when it was commercially available ? Is it possible to develop a game for an Atari now? If I can, then can I transfer it (“burn it” as the electronics guys like to say) to an EPROM chip and create my own game cartridge?
With a bit of googling and after watching some videos on YouTube I managed to find the answers. It seems that it is very possible to code a game for Atari 2600 nowadays, then test and debug it in an emulator and then if you want, there are a couple of ways to play it in an Atari console too.
The tools
The traditional programming language that Atari 2600 games were written back in the 80’s is of course Assembly, and more specifically the Assembly 6502 instruction set. Atari 2600 was running on an 8-bit MOS Technology 6507 CPU which was part of the 6500 CPU family.
However, nowadays it is not mandatory to code in Assembly 6502 to create an Atari game and this is possible due to the magnificent effort of these guys who created Batari BASIC. A wrapper language that feels like the good old BASIC and complies to Assembly 6502. This site offers very detailed documentation and examples that helped me a lot during the development process.
On top of Batari Basic, another awesome guy created a VS Code extension called Atari Dev Studio (GitHub link). The extension is very easy to be installed from VS Code extension marketplace and offers a friendly environment for coding, running, debugging Atari games in Batari BASIC and even designing sprites for them. Also, it comes bundled with Stella, the most common Atari 2600 emulator in order to enable developers to run and test their games locally.
Another tool that helped me a lot is Atari background builder. It makes it super easy to design eye-catching title screens and other sprites. It also transforms PNG and JPG images to Assembly coded bitmaps that can be used immediately in your game.
The game
Before I started coding the actual game I thought that I would like to create something to be simple enough to help me understand the concepts and the language (this BASIC language is way easier than Assembly but do not forget that it is primitive too) but to be original. So I did not choose to create a clone of pong, breakout or space invaders. Finally, I had the idea of “Beer Mania”. The gameplay is simple and pretty straightforward: A small figure in the bottom of the screen is moved horizontally using the joystick input (or arrow keys in the emulator) and tries to catch the glasses of beer falling from the sky at random points. The player has 4 lives, losing one for each glass he/she misses and he/she gets 10 points for each glass of beer that catches.
Creating the game
I believe there is no reason to do an in-depth analysis of the code line-by-line as it will soon get way too technical. The code of the whole project is available on GitHub for anyone who may want to see it in detail and get his/her hands dirty.
However I would like to share some of the highlights and the things that I personally found interesting or very different than what coding / software development looks and feels like today.
The highlights
- All graphics are bitmaps
Like, actual bitmaps. In the Assembly of Atari (and thus in Batari BASIC as well), bitmaps are represented by 2D matrices of 1s and 0s that represent pixels. So everything that is displayed in the screen like sprites, backgrounds, characters etc. are explicitly declared and coded in binary form. For each bitmap there is also another (parallel) 1D matrix (array) that specifies the color of the specific line. Notice, that due to limitations of the era (and mostly of CRT screens), any pixels that are in the same line must have the same color.
Here is an example of a 2D bitmap of a graphic component (sprite)
player0:
%01000010
%01100100
%00011100
%00111100
%00011100
%00011000
%00001100
%00001100
%00001100
%00000000
endplayer0color:
$1C;
$1C;
$1C;
$1C;
$1C;
$1C;
$0E;
$0E;
end
2. Memory limitations
I think that the fact that only 26 (8-bit) variables were allowed (in standard kernel) says it all.
Atari 2600 carried only 128 bytes of RAM by itself and supported up to 4kB of memory on the ROMs of the cartridges. This technical constraint made programmers of this era very creative with the use of memory who soon came up with a “hacky” technique called “bank switching” and allowed to increase the size of the ROM that can be utilized by the program to an average of 32 kB of code.
Memory limitations accounted for another thing: In Atari 2600 you simply cannot have it all, or at least you cannot have it all at the same time. According to some options (kernel_options) that the programmer sets at the very start of the program, some features can get disabled in favor of some other ones. This options have a global scope, for the whole game and cannot be changed during program execution. It is the programmer who decides for each game which features (if any) he/she wants to sacrifice in order to get something else. A typical example is this setup of kernel_options:
set kernel_options player1colors pfcolors no_blank_linesThis kernel_options setup means that we can use multiple colors for each line on player1 sprite and in the playfield (mainly the background of the game) and that no blank lines will be displayed between rendered lines but this has the cost that we cannot use the missiles (reserved sprites that can be used as objects that a player can throw).
More details on the kernel_options trade-offs can be found on this link.
3. Integer values up to 255
This is probably directly linked to the memory limitations mentioned above. Each one of the 26 available variables is only 8-bit long which means it can only hold positive integer values up to 255. Again, programmers at ’80s had to get creative in order to represent negative values.
As the documentation of Batari Basic mentions:
Negative numbers are somewhat supported. Although variable values can contain 0–255, the numbers will wrap if 255 is exceeded. Therefore, you can think of numbers from 128–255 as being functionally equal to -128 to -1. This is called “two’s compliment” form because the high bit is set from 128–255, so this high bit can also be called the “sign.” In other words, adding 255 to a variable has exactly the same effect as subtracting 1.
Pretty impressive.
4. Use of the “goto” statement
Despite it is considered a really BAD programming practice nowadays, “goto” statements are more than common in Batari BASIC. This is probably due to the fact that they are easily converted to the respective jmp Assembly statements. Thankfully, since the ’80s coding paradigms have been evolved to way more structured.
5. Inline Assembly and bit operations make things really faster
There are many things that can be either done using less lines of BASIC code and run slower or by writing a bit more of inline Assembly and run way faster. The same applies for mathematical operations that can be done using bit operations like XOR. Initializing variables and performing multiplication for example was significantly faster using inline Assembly code.
6. Frames are rendered inside a SINGLE infinite loop
The whole gameplay takes place inside an infinite loop that has this structure (it is just a theoretical example, not intended to work as is):
gameloopframe_count = frame_count + 1player1y = player1y + 1
goto animate_spritesdrawscreenif joy0right then player0x = player0x + 1
if joy0left then player0x = player0x - 1
if joy0up then player0y = player0y - 1
if joy0down then player0y = player0y + 1
if player0y >= 80 then player0y = 80
if player0x <=1 then player0x = 1
if player0x >= 153 then player0x = 153update_scoregoto gameloop
You see those goto ‘s again ? Even a simple structure that could be coded as a while loop in a modern language, in Batari BASIC is written as code under a label with a goto the start of the label at its end. On the first 3 lines after the declaration of the label, we animate the player1 sprite and then jump code execution to another label we have declared ( animate_sprites), then drawscreen is the command that actually renders the frame changes.
These are my main observations in terms of differences to modern software paradigms.
Running the game
As I mentioned before, Atari Dev Studio comes with Stella, an Atari 2600 simulator. After I coded the game, I clicked on the rocket icon (‘Compile source code and run in emulator’) on the bottom left of my screen and after some seconds, the emulator started and my game appeared on the screen.
The compiler by default exports a symbolicated (ending in .bas.sym) and a non-symbolicated (ending in .bas.lst) Assembly file and of course a .bin executable, which is the file that actually runs in the emulator or in the Atari 2600 console.
Playing the game in a real Atari 2600 console
Now, that the game is ready there are 2 ways to play it in a real Atari console.
The first one (and probably the hardest) is to buy all the necessary materials in order write it in an EPROM (Erasable Programmable ROM), then solder the EPROM in a PCB, add the PCB in a cartridge case and finally add it to the console. This process requires some equipment which comes at a cost. You will need a soldering iron, an EPROM programmer, solder paste and of course the PCB and the plastic case for the cartridge. The process seems to be a bit difficult and I only suggest it for the more advanced users who have significant experience with electronic components soldering on PCB. This YouTube video explains the process in detail and I think it is a nice place to start.
The second and easiest way is to buy one SD multicart cartridge. I do not want to disclose any links to products as it may be considered an advertisement, but I am sure that you can find them with a bit of googling.
These are commercially available cartridges that take an SD card that can hold many ROMs. They also come programmed with an interface that enables the user to choose between the various ROMs. So the only think you have to do is to copy your compiled ROM (.bin executable file) in a FAT/FAT32 formatted SD card and add it to the multicart cartridge. This YouTube video will probably help you.
Final thoughts
Apart from being a really funny experience, I learned a lot of things during the process of creating a game for a gaming console that ceased to exist years before I was even born. The challenges that I faced made me understand the craftsmanship, the level of technical experience and the creativity that was needed by the programmers of this era. I also understood the huge leaps that have been made in computer programming during the last decades at the deepest possible level.
