Great Balls of Fire

I’ve managed to get some more stuff going on in the Atari 2600 game I’m working on.  The following video demonstrates the ability for the program to display something new: fireballs.

There’s still a lot of work to be done, yet.  I’m going to see if I can get more than one set of fireballs on screen at the same time.

Progress 2600

After a couple of weeks of breaking my brain on the Atari 2600 game I’ve been working on, I’ve finally made some significant progress.  I now have a gradient sky and grass background, the castle, a player-controlled ballista, and the ability for the ballista to shoot an arrow upwards into the sky when the player presses the joystick button!


After my last post on the game, I spent three weeks working on a general purpose “kernel” (the part of the program responsible for drawing what you see on the screen) that would do everything I wanted in one little package.  It took too long for me to realize that this was never going to happen.  There is just not enough processing power for it in the Atari 2600.

The visible image displayed by the Atari is divided into 192 horizontal lines (called “scanlines”).  This means the Atari effectively outputs a 192p resolution image — a far cry from the 1080p resolution many TVs have today.

Each scanline is drawn from the left to the right.  In old CRT televisions, an electron beam is shot at the screen from the inside of the tube.  This beam is what actually illuminates the screen with colors.


After the right edge of the screen is reached, the electron beam moves back to the left and down in order to start drawing the next scanline.

During each scanline, the Atari programmer has 76 “cycles” worth of processor time to execute commands which will tell the TV what to draw on that specific line. Individual instructions (like adding two numbers, storing a value into memory, reading a value from memory, etc.) typically take between 2 and 7 cycles each to execute.  At best you can perform 38 2-cycle-long instructions per line.  In reality, however, doing something useful will require that you run instructions that take more than 2 cycles to run.

As if being starved of processing power wasn’t enough, you actually only get 22 of those 76 cycles to work with before the graphics for that line start getting drawn!  (Technically, this is the time that the electron beam is not drawing as it moves from the right edge of the screen back to the left edge in order to start drawing the next scanline).  If you try to tell the Atari to draw something on the left edge of the screen by the 23rd cycle in the scanline, it’ll be too late and the TV won’t draw what you wanted.  Because of this, your program always has a few steps ahead of the TV’s drawing beam in telling the TV what it’s supposed to draw.

It typically takes a minimum of 21 cycles to execute the necessary instructions to prepare the “playfield graphic” for the current scanline:

lda PFData0,y   ; Load playfield graphics 1 to draw (takes 4 cycles)
sta PF0         ;  Set playfield graphics 1 to draw (takes 3 cycles)
lda PFData1,y   ; Load playfield graphics 2 to draw (takes 4 cycles)
sta PF1         ;  Set playfield graphics 2 to draw (takes 3 cycles)
lda PFData2,y   ; Load playfield graphics 3 to draw (takes 4 cycles)
sta PF2         ;  Set playfield graphics 3 to draw (takes 3 cycles)

The very next instruction after that will finish on at least the 23rd cycle of the current scanline, which means that it’s too late to get the TV to draw anything else directly along the left edge of the screen.

In my program, this background graphic is the castle.  On a scanline where any part of the castle appears I can’t draw anything else along the left edge of the screen.  Anything I want to draw on the same scanline (like the player-controlled ballista) will have to be positioned a little ways from the left edge if I want it to appear.

By a fortuitous happenstance, I had originally planned for the ballista’s movement to be limited to within the castle — the player could never move the ballista past the towers to the left and right.  Thanks to this limited movement range, I had enough time after setting the castle playfield graphics to also set the ballista graphics before the ballista itself ever needed to be draw.

Drawing the ballista currently takes about another 24 cycles in my code.  This brings me to a total of 45 out of the 76 cycles available for the current scanline.  At this point, the TV has drawn half the scanline, so I can’t draw anything more on the left half of the screen.  If I want to draw a second object on the same line, it will always have to appear on the right half of the screen.  This isn’t acceptable with my current goals for the game.

What most Atari programmers end up doing is to halve the vertical resolution of their game in order to double the amount of processing power they have per line.  This works due to various technicalities with the Atari hardware which can cause it to draw every other scanline in the exact same way as the one before it (this technique is typically called a two-line kernel).  The side effect is that the vertical resolution of the game is now reduced to 81p.

This double-scanline processing gives you more time to properly draw another object on the same line, but it still wasn’t quite enough for what I originally wanted. This is due to the fact that in order to draw all the objects I wanted I would have to reuse the limited amount of sprites (i.e. animated objects) available in the Atari.

Re-using a sprite meant I would have to re-position it in the middle of the screen.  Re-positioning a sprite while the screen is drawing results in a thin black horizontal line appearing on the left edge of the screen.  These black lines can be seen on many professionally released Atari games from back in the day, like Vanguard (pictured below), and was the only way to get the Atari to draw more than two complex shapes on the screen at a time:


While attempting to create a general purpose kernel, I decided it would be smart to really think about what I actually needed the program to do.  I took a look at all the possible things I wanted to have happen on the screen, and from this I determined how many things would need to be drawn on the same line, and where on the screen they would be drawn.

I took a screenshot of my game and, using a graphics editor, added some fake graphics to it to mock up a game screen with all the possible things that could appear onscreen being drawn at once (e.g. the ballista, an arrow, two dragons, fireballs, the castle, etc.).  The game would never be in this state, but it gave me a starting point for dividing up the entire screen into multiple horizontal sections.  These sections defined points where the program would have to draw different things.  For example, the player-controlled ballista will not be able to move vertically, so I divided the part of the screen where it would be drawn into its own section.

After splitting the screen into several sections, I then focused on looking at how many things could possibly be drawn simultaneously within the same horizontal section.  I made a couple of game design decisions at this point which would limit the amount of work I would ever have to possibly do within one horizontal section.  For example, I decided that if two dragons were onscreen at the same time, they would always appear at two different, non-overlapping altitudes, and only the lower dragon would ever shoot fireballs.  This meant that I would never have to worry about drawing either two dragons or a dragon and a fireball on the same line.  This helped a bit, but my ideas were still too much for a general purpose kernel.

During all this time, I was also researching how other people were able to draw multiple sprites onscreen at once.  I came across a forum post somewhere which mentioned that some people write multiple kernels to handle this, with each kernel being responsible for drawing only a certain portion of the screen.

With this new approach in mind,  I took my program, threw away most of what I had written, and started over again almost from scratch.  This time, instead of using a single general purpose kernel which would be responsible for drawing the screen, I created multiple kernels, each one of which would be responsible for only drawing a small section of the screen.  I made the program change the background color within each section to help visualize everything:


This seemed like a promising new start.

With this done, I decided to implement the arrow sprite, which is what the player would be shooting up at enemies.  The arrow sprite would only ever need to be drawn in the sections above the one in which the ballista would be drawn, so I modified only the kernels responsible for those sections, making them call a subroutine which would draw the arrow.

I got this working in fairly short order with the arrow moving from the lower-middle of the screen to the top.  The arrow would then looping to the bottom and repeat the animation indefinitely.  In the image below you can see the arrow being drawn near the top-left corner of the screen.


Next, I tweaked the program so that the arrow would no longer loop and, instead, would only rise to the top of the screen once.  In effect, I made the program automatically shoot the arrow once when the program started.

After this I hooked up the joystick button input to the arrow drawing logic and made it so the player would control the shooting of the arrow.  Every time the player pressed the joystick button, a new arrow would fire up toward the top of the screen.

Then I decided to re-implement the code which controlled the ballista’s horizontal movement, and made it so that the arrow would be fired from whatever horizontal position the ballista happened to be at.  I didn’t actually get the ballista to draw at this point, but I was now able to control when and where the arrow would be fired.

With the arrow graphics logic pretty much completed, I then added in code to draw the ballista.  At this point, things got a little screwy:


My code was taking too long to draw the ballista, so it ended up getting stretched out and drawn incorrectly.  I was also unnecessarily re-positioning the ballista to the same point multiple times on ever frame, resulting in all the black lines to the left of the ballista.  I cleaned up my code a bit and resolved these issues.

Adding in the castle graphics screwed everything up again, and it took a little longer to resolve all that (I neglected to take a screenshot of it, but, trust me, it was a mess).  Once I got the castle drawing correctly, however, a new problem appeared: whenever an arrow was being shot, the section it was currently in would expand in height if that section also had some of the castle drawn within it.  This took further refinement of the code to resolve.

Eventually I got things drawing mostly the way I wanted with only some minor glitches, such as the uneven bottom of the left half of the rear castle.  I’m living with that for now and might try to fix it later.


One thing I’ve certainly learned about programming for the Atari 2600 is that “the perfect is the enemy of the good”.  If you try to get things perfect, you’ll a) never reach that point, and b) miss out on things being “good enough”.

Again, you can see the acceptance of small imperfections in professional games, such as with the black lines on the left edge of the screen in Vanguard (pictured earlier), or the dip in the left edge of the ground in Space Invaders:


In any case, it might be time to try getting the ballista in my game to appear in multiple colors and/or display an animation whenever the player fires an arrow.  We’ll see what the next few weeks will bring.


I found a great online development environment for the Atari 2600 console at I noticed the URL while skimming through a book on Amazon entitled Making Games for the Atari 2600, by Steven Hugg.

There are a lot of great code examples on the site, but the most useful thing about it, IMO, us the fact that your code is compiled and executed as you type. Being able to instantly see the result of your changes is incredibly convenient. Also useful is the timing calculations that the site can do on your code. If you want to do any tinkering with Atari 2600 code, be sure to check that site out.

