By Steve Fulton
5/17/2020 : Brickbasher 2600

There are many reasons why some of my projects never gets finished. Here are a few of the more obvious ones:

• They were not a good ideas
• They were beyond my capabilities
• The idea morphed into something else
• I got distracted

However, sometimes projects are stopped because they are “too attractive” and “too alluring”. so much so they become all consuming. A good example of this is “Brickbasher 2600” and an Atari VCS game built with bAtari BASIC.

I found the old code for the game my hard drive a few days ago, started in late 2018 It’s a game based on Atari’s classic coin operated game, Breakout. I’d forgotten all about it. It’s as if I blocked the entire episode out of my mind.

….

I decided to start working an an Atari VCS games back in 2018 because, honestly, it just felt like the right time to do it. It was the first season of the Into The Vertical Blank podcast, and I thought that maybe an “Into The Vertical Blank” themed VCS game might be possible. I had dreamed of being a programmer for Atari in my youth. Making a homebrew game for the VCS felt like the next best thing.

So I downloaded bAtari basic from its’ home on GitHub, and got started.

Like most people, the first thing I usually do when starting on a new software development platform is to get something simple to display. This involves finding a basic example, and then swapping out just enough code to make to customize some small bit but also allow it to still run without errors. This could be classic “Hello World” or anything else really, it just needs to get me over the hump from mere observer to active participant.

I did this with a VCS program called “steve2” which was just a simple recoding of a title screen demo that came with the the bAtari Basic package. I changed the name on the title screen to “Tiler” imagining maybe creating a game about roofing tiles based on the story Claw Hammer from the podcast. I wrote a little bit of code for Tiler, managing to get a hammer sprite and nail sprite that could be pounded into the screen, but soon realized I had no idea where to take the concept and I stopped.

However, the “spark” had been lit. I was over the hump and wanted to learn more

The next step was to read the official documentation. For bAtari those docs are on the Random Terrain web site.

When I first dove into bAtari it became clear to me that this “BASIC” language is really an Atari VCS compatible game engine that exposes some of the primary features of the hardware without forcing developers to build their own kernel. The “kernel” in program for VCS is the low-level set of code that creates the line-by-line display required by the VCS’s TIA Chip (Television Interface Adaptor). Since the VCS had no memory buffer for holding display information for an entire screen (a feature of nearly all systems game systems that followed it,) each line of display has to be programmed individually in real-time.

The best Atari VCS programmers know how to wring every last bit of performance out their own custom kernels. bAtari Basic abstracts this from the programmer, providing a multipurpose kernel that has been made as flexible as possible for a broad range of games.

bAtari allows a programmer to customize anything with 652 Assembly, but I decided to stay within the guardrails of bAtari Basic to see what I could make. I was not trying to prove my technical ability, I was trying to be creative and get something accomplished. This is the main draw for languages like bAtari Basic: to allow people to flex their creative muscle while limiting their exposure to the technical underpinnings of the system itself. There are trade-offs of course. The particular kernel (actually there are several kernels) employed by bAtari Basic might not be suitable for every game. In fact, I figured part of the job of a bAtari Basic programmer is to work within the constraints of a language that was built within the constraints of the VCS itself.

While I did not want any limitations, at the same time I wanted to create something. Anything. But what could be created with the available resources and limitations? I was kind of stumped. I’ve played a lot of Atari VCS games in my day. I played my first 42 years ago, and I’ve pretty much never stopped. I felt it should be innate to me at this point to know what is possible or not on an Atari VCS. But is was really hard.

Was I paying attention that whole time?
Was I even capable of doing this?

Thing became more clear ss I read through the bAtari Basic documentation, and a creeping realization came over me. While bAtari is an implementation of a kernel for the VCS, it still adheres closely to the features and limitations of the original hardware. Patterns emerged that matched-up with my many decades of experience playing games for the console, highlighting certain features and idiosyncrasies of the VCS that I had unconsciously cataloged since I first played one in 1978.

