SeaGtGruff

Do you mean running on a user tool script in Crimson Editor or just plain running on Windows XP? My initial attempts to run PCAE 2.7 in your script weren't successful, but I do have that version running stand-alone on XP. My emulator of choice is still z26. I modified your Crimson Editor User Tools script by using E:\Atari2600\z26\Z26.EXE as the Command and $(FilePath).bin -p8 -M1 -n as the Argument and E:\Atari2600\z26 as the Initial Dir. (my C drive is cluttered with other stuff). I meant as a standalone program. PCAE 2.7 ran fine on my other computer, but I can't even get it to start up at all on my new computer. I don't know if it's something to do with the CPU (dual-core), or my version of DirectX (9), or what. But since PCAE 2.5 seems to be the last version which supported passing a game to run as part of the command line, and is also the most recent version that I'm able to get to run on my new PC, I opted for using PCAE 2.5 in the tutorial. Just for the record, this is what I get whenever I try to start up PCAE 2.6 or PCAE 2.7 on my new computer: With 2.7, if I click "click here," it gives me this message, which seems to indicate that kernel32.dll is the problem: But with 2.6, I get this message instead, which doesn't say kernel32.dll: Michael Rideout

I haven't tried 7800 programming yet, but I downloaded your tool for when I eventually do. Thank you for sharing it! Michael Rideout

I'm glad to hear that the instructions were easy to understand and follow. I'd gotten kind of hung up on that session for some reason, but now that it's out of the way, I ought to be able to get back on track during the next week. I might even be posting Session 4 later tonight. One thing I'm curious about, has anyone been able to get PCAE 2.7 to run? I swear, it ran just fine on my old PC; but I can't get it to run at all on my new PC, and I don't know why not. Michael Rideout

