So I'll spare you the stuff you can find on Google and just sorta' paraphrase it here. Batari BASIC is a basic-like programming language for the Atari 2600. The Atari 2600, aka. Atari VCS, Sears TeleGames Video Arcade, is an 8-bit video game console, a part of the second generation of consoles, and was released in 1977. It's notoriously one of the HARDEST game consoles to program for as it was back in the day. Guys like Rob Fulop, Gary Kitchen, Warren Robinette, David Crane, or Howard Scott Warshaw, made the machine do it's thing by programming in cold hard Assembly language....what does Assembly look like....well...

The relevant parts being LDA (Load Address), JSR (not sure), LDY......yeah, THAT is how they programmed it. But that's not all. The Atari 2600 did not have a graphics processor, aka a GPU, aka a Frame Buffer as it's called in older units like the NES. The Atari 2600 LITERALLY did it's calculations based on the posiotion of the television screens' electron gun - the part inside legacy CRT Televisions, that zaps from left to right on the TV screen, making the image appear by zapping the phosphors coating the back of what otherwise is a glorified lightbulb. There is some space outside that range such as the "back porch" "front porch" or "Vertial Blank" - which go unseen by the player (usually), this extra part of the cuycle of drawing the TV screen line by line was used for calculations (score, lives, etc). This meant you had to count every friggin scanline on the 2600. That's right, all those "rasters" you CRT people keep yammering on about, the legendary programmers of the days of old had to count all of them, and not just the lines, but how much OF that line is being used to draw a picture to fit more game logic in WHILE the screen is being drawn.

