Stellaaaaa!

I found a great online development environment for the Atari 2600 console at 8bitworkshop.com. 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.

Atari 2600 Programming

It’s been a while since I last looked into writing programs for the Atari 2600. The last thing I was messing with was drawing a sort of castle onto the screen. I was having a bit of trouble with that and my interest eventually just petered out.

I recently returned to this project and got the castle to draw nicely. I then added a sky and grass to the background, then I added some fancy shading to the grass. Here’s a screenshot of what I have so far:

I would like to eventually use this as the basis for some sort of game. The idea currently swimming in my head is to have the player control a ballista inside the castle which he could move to the left and right. Dragons would fly across the screen in the sky and the player would have to shoot them.

The dragons would vary in color, with certain colored dragons being faster than others. The dragons would also shoot fireballs down at the player. If possible, it would be cool to add swooping dragons as well.

We’ll see if any of that ends up happening.

I’m experimenting with drawing sprites right now (sprites are things that can move, like the player for example). I’ve managed to get the player 1 sprite to display, but it’s not anything usable for a game yet.

I’m optimistic that I can get a moveable player on the screen soon. I’m a little worried that the sprite logic might force me to simplify the color gradient for the grass — processing power is very limited on the Atari.

I’ll probably post the source code for this program once I have a moveable player implemented.

Atari 2600 Programming

atari 2600When I was a kid, our family had an Atari 2600 Video Computer System, as did many of our friends and relatives.  We had a good number of games, and many great memories were made playing them.

A few years back I got a book (Racing the Beam: The Atari Video Computer System, by Nick Montfort and Ian Bogost) that talked about how those old games were programmed.  It was quite fascinating.  The approach to programming the Atari 2600 is quite a departure from what I do every day as a software developer.  I gained a lot of respect for the old Atari game programmers; they performed incredible feats of coding.

More recently, on a whim, I decided to read up on Atari 2600 programming about a month ago.  Here’s a little bit of what I’ve learned:  To run games, the Atari 2600 uses a MOS Technology 6507 microprocessor (a variant of the MOS Technology 6502, a generic 8-bit microprocessor which was first produced in 1975 and is still used in hundreds of millions of devices to this day).  This is the central processing unit: the chip that executes the software written by Atari programmers.

The central processor interacts with two other chips.  One is the MOS Technology 6532, another generic chip designed to provide RAM (only 128 bytes — your computer probably has at least eight billion bytes or more), a couple of I/O ports for interfacing with peripherals (e.g. joysticks), and a timer. The other is a custom chip called the Television Interface Adapter (or TIA), nicknamed “Stella”.  The TIA is responsible for generating the signals that are sent to a TV in order to generate images and sound.  The TIA was designed to keep costs down, and cost-cutting measures led to the chip exhibiting some very peculiar behaviors which required arcane knowledge and carefully timed commands to effectively control.

After learning about programming the 6507 to control the TIA, I’ve discovered that the Atari’s reputation for being notoriously difficult to program games for is not overstated.  First of all, in 1975 we didn’t have computers powerful enough to provide layers of abstraction between the programmer and the hardware which act to simplify programming tasks. The Atari requires coding in an assembly language — literally the lowest level of programming possible in a computer (sometimes called “bare-metal” programming because of the programmer’s metaphorical proximity to the physical hardware).

To illustrate the difference between modern software development and programming in assembler, imagine that you want to write a poem on a piece of paper.  Modern programming is like you grabbing a pencil, then manipulating that pencil to write the desired words on a piece of paper.  With assembly programming, if you want a pencil, you can’t just grab one — you have to first chop down a tree to get some wood, mine some graphite out of the ground for the lead, etc.  Programming in assembler for the Atari’s Stella chip is like you having to time those axe and pick swings in step with your heartbeat or you die.

The ultimate testament to the skill of the original Atari programmers is the fact that the games for the Atari 2600 could not be longer than 4096 bytes.  The entire text of this blog post you are reading takes up a little bit more than that!

So, I decided to try my hand at doing a little Atari 2600 programming myself. I followed a tutorial by Andrew Davie to get started.  Unfortunately, some of the code examples had bugs in them that made learning Atari programming very frustrating at times — I had to debug code that I was in the process of learning!

Here is my first Atari 2600 program (hosted on Google Drive — please leave a comment if there’s a problem with the link).  All this program does is display a Canada flag.  It might not seem very impressive, but if you’re familiar with Atari programming you’ll know it’s no trivial task.

canflag0 screenshotThis zip file contains the compiled ROM that you can load up and run in an Atari emulator like Stella (named after the Atari’s custom chip).  If I had the hardware, I could literally burn this ROM file into a writable Atari cartridge and run it on an actual Atari 2600 machine.

Also included is the source code to which I’ve added copious amounts of comments to make it easier to follow (feel free to tinker with it), and a symbol dump file generated by the program that compiled my code which shows exactly how each command in the source code is converted into numbers that the 6507 can understand.

Also, if you’re interested, here is a PDF of the 1979 Stella Programming Guide.

Edit: Spiceware has also put up an excellent programming tutorial as multiple topics on the AtariAge forums.

Determining Assembly Compile Time in VB.NET

I recently came across a function for determining the date and time a .NET assembly was compiled on. This works for EXEs and DLLs.