batari BASIC for Beginners -- Session 3: Getting Set Up ------------------------------------------------------- It's a good idea to keep things organized on your computer, to help you find things more easily. For this tutorial, we'll create a directory where we'll put most of the programs we'll be installing. You don't have to use the same organization and directory names that I do, but I advise you to use some kind of organization that makes sense to you. The following instructions assume that you want to organize things the same way that I'm going to, and that you're using Windows. If you want to organize things differently, or if you aren't using Windows, then you'll need to adjust the following instructions as appropriate. On your computer, go to the root directory of your C: drive and create an "Atari2600" directory (i.e., "C:\Atari2600"). Inside it, create the following subdirectories: Docs (i.e., "C:\Atari2600\Docs") ROMs (i.e., "C:\Atari2600\ROMs") Screenshots (i.e., "C:\Atari2600\Screenshots") Installing DASM --------------- The batari BASIC package already contains an MS-DOS executable of the DASM assembler, but you might want to download and install the full DASM package, since it includes some documentation that isn't in the batari BASIC package. And if you're using a non-Windows system, you'll need to download DASM to get the version that works on your system. If you don't need or don't want to download the full DASM package, you can skip to the section about "Installing an Emulator." Go to the "C:\Atari2600" directory that you created earlier, and create a "DASM" subdirectory (i.e., "C:\Atari2600\DASM"). Go to the DASM homepage (http://www.atari2600.org/DASM/). In the "DASM Assembler Download" section, click on the link for the newest version of DASM (as I write this, the newest version is 2.20.10b; the date to the left should say "2005," not "2004"). When the computer asks whether you want to open or save the file, click on "Save," then browse to the "C:\Atari2600\DASM" directory, and save it there. Once the file is downloaded, go to the "C:\Atari2600\DASM" directory and decompress it with whatever decompression utility you use-- WinZip, PKUNZIP, Windows' compressed folder feature, etc. You should extract the files to the "C:\Atari2600\DASM" directory, and use the option to keep the directory information, so the files will be extracted into their appropriate subdirectories. Installing an Emulator ---------------------- You need only one Atari 2600 emulator, but you might want to install more than one, especially if you want to try out several to see which one you like best. For this tutorial, I'll be using the Stella emulator most of the time, but I'll give instructions for installing three of the more popular emulators for Windows-- Stella, z26, and PCAE. If you want to install just one emulator, decide which one you want to use, and skip to that section. Or you can follow the instructions to install all three emulators. If you aren't using Windows, you'll need to use an emulator that works with your operating system. Installing Stella ----------------- Go to the "C:\Atari2600" directory that you created earlier, and create a "Stella" subdirectory (i.e., "C:\Atari2600\Stella"). Go to the Stella homepage (http://stella.sourceforge.net/). In the left sidebar, in the "Downloads" section, click on the link for the "Stable Releases." On the next page, click on the link for the newest version of Stella (as I write this, the newest version is 2.1). For Windows, you'll want the "Binary installer (exe) for Windows 98/ME/2000/XP." You'll be taken to another page and asked to select a mirror; just click on the link for the first site, or look for the site closest to your location. When the computer asks whether you want to run or save the file, click on "Save," then browse to the "C:\Atari2600\Stella" directory, and save it there. Once the file is downloaded, go to the "C:\Atari2600\Stella" directory and double-click it to start the installation. You should install the program in the "C:\Atari2600\Stella" directory. Installing z26 -------------- Go to the "C:\Atari2600" directory that you created earlier, and create a "z26" subdirectory (i.e., "C:\Atari2600\z26"). Go to the z26 homepage (http://www.whimsey.com/z26/z26.html). Click on the link to download the newest version of z26 (as I write this, the newest version is 2.13). When the computer asks whether you want to open or save the file, click on "Save," then browse to the "C:\Atari2600\z26" directory, and save it there. Once the file is downloaded, go to the "C:\Atari2600\z26" directory and decompress it. You should extract the files to the "C:\Atari2600\z26" directory. Installing PCAE --------------- For our purposes, we would prefer to use an emulator that can start up playing a particular game. The most recent version of PCAE that can do this is version 2.5, so that's the version we'll use in this tutorial. Go to the "C:\Atari2600" directory that you created earlier, and create a "PCAE" subdirectory (i.e., "C:\Atari2600\PCAE"). The PCAE emulator has no homepage, but you can download version 2.5 from the "Zophar's Domain" website (http://www.zophar.net/a2600.html). In the "PC Atari" section, click on the link for "v2.5." When the computer asks whether you want to open or save the file, click on "Save," then browse to the "C:\Atari2600\PCAE" directory, and save it there. Once the file is downloaded, go to the "C:\Atari2600\PCAE" directory and decompress it. You should extract the files to the "C:\Atari2600\PCAE" directory. Installing batari BASIC ----------------------- The batari BASIC package doesn't divide its files into subdirectories, but if we install them all in the same directory, the directory will become cluttered as we write and compile our game programs. We'll create subdirectories to help us organize things. Go to the "C:\Atari2600" directory that you created earlier, and create a "bB" subdirectory (i.e., "C:\Atari2600\bB"). Inside it, create the following subdirectories: Docs (i.e., "C:\Atari2600\bB\Docs") Includes (i.e., "C:\Atari2600\bB\Includes") Projects (i.e., "C:\Atari2600\bB\Projects") Source (i.e., "C:\Atari2600\bB\Source") The version of batari BASIC that we'll be using (0.99b) hasn't been posted on batari BASIC's "semi-official" homepage yet, so we'll have to download it from batari's (Fred Quimby's) blog on the AtariAge website (http://www.atariage.com/forums/index.php?automodule=blog&blogid=134&). Scroll down to the "bB latest build" entry, and click on the link for the "batari_Basic_Bleeding_edge_99b.zip" file. When the computer asks whether you want to open or save the file, click on "Save," then browse to the "C:\Atari2600\bB" directory, and save it there. Once the file is downloaded, go to the "C:\Atari2600\bB" directory and decompress it. You should extract the files to the "C:\Atari2600\bB" directory. Now comes the fun part! First, move (drag and drop) the following file into the "C:\Atari2600\bB\Docs" directory: license.txt Next, move the following files into the "C:\Atari2600\bB\Includes" directory: 2600basic.asm 2600basic.h 2600basicfooter.asm 2600basicheader.asm banksw.asm bankswitch.inc default.inc div_mul16.asm div_mul.asm fixed_point_math.asm macro.h multisprite.h multisprite.inc multisprite_kernel.asm pf_drawing.asm pf_scrolling.asm score_graphics.asm startup.asm std_kernel.asm std_overscan.asm std_routines.asm vcs.h Next, move the following files into the "C:\Atari2600\bB\Projects" directory: 2600baside.bat avox.bas mazecraze2.bas ms.bas RallyB.bas Finally, move the following files into the "C:\Atari2600\bB\Source" directory: 2600bas.c 2600basic.sh keywords.c keywords.h makefile postprocess.c preprocess.lex statements.c statements.h This should leave you with the following files still in the main "C:\Atari2600\bB" directory: 2600bas.bat 2600basic.exe batari_Basic_Bleeding_edge_99b.zip dasm.exe postprocess.exe preprocess.exe Before we can successfully compile a batari BASIC program using this organization, we'll need to modify the two compile batches. Right-click on the "2600bas.bat" file. In the pop-up menu, click on the "Edit" option. You should see the following lines of text: preprocess <%1 | 2600basic.exe>bB.asm postprocess>%1.asm dasm %1.asm -f3 -o%1.bin The first thing the batch file should do is change to the "Includes" subdirectory so it can find the "include" files. Then we'll have to modify the other commands so the batch file can find them, too. Edit the batch file so it looks like the following: cd Includes ..\preprocess.exe < %1 | ..\2600basic.exe > bB.asm ..\postprocess.exe > %1.asm ..\dasm %1.asm -f3 -o%1.bin Save the changes and close the batch file. Now we need to make similar changes to the "2600baside.bat" file. Go to the "C:\Atari2600\bB\Projects" directory and right-click on the "2600baside.bat" file. In the pop-up menu, click on the "Edit" option. You should see the following lines of text: @echo off preprocess <%1 | 2600basic.exe>bB.asm postprocess>%1.asm dasm %1.asm -f3 -o%1.bin Edit the batch file so it looks like the following: @echo off cd ..\Includes ..\preprocess.exe < %1 | ..\2600basic.exe > bB.asm ..\postprocess.exe > %1.asm ..\dasm %1.asm -f3 -o%1.bin Save the changes and close the batch file. Installing 2600IDE ------------------ We'll need to use a text editor to write batari BASIC programs, but as mentioned in Session 2, it's better to use an IDE ("integrated development environment"), which is a fancy kind of text editor that programmers use for writing, compiling, and running programs. Jacco Mintjes ("Attendo") created the 2600IDE editor just for batari BASIC, so let's install the newest version of it (0.4.1). Go to the "Atari 2600 BASIC IDE" thread in the AtariAge Forums (http://www.atariage.com/forums/index.php?showtopic=72573&hl=2600ide). Scroll down to the bottom of the first entry, and click on the link for the "2600IDEV04_1.zip" file. When the computer asks whether you want to open or save the file, click on "Save," then browse to the "C:\Atari2600\bB" directory, and save it there. Once the file is downloaded, go to the "C:\Atari2600\bB" directory and decompress it. You should extract the file to the "C:\Atari2600\bB" directory. Once the "2600IDE.exe" file is extracted, double-click on it. This will pop up a "Locate emulator executable" window. Browse to the directory that contains the emulator you want to use (Stella, z26, or PCAE). For this tutorial, we'll primarily use the Stella emulator, so browse to the "C:\Atari2600\Stella" directory. Once there, double-click on the "stella.exe" file to select it as the emulator which 2600IDE will use. (Note that we can switch to a different emulator later if we want.) You should now see a tiny window that says "Emulator located." Click on the "OK" button to finish. Now that we've installed and set up the 2600IDE editor, we can test it by compiling one of the programs that came in the batari BASIC package. Click on the "File" menu and select the "Open" option. In the "Open" window, browse to the "C:\Atari2600\bB\Projects" directory. Let's compile the "RallyB.bas" program. Double-click on the "RallyB.bas" file, and it will load into the 2600IDE editor. We won't worry about trying to understand any of the program code right now. Instead, let's just compile it. Click on the "Actions" menu and select the "Compile" option. The screen will flash, and then return to the program listing. To run the compiled program, click on the "Actions" menu and select the "Run a Compile" option. Browse to the "C:\Atari2600\bB\Projects" directory (if you aren't already in that directory), and double-click on the "RallyB.bas.bin" file to run it. The Stella emulator will start up and display the "RallyB" game. Use your cursor control keys to move your car around the maze of streets. After you've tested the game for a little while, click on the "close" icon in the upper right corner of the Stella window to exit the emulator. Next, click on the "File" menu and select the "Exit" option to close the 2600IDE editor. Installing Crimson Editor ------------------------- Although the 2600IDE editor is easy to use, and has a built-in sprite editor and playfield editor, the primary editor that I'll be using in this tutorial is the free Crimson Editor. Crimson Editor is much more powerful than the 2600IDE editor, because it's been under development for a much longer period of time. Go to the "C:\Atari2600" directory that you created earlier, and create a "CrimsonEditor" subdirectory (i.e., "C:\Atari2600\CrimsonEditor"). Go to the Crimson Editor homepage (http://www.crimsoneditor.com/). Click on the link for the newest version (as I write this, the newest version of Crimson Editor is 3.70). On the next page, click on the link for the "Crimson Editor 3.70 Release" file. When the computer asks whether you want to run or save the file, click on "Save," then browse to the "C:\Atari2600\CrimsonEditor" directory, and save it there. Once the file is downloaded, go to the "C:\Atari2600\CrimsonEditor" directory and double-click it to start the installation. You should select all of the components, and install the program in the "C:\Atari2600\CrimsonEditor" directory. Once the installation is finished, it will put a "Crimson Editor" shortcut on your desktop. Double-click on the shortcut to start it. You may see a scary-looking message that says the "Crimson Editor configuration file has been corrupted!" But then it says "Ignore this message if it is the first installation." (Whew!) Click on the "OK" button to continue. On the left side of the Crimson Editor window is a sidebar that shows your drives and directories. If you don't see this box, then look at the menu task bar and find the binoculars. Immediately to the right of the fourth binoculars icon (which says "Find Prev" when you point to it), there is an icon of a split window with a folder on it (which says "Directory Window" when you point to it). Clicking on that icon makes the directory sidebar appear or disappear. If the directory sidebar is not visible, then click that icon to open it. Then double-click on the "Atari2600" folder to expand it, double-click on the "bB" folder to expand it, and double-click on the "Projects" folder to expand it. You should now see all of the files in the "C:\Atari2600\bB\Projects" directory. Double-click on the "mazecraze2.bas" file to open it. (Of course, you could also click on the "File" menu, select the "Open..." option, and then browse to the file you want to open.) You'll note that the "Text1" tab is still there. You can right-click on it and select the "Close" option to close it, since it's just a blank text file. This will leave the "mazecraze2.bas" file open. As you can see, Crimson Editor lets you open multiple files at the same time, and click on their tabs to go from one to the other. In order to compile a batari BASIC program with Crimson Editor, we need to set up a menu function for us to use. Click on the "Tools" menu and select the "Conf. User Tools..." option. In the new window, click on the first line in the "User Tools" box, which says "- Empty - Ctrl+1." Then click in the "Menu Text" field and type "Compile bB Program." Next, click on the "..." button to the right of the "Command" field. Browse to the "C:\Atari2600\bB" directory, and double-click on the "2600bas.bat" file. This will put "C:\Atari2600\bB\2600bas.bat" in the "Command" field. Next, click on the ">" button to the right of the "Argument" field. In the pop-up menu, click on the "File Path" option. This will put "$(FilePath)" in the "Argument" field. Next, click on the ">" button to the right of the "Initial Dir" field. In the pop-up menu, click on the "Browse..." option. Browse to the "bB" folder and select it, then click on the "OK" button. This will put "C:\Atari2600\bB" in the "Initial Dir" field. Next, check the "Capture output" option, and uncheck the "Use short filename (8.3)" option. The "Save before execute" option should also be checked. Finally, click on the "OK" button to save the setup. Now let's compile the "mazecraze2.bas" program. Click on the "Tools" menu, and select the new "Compile bB Program" option. An "Output" window will appear at the bottom of the screen showing the results of the compile, which should end as follows: > Terminated with exit code 0. (That means "Everything was A-OK!") Now that we've successfully compiled the "mazecraze2.bas" program, let's set up another menu function so we can run it. Click on the "Tools" menu and select the "Conf. User Tools..." option again. In the new window, click on the "- Empty - Ctrl+2" line, just below the line that says "Compile bB Program." Then click in the "Menu Text" field and type "Run bB Program." Next, click on the "..." button to the right of the "Command" field. Browse to the "C:\Atari2600\Stella" directory, and double-click on the "stella.exe" file. This will put "C:\Atari2600\Stella\stella.exe" in the "Command" field. Next, click on the ">" button to the right of the "Argument" field. In the pop-up menu, click on the "File Path" option. This will put "$(FilePath)" in the "Argument" field. Click at the end of the "Argument" field so the cursor is at the end of the "$(FilePath)" entry, and add ".bin" to the end of it, so it says "$(FilePath).bin." Next, click on the ">" button to the right of the "Initial Dir" field. In the pop-up menu, click on the "Browse..." option. Browse to the "Stella" folder and select it, then click on the "OK" button. This will put "C:\Atari2600\Stella" in the "Initial Dir" field. Finally, click on the "OK" button to save the setup. Now let's run the compiled "mazecraze2" program. Click on the "Tools" menu and select the new "Run bB Program" option. This will start up the Stella emulator with the "mazecraze2" game. Use your cursor control keys to wander around the maze. After you get totally lost, click on the "close" icon in the upper right corner of the Stella window to exit the emulator. There's more we could do to set up the Crimson Editor program, such as creating language files so that Crimson Editor will color code the batari BASIC and 6502 assembly keywords, but we won't worry about that right now. We also won't worry about installing any other programs yet, such as the Distella disassembler; we'll install them as we need to use them in the tutorial. For the time being, we're all set up and ready to rock and roll! Michael Rideout

I apologize, I thought I was going to get it posted this past weekend, but then I spent Saturday, Sunday, and Monday in bed with a fever and a headache. I finished Session 3 tonight, and I hope the installation instructions in it are okay. Michael Rideout

It's a pun, a combination of "Sea Goat" (because I'm a Capricorn) and "Billy Goats Gruff" (because one day when I was being grouchy, my mother said, "I declare, you can be so *gruff* at times," and I immediately thought of the name "Sea Goat Gruff"). When I joined AOL back in 1995, there was a 10-character restriction on the AOL screen names at that time, so I abbreviated "Goat" to "Gt" and left out the spaces, hence I capitalized the S, G, and G to help indicate that they're the beginnings of separate words. I have the next several installments planned out, but I got hung up on the third installment, which is a pretty good indication that I need to simplify things more, plus I need to stop playing games (I'm addicted to "Millipede" and "Well of Souls" right now). My current session plan is as follows: Session 3 - Getting Set Up (installing batari BASIC, DASM, Crimson Editor, Stella, etc.) Session 4 - The TV Picture (a brief description of how the TV fields and frames are drawn) Session 5 - The Atari's Features (an overview of the 2600's graphics features, what it can do) Session 6 - The Atari's Memory Map (an outline of the 2600's memory organization and mirroring) Session 7 - Designing a Game (some comments about planning a game) Session 8 - The Programming Statements (an overview of batari BASIC and 6502 assembly) Session 9 - Writing a Program (an overview of coding rules and programming structures) Session 10 - Video Blanking, the Background, Colors, and Kernels (first actual programming lesson, how to do a simple kernel loop in assembly, how to choose and set the colors) Session 11 - The Playfield, the Ball, and Collisions (drawing and controlling the playfield and ball, detecting and processing collisions) Session 12 - The Console Switches and Game Controllers (reading/processing the console switches, the joysticks, the paddles, etc.) Session 13 - The Players and Missiles (drawing and controlling the players and missiles) Session 14 - The Timer (setting/reading/processing the timer) Session 15 - Sounds (creating sounds) I know the title is "batari BASIC for Beginners," but I want to include assembly programming at the same time, because it's very easy to include in-line assembly within a batari BASIC program, and there's a lot of things you really can't do in batari BASIC unless you use assembly to do it. So I want to give an overview of the kinds of things you really need to know for 2600 assembly programming-- how a TV picture is drawn, how a game's display kernel controls that, etc. And I want to post the next several sessions in groups. Ideally, I should have posted 1, 2, and 3 at once, and then I could do the other sessions in threes as well-- 4, 5, and 6, then 7, 8, and 9, etc. And my current outline is subject to change based on feedback and what people want or need. I'm trying to get 3, 4, 5, and 6 posted this weekend to get me back on track. Michael Rideout