So as you can imagine I'm sure, this makes it a very tedious system to program. So during the 2000's, someone came up with an easier way - a "engine" of sorts, an interpreted language that later is compiled into your standard Stella/Z26 Emulator ROM Binary: Batari BASIC. The idea was to make it easier for would-be homebrewers to actually become homebrewers. The hope is eventually to move to the old ways of doing it (which really unlocks the 2600's surprisingly amazing full potential). Seriously, think about it, in 1977, Combat, Air-Sea Battle, and Night Driver were "State of the Art" - basic, bblocky, simple games with time limits and possibly only one or two player support and nothing more. No title screen, no big story, no big deal. Games that are roughly 2 Kilobytes in size. Skip to the mid 80's we have Pitfall II which is as big as some Black Label NES platformers in size in 1/4th the size, we had things like F-14 Tomcat Simulator that was not just an advanced flight sim for the 2600, but also looked quite impressive for the aging console as well. Then you get to SUPER amazing modern things, such as Andrew Davie's efforts with the C64 game Boulderdash. The initial game released almost a decade ago was awesome, but the current second variation he has now puts the Atari 2600 on par with a late-era NES in some ways, thinks something like Blaster Master. Hell, we even have a full RPG - Penult - with SAVE SUPPORT (SaveKey/AtariVox). The point I'm making is Batari BASIC is likely very limited, BUT, it's a good stepping stone to full-on programming the 2600, or making simpler games more on par with something between 1977-1987.

And even more impressive is just how "anemic" the hardware is by the numbers. What we have is a 6507 at 1.19MHz for a CPU, a 6532 "RIOT" RAM Input/Output TImer chip with only 128 Bytes - that's right BYTES - of RAM, and handling controller inputs in some cases (except Paddles which go to the next chip)....the closest thing the 2600 has to a GPU is the custom Atari silicon "TIA" or "STELLA" chip - also known as the "Television Interface Adapter" which polls the paddles, and makes the picture into something a regular at home TV can understand over an analog TV station. Sure, the conrollers have one button - but we have ways around that, because we can repurpose the console switches once meant to make Combat more visible on a Black and White TV, handicap yourself against a amateur player, and even select game variations and start up the game. That's what all six switches on my Taiwan Heavy Sixer above do, Crazy huh? But you can cahnge Color/B&W to change controller types for one game (ie Zombie Chase which uses a Joystick OR the unerrated Driving Paddles), or the Difficulty Switches to pull up a map such as in Starmaster. The thing is, it's limitations are it's strength - the 2600 is so open-ended, there's not as much limitation as with something newer like the NES. It also utilizes on-cart expansions just like the NES to pull these sorts of wild new things off.

The first thing of use are the "fixed assets" as I liked to call them, that the 2600 has for generating graphics: 2 Player sprites (player0, player1), two missile sprites (missile0, missile1), a ball (simply called "ball"), and a playfield (PF).

These Assets were originally intended for the following purposes....

• Player0, Player1 - Player graphics for 2 player games, ie Tanks in Combat or the Turrets in Space Invaders
• Missile0, Missile1 - Missiles associated with those sprites, with size adjustited using the NUSIZ command
• Ball - A singular graphic intended for things like Breakout and Pong
• Playfield - Only half is usually drawn and it's usually mirrored or duplicated on the other side of the screen (drawing the left first), hence why so many 2600 playfields are "symmetrical"

Most early Atari Games had single color graphics because that's how it was original designed. Later games figured out you could change the color on the next scanline to create multi-color characters. This means, unless you're Andrew Davies or Champ Games and have some extra processing, you won't get "bitmap" style sprites. As that's now how the Atari draws pictures on screen.

Let's talk about scanlines a bit. The TIA chip, or "Television Interface Adapter" chip inside the 2600 is what draws the screen. See Diagram below.

So basically, a American NTSC television set refreshes the screen 60 times a second - 60 Hz (PAL 50 from Europe/UK does 50 times a second). In that time that the screen is drawn, fractions of a second of the CPU time and TIA are dedicated to EVERYTHING the Atari is doing. There's no PPU, no Frame Buffer, no Graphics Card - the ATARI 2600 does everything in real-time. Meaning, during the Vertical Blank and Horizontal Blank, the Atari is doing things like polling and scanning controller ports/switches, calculating scores, basically all the "boring mathmatical stuff", then it draws the screen through a fraction of that. It's extremely simple in concept, but extremely tricky, and tedious in execution. This made the 2600 one of the hardest systems to program for.

In the old days, the legends, you know David Crane (Pitfall), Warren Robinette (Adventure), Howard Scott Warshaw (ET, Yar's Revenge, Raiders of the Lost Ark)....they had to COUNT every scanline, and had to program in 6502 Assembly Language. Which looks a little something like this...

All that was using mnemonics (yes, the grandfather that granted us the name of social media shitposting today known as "memes" - it came from a programming term for the commands in assembly language basically) - small abbreviations of lda (load address) or sta (store address) - yes, I've been trying to learn this stuff for about, uh, 30 years now - to control the game. The code you see above is for the states of the Dragons in Adventure (CX-2613, Warren Robinette, 1978 (released 1980) by Atari Corp). BatariBASIC keeps us from having to deal with such tedium and instead programming with something closer to say....QBASIC.

So above is QBASIC for DOS - a programming language I'm far more, well, familiar with. Notice how different that code looks, you can even almost make out what they are doing in the software code if you are hep to computer technology decently enough. BATARI Basic works like this. So what Batari BASIC does is converts your QBASIC-like sourcecode using the DASM compiler (or Microsoft Code in my case) to compile your software with. So you're not needing to count scanlines, make notes on what data is in what register all the time (there's some of that but that'll be down later in the page). Also, while programming in this, you will be learning more about how the Atari 2600 works on a deeper level - such how how those toggles and buttons REALLY work (and why they need a thing caled "Debouncing", lol).

I suggest if you are starting off, you should consider the 2600's limitations, and a little thing known as "Bushnell's Law" - well, who is the Bushnell guy? What what's his "law".....well....

To the left you see, is Nolan Bushnell, founder of Atari (originally Syzygy - try pronouncing THAT), and his "law" was simple to learn, hard to master - kind of like playing the guitar (or any instrument) really. That's the goal. That's why a lot these Atari 2600 games have stood the test of time. At first glance, they all look simple, and stupid, but in reality, have a lot more in common with a modern DLC and paywall ridden "Casual gaming app" on an iPhone than you might realize. Because things like Candy Crush, or Flappy Birds - are SIMPLE in concept and functionality enough for your average person to start playing it (if you remove all the DLC and Paywall stuff of course), but hard enough to be very challenging, especially at upper levels. That's why me and my friend sin the 1990's used to talk about the late night Atari 2600 gaming session with a shoebox full of manual-less games, and only the hum of the crickets and RF TV interference patterns coming through the speaker when not making in game sounds. Even if you did not have a manual - which most of the Arcade ports did for the 2600, but most people in the arcade just walked up, popped in a quarter, and went to town without a single lick of instruction - and got good just by playing it.

So when I started dabblign around, I started playing with a "stupid" idea I started calling "Wall War" - and it turned out to be pretty fun. Similiar basic premise as Pong (which is what Atari got famous for originally) - 2 players, one at each side of the screen, one shooting at the other one for high score, score hits 99, other player wins. Now it's only 3 months into messing with this thing and I've basically got a full fledged release-class game coming together.

The whole goal was to find something simple to make for my first game that touched on all the basics of all the classic games beit Combat, Air-Sea Battle, Berzerk, Pong, Defender, or what have you. Something that taught me how to program Joystick Controls, program missiles, program sounds, program basic movements and manipulations of characters, playfield, attract mode. Kinda' get a tour of what making a 1977 style game would be like in bB.

So what I suggest that helped me in starting down this path, was playing some 2600 games, and observing how the characters react, how they behave. How a 1 player game A.I. (nothing even close to ChatGPT BTW) follows the player without looking like some dumb turret following the player around perfectly. How the controls work, what are the best speeds for a given scenario, what missiles move like, what kind of audio you want...basically, look around at something basic, and pick it, and then look at how it's done.

rem One of the first important things to do is to comment on your code. I see a lot of bB devs put a comment using the "rem" or ";" to define that it's a "remark" at the top of the code to tell you what the game is, and other various stuff. Some people might just put a simple line like "Magic by Ric Ocasek" while others will put lines like "This is a game where you are a guy walking on water in a swimming pool healing NPCs with your aura for the Atari 2600 - by Ric Ocasek".

rem The next part of the code will be setting Kernel, Romsize, and other "Kernel options" for the Batari BASIC Kernel


A lot of people would look at these graphics and think "hey, that's easy" - trust me, it's not. One of the hardest things about drawing any 8-bit graphics is working within the limitations of the system, which for the 2600, there are many. Oh you might laugh now, but once you actually try to make something only eight pixels wide using one color that's supposed to look like something from real life, you'll quickly realize how amazing it is that something like Pitfall was even possible on this system.

Most basic 2600 games have SINGLE COLOR sprites. We're talking things like E.T., Pac-Man, the Dragons in Adventure. "Multi-Color" Kernel sprites are the Activision/EPYX style sprites. If you've ever taken a look at the art of the Atari 2600, you probably have noticed that most of the impressive looking graphics, when looked at up close, are made up of single lines of the same color, with multiple lines of different colors.

The most important thing to consider regarding sprites is this distinction of single color, or multicolor. If you notice, Pitfall Harry is made up of a line of brown (hair), some lines of tan (head), a shorter line of tan (neck), lines of green (shirt),then lines of brown again (pants). You are limited to only a single color per scanline.

While the Atari 2600 > NES in color pallete (the 2600 is capable of 256 colors total, the NES is only capable of I think something like 26 out of a 64 color pallet or something like that), it's limitedin pixel size. Sprites can only be up to eight pixels across, but can be as tall as the screen if you want. Usually I stick to 8x8 for most sprites.

And what might be "detailed" might not necessarily look good. You might need to settle more for "representing" something, than actually making something that will make people go "wow". Because on an Atari 2600 game in 2025, you're not really going to wow anyone with graphics, that's not why people play Atari games. Only mega-geeks with neckbeards who think looking good is more important than proper function will go to a 2600 game to point out how shoddy the graphics are. We know, it's an 8-bit system designed in a time when most Arcade games were BLACK AND WHITE! Seriously, there's some arcade games the 2600 coudl eat for lunch when it came out in 1977.

Let's talk art styles of various developers....yes, developers, not Artists. The Atari 2600 was programmed for by usually ONE lone person in a room at the office - not a multi-person team like today. If Howard Scott Warshaw was programming, he was doing the artwork. If Warren Robinette was programming, he was doing the artwork.....you get the idea.

Early on, most of these people, Rob Fulop, Joe Decuir....they were trying to replicate what was in the arcade. That's why a lot of early Atari games reuse the stame sprite designs, because these designs were likely generated by TTL hardware in an arcade game originally, which is an even harder method of making graphics than the 2600 has. That's why the cars in Indy 500 look like a smaller version of the cars in "Street Racer".

Later on, as themes became more elaborate, designers started to get more creative. Say what you will, but I like Warren Robinette's wacky art style from Adventure, it gives the game it's sort of laid back and somewhat zany yet still medevil character, kind of like a 2600 version of Monty Python and the Holy Grail.