Transcription

Your support is greatly appreciated! https://www.patreon.com/8blit

Welcome to 8Blit, In this episode we’ll explore a little bit about how Atari VCS games were made in the past, and how we can upgrade our current process using a free Integrated development environment, along with a really great extension. I hope you’ll stick around as we’re introduced to Visual Studio Code, and the Atari Dev Studio.

So, let’s get started!.

When the ATARI VCS first hit store shelves in September of 1977, it sold over half a million units in its first year, with only 9 games available in it’s library at launch. However, by the end of 1979 the VCS had a customer base of over 2 million units with an extended library of 36 games. Over the next decade or so, this expanded to over 30 million units and literally hundreds of available games.

Since the ATARI VCS was discontinued in 1992, the homebrew scene took over the development of new games for the system, with over a couple hundred releases over the years. Many of which are available to purchase on cartridges from the AtariAge website. I’ll include a link in the description. Even today, there’s an active developer community producing several games each year.

Some developers create for the VCS out of nostalgia, creating games for the first game console they had growing up, spending countless hours playing with family and friends. Others do it for the challenge. Working with extremely limited resources, on hardware meant only for simple games. Pushing the limits of a system over 40 years old.

Whatever your reason, programming for the VCS can be baffling, even frustrating at times, but in the end it can be a very worthwhile and rewarding endeavor. When you finally create a stable screen, draw your first graphic, start creating a new game, you become a part of the history, a part of the future, and a stewart to the legacy of the Atari VCS.

If you google the language originally used to program games for the VCS, you get some confusing results. Some people say the C language was used, another person insists they were programmed in Atari Basic, but the majority consensus is on Assembly language.

While C is an extremely flexible language and is certainly used to program for the 6502 and 6507 processor, the output of a purely C implementation would not be precise enough for most VCS games. The VCS requires precision timing due to hardware limitations, so in order to do this, the C implementation would most likely be an outer wrapper for embedded Assembly instructions, and therefore more Assembly language than C language. Atari basic however is entirely out of the question, as it used an interpreter to run Basic code rather than compiling the code into the machine language that the 6502 processor executes. Atari Basic was available in 1979, but it was first used with the Atari 8-bit line of computers, and required it’s own cartridge to run the programs.

Assembly language however, gives you the ability to control exactly what the processor is doing, which is essential to minimize the number of machine cycles your code uses to perform each task, such as drawing your player graphics and other game operations, in order to not only fit as much in to the limited time you have, but also to squeeze the game into the small cartridge size, which was only 2 kilobytes when the VCS was released. What do you think, am I way off? What are your thoughts? Let me know in the comments below!

Originally, VCS games would have been programmed on one machine, sent to another machine with a cross compiler, and the binary sent somewhere else to burn test a rom to insert into a cartridge and then inserted into VCS hardware. If there was a bug, then you’d review the code, make your corrections, and then start the whole process again.

These days we’re privileged enough to have access to several free tools for the VCS that enable us to build and test in a matter of seconds. We already have experience writing our code in a text editor, compiling it from the command line with the dasm assembler, and testing our creation within the stella emulator. This is a great process, and certainly more streamlined than the original VCS developers had at their disposal. However, there are some other tools out there that make it even easier. One such tool is the Atari Dev studio.

Released in 2019, Atari Game Studio is described as a ‘one-stop-shop for any programmer’. That is, programmers wanting to develop for the Atari 2600 or 7800. Which, if you’re here. I imagine thats you!

Atari Dev Studio is an extension for Microsofts’s cross-platform Visual Studio Code, and comes packaged with the BATARI Basic and 7800 Basic compilers, and the DASM assemblers, as well as the Sella and A7800 emulators. All of these are automatically installed for you and set up when you add the extension. It features syntax highlighting, a very handy reference tool, a sprite editor, and other bells and whistles. But, enough talking about it. Let’s have a look at how to set it up, compile and execute a program.