I had trouble with your mock-up; I could get it to run, but I couldn't figure out the controls. I mean, was I supposed to be able to make Babs jump, because I couldn't figure out how to, but how else was I supposed to get past Elmyra and complete the level? Does it require a joystick, or can I use the keyboard instead? Anyway, yes, you can use different colors for the playfield, but it depends on how you want to do it. It's easy to change the playfield color from one scan line to the next, so you could have a scan line or two of green for the grass, then change the color to brown for the next several scan lines for the dirt, like this: Level_1.bmp You can also change the playfield color in the middle of a scan line, but there are limitations to how fast you can do that, and which positions you can make the color changes happen at, plus if you do that then you have to get the timing just right to make the change occur where you want it to. Your new title screen *looks* good, but you've made the playfield pixels too small; they're twice as wide as you've made them, so you won't actually be able to create that title screen. I thought your original title screen looked fine, and the mock-up I made for it positioned the capital "T" of "Tiny" and "Toon" so that you wouldn't need to change the PF0 register from one half of the screen to the next, but you'd still have to change PF1 and PF2 from the left side to the right side. I think your game looks doable, if you stick with what the 2600 is capable of graphically. Michael Rideout

Try reading this. Thanks for the help^_^ Don't know if this will help, but here are some zipped GIFs, mostly of images that I had made for my own use, as follows: 128 Colors.GIF - Screenshot of z26 displaying full Atari palette, to help pick colors. 2600 Background.GIF - Shows screen positions where color changes can be made. 2600 Border.GIF - Shows screen positions where blanking can be enabled/disabled. 2600 Player x 1.GIF - Shows smallest pixels for players, using single-width mode. 2600 Playfield Copied.GIF - Shows playfield registers and pixels, in duplicate mode. Title Screen 1.GIF - The original title screen mock-up that you posted in this thread. Title Screen 2.GIF - I stretched your screen, overlaid the playfield screen, and made this. Title Screen 3.GIF - This is the same as above, but I removed the grid overlay. Michael Rideout TinyToon.zip

