Changing Atari VCS Graphics -- The Easy Way

by Adam Trionfo
OC&GS Newsletter, April 1999
(Re-Written and Updated, March 2012)

This tutorial has been completely revamped and updated. Some of the features present in the original tutorial (as printed for the paper version of the Orphaned Computers & Game Systems newsletter in 1999) were cut for the original HTML conversion that had been been online from about 2000 to early 2012. All of those features have been restored and are present in this version. New features included in this updated version are links to all of the programs used in this tutorial as well as a major overhaul of the text.

     -- March 28, 2012, Adam Trionfo

This document explains two easy methods that may be used to change the graphics in an Atari 2600 (aka Atari VCS) game. A step-by-step example is provided that gives the details on how to change the graphics in Space Invaders. No programming experience is required to follow these instructions.

Table of Contents:

  1.  Introduction
  2.  And People Do This How...?
  3.  No Assembly Required
  4.  The Essential Hardware
  5.  The Essential Programs
  6.  Getting Set Up
  7.  Method I -- No Hex Involved
  8.  Method II -- Some Hex Involved
  9.  Playing the Hacked Game on a Real Atari 2600
  10.  It Worked! Now What?

I.  Introduction

Somehow you found yourself reading the opening sentence of an article about how to change the graphics of Atari's first cartridge-based system: the Atari 2600, sometimes referred to as the Atari VCS. How did you get here?

Do you think of yourself as a real Atari VCS fan -- a collector and player? Perhaps, instead, you are just a casual VCS player. You have some of the best games and you avoid the bad ones. When you heard of the Stella Gets a New Brain CD compilation from 1996 that contains twelve Starpath Supercharger games plus rarities, did you have to own one to complete your collection? Possibly you have no idea what the Stella Gets a New Brain CD even is. Do you have an Atari VCS emulator installed on your computer along with some cartridge ROM image that are of interest to you? Was one of the modern console Atari 2600 compilations your first experience with Atari's first cartridge-based cosole? Maybe you stumbled on this site quite by accident and are wondering why I don't just get on with it...

Whichever category you place yourself in isn't important. This article is aimed squarely at the player (not the programmer) who is interested in making a VCS game a little more of their own by changing the graphics that have become so familiar to us all.

Even a casual scouring of the Net for VCS information will pull up enough information to keep anyone occupied for a lifetime. So if you are just a little bit curious, where do you start? That was the proposition that lay before me in the summer of 1998. I looked around for information that was aimed at a non-assembly-programmer: I never found any.

On the Internet, there are a number of games that have had the graphics changed. One of the more interesting graphic conversions of an Atari VCS game that I came across at that time was Beast Invaders, a hack of Atari's Space Invaders. The hack was done by Yak (of Tempest 2000 fame). The game is infested with- what else- Llamas. It was this graphic conversion that first intrigued me to look beyond the mere playing of VCS games. After a little work I was able to change Space Invaders myself.

I wish to encourage tinkering with VCS games. I have tried to make this a step-by-step approach to changing the graphics in a 2600 game -- specifically Space Invaders. This article is a guideline to the programs and a few of the techniques that I used to convert the graphics in Space Invaders to OC&GS Invaders.

If you have the skill to use Windows and a few programs that use the command-line (which many people refer to as the "DOS Box"), then you should have no problem with the programs required to change the graphics in a VCS game. Perhaps, after trying this out, someone reading this will say, "Wow, this is so easy. I'm going to make myself a new VCS game." I hope so!

II.  And People Do This How...?

How do people make new games for the VCS? How do they change the graphics in a classic game like Space Invaders? Do you (like me) look with awe at anybody who has the ability and devotion to learn to program the VCS? Creating an Atari VCS game is beyond me at this point. That fact did not stop me from wondering how to change in-game graphics.

If you ever thought that it would be neat to replace some Atari game graphics with some of your own, then you will be thrilled to know that it is rather easy. The best part of all is that it requires no programming skill.

III.  No Assembly Required