The first thing you’ll need is Visual Studio Code, which is available to download free for Windows, Linux, and MacOS. I’ll include a link to the website in the video description. After you’ve downloaded and installed Visual Studio Code, open up the application. Let’s start by downloading all the 8Blit examples from GitHub. We’ll do this by cloning the 8Blit Repository.

Just click on ‘Clone Git Repository’, and then in the location box above, we’re going to paste the 8Blit Repository URL, which will also be included in the video description.

A window will pop up where we can select which folder we want to clone the repository. I’m going to use my current working folder, but you can select any other folder on your machine. Once you have your folder selected, click ‘Select Repository Location’.

Visual Studio Code will start pulling all the files from the Repository. Since the examples are all small text files, this should be completed quickly. When it’s done you can click on the ‘Open’ button to have Visual Studio Code open the cloned repository. In the explorer bar we can see a folder for each of the previous episodes. Let’s open up one of the examples from the last episode.

In the code tab we can see the Assembler source code, and we can scroll through it using the scroll bar on the right.

At this point, Visual Studio Code doesn’t know what to do with our code. Which we can see when we try to run it. Currently, it thinks we’ve opened up a plain text file. We can see this down at the bottom left of the screen. From here we can select what our file is, but if we look at the available types, none of them are for the dasm assembler.

Up at the top of the list we can search the Visual Studio Code marketplace for extensions that can handle files with the ‘asm’ extension. As you can see, there are lots of available extensions for Assembly language, but the one we’re looking for today is the Atari Dev Studio. Clicking on the extension will bring up an information page, and from there you can click on the ‘Install’ button.

When it’s down installing we can go back to our example code and see that it now features syntax highlighting making it much easier to read, and the file type is now set to ‘dasm’. Plus, if we hover over an instruction, a handy popup window shows us additional information about each of the 6502 instructions. Such as the name, the direction the data flows, what processor status flags it affects, along with the difference addressing options, the number of bytes the instruction uses, and the number of machine cycles it takes to execute for each addressing mode.

We can try compiling the example using the little ‘play’ button on the bottom bar. This will pass the code to the ‘dasm’ assembler and show the results of the build in the ‘output’ window. The Atari Dev Studio also installed the ‘Stella’ emulator, which we can automatically launch after building our code by clicking on the little ‘rocket’ icon.

When it comes time to draw your graphics, you can use the built in ‘Sprite Editor’. Create a new project to define what Console you’re using, the dimensions of the graphic, the region palette you want, and how many colors to use. For the Atari 2600, one is the only option. You can set the background color for the editor to make sure your background and sprite graphics will look good together. For the sprite I’m going to choose a blue, select the ‘draw’ tool, and then start drawing a character that might look familiar to you. If you make a mistake you can use the ‘erase’ tool to clean up.

Now that we have our first sprite, I’m going to duplicate it, and then modify the new copy to create two frames for an animated character. We can save our project to work on later, as well as our palette. Most importantly we can export our sprite into several different formats depending on the technology you’re using to build your game. Opening up our saved file we can see there’s a data table for two sprites in bottom to top orientation. If we copy the first one, paste it into our example file, add a zero’s byte at the top, and then click on the little rocket icon to assemble and launch Stella, we have ourselves our very own ghost from Ms. PacMan.

Overall, the Atari Dev Studio is a solid extension for Visual Studio Code. It’s easy to use, not overly bloated with features you never asked for, and it’s well supported. I highly recommend you give it a try. Let me know what you think in the comments.

I want to thank everyone for your continued support.

If I’ve peaked your interest in developing for the Atari VCS, or if you found this video interesting, please let me know with a like, a share, a comment, or all of the above. If you haven’t already done so, please consider subscribing to the channel to keep updated when new videos come out. As always, the example code for this episode, and all previous episodes are available in our github which is linked in the description.

As always, thanks for watching, and I’ll catch you next time!

Back to top of page