Not fully correct. You can have gr.8/gr.9/gr.15 side a side. Could you two explain how to do this? I have been curious about this possibility, and someone mentioned that they had seen it done, but I have not yet seen any information on how to do it. Thanks in advance! Michael Rideout

Excellent! I can't wait to get home tonight and install it! Michael Rideout

Well, the PAL version is different than the NTSC version. As far as I know, none of the cartridges for the special contest version were ever found. The web pages which give the solution to the PAL version state that the PAL version is believed to be the same as the contest version-- although of course the colors and scan line counts would have to have been changed for compatibility with NTSC TVs. Based on what I did to win the contest version-- simply move all the objects from room to room in a particular order-- the solution to the PAL version does seem to match the contest version. Unfortunately, I can't verify whether they were the same or not, because I was very busy moving objects around and trying to find the clues in the correct order, plus I wasn't using the "riddle sheet" that they gave out to help us figure out the clues, so I don't know which objects were triggering the clues in the different rooms. For all I know, the order of the rooms was the same in the PAL and contest versions, but the objects which triggered the clues in those rooms might have been totally different. Michael Rideout

I believe supercat posted a file in his blog to allow preliminary 4A50 "emulation" on a 7800 with a Cuttle Cart 2, but I don't think the 4A50 design is finalized yet. I haven't tried it out yet. I don't know how many people actually have a 7800 and a Cuttle Cart 2, but any developers who do might want to start experimenting with the 4A50 scheme, since emu support for 4A50 is probably more likely to be added once the design is finalized and people start to create games that use it. I'd guess it's sort of like the chicken and the egg-- emu support for 4A50 will make it easier for developers to program for it, but emu support might not come until developers start programming for it and thereby create an actual need for emu support! Michael Rideout

He actually gave AGH an interview some years ago. Here is a link (with lots of good information about the contests): http://www.atarihq.com/2678/swordqst.html 1023790[/snapback] John Hardie did a follow-up interview with me last year, but I never saw it appear anywhere. The first interview that he did several years ago was conducted over the phone, but for the follow-up he came down south and met me in person. I got the chalice out of the bank so he could see it, and he took several pictures of it. I was checking out some of the web sites that talk about SwordQuest, and I saw that they are either missing a few snippets of information (e.g., the name of the person who solved FireWorld-- and I mean the NTSC home version, not the one that was made for the contest), the solutions to one of the clues was wrong, etc. So I've decided to put together my own SwordQuest FireWorld web pages, and post them on AtariAge or whatever-- not to replace any of the other very fine web pages out there, but rather to complement them a bit. However, I have a lot of stuff going on right now, plus I really should be working on my bB tutorial instead of continually letting myself get distracted, so it will probably be a week or three before I complete my SwordQuest FireWorld "project" and post it anywhere. Michael Rideout

Both would be possible (and not terribly difficult) using my RallyX or Superbug track engine and a Supercharger. The Rally X track is 32x56 and takes 224 bytes, and the SuperBug track is 128x128 and takes up 2k. Though a 128x128 maze would be very tough to navigate! I remember that Michael Rideout wrote a random maze generator in bB, but I wonder if it could be extend to work with a much larger track on a Supercharger? 1025569[/snapback] When I suggested bigger mazes extending off screen, I actually had that bB maze generator in mind! It uses a common maze-generation algorithm, so it should be easy enough to adapt it to a larger maze. However, the only reason it worked at all in bB was because bB maps the playfield to RAM. I know the Supercharger has RAM, but I don't know how much or how to address it. I could create a larger random maze with M-Network bankswitching and its extra RAM, but from what I've heard it would be hard to manufacture cartridges using M-Network bankswitching, so I suppose it would be more logical to use the 4A50 bankswitching cartridge (and there would be more RAM and ROM as well). I suppose that program I wrote actually created "pseudo-random" mazes, since it could generate only 255 unique mazes. I didn't fully follow the thread a while back about random number generators, but I take it that a better method could easily be added to bB, in which case I could modify that program to generate more than just 255 unique mazes? Anyway, as long as there's enough RAM to store the maze data, it should be a fairly simple matter to adapt that program for generating much larger mazes. Michael Rideout

How about drawing the maze with bigger walls and passages (as someone already suggested), and having the maze extend offscreen-- you can't see the entire maze at once, and the screen scrolls as you move around? Michael Rideout

Sounds like fun! What, you can't control the bat, too?!? What was that game where you got to play Godzilla or some other monster? Michael Rideout