• 128 bytes of RAM: I’d heard for many years that the Atari 2600 had only 128 bytes of RAM, but it did not sink in until I started using bAtari BASIC. 128 bytes basically means you can track 128 8-bit numbers, or as GCC hardware developer Steve Golson said in our recent interview, “1024 precocious bits” A “bit” in an on/off, ingle price of information. Not everything in a game can be represented as true/false as you might need to track screen x/y locations, scores, lives, etc, and many of those things require a full byte for numerical storage. bAtari Basic is even more restrictive. Of that 128 bytes, only 26 bytes are available to your game because the rest are used by the game engine kernel. You must track EVERYTHING dynamic in your game with those 26 bytes. Instantly this removed a whole set of ideas of games that I might want to make off the table. This is one of the first big trade-offs you make when using bAtari Basic.
  (By the way, this also made me realize the power of the 4k RAM in the Atari 7800, and 6K of RAM added with the Starpath Supercharger. All of a sudden I could see how game like DragonStomper, the first console RPG, could only really be made with that extra RAM. My eyes were opening.)
• Sprites: Sprites are the independent graphics that a game moves on the screen to create players, enemies, shots, etc. Some systems, like the VCS and the Atari 800 use what are known as “hardware sprites”, which means they are built-into the system and can be easily manipulated. Other systems such as the The Atari ST employ what is known as “soft sprites or software sprites” which must be defined and controlled completely by a programmer. The Nintendo Entertainment System has 64 sprites that can be defined and manipulated by a programmer, By contrast, The Atari VCS can display 2 sprites, 2 missiles and one ball. That’s it. bAtari Basic’s default kernel works under these limitations. The language also supports a Multi-Sprite kernel with 6 sprites, and the DPC+ kernel that can handle 10, both with various other advantages and disadvantages over the default kernel.
  
  When displaying sprites on the VCS, there are many options built into the hardware. For example, sprite can be displayed double or quad-wide and can also be displayed as multiple copies of itself. This got me thinking about the game Combat! and how the bi-plane and jet game variants of this first game for VCS allowed for multiple and bigger planes.
  
  A light bulb suddenly turned on!
  
  By learning bAtari Basic I was in-turn learning some basic of the aspects of how the VCS was actually used to create games in the beginning! It was obvious (to me) that these sprites options were employed to make Combat!. Furthermore, the double-wide option reminded me of the player’s paddle in Breakout. When that game starts getting fast, the player’s paddle shrinks in size. Could the programmer have simply employed a double-wide sprite at the beginning of the game, then switched to a single-wide paddle as the difficulty increased? Maybe. But it didn’t matter. Reading the documentation for bAtari Basic was like opening up a whole new world of understanding for me for the Atari VCS. I loved discovering these little bits of information that compounded up my conceptual knowledge of how the original VCS games were built.
  
  Thinking about it further, Video Olympics might also uses the ability to create multiple copies of a sprite. This would explain how certain versions of Pong on that cartridge allow for multiple rows of paddles controlled by the user. Again, I did not know if these were the methods employed by the original programmer, but it did not matter. I could imagine a way to solve the “problem” of Video Olympics, and it felt liberating.

• Just to confirm my suspicions , I found the “Stella Programming Guide” from 1979 online. Famously, “Stella” was the code-name of the VCS, also named after Joe Decuir’s bicycle. In the guide I found a chart that described the features of Sprite display, and they matched-up with what was available in bAtari Basic. In fact, even then names of memory addressed used to set the sprite information (NUSIZ0, NUSIZ1) were the same. My instincts were correct. I was seeing the exact same features as the first Atari VCS programmers!
  
  
• Colors: When reading about Colors, I noticed something that made me think of the first times I played the Atari VCS. As I stated before, the TIA hardware in the VCS allows for 2 player sprites and two missiles. One for each Player. However, the missiles MUST be the same color as the the Player. Reading this gave me total recall of first played Outlaw on the VCS and wondered why my shots were the same color as my cowboy. It’s a very simple thing, but stood out to me, even as an 8 year old, as being unrealistic and forcing me out of the fantasy of the game into the real world. Games like Outlaw are filled with these types of nuances that live directly in the “Vertical Blank” (not the real one, the virtual one we talk about in the podcast) and drive me nuts on a daily basis. However right here, 40 years later, I had an explanation. The shots HAD to be the same color, at least using the default VCS capabilities. More secrets of the VCS were unlocked before my eyes.
  
  To further this concept of colors, the VCS also has a single Ball object on the VCS and it must be the same colors the playfield graphics (more on the playfield graphics later). This made sense too. I recalled that the Ball in the Video Olympics cartridge was always the same color as the playfield, and sometimes got lost momentarily among the various obstacles as you were playing. Of course! This was based on the hardware limitations!
  

• I’m sure there are ways to change this, but not every programmers wants to re-engineer an existing system to make a game. Some, just want to create! Since Video Olympics was one of the first VCS games made, the programmer (Joe Decuir) most likely employed the default capabilities that were provided by the hardware, and this meant the ball was the same color as the playfield.
  
  To confirm these color limitations, I looked at the the Stella Programmer’s Guide again, and I found a table that showed exactly this. Colors for the players and missiles were indeed the same, as were those for the ball and playfield. In cases like this, bAtari Basic was a direct line into the VCS. This made me feel less like I was “cheating” using bAtari, and more like I was simply using modern technology to make the chore of building VCS game much easier.
  
  
• The Playfield : The Atari VCS includes a graphics feature called The Playfield. A quick check of the Stella Programmer’s Guide showed me that not only is The Playfield a standard feature of the VCS hardware, but much like NUSIZ0 for sprites, bAtari Basic uses the same names for memory addresses (PF0,PF1,PF2) as a low-level assembly language programmer would use to manipulate the Playfield. This was further confirmation to me that the features I was was discovering were similar to the ones available to the original VCS programmers.
  
  The Playfield is coarse pixel display area that allows for the creation of mazes and obstacles that, for instance, the players will navigate or will stop missiles. The “pixels” are really large blocks displayed at 32×11 or 32×12 depending on which bAtari Basic kernel you are using.
  
  The default bAtari Basic kernel allows you to place Playfield graphics across the entire screen. However, bAtari’s Multi-Sprite Kernel has a mirrored playfield. This idea of a mirrored playfield is another Atari VCS nuance that has stuck with me through the years. The mazes in Combat and even the room in Adventure always struck me as unrealistic because they were completely Symmetrical. These symmetrical playfields make-up the background graphics of my Atari memories, and a are a huge part of what makes-up The Vertical Blank in my head.
  
  These playfield graphics were intriguing because it seems like they could be manipulated in ways that might not have been originally intended. For instance, I’d always wondered how a game like Atari VCS Surround was made. When I first saw the playfield graphics, a possible methods became apparent to me. The “players” in Surround were the two player sprites, but their trails were probably playfield graphics.
  
  Furthermore, each individual line of the Playfield can be a different color, and the heights can be adjusted. As well, bAtari basic including a function for turning playfield graphic “on and off”.
  
  “On and off”
  
  Bingo!
  
  Turning playfield graphics on and off seemed like an interesting concept for making a game!
  

After discovering these features and more,, ideas for VCS games trickled into my brain. I now had a little bit of insight into how some of the original Atari programmers could have looked at the features and limitations of the VCS hardware, and began devising games based on both. In fact nearly all of the original 9 Atari VCS games released in 1977 used some or all of the features I had discovered in the bAtari Basic manual.

But what game would I make?

The answer came quickly. The Fact that Playfield graphics could be turned on and off, reminded me of one of Atari’s greatest games: Breakout. Atari VCS Breakout was my first “love” when it came to video games, and I felt like me entire life in technology started with that game. It was only natural I would try to recreate it.

I started by using the Playfield in the regular kernel so I could plot across the entire screen. By limiting the height of the layers of “bricks” (rows of playfield graphics) , and expanding the height of the other lines, it seemed possible to create the rows of bricks required for what was becoming my own version of the classic game named BrickBasher 2600.

The biggest breakthrough (no pun intended) came when I figured out some simple code to check to see if the Ball had hit one of the bricks. Since collision detection only exists among the Players Missiles and the Ball, but not the Playfield, defining when a brick is “hit” and needs to leave the screen must be accomplished another way.

Since all the brick are uniform size, I figured I could write a simple bit of code to see if the ball was currently within the bounding box of a brick. If the “brick” (a Playfiend Graphics) was “on” I would simply turn it off, bounce the ball at an angle, and my job would be done.

The code looked like this:

_Check_Brick_Hits 
 if !collision(ball, playfield) then goto miss
 m = ((ballx-14)/4) - 1
 if m > 31 then m = 31
 n = ((bally-18)/4) + 2 
 if n > 8 then goto miss 
 if !pfread(m,n) then goto miss 
 rem if hitbrick = TRUE then goto balldown
 pfpixel m n off
...

It was messy and filled with literals but it worked!

The experience was thrilling.

My quest was the keep the game under 2K of ROM, because that was a limitation of the earliest Atari VCS programmers. Every time I came-up with a coding solution to a problem, I would refactor and refactor again until it was the most economical use of code I could device. Sometimes features got lost, but as long as the game stayed pretty much like Breakout, I didn’t care. I was finally building a game for actual Atari hardware.

A lot more than the code above items went into making my first demo of Brickbasher 2600. Lots of iteration and tradeoffs and refactoring went into just getting just as far as I got. And I admit, the results are still kind of underwhelming. Nothing really works EXCATLY right, but almost all of the features are just on the cusp of being finished.

However, I stopped here for a good reason: The Atari VCS began consuming all my downtime. I found myself thinking in terms of the VCS all day and night. On one fateful day in early December 2018, while driving to pick-up one of my kids, I recall my mind wondering to the game Canyon Bomber. I was trying to remember exactly how it was played, and more importantly, if the game could be recreated with a similar Playfield block strategy as my Brickbasher game. I was so consumed with sudden idea about that VCS programming that I forgot I was driving.

I ran a red light and nearly got into an accident.

This was a wake-up call for me.

Sure, I always wanted to make a game for VCS, but maybe that was not the right time. It was all consuming, but I suppose my All was not ready to be consumed. Finishing Brickbasher 2600 then was simply not in the cards.

That is where I stopped in December 2018.

I moved away from Brickbasher, tried a few other concepts, and then quit bAtari completely, afraid to be seduced once more by the power of nuance, the power of nostalgia, by the power of childhood dreams fulfilled that had taken me almost to the brink.

I stopped until today (May 17, 2020) when I updated the game with one line of code so the ball would restart.

This version of Brickbasher 2600 is presented here. There is no scoring or game end. Really, it’s just an exercise in how to uses sprite, ball, playfield, collision detection and a little bit of math for angles and detecting hits on the playfield.

You can get the demo code here and try it out.
Brick Basher 2600

Building my first Atari VCS game demo was an amazing experience. It brought me joy I never thought possible, but also captivating me in an almost frightening way. Maybe I waited too long? Maybe I did not wait long enough? However, I’m pretty sure there will be a time in the near future when I will test the waters once again, and if I’m careful, not get irrecoverably pulled under and into it’s grasp.

Pulled directly into The Vertical Blank.

12/6/2018

First demo complete of of Brickbasher 2600. This was my attempt to to use the basic resources of bAtari to make a Breakout game. It still needs a lot of work, but he basic concept appears possible in under 2K.