I shall discuss two ways to change the graphics in an Atari VCS game; neither requires any assembly programming skills. Surprised? The reason for this is that there are tools available that allow anyone, even a casual computer user, to look at what makes a VCS game tick. Devoted programmers have been kind enough to donate the tools they create to the public domain.

To change graphics in a VCS game, one only needs to know addition and conversion from decimal to hexadecimal. Uh-uh. You don't know how to change Base-10 (regular numbers) to base-16 (hex numbers)? No problem- most modern calculators can do it for you- or use the scientific calculator in any version of Windows.

Does that still sound like too much work? Well then you will be pleased to know that there is an even easier way that requires no math at all. This is for the person who wants to stay away from the code as much as possible.

I have a preference for the method that requires the use of addition and hexadecimal conversion. This is because I would like to eventually learn a little 6502 assembly language. Of the two methods, you can choose the one that suits you best.

IV.  The Essential Hardware

A VCS game can be changed in a number of different ways: I will only be discussing how to do this using a computer running Windows. This article was originally written on a 486 running Windows 98. Many of these programs may work on older and slower computers (even a 386 or older!). I'm aware that that sort of computer would not be of easy access-- and one is not needed. This version of the article, updated in 2012, uses Windows XP. I expect that Microsoft's newer versions of Windows should work too.