This looks very nice, it offers a lot of potentials! The 4A50 bankswitching is going to be great! Michael Rideout

Very interesting, indeed. Thanks for sharing this! Michael Rideout

And a very nice small intro it is, too! Assuming that this is related to the project that you wanted bankswitching help for, it will be interesting to see what you do with it once you actually add some bankswitching and have more memory for screen data and such! Michael Rideout

Why not insist on starting with a maximum of 2K, like the really early games? Anyone who can squeeze a decent game into 2K has my deepest admiration. Of course, a lot of those early games weren't much in the way of appearance (screen graphics), and the gameplay was often extremely simple, but appearance isn't everything, and simple gameplay can still produce very fun games. But having said that, just because someone's first game is 8K, 16K, etc., doesn't mean that the code can't/won't be tight and efficient, and that the person's games are likely to never reach their full potential. For example, the kernel itself and all the main routines might be extremely small and tightly-coded, with many, many Ks of *data* (playfield maps, player shapes, color tables, etc.). Just because he's needing to go past the 4K barrier in his first game doesn't mean his game must therefore be filled with bloated code that a "better, more superior" coder could chop down into a quarter of the size! Maybe it's bloatware, and maybe it's not! Still, I kind of like the idea of starting with 2K, and then working up to 4K, before getting into bankswitching... or maybe being required to take a 4K game and find a way to squeeze it down into 2K without losing too much. Who ya gonna call? The Atari 2600 Newbie Programming Gaming Police! "But officer, I was only doing 8K!" "Yes, but the limit is 2K in this neighborhood, there are children present." Michael Rideout