As for my castle program, I did some more work on it over the weekend. I tightened up the castle drawing code a little bit and made the castle a little taller. I also got rid of the shading on the grass for now; I want to save as many cpu cycles as possible for the time being. The colors are a bit dark and need to be tweaked, but I’ll do that once I have actually sprites moving around so I can get a better sense of what colors will work best.

In the screen shot above you can also see a ballista in the castle courtyard. This is going to be the player. It doesn’t actually do anything yet, but eventually the player will able to move the ballista left or right within the castle walls.

Once player sprite motion is implemented I’ll work on making it shoot arrows up at the sky. I have some animation frames drawn for the firing of the ballista which I hope to be able to add in as well.

I came up with a ton of ideas to add to the game over the weekend as well, including different enemy types, power-ups, difficulty settings and even a possible boss battle. If I don’t lose interest too soon, I think I can make a pretty enjoyable game out of all this.

Return to Minecraft

Over the past two-and-a-half years or so I have been keeping a persistent Minecraft world on my home computer. Every now and then I’ll start up the server and delve into my little Minecraft world of a couple of weeks or months. Every time I do I invite a couple of friends to continue their own creations. It’s been a while since I last played Minecraft, but I recently started up the server again and have been hard at work creating new structures.

Here is an overview of most of the “civilized world” in my server:
In the center-left is my main home: a large house made of marble mined from the Nether.  Some other points of note include:

  • The World’s Tallest Tower (center) – a cylindrical tower that reaches the maximum height allowed in the game.
  • The Great Southern Wall (center-right) – a giant wall which was constructed to keep the civilized lands safe from the desert to the south.  Just FYI, I build this wall before I even heard of Game of Thrones, so, no, I wasn’t copying it.
  • The Great Warehouse (right) – a sprawling warehouse filled with racks and racks of chest.  I was inspired to build this when the fourth Indiana Jones movie was announced.
  • The Obsidian Tower (upper-right) – a tower made of obsidian, built by one of my friends.  It is not quite complete.
  • The Missile Silo (center) – a large ICBM sits in the southern end of civilized lands, ready to inflict mutually assured destruction against any nuclear enemies.
  • The Black Pyramid (center-bottom) – a black pyramid constructed of netherbrick.  The interior is completely dark and acts as a sort of arena for killing monsters should the need for special materials only dropped by them arise.

There are many other individual structures too numerous to list, and there are extensive networks of underground tunnels and spaces which are not easily viewed.

Here are some more photos of just a few things built within the world.  There are many more impressive structures and vistas besides these:

The Obsidian Tower.
One of the earliest creations was a village containing a variety of smaller buildings.
One of the many bridges situated along The Great Road — an absurdly long road I’ve worked on which stretches out far to the East.
The Great Road features many beautiful views.
The view from the rear of my main home base. The Black Castle is perched atop a distant mountain, silently menacing the surrounding lands.
A cozy chalet along The Great Road.
A coastal desert fortress constructed by one of my friends.
One of my friends is currently constructing a giant statue made to look like the humanoid characters in the game.
An admittedly poor view of Little Egypt which lies immediately south-east of my main home base.
A view of the rear of my mansion. There are many animal pens and a good deal of farmland near my mansion which were built for resource gathering. The bell tower on the left was a copy of a similar tower I saw photos of online. In the distance you can see the Portal Temple, which was the site of the world’s first portal to the Nether.
A statue created as a tribute to all miners. This was constructed at the mouth of one of the many mines along The Great Road which were struck for the stone needed for its construction.
I mentioned earlier a “Great Road”. This is a project in the world where I have created a long, east-west running road across the Minecraft world. The last time I measured, it took about half an hour to walk from one end to the other.

This “Great Road” begins at the eastern coast of the area where everything started and runs westward. During this most recent return to Minecraft, a new megaproject was started in which The Great Road was to advance to the west, across the ocean. The Great Bridge to the West will be the largest structure in the world once it is complete.  It’s beginnings are visible in the lower-left corner of the overworld map near the start of this post.

You can get a feel for how long the bridge is from the following image. Here we see much of the known world, and The Great Bridge to the West is in its initial stages, reaching only 3/4s of its planned final length.

The Great Bridge to the West is not yet complete. Here are some progress shots:

Initial planning the east landing and overall bridge superstructure.

I decided I wanted the bridge to made up of repeating segments in order to break up the monotony of building a bridge that was identical along its entire length and to give it some aesthetic character. After a couple of refinements I settled on an acceptable segment design.

Here we see the construction of the eastern abutment and the prototype superstructure segment template.

Initial preliminary construction of three bridge superstructure segments depicting the three layers of each segment.