If you plan to run your game on a real Atari VCS, then you will also need a VCS and a Starpath Supercharger (which will plug into your computer's speakers or directly to your sound output on the computer). I'm aware that there are other methods of playing Atari games on the Atari 2600, but the Supercharger is fairly common, so I will cover that method only.

If you prefer another hardware or software platform, then don't get discouraged. Even though this article will be covering programs for machines running Windows, all that is going to be described here can be done on the more popular machines such as the Macintosh and Linux. If you're looking to try-out esoteric computers, then this can even be done on a Commodore 64 or Amiga. If you're not running Windows, than use this tutorial more as a general method to change the graphics and not as a how-to guide.

V.  The Essential Programs

You do not have to be running Windows to use any of these programs. However, the multitasking capability of Windows will make the task a little easier for you. The best place to get the software described here is from Dan Boris's Atari 2600 Tech Info Page. Dan's web site is crammed with additional Atari technical information as well as commented VCS source code. A link to the page is provided here:

The essential programs needed to change the graphics in a VCS game are:

  1. Atari 2600 / VCS Emulator

         An Atari 2600 emulator for Windows will be used to run your modified game ROM during the test phase.
         When this article was originally written, PC Atari Emulator (PCAE) by John Dullea was used as it worked best on my Windows 98 computer. Since that time many other popular emulators have appeared. I could not get PCAE 2.5 for DOS or 2.6 for Windows to run under Windows XP without trouble. Therefore, I no longer recommend their use for this tutorial.
         Stella, a newer Atari emulator is updated frequently. It also has many more features and supports nearly every Atari 2600 game. For this reason, this tutorial has been modified to use for use with Stella. Download the latest version from the Stella homepage. If you have difficulty obtaining Stella from the homepage then a link to the current-at-this-time (February 2012) version of Stella is available as a local download. Also, if Stella changes over time enough that this tutorial no longer works with it, then it may also be a good idea to use the local link.

         Stella Emulator (Homepage)
         Stella 3.5.5 for 32-Bit Windows (Local Version)

    Although PCAE is not used for this tutorial, local links to the programs are provided for completeness. Again, this older emulator is not required to follow this tutorial.

         PC Atari Emulator 2.5 for DOS (Local Version)
         PC Atari Emulator 2.6 for Windows (Local Version)

  2. DiStella (By Dan Boris and Bob Colbert)

         This program is used to take an Atari VCS ROM image, as used with an emulator, and change it into source code. When a program is assembled, all documentation is left out of the executable file; so when the disassembly is complete there is no documentation. There are some novel ways that DiStella allows you to track graphics down without any knowledge of assembly language required.

         DiStella 2.10 (Local Version)

  3. DASM (By Matthew Dillon)

         This is a high level assembler that can be used for the 6502. It uses a text file as input and generates a file that is executable on the VCS. It is completely CLI (Command Line Interface) driven, but don't let that scare you away. Note: I had to read the documentation file dasm.doc using the MS-DOS editor, otherwise it looked garbled.
         In conjunction with Distella, DASM is the method I prefer to change graphics in a game. It gives me the feeling of additional control that I don't get while using Showgfx and Editgfx.

         DASM 2.02 (Local Version)

  4. Showgfx / Editgfx (Bob Colbert & Dan Boris)

         Showgfx is used to create an ASCII listing that can be examined for graphics very easily. It requires no knowledge of the hexadecimal numbering system. Editgfx takes the ASCII file that ShowGfx creates and changes it back into a binary file. Folks, it doesn't get any easier to change VCS graphics than this!

         Showgfx / Editgfx (Local Version)

  5. Makewav (By Bob Colbert)

         There is no rule that says you ever need to run a modified game ROM on a real VCS. It just seems much more satisfying watching a wood-grained Atari Video Computer System run a modified game.
         Makewav will convert a VCS binary file into a wav file that can then be loaded into the Starpath Supercharger on a real 2600. This means that you must limit the size of the ROM to what the Supercharger can handle- 6K. This won't be a problem for us as we'll be modifying Space Invaders, which is a 4K ROM.

         Makewav 4.2 (Local Version)

  6. Space Invaders Cartridge ROM Image

         In order to change the graphics in Space Invaders, you will need the spaceinv.bin file. This ROM file contains a copy of the VCS game code. There is no way to follow these instructions without this ROM image.

         Space Invaders (Local Version)
         Space Invaders Page (

  7. Beast Invaders, Hack by Jeff Minter

         This hacked game is not absolutely required, but it was the inspiration that led me to originally change the graphics in Space Invaders. Besides, haven't you always wanted to save the earth from those dastardly invading llamas from space?

         Beast Invaders (Hack) (Jeff "Yak" Minter's ROM Hack)(Local Version)

  8. OC&GS Invaders, Hack by Adam Trionfo

         This hacked game is also not absolutely required, but OC&GS Invaders was the final result that I created in the summer of 1998 when I hacked the graphics of Space Invaders. Now it is lost in an overwhelming tide of Space Invaders hacks, but in 1998 hacks of any kind for the Atari VCS were few and far between. It is only now, in 2012, that I make this hack publically available.

         OC&GS Invaders (Hack) (Adam Trionfo's ROM Hack)(Local Version)

VI.  Getting Set Up

Follow these steps to get all of the programs you need into one place, which I will refer to as the programming directory. Later, when you are asked to type in a command, you must be in the programming directory.

  1. Decompress all the zip files into separate directories.
  2. Install the Stella Atari 2600 emulator.
  3. Create a directory on the C:\ drive called "Atariprg." There is nothing special about this name, but it is what this tutorial will use in all examples. If you choose to call your directory something else, then remember that this tutorial will use the directory name "Atariprg" in all examples.
  4. Place the following files from the separate directories into another separate directory.
           1.   dasm.exe
           2.   distella.exe
           3.   Editgfx (from the 2600gfx directory)
           4.   makewav.exe
           5.   Showgfx (from the 2600gfx directory)
           6.   spaceinv.bin
  5. If you want to try Beast Invaders and OC&GS Invaders, then place those bin files into the separate directory.
  6. Play Space Invaders using Stella to assure that the emulator has been installed correctly. The easest way to play the game is to start Stella in Windows and then navigate to the directory that holds the Space Invaders ROM. An alternate method would be to use the command line and navigate to "C:\Program Files\Stella" and then type:
         stella C:\Atariprg\spcinvad.bin
  7. If the emulator works but is not running at the correct speed then read the Stella documentation for suggested fixes.

VII.  Method I -- No Hex Involved
(An Easy Way to Change VCS Graphics)

Using this method is the easiest way to change the graphics in a VCS game. However, if you ever intend to change more than just a game's graphics, then you will need to use the second method. Remember that all the commands in these steps must be entered from your programming directory called "Atariprg."

If you're running any modern version of Windows, you can find the prompt at which you'll be typing your commands by clicking the Start button, clicking All Programs, clicking Accessories, and then clicking Command Prompt.

To make sure that your commands will be entered while you're in the correct directory, you'll probably have to use the command for changing directories (cd) before you do anything else. An example would be: cd c:\Atariprg

If the path to your Atariprg directory is longer than that, refer to the location bar at the top of the visible Atariprg folder window to determine the entire path that should be entered after cd. The prompt should ultimately display the current path and directory, ending with \Atariprg> -- and it will remain that way until you change directories again or exit the Command Prompt.

For those who have never used the Command Prompt before, or need a quick refresher, I suggest using a search engine with the phrase "how to use the windows command prompt." This will likely bring up millions of links. Pick one that you like and check it out. Spending a few minutes learning how to change directories, list, copy and delete files will pay dividends later.

  1. Create a text file that displays the contents of each byte (which includes graphics) in Space Invaders. It is important to know the size of the game ROM. Space Invaders is 4K, or 4096 bytes. To create the text file, enter the following command (note that the number before 4096 is the number '0' and not the letter 'O'):
         showgfx spcinvad.bin 0 4096 > spcinvad.txt
  2. Now, using a text editor (Windows Notepad will work fine with the "Courier New" font), you must look through spcinvad.txt for the graphics. Showgfx displays the contents of every single byte. Here are a few tips to find graphics:
    1. The numbers on the left side of the spcinvad.txt file are hexcadecimal. The range is 0000 - 0fff. In decimal this translates to 0-4095. That is 4096 bytes, or 4K.
    2. Graphics are going to be stored upside-down most of the time (this is certainly the case with Space Invaders).
    3. Sometimes game graphics are split into pieces. Train your eyes to see a character in less than whole parts.
    4. Not all the graphics are in one place. In Space Invaders, for instance, you will find that game graphics are separated from the game score characters.
    5. Some of the graphics will be obvious, while others will not. So, if you can't find what you are looking for, keep looking!

  3. This is what the player's ship looks like in spcinvad.txt. Notice the shape of the player's ship takes up ten bytes, from memory locations 0C0A to 0C13 (in decimal, that range of 10 numbers is 3082 to 3091). If you search for the text "0c0a" then you will find the bottom of the player's ship. In the next step, we will change the ship to a happy face.
    0c0a |XXXXXXX |
    0c0b |XXXXXXX |
    0c0c | XXXXX  |
    0c0d |XXXXXXX |
    0c0e |  XXX   |
    0c0f |  XXX   |
    0c10 | XXXXX  |
    0c11 |  XXX   |
    0c12 |  XXX   |
    0c13 |   X    |	 
  4. Unlike method II (below), changing the graphics with this method requires no math at all. Just change the X's to form the shape of a happy face. Notice that we are creating it upside-down. If we created it right-side up, then the face would be upside-down on the screen when you play the game.
    0c0a | XXXXX  |
    0c0b |X     X |
    0c0c |X XXX X |
    0c0d |X X X X |
    0c0e |X     X |
    0c0f |X     X |
    0c10 |X X X X |
    0c11 |X     X |
    0c12 |X     X |
    0c13 | XXXXX  |
  5. After you have saved the changes to spcinvad.txt (making sure that the file has been saved as ASCII, which Notepad does by default), then it is time to create a binary file for the VCS emulator. Make sure to call the new file something else besides spcinvad.bin. In this example I call the new binary file "testspac.bin."
         editgfx spcinvad.txt testspac.bin
  6. Now use your preferred method to run Stella to test the changes. Remember that the new file that you want to play is called "testspac.bin". If everything went well, then the player's ship now looks like a happy face.

  7. If you search through spcinvad.txt, some of the other Space Invaders graphics are easy to spot. For instance, try changing the invader on the top row. Those graphics are located from 0c96 to 0c9f (invader's first animation) and 0c8c to 0c95 (invader's second animation). After you make the changes to spcinvad.txt and save the file, use editgfx to create a new binary file as you did above. Test the new file in Stella.

  8. Once you've changed the top invader's graphics, try locating the rest of the invaders and changing those graphics too.

You've just changed the graphics in your first Atari VCS game. Pick another game and see what you can find in there. You may soon find that it is addictive changing the graphics in games!

VIII.  Method II -- Some Hex Involved
(Another Easy Way to Change VCS Graphics)

The second method used to change a VCS game's graphics is only a little more complicated than the first. Here is an overview of the steps involved: disassemble the ROM, find the graphics, change the hex data statements, and assemble the ROM again. This method is a little more involved, but the effort it takes is well worth it. If, at another time, you intend to modify a game's gameplay, or even make a game yourself, then these steps are mandatory knowledge.

  1. Disassemble Space Invaders. This step creates the source file needed to change the graphics. The following command will create the source file for Space Invaders:
    	 distella -paf spcinvad.bin > spcinvad.src
  2. Just to make sure that the disassembly worked okay, assemble the source file using DASM. Type the following:
    	 dasm spcinvad.src -f3 -otest1.bin
  3. Using a directory listing, check the size of the file test1.bin. It should be 4096 bytes.

  4. If the file size is 4096 bytes then it's time to make sure that the two files are byte-for-byte identical. Use the File Compare (FC) command-line utility included with Windows to compare the original Space Invaders ROM file with the newly created file test1.bin. Type the following:
         fc spcinvad.bin test1.bin
    Your results should say "FC: no differences encountered." If some differences are found, then something went wrong during the disassembly process or the assembly process. I've never had the files not match. If you are having trouble at this point then make sure that you have followed the directions very carefully to this point.

  5. At this point we are sure that test1.bin is identical to the Space Invaders cartridge ROM. Normally we are purposefully altering the file by changing the graphics. Start Stella and play test1.bin. The game will play as normal.

  6. If you are at this step, then you have disassembled a ROM, assembled that same ROM, and tested it to make sure that it works. In this step we will determine areas of the source file created with Distella that are most likely to contain graphic data. Then we will create a configuration file that will help us view our source file in a manner that the data will become easier to look for graphics.
    1. Using a text editor (Notepad works well), view the source, called spcinvad.src. created by Distella.
    2. Search for .byte.
    3. Mark the beginning address and the ending address. For Space Invaders there are two places where these exist (FBFE-FD66 and FF4C-FFFF).

  7. You can skip this last step if you like, as it's here to give a brief background... and maybe to confuse you. If you read it, scratch your head and then feel even more confused, then I recommend forgotting that you read it at all.

    If you have never used hex before then all these addresses will make no sense to you. You're probably still wondering something like "I don't see FD66 or FFFF." That is because each piece of data is held in a higher address than the last piece. The fastest way to get the correct addresses of areas that hold graphics (actually just the most likely areas to hold graphics) from any ROM is to look at the first and last address where .byte exists. For instance, to understand how I computed the ranges FBFE-FD66, examine this excerpt from the source file created with Distella:
         Address       Data Contained at Address
         -------       -------------------------
         LFBFE: .byte $00, $00, $00, $00, etc
                ...Additional bytes filled with data
         LFD61: .byte $03, $17, $2B, $23, $75, $B4
                      ^    ^    ^    ^    ^    ^
     Addresses        |    |    |    |    |    |
     keep counting -> FD61 FD62 FD63 FD64 FD65 FD66	
    Still confused? Don't worry. This involves a completely new number system: hexadecimal. You wern't born knowing how to count to 10. You had to learn. The same is true with this. I recommend reading the first chapter of any 6502 programming book, which will usually start off with easy-to-understand explanations of hexadecimal. Several books of this sort are available in pdf format on the internet or can be bought used at reasonable prices on the Internet. For instance, here is a link to Programming the 6502 by Rodnay Zaks on

         Programming the 6502 by Rodnay Zaks

    If you just want to change the graphics and don't care about hexadecimal and now you're sorry that you even heard about it, then don't worry. Using Method I to change the graphics will work for many Atari games.

  8. Using a text editor, create an ASCII configuration file called spcinvad.cfg containing only the following information (both the name of this file and its contents are case-sensitive). Save it to the programming directory.
    In some cases Notepad may add a .txt file extension to the filename so you may end up with a file called spcinvad.cfg.txt. If this happens, then the file needs to be renamed or else it won't work with Distella. Simply rename it from the Command Prompt or use Windows Explorer.

    Notice that the first line of the code that we're dealing with in spcinvad.cfg contains the first and last .byte address -- the same is true of the second line of the configuration file.

    If you don't understand how the hex values of FD66 and FFFF were reached, then when you are doing this for another game's ROM image, just pick the first address and one near the end. For instance in this case choose FD61 instead of FD66. No matter what you choose it is okay, as DASM will just display what is in non-graphic bytes as graphics in the source file.

  9. After the configuration file is made, it is time to disassemble the binary file again, this time revealing code that is a little easier to find graphics in. Type:
         distella -paf -cspcinvad.cfg spcinvad.bin > spcinvad.src
  10. View the new spaceinv.src file. Search for FC0A and start examining the file from there:
           .byte $FE ; |XXXXXXX | $FC0A
           .byte $FE ; |XXXXXXX | $FC0B
           .byte $7C ; | XXXXX  | $FC0C
           .byte $FE ; |XXXXXXX | $FC0D
           .byte $38 ; |  XXX   | $FC0E
           .byte $38 ; |  XXX   | $FC0F
           .byte $7C ; | XXXXX  | $FC10
           .byte $38 ; |  XXX   | $FC11
           .byte $38 ; |  XXX   | $FC12
           .byte $10 ; |   X    | $FC13
    Beside each .byte are two hex digits (the '$' signifies that the number is hex). Using an 'X' as a comment, a graphic representation of what each byte contains follows the hex data . This is followed by the data's memory location.

  11. Change the player's ship into a happy face by changing each line's hex value after .byte.

    Here is a quick explanation for those who don't know binary or hexadecimal. Each 'X' represents represents a weighted binary digit. There are 8 bits in a byte. Each row of up to eight X's represents one byte. In order to get the byte's value, we have to add up each value that has an X under it. An 'X' value furthest left represent 128 while an 'X' value furthest right represents a 1. For example, the very bottom of the player's ship is held in address FC0A. That value is FE. Here is how to calculate the value needed for the bottom of the player's ship at address FC0A:
            Binary Weighted Bits
         128  64  32  16  8  4  2  1  = Numbers = 255 ($FF)
         X    X   X   X   X  X  X     = Weighted X's = 254 (or $FE)
    Add up the seven numbers that have an X under them. These seven numbers are 128, 64, 32, 16, 8, 4 and 2. This totals 254 in decimal. The decimal value of 254 converted to hexadecimal is $FE.

    As another example, here is how to calculate the value needed for the bottom of the happy face at address FC0A.
            Binary Weighted Bits
         128  64  32  16  8  4  2  1  = Numbers = 255 ($FF)
              X   X   X   X  X        = Weighted X's = 124 ($7C)
    Add up the five numbers that have an X under them. These five numbers are 64, 32, 16, 8 and 4. This totals 124 in decimal. The decimal value of 124 converted to hexadecimal is $7C.

    This explanation is extremely terse. The first chapter of a 6502 book will usually explain binary and hexadecimal number systems.

    Each byte of a graphic must be translated to hexadecimal in this manner. Use a calculator to help translate between decimal and hex digits. When you are done, save the file (without changing the name). Note that you only have to change the hex numbers-- there is no need to change the X representations (as was the case with Method I), as these are only comments and will have no bearing at all on the final binary file.

    When you're finished, the finished happy face will look like this:
           .byte $7C ; | XXXXX  | $FC0A
           .byte $82 ; |X     X | $FC0B
           .byte $BA ; |X XXX X | $FC0C
           .byte $AA ; |X X X X | $FC0D
           .byte $82 ; |X     X | $FC0E
           .byte $82 ; |X     X | $FC0F
           .byte $AA ; |X X X X | $FC10
           .byte $82 ; |X     X | $FC11
           .byte $82 ; |X     X | $FC12
           .byte $7C ; | XXXXX  | $FC13
    Note that in the above example, I did change the comments to look like a happy face. However, I could have just as well have left the souce code like this:
           .byte $7C ; |XXXXXXX | $FC0A
           .byte $82 ; |XXXXXXX | $FC0B
           .byte $BA ; | XXXXX  | $FC0C
           .byte $AA ; |XXXXXXX | $FC0D
           .byte $82 ; |  XXX   | $FC0E
           .byte $82 ; |  XXX   | $FC0F
           .byte $AA ; | XXXXX  | $FC10
           .byte $82 ; |  XXX   | $FC11
           .byte $82 ; |  XXX   | $FC12
           .byte $7C ; |   X    | $FC13
    The above source code with the hex digits changed, but with the comments left alone, will still assemble into a version of Space Invaders that has the player's ship replaced with a happy face.

  12. It is time to assemble the source and see your new graphic. Type this:
         dasm spcinvad.src -f3 -otest1.bin
  13. Play the new version of Space Invaders using Stella. Space Invaders will play as normal, but the player's ship has been changed into a happy face.

IX.  Playing the Hacked Game on a Real Atari 2600

If you would like to play your hacked version of Space Invaders on a real Atari 2600 using the Starpath Supercharger, then use Makewav to create a wav file on the computer.

There are various speed options that can be used with Makewav. Which one you choose depends on how well the combination of your computer, Atari and Supercharger work together. You will find that some load speeds work better than others with your personal setup. A balance has to be struck between getting a file that loads correctly and a file that loads quickly. Note that even the slowest option loads a 4K file in about sixteen seconds.

The option that affects speed is the -f option. Here is what the option does, taken directly from the manual:

This flag allows you to change the speed of the tranfer. The valid range is 0-4 and the higher the number the faster the load. Don't be surprised if the faster transfers are not reliable, they are really pushing the limits of the audio circuitry. Suggested values for various media are: Audio Cassette = 0, CD = 1 or 2, Computer = 2, 3, or 4.
  1. Here is an example of using Makewav that should work on most machines:

         makewav -ts -f2 spcinvad.bin

    This version of the WAV file should load in about seven seconds.

  2. The first Makewav example should work well for most users. It creates a file that loads quickly and reliably. With my setup, I've never been able to create a WAV file that loads at a speed faster than 2. Loading a 4K game in about seven seconds is fine with me. If you want to experiment with loading the file faster, try these other commands, but remember, they may not work at all for you:

    1. makewav -ts -f3 spcinvad.bin
    2. makewav -ts -f4 spcinvad.bin

    Don't dispair if these faster options don't work. You may be cutting the speed down to about two or three seconds, but when compared to seven second load time, does it matter?

  3. Once you've created a WAV file, hook up the Supercharger to the computer's speakers or directly to the sound output of your computer. Often, you will be able to get a good load if the Supercharger is hooked up to computer speakers, but the file will fail to load at all when the Supercharger is hooked directly to your computer.

  4. Play the spaceinv.wav file using any wav player. Adjust the volume as needed until the game loads. If the file doesn't load, then try loading at a slower method. The slowest load would be:

         makewav -ts -f0 spcinvad.bin

    If the slowest load doesn't work than your problem is how the Supercharger is hooked up to the computer.

X.  It Worked! Now What?

You now have a happy face instead of the player's ship to do battle with the evil alien invaders. It didn't take long to do, so why not change the alien invaders as well. Make that terrible UFO into your initials. Make the shields into Pac-Man. Be creative.

Using these same methods, it is possible to change the graphics in most any Atari VCS game. Eventually, though, no matter how much you enjoy it, changing the graphics will become rather boring. The problem is that there is a real boundary to how creative you can be.

The solution to this boredom is to modify the actual code of a VCS game. I have not attempted this yet, but it is the next step that I will be taking. There is plenty of documentation on the 6502 and the VCS. There is also an abundance of commented source code available. So when you are ready for that "next step," don't be afraid to take it.

The logical progression after modifying a game's code is to create a game from scratch. I am not at that stage yet, hopefully someday I will be there. Until that time, as I learn more about the VCS, you can be sure to read about it in upcoming issues of OC&GS!

Good luck with all your efforts! -- AJT