There are several different schemes that were developed for bankswitching, so the "best practices' will depend on which scheme you choose. An excellent document to start with is the one that Kevin Horton wrote, which I gather is pretty much the "bankswitching bible." The actual descriptions of the different bankswitching schemes is a bit sketchy, and you must read them very carefully, then work out all of the details by putting 2 and 2 together so to speak. http://www.tripoint.org/kevtris/files/sizes.txt Actually, I think there might be another version of that document, also by Kevin Horton, but I don't have a link for it right now. The bankswitching schemes described in that document are the ones that were developed and used for the Atari 2600 "back in the day," and some of them may not be very feasible to use today as far as actually manufacturing cartridges for new games. Also, some new bankswitching schemes have been developed more recently, such as the one developed for the "Homestar Runner" game, or the one that supercat is working on. Anyway, according to one of Kevin Horton's documents, the "traditional" schemes can be divided into three basic types, as categorized by the sizes of the banks: (1) Bankswitching schemes where each bank is 4K in size. When you switch banks, the entire 4K ROM cartridge area is switched. In these schemes, when you switch banks, you typically end up in the same spot but in a different bank, hence it can be a little tricky to switch banks if you aren't sure what you're doing. (As I recall, at least one 4K scheme-- used by Activision-- switches banks whenever you JSR or RTS, so you don't end up in the same spot when you switch banks; instead, you end up wherever you JSR-ed to or RTS-ed to.) There must generally be a certain amount of code that's duplicated in each bank, such as the vectors at the top of the ROM ($FFFC/$FFFD and $FFFE/$FFFF), or any code or program data that must be available "at all times," regardless of which bank you're in. (2) Bankswitching schemes where each bank is 2K in size. The bank at the upper 2K area ($F800 to $FFFF) is fixed-- it never gets switched-- but the other banks can be switched into the lower 2K area ($F000 to $F7FF). This sort of scheme can be easier for some people to use, because you can be sitting in the fixed bank in the upper 2K area, switch the bank in the lower 2K area, then JMP or JSR to code in the lower 2K area. When you're done, you can JMP or RTS back to the upper 2K area to switch banks again. Of course, you can also switch banks while you're in the lower 2K area, the same way that most 4K schemes work. (3) Bankswitching schemes where each bank is 1K in size. The bank at the upper 1K area ($FC00 to $FFFF) is fixed, and (as I understand it) any of the other banks can be switched into any of the other three 1K areas ($F000 to $F3FF, $F400 to $F7FF, and $F800 to $FBFF). This sort of scheme is the most flexible, since you can switch a bank while you're sitting in that area (as in the 4K schemes), or be in the fixed bank while switching banks in another area (as in the 2K schemes), or be in one of the switchable 1K bank areas while switching banks in another 1K area. Using bankswitching is actually pretty easy, once you wrap your brain around the basic concepts. The first hurdle is understanding how to code each bank in your program, using DASM or whatever other assembler you prefer. As I see it, there are three ways you can do this (at least, I've done it three different ways): (1) You can code each bank (1K, 2K, or 4K) as though it's a separate program so to speak, using the appropriate ORG address (or whatever your chosen assembler uses), compile the banks separately, and then join the individual compiled banks into a single ROM image using some kind of file-joining utility. This is the method I used first, before I knew better. If there's a "wrong" way to write bankswitched programs, this is probably it! (2) You can code each bank as though it's a separate program (exactly the same as above), but use INCBIN commands in the final bank to add the other compiled banks into the last bank while you're compiling it. This is the second method that I used, but it's only marginally less stupid than the first method. (3) You can code all of the banks at the same time, in the same source code. This is the best way to do it. You must use combinations of ORG and RORG commands (or whatever your chosen assembler uses) to make sure that each bank gets put in the correct location in the final compiled ROM, while simultaneously relocating any address references to the correct region(s) between $F000 and $FFFF. Assuming you're using DASM, and assuming you're using the third approach, the exact organization of the code will depend on which bankswitching scheme you're using-- not just the sizes of the individual banks, but also the number of banks. In a nutshell, if you number each bank from 1 to whatever, then each bank must be placed in order in memory, consecutively from 1 to whatever, with no gaps in the addresses. Each bank's "physical" starting address will be determined by its size and its number. For example: If you're writing a 2K non-bankswitched game, it's located from $F800 to $FFFF. If you're writing a 4K non-bankswitched game, it's located from $F000 to $FFFF. If you're writing an 8K bankswitched game, where each bank is 4K, then there are two banks in all-- 1 and 2-- so bank_1 is located from $E000 to $EFFF, and bank_2 is located from $F000 to $FFFF. However, since bank_1 will be seen in the normal 4K area when it's selected, you must relocate bank_1 to $F000 to $FFFF, as follows: ORG $E000 ; Beginning of bank_1, size 4K, RORG $F000 ; but we must relocate it to the actual 4K ROM area. ; ; code for bank_1 goes here ; ORG $F000 ; Beginning of bank_2, size 4K, RORG $F000 ; which also gets seen in the actual 4K ROM area. ; ; code for bank_2 goes here If you're writing an 8K bankswitched game, where each bank is 2K, then there are four banks in all-- 1, 2, 3, and 4-- structured/located as follows: ORG $E000 ; Beginning of bank_1, size 2K, RORG $F000 ; but we must relocate it to the lower 2K ROM area. ; ; code for bank_1 goes here ; ORG $E800 ; Beginning of bank_2, size 2K, RORG $F000 ; which also gets relocated to the lower 2K ROM area. ; ; code for bank_2 goes here ; ORG $F000 ; Beginning of bank_3, size 2K, RORG $F000 ; which also gets seen in the lower 2K ROM area. ; ; code for bank_3 goes here ; ORG $F800 ; Beginning of bank_4, size 2K, RORG $F800 ; which is fixed in the upper 2K ROM area. ; ; code for bank_4 goes here If you're writing an 8K bankswitched game, where each bank is 1K, then there are eight banks in all-- 1, 2, 3, 4, 5, 6, 7, and 8-- structured/located as follows: ORG $E000 ; Beginning of bank_1, size 1K, RORG $???? ; relocatable to any of the lower 1K ROM areas (?). ; ; code for bank_1 goes here ; ORG $E400 ; Beginning of bank_2, size 1K, RORG $???? ; also relocatable to any of the lower 1K ROM areas (?). ; ; code for bank_2 goes here ; ORG $E800 ; Beginning of bank_3, size 1K, RORG $???? ; also relocatable to any of the lower 1K ROM areas (?). ; ; code for bank_3 goes here ; ORG $EC00 ; Beginning of bank_4, size 1K, RORG $???? ; also relocatable to any of the lower 1K ROM areas (?). ; ; code for bank_4 goes here ; ORG $F000 ; Beginning of bank_5, size 1K, RORG $???? ; also relocatable to any of the lower 1K ROM areas (?). ; ; code for bank_5 goes here ; ORG $F400 ; Beginning of bank_6, size 1K, RORG $???? ; also relocatable to any of the lower 1K ROM areas (?). ; ; code for bank_6 goes here ; ORG $F800 ; Beginning of bank_7, size 1K, RORG $???? ; also relocatable to any of the lower 1K ROM areas (?). ; ; code for bank_7 goes here ; ORG $FC00 ; Beginning of bank_8, size 1K, RORG $FC00 ; which is fixed in the uppermost 1K ROM area. ; ; code for bank_8 goes here I'm not entirely sure about the 1K method, because the description is sketchy or non-existent on the very points that I most have questions about! Presumably, any of the three lower 1K areas ($F000 to $F3FF, $F400 to $F7FF, and $F800 to $FBFF) can hold any of the first seven banks. If that's true, then the RORG addresses for those banks can be set to $F000, $F400, or $F800, depending on which 1K area you intend for that particular bank to be switched into. If a given bank holds game data rather than executable code, then it doesn't matter what the RORG address for that bank is, since none of the addresses in that bank will need to be "fixed" per se. That is, you could switch a data-only bank into any of the three lower 1K areas at different times in your game, as long as the code that's reading the data in that bank is referencing whichever 1K area you've switched that bank into at that particular time. And if the code in a given bank is entirely relocatable-- i.e., it uses branch statements, and the only time it ever uses JMP or JSR is when it's going to an address in some other bank rather than to some address within itself, and it never tries to read any data that's stored within itself-- then the RORG could also point to any of the lower 1K areas. But if the code within a given bank does a JMP or JSR to some address within that same bank, or reads data that's stored within that same bank, then the RORG must be set to a specific 1K area, and that will be the only 1K area that you should ever switch that bank into. I'm not sure that the preceding description is correct, but it's the only way that makes sense if my understanding of this scheme is correct. I won't give "skeletons" for the other schemes, since the preceding examples will give you the general idea. For example, if you're writing a 32K bankswitched game that uses 4K banks, then there will be eight banks in all, and their ORG addresses will be $8000, $9000, $A000, $B000, $C000, $D000, $E000, and $F000, with all of the RORG addresses being $F000. Since the Atari 2600 is in a random state on powerup, it's possible for any bank(s) to be in memory at powerup, and you'll need to take that into consideration. For example, if you're using a scheme with 4K banks, then all of the banks must have identical vectors in their last four bytes, pointing to the startup code, which must be duplicated at the same location in all banks. That way, the Atari will always be able to successfully jump to the startup code regardless of which 4K bank happens to be in memory at powerup. Also, it's best for the startup code to immediately select the bank that you actually want to start in, because this will let you minimize the amount of code that must be duplicated in all banks. For example, with a 4K bank scheme, the startup processing might be as follows: (1) Turn on the Atari. Any one of the 4K banks might be in memory. (2) The processor looks at the address that's pointed to by the vector at $FFFC and $FFFD, and then jumps to that target address. Therefore, all of the 4K banks must have the same lo-byte/hi-byte address coded in $FFFC and $FFFD, and all of the 4K banks must have the same executable code at the target address which that vector points to. (3) When the Atari executes the code at that startup target address, the first thing it should do is select whichever 4K bank you want to have in memory initially. As stated above, the code which does this should be duplicated in all of the 4K banks, so that it won't matter which bank is actually in memory when the Atari executes the instruction to switch to the desired startup bank. (4) As soon as the Atari has executed the instruction to select the desired bank, that desired bank will be in memory, therefore the remaining startup code won't need to be duplicated in all of the other 4K banks. After that, you can pretty much code whatever you want in each of the 4K banks, and switch back and forth between them as desired, as long as you're careful to remember that each time you switch to a different bank, you'll immediately end up in the new bank, but will be in whichever memory location comes after the last instruction you just executed. Note that if you're planning on staying in any of the 4K banks for an appreciable length of time-- i.e., long enough to need to perform the display kernel-- then you must include the kernel in that 4K bank, or at least include *a* kernel in that bank. That is, there's really no reason why it must be the same as the kernel in any of the other 4K banks. For instance, you could have different kernels in different 4K banks if your screen display isn't going to use a single kernel for everything-- e.g., a title screen kernel in one bank, and the main game kernel in another bank, etc. On the other hand, if you're using a scheme that has 2K or 1K banks, then you'll always start in the last bank, at the vector in $FFFC and $FFFD, hence you'll want to point that vector to some address in the last bank, since you'll have no way of predicting which bank is in the other 2K area (if you're using 2K banks), or which three banks are in the other three 1K areas (if you're using 1K banks). This means you don't need to duplicate the startup vector or startup code in the other banks, since none of the other banks can occupy the uppermost 2K or 1K area anyway. Consequently, you can just execute whatever startup code you want in the upper 2K or 1K area, and then start selecting the other bank(s) as desired. As far as the actual technique of switching banks, that will depend on the scheme you're using, since each scheme has its own bankswitching "hotspot" addresses or other methodology for selecting between the different banks. You can learn more about this part of it by reading Kevin Horton's bankswitching documentation. I hope the information I've given above, coupled with the information in Kevin Horton's documentation, is enough to get you started. I suggest that you choose one specific bankswitching scheme and experiment with it exclusively. Then, when you've gotten used to that scheme (or perhaps have decided that it's not for you after all), you can try a different scheme. Learn one at a time, rather than trying to learn all of them at once. Michael Rideout

There are also several Michael Rideouts in the world, even a few who are around my age. But none of them live in my immediate area, because Rideout isn't a very common name down south; it's more common up north, especially in Canada I think. Not surprisingly, my parents are from up north (but not from Canada). I have a brother named Paul, and when I was younger our family used to have a female Doberman named Greta. This became the subject of jokes when "the Greta Rideout case" became publicized in the news and was subsequently made into a TV movie (if I remember correctly, Greta Rideout charged her husband Paul with raping her). Michael Rideout

I don't know Steven Bell well, I just hung out with him and the other EarthWorld alumnis for a while before and after the FireWorld contest, but to me he seemed to be the quiet type, more likely to follow along than to be an instigator. So if this is the same Steven Bell-- and it may very well *not* be-- then I expect he might have been chumming around with one or more people who instigated the B&E, and he just let himself get dragged along into it. He simply didn't strike me as the type to go looking on his own for that kind of trouble. In San Francisco, I don't recall him ever once suggesting "let's do this" or "let's go there"; as I recall, he was just following along with whatever the others suggested we do (as was I). If this *is* the same Steven Bell, then I sincerely hope everything is going well for him these days. Sure, "do the crime and do the time"; but if you do the time, you shouldn't have to keep doing it forever after. We all make mistakes-- lord knows I've made plenty, and I expect I'll probably make more before I die-- but I don't think it's right for people to keep shoving our mistakes in our face and continue punishing us after we've paid for them. I'm not suggesting that anyone here is doing that, I'm saying it often happens like that in the world, and I think it sucks, especially since the people who do that undoubtedly make mistakes, too. After all, we're all human, and we're all imperfect. I'm actually grateful to meatlog for posting the information, not because I enjoy poking into anyone's privacy, but rather because it may answer the question of why I wasn't able to contact Steven Bell when Tramiel's Atari announced their intention to cancel the contests. Michael Rideout

I don't know if it was the first, but Alkabeth does have 3D dungeon mazes-- albeit they are very, very simply drawn, almost like a wireframe view, except the walls aren't see-through (but the monsters are!). Michael Rideout

(I don't know if I should be posting these sessions under the same thread, for now I'll post them as separate threads.) batari BASIC for Beginners -- Session 2: What You'll Need --------------------------------------------------------- To program for the Atari 2600 using batari BASIC, you'll need to have the following: A Computer ---------- Since the batari BASIC compiler actually runs on a computer, you'll obviously need a computer. And since you're reading this tutorial in an online forum, I presume that you already have a computer! However, your computer must use an operating system for which all of the necessary tools are available. I'm using a computer running Windows XP, and batari BASIC is probably most readily accessible for a Windows computer-- because the Windows executables for batari BASIC are already built when each new version is released-- so for the most part this tutorial assumes that you're using a Windows computer. (By the way, I was still using Windows 95 up until a few months ago, and I was starting to run into compatibility issues with some of the tools, so if you're still using Windows 95, you might want to consider upgrading to at least Windows 98, if not a more recent version like Windows XP.) If you're using some other operating system-- Mac OS X, Linux, Unix, Amiga, etc.-- you'll probably need to build batari BASIC executables, and possibly executables for some of the other tools, which will run on your system. I encourage anyone using a non-Windows operating system to contribute comments or instructions, and to post any executables that you've had to build, for the benefit of any other readers who are using the same operating system as you. A Text Editor or IDE -------------------- You'll need a text editor to write your programs with. Any text editor will do, even a word processor, as long as you save your program source code as a plain ASCII text file so batari BASIC and DASM can read it. Note that all text editors are definitely not equal, so you may already have one that you prefer to use. If you're using a Windows computer, you can use EDIT.COM, Notepad, or WordPad, all of which are included with Windows. EDIT.COM is the old MS-DOS editor, so it runs from the command prompt (just open a command prompt and type "edit"), and it doesn't look as "pretty" as Notepad or WordPad. However, EDIT.COM lets you edit multiple files at the same time, whereas Notepad and WordPad can work with only one open file at a time. On the other hand, you can always open multiple copies of Notepad or WordPad if you want to edit more than one file at a time. In any case, I suggest that you use EDIT.COM, Notepad, or WordPad only if you have no other options available. Instead, you are strongly urged to use an IDE ("integrated development environment"), which is simply a special text editor that can be set up to compile and run programs in different programming languages. Again, all IDEs are not equal, and if you're a programmer, you may already have an IDE that you prefer. There are some advanced IDEs that are sold commercially, but unfortunately they tend to be a bit pricey, since they're marketed to professional programmers. There are also some good shareware and freeware IDEs available, although they tend not to be as feature-laden as the upscale commercial IDEs. In this tutorial, I'll be using Crimson Editor, which is a free IDE for Windows that's available over the internet. In Session 3, I'll show you how to set up Crimson Editor to compile and run batari BASIC and 6502 assembly language programs. Another option is to use the free 2600IDE program which Jacco Mintjes ("Attendo") created specifically for batari BASIC. Although 2600IDE doesn't have all of the editing capabilities (e.g., search, or search and replace) that are standard with most text editors, it does have a built-in sprite editor and playfield editor, and it's easy to use with the batari BASIC compiler and an Atari 2600 emulator. 2600IDE can also be used to write, compile, and run pure 6502 assembly programs. Finally, there was an MS-DOS based IDE called ADEV that came in the 2600SDK package, which was a package put together by Matthew Ozor, that used to be available on the DASM web site. The IDE was essentially like the EDIT.COM editor, but it included the ability to compile and run programs. Unfortunately, the link to download the 2600SDK package no longer works. Fortunately, Crimson Editor lets you do everything (and more) that the ADEV IDE let you do. Nevertheless, if you'd like to try the ADEV IDE, I've uploaded a copy of it to the AtariAge website. Non-Windows users are encouraged to post suggestions for text editors and IDEs that run under their chosen operating systems. The batari BASIC Package ------------------------ Several versions of batari BASIC have been released-- 0.1, 0.2, 0.3, 0.35, and 0.99. Version 0.35 is the most recent "official" release, and it can be downloaded either from the "semi-official" batari BASIC home page (where the earlier versions of batari BASIC are also available), or from the AtariAge web site. Version 0.99 has been posted on the AtariAge web site as a pre-release "work in progress." Since version 0.99 is currently the "latest and greatest" (pre-)release, that's the version we'll be using in this tutorial. As any newer versions are released, we'll migrate to them. The batari BASIC package includes a build of the Windows executables, but if you're using a non-Windows and non-DOS system, you'll need to build executables for your system. Brief instructions on how to do that are included in the documentation for batari BASIC. The DASM Assembler ------------------ Compiling a batari BASIC program is actually a two-step process. First, the batari BASIC program listing must be compiled with the batari BASIC compiler, which converts it into a 6502 assembly language source file. Then this assembly file must be compiled into a binary ROM image file using a 6502 assembler. The batari BASIC compiler creates assembly code which is formatted for the DASM assembler, so it's expected that you'll use that assembler. If you insist on using some other 6502 assembler, you'll need to be sure that it can handle the format used by DASM, or else you'll have to convert the DASM-compatible code to a format that's acceptable to your chosen assembler. Obviously, the preferred course is to just use DASM. Although the batari BASIC package already includes the Windows build of the DASM assembler, you're encouraged to download and install the DASM package separately, if only for the documentation that comes with it. And if you're using a non-Windows system, then you must download the DASM package separately, because it comes with builds for a variety of operating systems. Consequently, once you've downloaded and installed the DASM package, you might want to delete the versions for operating systems that you aren't using. An Atari 2600 Emulator ---------------------- Although you can run your Atari 2600 programs on an actual Atari 2600 or 7800 if you have the necessary equipment (e.g., a Supercharger, Cuttle Cart, Cuttle Cart 2, or Krokodile Cartridge, along with any other devices that they require for loading ROM images into them), it will be most convenient to run your programs on an Atari 2600 emulator. There are many such emulators available, for a variety of operating systems, so your choice of emulator will be partly dictated by your operating system, and partly based on your personal preferences (since all emulators are not equal). For this tutorial, I'll primarily be using the Stella emulator, but I'll occasionally also use the z26 and PCAE emulators, and possibly other emulators as well. In addition to the preceding required tools, there are some optional items that you're strongly encouraged to obtain: Programming Documentation for the Atari 2600 -------------------------------------------- There are several documents on the internet that explain the memory map of the Atari 2600, what the different memory locations do and how to use them, etc. If you get only one document, I suggest that it be the "Stella Programmer's Guide," which is available in PDF form. But you may want to search the internet for other documents as well. I'll post a list of documents I'm aware of in Session 3. A Command Reference for batari BASIC ------------------------------------ Although I'll be giving you information about the batari BASIC language in this tutorial, you'll also want to have one or more references that provide a handy summary of batari BASIC's commands. There are a couple of help files that came with some of the earlier versions of batari BASIC, but the help file hasn't been updated for version 0.99 yet. And there's also a batari BASIC help page that Duane Alan Hahn ("Random Terrain") put together. Having handy summaries such as these will be extremely useful as you learn how to program in batari BASIC. A Reference for the 6502 Assembly Language ------------------------------------------ You'll want to have one or more references that provide handy summaries of the op codes and addressing modes in the 6502 assembly language, especially tables that list the number of bytes and the number of machine cycles used by each op code in its various addressing modes. Programming for the Atari 2600 is very different from programming for a computer like the Atari 800, because on the Atari 2600 you must control the way each scan line is drawn on the TV screen. Furthermore, the Atari 2600's processor is slow (e.g., it's only two-thirds as fast as the Atari 800's processor, and the Atari 800 isn't very fast, either), which means you often end up "chasing the raster beam," or trying to perform certain tasks-- like changing colors or modifying the data for the players and playfield registers-- before it's time for them to be drawn on the scan line. Also, the Atari 2600 is limited to only 4K of cartridge ROM (although bankswitching allows this to be stretched to 8K, 12K, 16K, etc.), so Atari 2600 programmers generally try to find ways to squeeze their code into the smallest possible space. Thus, the number of machine cycles and the number of bytes used by the various 6502 assembly instructions will often be critical to know. A Loose-Leaf Binder ------------------- Even though you can download a lot of tutorials and documentation to your computer, and view it onscreen, it's very helpful to be able to leaf through this information in printed form. Thus, it's a good idea to print out these documents and put them in a loose-leaf binder for easy access, with tabbed separator pages to help you quickly flip to the specific document that you're interested in. You can also put blank sheets of lined notebook paper in the binder, so you can keep notes about game ideas; insights you've gained into an Atari 2600 memory location, 6502 assembly instruction, or batari BASIC command; scratch calculations for memory usage or cycle counts related to a game you're working on; etc. Graphing Paper and Colored Pens or Pencils ------------------------------------------ You may also want to put blank sheets of graphing paper in the binder, to help you can draw ideas for game screens, playfield designs, player shapes, etc. And for this, you might want to buy a selection of colored pencils or felt-tip pens, so you can sketch your ideas in color. A Paint Program --------------- In addition to (or perhaps instead of) drawing things on paper, you might want to use a paint program to help you design game screens on your computer. Windows comes with a Paint program, but you might have another graphics software program that you prefer. Sometimes you may want to do emulator screen captures of a game you're working on, and load it into a graphics program for inspection or editing, so it's a good idea to use a graphics program that can handle different types of graphics file formats. An Advanced Calculator ---------------------- You will frequently find it helpful or necessary to convert between decimal, hexadecimal, and binary number bases, or perform calculations in these number bases. Windows comes with a Calculator program that can be switched to "Scientific" view for such things, but you might also want to get a pocket calculator that can do operations in hexadecimal, and that can convert numbers from decimal to hexadecimal or binary and vice versa. A File Comparison Utility ------------------------- When you're working on a game, you might have several different copies of the game where you've tried out different things. In that case, you may find it helpful to be able to quickly compare two files and see where they're different. Windows has a file comparison command, but there are some free file comparison utilities available on the internet that you might want to look into. Also, many of the more up-scale IDEs have built-in file comparison functions, so if you're using a fancy commercial IDE, you might not need to find a separate file comparison utility. In Session 3, I'll show you how to integrate a free file comparison utility with the free Crimson Editor IDE. A 6502 Disassembler ------------------- You may occasionally find it very helpful to disassemble a game that someone else wrote, to see how they did something. There are some commented disassemblies of several Atari 2600 games on the internet, but you might have to disassemble a game yourself. There are two 6502 disassemblers which were specifically designed for disassembling Atari games-- Distella for the 2600 and 7800, and DIS6502 for the 8-bit Atari computers (although with the proper equates file, DIS6502 can also be used to disassemble games for the Atari 2600). A File Splitter --------------- The Distella disassembler can't disassemble ROMs that are larger than 4K, so if you want to disassemble a game that uses bankswitching, you'll first need to split the ROM into two or more 4K segments. I've written a Windows utility program that can do this. A Hacking Utility ----------------- Finally, you might find it helpful to look at a game ROM with some sort of hacking utility, because such utilities generally display the ROM data in a format that makes it easy to find the player shapes. On the other hand, game graphics are usually considered to be protected by copyright, so you need to be careful and considerate when looking at the player graphics used in someone else's game. In Session 3, I'll discuss ways to organize everything on your system, and help you get all of the required or optional tools downloaded and installed on your computer. Michael Rideout