Apparently, the date and time that the compiled objects of an assembly are linked together is stored in the header of the final output as a count of the number of seconds that have elapsed since midnight on Jan 1, 1970. Here’s the function that reads this information from the file header and returns it as a DateTime variable:

    ''' <summary>
    ''' Returns the date and time that the specified assembly was compiled on.
    ''' </summary>
    ''' <param name="filePath">A full path to a .NET assembly.</param>
    ''' <returns>A DateTime value.</returns>
    Function RetrieveLinkerTimestamp(ByVal filePath As String) As DateTime

        Const PortableExecutableHeaderOffset As Integer = 60
        Const LinkerTimestampOffset As Integer = 8

        Dim b(2047) As Byte
        Dim s As IO.Stream = Nothing

        Try
            s = New IO.FileStream(filePath, IO.FileMode.Open, IO.FileAccess.Read)
            s.Read(b, 0, 2048)
        Finally
            If Not s Is Nothing Then s.Close()
        End Try

        Dim i As Integer = BitConverter.ToInt32(b, PortableExecutableHeaderOffset)
        Dim secondsSince1970 As Integer = BitConverter.ToInt32(b, i + LinkerTimestampOffset)
        Dim dt As New DateTime(1970, 1, 1, 0, 0, 0)

        dt = dt.AddSeconds(secondsSince1970)
        dt = dt.AddHours(TimeZone.CurrentTimeZone.GetUtcOffset(dt).Hours)

        Return dt

    End Function

I found this function at http://www.codinghorror.com/blog/2005/04/determining-build-date-the-hard-way.html

For more info, check out http://msdn.microsoft.com/en-us/library/ms680313

Detecting 32-bit vs 64-bit OS Architecture in VB.NET

At work I recently had to find a way to determine whether an application was running on a 32-bit or a 64-bit version of Windows.  Stupidly, neither the My.Computer.Info nor the System.Environment classes contain details on whether or not the OS is 32 or 64 bit, though they contain other information describing the OS.

I did a lot of searching on the web, but found the results quite lacking. Many people recommended I simply check the length of an IntPtr:

If IntPtr.Size = 8 Then

	' 64 bit machine

ElseIf IntPtr.Size = 4 Then

	' 32 bit machine

End If

This works fine…but only if your application is compiled for “AnyCPU” as the target CPU.  If you compile your assembly with the target CPU “x86”, for example, IntPtr.Size will always be 4 bytes, regardless of the OS architecture.

Others recommended searching the file system for the existence of a “C:\Program Files (x86)” folder.  Ugh.  Not only does that mean accessing the slooooooow hard drive, but it’s also accessing data that the user can modify himself.  That’s just not right.

A third recommendation had to do with searching for the existence of particular environment variables, but those, too, are editable by the user and not guaranteed to exist.

A fourth recommendation I came across involved using Windows Management Instrumentation.  WMI is a Windows OS infrastructure which provides information about the OS and available resources (RAM, hard drives, database servers, etc.).  I couldn’t find any proper code example for what I needed, so I came up with one myself.  Here is a method you can use in your VB.NET assemblies to determine whether or not the assembly is executing in a 32-bit or 64-bit OS:

''' <summary>
''' Returns a string describing whether the OS is 32-bit or 64-bit.
''' </summary>
''' <returns>A String value (e.g. "32-bit").</returns>
''' <remarks>If an error occurs, the result will be an empty string.
''' <para>Requires a reference to System.Management.</para></remarks>
Public Function GetOSArchitecture() As String

' More Info on WMI available here:
'
' http://msdn.microsoft.com/En-US/library/aa394239.aspx

Dim osClass As System.Management.ManagementClass = Nothing
Dim result As String = "32-bit" ' Default to 32-bit for OSes which don't support the OSArchitecture property of the Win32_OperatingSystem WMI class.

Try

    ' Get the singleton Win32_OperatingSystem WMI class so we can access properties about the OS.
    osClass = New System.Management.ManagementClass("Win32_OperatingSystem")

    ' Loop thru all properties of the single instance of the Win32_OperatingSystem class and look for the property which will tell us if
    ' the OS is 32-bit or 64-bit.  If the property is not found, the OS is assumed to be 32-bit.
    ' NOTE: I'm not 100% sure if this detects 64-bit versions of XP.  See above MSDN link for more information.
    For Each mgo As System.Management.ManagementObject In osClass.GetInstances
        For Each prop As System.Management.PropertyData In mgo.Properties
            If prop.Name = "OSArchitecture" Then
            result = prop.Value.ToString
            Exit For
        End If
        Next
    Next

Catch ex As Exception

    result = String.Empty

Finally

    ' Clean up
    If osClass IsNot Nothing Then osClass.Dispose()

End Try

Return result

End Function

This code was written in VS.NET 2005 (.NET 2.0).  You’ll need to add a reference to System.Management to your assembly for this method to work.

So, if you’re looking for a simple function that will reliably return whether or not the OS your assembly is running in is 32-bit or 64-bit, use this.  This method *will* return “64-bit” if your OS is 64-bit and your assembly was compiled using the target CPU “x86”.  The only caveats are:

  1. I don’t know if this works under Windows XP 64-bit.  The OSArchitecture property of the Win32_OperatingSystem WMI class is said to not be present for Windows XP, so it probably doesn’t.
  2. If you’re running your assembly from within an emulator, I don’t know if this returns the architecture of the emulated OS or the host OS.  I’m guessing it would return the architecture of the emulated OS.

So, there you go.  Enjoy.

A Challenge to Website Hackers

I am proposing a challenge to all website hackers out there: create a program to automate the registration of phone numbers into the Canadian National Do Not Call List.  I’m sure there must be someone out there with the OCR programming skills to get around the relatively simple captcha on the registration screen:

canadian_donotcall_list

Sadly, even with my phone number on the list I still get at least one unsolicited phone call per day.  There really should be a way for victims of telemarketers, newspapers, survey companies, and political parties to charge said entities for unwanted, unsolicited calls.  If only people cared about happiness and well-being rather than money.  Still, at least the token effort of this list is something.

So, if you have the skills, why not use them for good instead of evil?  Get every valid phone number entered into the Canadian National Do Not Call List.