My friend, being a little overzealous, started creating bridge segments right away. What I wanted to do first was to just have the three progressively completed segments to act as a guide, and to first create a skeleton of the bridge spanning the entire length of the ocean before building the superstructure segments on top of it, layer by layer.

An overview of the bridge’s initial progress.

Construction of the bridge skeleton is temporarily halted when it hits a good-sized island. A small base of operations was set up on this island.

The skeleton reaches across the entire ocean. Without the segments filled in it is easier to count how many segments span the entire ocean. I planned to use this information to design additional support structures for the bridge (e.g. pillars, suspension towers, etc) but I’m not 100% what I will do (if anything).

The first layer of the superstructure is complete.

The skeleton of the bridge without the segments completed continues off into the night.

With the skeleton complete, the meat starts being added, one layer at a time across the entire span of the bridge.

Side view of the eastern end of the bridge. The building on the shore covers the entrance to the mine used to gather materials for the bridge and includes storage and smelting facilities.

A depot was built along the bridge at the point where the large island that interrupts it.

Beneath the depot are some buildings, farms, and a mine.

Prior to this particular megaproject (which my friends are helping me on) there was another megaproject in which a bridge across a sea far to the east was built. This bridge — known as The Great Bridge to the East — was, at the time, the largest structure in the world.

Here are some shots of its construction:

Initial two tower foundations are done up to the surface and the outlines of the bridge proper are being contructed:

Aerial shot of the bridge and tower foundations:

The tower foundations were build up right from the sea bottom:

The tower frames going up:

Tower outlines at night:

Filling in the towers:

Tower construction:

The towers dark and ready to be lit:

Lighting the towers:

View from the interior of one of the towers as it is in the process of lighting up:

Nearly completed bridge at nightfall:

View of the west bank approach:

The completed bridge as viewed from the east bank:

Near large constructions like this I usually create a small home base. Here’s the interior of the one near this project:

Another megaproject in the world is the East Gate.

Gore’s Medal

In World of Tanks, players may be awarded “epic medals” under certain extraordinary circumstances.  These medals are usually inspired by some historic military commander, hero, or event.

The other day, I acquired “Gore’s Medal” for the first time in my Hummel.

The other awards I won in that battle:

“Ace Tanker” mastery badge

Earn more base experience in a single battle than the average highest experience of 99% of all players in the same tank within the last seven days

“Fighter” honorary rank

Destroy 4 or 5 enemy vehicles in the course of the battle.

“Arsonist” token

Destroy an enemy vehicle by setting it on fire.

“Bruiser” token

Damage enemy modules and/or knock out their crew members at least 5 times in the course of the battle.

“High Caliber” battle hero medal

Awarded to players who dealt the largest amount of damage during the battle and where the total damage dealt is at least 20% of the total hit points of all tanks on the enemy team.


Mark of Excellence: Hummel

I earned my first Mark of Excellence on my Hummel the other day in World of Tanks.  These are special markings that are drawn on the barrel of a player’s tank which indicate exceptional performance.



These in-game markings borrow from the old “kill rings” or “victory marks” tank crews would paint onto their tank guns to mark their kills.


Exemplary Performance

I’ve had some good games since I started playing World of Tanks again.  Here are some awards I recently earned:

The Arsonist award is not easy to get, especially with an SPG.  With a single shot, you have to almost destroy a tank and score a critical hit on the fuel tank and have the fuel tank rupture and catch fire and have the fire do enough damage to finish off the tank.


I was wondering if I’d ever get the Bombardier award, as it entails destroying two tanks with one shot.  High-explosive artillery shells FTW!


I was not expecting the Battle Buddy award; I had no idea it existed.  I guess it says something about an arty player since SPGs are typically not very accurate and often fire high-explosive shells which cause splash damage. It’s very easy to damage allies if one is not careful.


Destroying a third of the enemy team by yourself is a decent accomplishment.


The Raider award is earned when you capture the enemy base — you have to make it to the enemy flag and stay close to it for a minute or two — and do it without ever being spotted by the enemy.  This is fairly humiliating to the enemy.  It’s especially so when the enemy does it with a terribly slow SPG.


The game also has a campaign for each class of tank.  Each campaign consists of fifteen missions, and each mission consists of a primary win condition and a secondary win condition. These missions are just a goal you can set for yourself — you don’t have do them.

The reward for completing a mission is typically a pile of credits and/or some in-game consumable.  Completing a mission with honors (i.e. fulfilling both primary and secondary conditions) rewards additional credits.   The reward for completing every mission in a campaign includes a female crew member (and this is the only way to get them).

I had completed the entire campaign a few days ago, but the game gives you the option to retry any mission which you did not complete with honors the first time.  Tonight I managed to finally complete the entire campaign with honors.



The results of the game wherein I completed the final mission with honors:


And, finally, here’s a photo of my favorite tank — the Hummel: