SeaGtGruff

batari BASIC for Beginners -- Session 1: Introduction ----------------------------------------------------- The goal of this tutorial is to help beginners learn how to write their own programs (presumably games) for the Atari 2600. Unfortunately, it isn't feasible to teach computer programming or computer game design in a tutorial such as this, so the emphasis in that first sentence should be on "to help beginners learn"-- i.e., not "to teach beginners." I'll introduce you to the essential concepts as best as I can, but you're strongly encouraged to supplement any information in this tutorial with information from elsewhere-- BASIC programming tutorials or books, 6502 assembly programming tutorials or books, other Atari 2600 tutorials or documentation, articles or documents about TV displays, etc. This tutorial will be presented as a series of posts in the AtariAge forums, but at some point in the future I hope to revise it into a sort of HTML-formatted e-book that can be saved to your computer and read offline, complete with plenty of nice illustrations, etc. But for now, posting the sessions to AtariAge will make it easier for me to get the ball rolling, and will of course allow everyone to contribute their comments or questions. The title of the tutorial suggests that it's about using batari BASIC to write Atari 2600 games, but it's also going to be about using 6502 assembly language. I intend to cover both languages more or less in parallel, but since the tutorial is aimed at beginners, the main focus will usually be on batari BASIC. For those who don't know yet, batari BASIC (a.k.a. "Atari 2600 BASIC") is a high-level programming language created by Fred Quimby ("batari"), primarily to make it easy for beginners to get started in Atari 2600 game programming, but also to help serve as a stepping-stone toward learning 6502 assembly. To quote from the batari BASIC "readme" file, "Atari 2600 BASIC is intended as a beginner's platform so that one may become accustomed to the intricacies of the system. Although Atari 2600 BASIC is a viable development platform on its own, its real purpose is as a stepping stone toward 2600 programming using assembly language. Atari 2600 BASIC 'lowers the bar' so that others with limited programming experience can write games that can run on a real Atari 2600 or an emulator." However, it should be noted that batari BASIC itself doesn't run on an Atari 2600 (e.g., in the same way that Atari BASIC runs on an Atari 800 computer). Instead, batari BASIC is actually a compiler that runs on a computer, therefore you must use a computer to write game programs in the batari BASIC language, then compile them into ROM image files that can be run on an Atari 2600 emulator (on a computer), or loaded and run on an actual Atari 2600 or 7800 using a device such as a Supercharger, Cuttle Cart, Cuttle Cart 2, or Krokodile Cartridge. This means you'll need to start by downloading and installing all of the necessary tools on your computer, which will be the focus of Sessions 2 and 3. It should also be noted that batari BASIC isn't a "hacking tool"; you can't use batari BASIC to modify existing game ROMs, nor is it really possible to disassemble existing game ROMs into batari BASIC code and then hack the source code. On the other hand, if you happen to have the program listing for a game that was written in batari BASIC, you can modify the program listing and then recompile it with batari BASIC (assuming the original programmer doesn't mind you doing that). Thus, you won't be able to use batari BASIC to hack Atari 2600 "Adventure" by Warren Robinett, but you will be able to use batari BASIC to modify my own "Reventure" game, which I'll be working on as one of the example games in this tutorial. Since the purpose of this tutorial is to help you write games or other types of programs for the Atari 2600, I'll include some actual games for illustration. However, there are many different kinds of games, and each kind of game tends to have its own types of "issues" that need to be dealt with-- indeed, different games in the same category can have their own individual issues-- so it will be impossible to cover every sort of issue that might arise. Nevertheless, I'll include a variety of sample games, to help ensure that a variety of issues get discussed. Most of the sample games will probably be very simple, possibly not even complete "games" per se, and you're welcome to use them as a basis for creating games of your own. In addition, there will be a lot of snippets of code, and programming samples that by no stretch of the imagination could be classified as "games," to illustrate different ideas or to help you explore different features of the Atari 2600. Finally, I want to stress up front that I intend to keep the pace of this tutorial slow and methodical. For example, I intend to cover each of the Atari's features in one or more sessions of their own, rather than trying to present everything at once. This means you shouldn't expect to be able to start programming a game right away. I apologize in advance for this, but there are other tutorials about programming the Atari 2600 that you can refer to if you get impatient and want to jump ahead to something I haven't covered yet. In Session 2, I'll discuss the minimum required tools that you'll need to get started. And in Session 3, I'll discuss the process of getting these tools set up on your system. Michael Rideout

That's great! Thank you! Too bad about $00 though. Michael Rideout

Let's hope it's just temporary! Michael Rideout

Version 2.1 has been released: - Build issue corrected. - Support for disassembly of CAS files. - Drag and drop from Windows Explorer James 1020752[/snapback] Version 2.1 works great! I do have one question/request, though: Last night I used the VCS.H file that comes with DASM to create a 2600.EQU file for DIS6502, so I can disassemble Atari 2600 ROM images. It works great (you have to load the ROM as a raw file, then select the starting address), but I ran into an issue with the TIA addresses. Basically, the TIA read addresses-- which are used for collision detection and such-- start at the same addresses as the TIA write addresses, so I tried to define those addresses twice (once for writing, and again for reading). Unfortunately, that didn't work, DIS6502 just ignored all of the labels from the first duplicate onward. Is it possible, or could a feature be added, to define two labels that point to the same address? I realize this will present issues to the disassembler, since it won't know which label to use. But maybe if there was a way to let the user select which equate to use for a given line of code, or some way to tell DIS6502 to use equate1 for loads and equate2 for stores? I'd be a bit surprised if something like this hasn't been discussed before, since surely it's not that uncommon to reuse a (RAM) memory location for two or more things in the same program? Of course, there are other possible issues with 2600 disassemblies, such as the fact that the TIA and RIOT addresses get mirrored all over the place, and some games may use the mirrors; and then there are the bankswitching "hotspots," which vary depending on the bankswitching scheme. Anyway, I'm attaching my 2600.EQU file, with the "TIA READ ADDRESSES" remarked out for the time being. Michael Rideout 2600.zip

You can download the latest version from this very forum: http://www.atariage.com/forums/index.php?a...e=post&id=40558 I also recommend Crimson Editor, a free IDE that can be easily set up to work with batari BASIC and/or 6502 assembly programming. To answer your private message to me (because other people probably want to know the answer as well), no, I haven't launched my tutorial yet. I kept trying to revise it, and then I got sidetracked by other things. But I'm going to start posting it tonight or tomorrow night. And it won't be formatted in HTML like I'd intended, it will just be posts to this forum. Once it gets well under way, I plan to go back and start redoing it as a spiffy HTML version. Be warned, though, that I don't plan to get into any actual programming right away, because I intend to cover some preliminaries first, such as getting things set up on the computer-- downloading and installing the necessary tools, configuring Crimson Editor to work with batari BASIC and 6502 assembly, modifying the compile batches to allow the use of subdirectories, etc. Also, my intention is to cover the Atari's basic features one by one, therefore you may not be able to start working on a game until several sessions into the actual programming sessions. Michael Rideout

Excellent. I would appreciate that Michael. 1020077[/snapback] I can't seem to get a decent photo. I'm attaching one of the better ones, but it's too dark; on the TV screen, the colors were brighter. I tried to apply various types of adjustments to the photo (brightness/contrast, gamma correction, etc.), but none of them worked very well, so I'm just attaching the unmodified photo. Michael Rideout 7800.bmp

I'm curious why you can't load raw files - this has been supported since 1.7. Also, what menu items/options are missing? Feel free to send me what you're trying to disassemble if you're still having this issue so I can see what it does in 2.0. thanks James 1020464[/snapback] It may have been either an installation or operating system issue. The computer I was using at that time died a few months ago, and I'm now using a totally different computer. The older one was still running Windows 95 (!), and over the years I had installed several different versions of dis6502 on top of each other in the same directory. The computer I'm using now is running Windows XP, and I've installed dis6502 version 1.9-- and now version 2.0-- in their own directories. I just tried to load the same raw file that failed to load back in October, and it's working fine now (on this computer). I notice that the raw file opens in a pop-up window, so maybe Windows 95 had a problem with that, because I never got a pop-up window when I tried to load the raw file on my old Windows 95 computer. As for the differences between the documentation and the actual menu options in the program, the documentation I'm looking at is for version 1.4, because I can't find any newer documentation. In the version 1.4 documentation, the menu bar has the following menus on it: File - Select - Labels - Tools - Options - Help In the version 1.9 program, the menus are as follows: File - Labels - Tools - Options - Help As you can see, the "Select" menu seems to have been done away with at some point between version 1.4 and version 1.9. And there are also some differences between the menus in these two versions-- in general, version 1.9 has additional selections, but in some cases it has fewer selections. So it would be great if the documentation were brought up to date by someone. But my biggest problem was that I was having trouble getting things to work-- like loading a raw file, or telling dis6502 that a certain section of bytes are data rather than code so it wouldn't try to disassemble them. Those things seem to be working on this computer, so I'll try disassembling my USR routines again. I'm looking forward to version 2.1, since version 2.0 is giving me the missing DLL message that's already been described in another thread. By the way, I think it would be great to be able to disassemble Atari 2600 ROM images with dis6502. I suppose it already can, as long as the ROM image is loaded as a raw file, and the proper equates are used. I'll have to give that a try, too! Michael Rideout

I have a small program I wrote for the 2600 that displays all 128 colors at once, which I've previously posted in other forums/threads at AtariAge. And I now have a working 7800 again, with a Cuttle Cart 2, so I've taken several digital photos of my 7800 running the 128-palette display. Unfortunately, I couldn't seem to get a decent photo, so I didn't post any of them yet, but I'm going to try again tonight when I get home, and post a good one in this thread "for the record." Then we can compare the actual 7800 palette in the photo to the palette in the emulator. Michael Rideout

Okay, here's an updated version. All I did was add some more text to the help guide, and add some output messages. I did confirm that including spaces in the directory path or file name is okay, as long as you put quotes around it so the program understands that it's all one parameter. The new help guide, and an example of the new output messages, are shown below. Michael Rideout SplitFile.zip

Actually, I forgot that you can also just type "1," "2," or "4" for the size. And right now it might not like directory paths or file names that contain spaces-- I haven't tested that yet, it may work. I probably need to tinker it with it a bit more anyway, to add some kind of output messages, like trap error conditions and display some appropriate error messages, and especially output some kind of message when the program runs correctly, like showing a list of the output files that it wrote. Michael Rideout

I have an XP upgrade. Pretty please, with sugar on top? I'd really like to see some of the code for these games without having to ask someone to disassemble a bunch of games for me. I'm gone for the weekend, but you can be sure it'll have a download early next week if it's ready. Thanks, -JD 1012516[/snapback] Sorry for the delay! The original program was a QAD ("quick and dirty") hack that had the input and output filenames hardcoded (!) into the program, and I would just change the names and then run the program directly in QuickBASIC without even bothering to compile it. I had to totally rewrite it to be a true "command line" utility program, which is called "SplitFile." If you need help with it, you can just type "splitfile" at the command prompt and it will display a brief help guide, as so: As the preceding help guide states, the original input file can be split into one or more output files which are 1K, 2K, or 4K in size-- the reason being that (according to the bankswitching documentation by Kevin Horton) the various Atari 2600 bankswitching schemes can be grouped into three categories: (1) those that use banks which are 4K in size, (2) those that use banks which are 2K in size, and (3) those that use banks which are 1K in size. If no size is specified, then 4K will be assumed. Thus, if you know the bankswitching method used by a game, you can split the ROM into the individual banks, whether they are 1K, 2K, or 4K in size. The output files will be placed in the same directory as the input file, and will have numbers appended to their names, preceded by an underline character (e.g., "_1," "_2," "_3," etc.). The original extension will be kept. If the input file is less than or equal to the stated bank size, then only one file will be output. And if the input file is not an integer multiple of the stated bank size, then the last output file will be however many bytes were left over. For example, let's suppose that the SplitFile.exe program has been placed into the directory named C:\Atari\2600\Distella, and that a Burgertime.bin ROM file is in the directory named C:\Atari\2600\ROMs. The Burgertime ROM uses M-Network's bankswitching method ("E7"), which uses 2K bank sizes. So to split the Burgertime ROM into the appropriate 2K banks, you could type any of the following commands at the command prompt: or or and so forth. In each of these examples, the output files would be as follows: The program is written in FreeBASIC, which is a free BASIC compiler that uses a BASIC language which is mostly compatible with QuickBASIC (except FreeBASIC has some additional commands, plus a few of the commands have been modified somewhat from their QuickBASIC counterparts). The source code is included, in case anyone wants to peruse it, modify it, or port it to some other language. Michael Rideout SplitFile.zip

That is so true! Sometimes I wonder why that is... 1982: "Hurry up and finish that game, or you're fired! We unveiled the mock-up at the Consumer Electronics Show yesterday and promised the press that it would be ready for Christmas this coming weekend!" 2006: "Think I'll do some more work on the game today, I've got the first three screens looking good, but I still need to tweak the joystick routine a bit, and then next week I need to rewrite the audio, because right now it sounds like a couple of dueling chainsaws." 1982: "Hurry up and finish that game, or you're fired! We want to put you to work on "Return of the Teen-Aged Killer Mutant Pac-Men from Outer Space," plus "Snore Quest Phase 6: World of Bubbles," both of which we told all of the magazines we would have ready for Christmas tomorrow!" 2006: "I'm having a great time working on this game! I wonder what I'll work on when I'm through with this one? Oh, no need to worry about that yet, I'll just stay focused on this game for now." 1982: "What? Haven't you finished that game yet? You're fired! Oh, and on your way out the door, you can stop by the Payroll Department and pick up your frozen turkey Christmas bonus in thanks for the multi-billion-dollar game you created last month! And don't forget, no one must ever know that it was you who wrote that game; you signed a non-disclosure agreement, and the company gets all the credit (plus all the profit) from every game you created!" 2006: "You know, I might not make any money from writing this game, and I'll actually have to shell out some money of my own to get the cartridges made, but it sure does give me a super-cool natural high to hold a finished game cartridge in my hands, smell that new game smell, and see my name printed on the label." Hmm... on second thought, never mind! Michael Rideout

Yes, I noticed a few weeks ago that the link no longer works. Not that I needed to download it (I already have it), but I was including it in a list of available IDEs for Atari 2600 development, and I wanted to be sure it was still available. I no longer have the original zip file, but I'll zip up and send you what I have, if I can figure out everything that went with it. But I'd like to point out a few things: (1) The editor that the 2600SDK uses is a DOS-based program, so it doesn't look very pretty in Windows. You can actually get a more full-featured Windows-based IDE by downloading the free Crimson Editor program. That's all the 2600SDK editor is-- a DOS-based IDE that you set up to call DASM to compile with, and to call an emulator to play the compiled ROMs with. You can do the same thing with Crimson Editor. For that matter, you can do the same thing with the 2600IDE editor, which has a built-in playfield and player editor (although its text editor features are very simplistic compared to IDEs that have been under development for several years). So there's nothing special about the 2600SDK editor. (2) The 2600SDK package also included the DASM assembler, along with the VCS.H and MACRO.H include files that are used with it, for compiling programs. However, the version that was included was old-- that is, there have been several newer realeases of DASM since then. (3) As I recall, the 2600SDK package also included the Stella emulator-- or it may have been z26. But again, newer versions of Stella have been released since then. (4) Finally, the 2600SDK package included the "Stella Programming Guide" PDF document, which is available from several web sites. So there's no particular reason why you need the 2600SDK package. I do happen to be a little fond of, myself, but mostly for sentimental reasons-- it was what I used about a year and a half ago to get started with Atari 2600 programming! Michael Rideout

Thanks, I found the same link earlier tonight by searching the forums archive for "MemCard." I can't believe how cheap they are ($10, right?)! I haven't ordered one yet, but I figure I'll buy at least 2-- one for my 2600, and one for my 7800! This is a great time to be an Atarian-- batari BASIC, Cuttle Cart (1 and 2), Krokodile Cartridge, AtariVox, MemCard... what's next? (Maybe supercat's bankswitched cartridge with oodles of executable RAM?) Michael Rideout

I've seen this, and finally stumbled back into it re-reading all of my old posts. Is there a free web-based program that will split the file in half for you? The one Thomas refers to way back when no longer exists in it's old form. And if not, has anyone written their own they would be willing to share? Also, while I'm at it, how do you specify an address as GFX? -JD 1012329[/snapback] I wrote a simple little QuickBASIC program to split 8K (or larger) ROMS into two (or more) 4K segments. If you have Windows or MS-DOS (i.e., if you can run QuickBASIC executables), I'd be happy to spruce it up a little and share it. Michael Rideout

Yes - that makes sense. One thing to note is that I made turning much easier by allowing you to press diagnol prior to getting to an intersection to make your next move. For example, if you're moving up and want to take the next left, you should press up and to the left (diagnol) before you get to the intersection. When you reach the intersection, your ladybug will turn left (no need to line things up). This of course works in all directions. I can easily move around the maze, opening doors with no mistakes, but if people still think it's too difficult I will work on implementing the "fudge factor" as you described. 1012014[/snapback] Yes, I tried doing the diagonal move to turn more easily, and it did help a lot, but it was still kind of tricky to turn at times, especially when doing a "360" in certain areas of the maze. I figured that turning corners would get easier with practice, but in my opinion, anything you can do to make it easier for the player to move around will improve his or her enjoyment of the game. It's aggravating to get a game that you were really looking forward to, only to discover that moving around is difficult for one reason or other. Also, when movement is more difficult to do, it's my experience that I end up pushing harder on the joystick, which can shorten the lifespan of the joystick. So with a game that's as great-looking as Ladybug is, you want to do anything you can to keep the gamer's experience enjoyable (yet keeping the game challenging, of course). Michael Rideout

Ok, it helps the color - but wouldn't the flicker itself become a lot more obvious? 1011909[/snapback] I still need to try it on a TV with my 7800, but when I tried it on an LCD monitor with the Stella emulator (with both the monitor and Stella set to 60 Hz), the flickering didn't seem to be any worse. I know from experience that flickering is usually more noticeable when switching between two luminances that are farther apart (e.g., lum $0 and lum $E). But then again, $4C isn't as bright as $0E, due to the difference in the hues. I thought about trying to take a digital photograph of my TV screen, with my 7800 running a demo to show the difference, but I'm not sure how I could capture the blending effect of the flickering-- unless I make a short video capture? Anyone have any ideas? If I were using a film camera, I could just make sure that the shutter stays open long enough to get both frames so the blending can be seen. Is something similar possible with digital cameras? (I'm not an experienced digital camera user-- in fact, I only just bought a digital camera tonight after work!) Michael Rideout

I did a quick test of this in batari BASIC, and it does help, although of course the flickered red ends up having a grayish washed-out look. Also, the brighter color had to be about 3 times brighter than the normal color to get roughly the same effective luminance-- at least, using an emulator and an LCD monitor. I haven't tried my test on a TV yet, but the TV's phosphorescent effect might help. So, if it's possible to work that sort of color change into the kernel, on the scan lines where flickering must be used, it would be worth a try. Michael Rideout

The "PF0Array = $80" line isn't a "command" per se, it's an equate. It has two basic purposes: it tells the assembler that wherever "PF0Array" is seen in the program code, it is to be replaced (during the assembly process) with "$80"; and it helps make it easier for people to read or write the program code, since the programmer can just refer to "PF0Array" instead of having to write "$80" (which isn't self-explanatory the way that "PF0Array" is). Same with "ScoreshapeLow01 = $92". "PHP", on the other hand, is a 6502 assembly command which means "PusH the Processor status onto the stack." By itself, that doesn't mean "enable or disable bullet 1," although that is apparently what it's being used to do in this game. Michael Rideout

This looks great! I have only two gripes: First, it's hard to turn; you have to be lined up precisely right. Even if you think you're lined up just right, you might still be a tad off. Maybe you could add a small fudge factor, like if you're trying to turn, and are within a color clock either way, then you will automatically line up as needed so you can turn (if that makes sense). Second, the flickering when the ladybug overlaps another bug's scan lines makes both of them much darker (which is the nature of the flicker beast, of course). I wonder if making the colors brighter on those scan lines would help, since flickered colors get combined? That is, on scan lines where there's no flickering, just use the normal colors. But on scan lines where flickering is needed, if the colors are made brighter, then flickering them against the black background might result in a less noticeable loss of color, like this: Normal scan line (no flickering): Frame 1: Ladybug color = $44 (or whatever). Frame 2: Ladybug color = $44 (or whatever). Combined result: color = $44. Scan line with flickering: Frame 1: Ladybug color = $48 (i.e., twice as bright as normal). Frame 2: color = $00 (background). Combined result: color = $44? (not really, since hue 4 and hue 0 doesn't give hue 4; but lum 0 and lum 8 = lum 4?). I don't know if anyone's ever tried something like that, but it seems like it might possibly help. Michael Rideout

The dragons don't move around faster on the screen, they "just" eat you faster (if they get you in a good "I've got you in range of my jaws now" position). Michael Rideout

Come again? You have a box of what that you need to get rid of? I thought they were temporarily sold out or whatever until another batch gets made, or am I getting them confoozled with something else? Because if you've got something for sale, I'd like to know the details! Michael Rideout

On second thought, maybe I should clarify something. Yes, there is a way to convert the binary source of a game into batari BASIC-- but not automatically, and the resulting bB program will not compile into 6502 code that's the same as the original code. In other words, you could disassemble the binary source, analyze the disassembly manually, and do your best to replace sections of 6502 code with bB code that accomplishes essentially the same thing, or as nearly the same thing as you can manage. But this might require totally redesigning or replacing bB's include files, along with using inline assembly code for things that can't be adequately replaced with bB code. In short, the process would be very labor-intensive, and the results might not be good enough (fast enough or condensed enough) to justify the effort. On the other hand, such an exercise could be extremely educational, if it helped you figure out ways to accomplish similar results using batari BASIC (e.g., the original game is drawing a particular player shape and moving it around, so how can we draw the same player shape and move it around using bB statements). So no, there's no way to do a conversion automatically, but you can do your best to manually convert a non-bB game into a bB game that recreates the "look and feel" of the original game as much as bB is capable of. And there's no way to get the equivalent bB code to compile into an exact replica of the original game. Michael Rideout

I'd like to take a stab at this, too! There's another issue in addition to the ones already mentioned. Basically (no pun intended), bB code isn't going to be as optimized as pure 6502 code could be, due to the manner in which the bB code is converted into 6502 code. For example, consider a simple custom display kernel, written entirely in bB code: COLUBK = $94 : rem * Set the background to blue loop VBLANK = 2 : rem * Turn on the video blanking for x = 1 to 30 : rem * Draw 30 blanked scan lines WSYNC = 0 next VSYNC = 2 : rem * Turn on the vertical sync pulse for x = 1 to 3 : rem * Draw 3 blanked scan lines WSYNC = 0 next VSYNC = 0 : rem * Turn off the vertical sync pulse for x = 1 to 37 : rem * Draw 37 blanked scan lines WSYNC = 0 next VBLANK = 0 : rem * Turn off the video blanking for x = 1 to 192 : rem * Draw 192 blue scan lines WSYNC = 0 next goto loop When this bB code is compiled, the resulting 6502 code is something like this (I've edited it to look more like "normal" 6502 code): LDA #$94 STA COLUBK .loop LDA #2 STA VBLANK LDA #1 STA x .L03forx LDA #0 STA WSYNC .L05 LDA x CMP #30 INC x bcc .L03forx .L06 LDA #2 STA VSYNC .L07 LDA #1 STA x .L07forx .L08 LDA #0 STA WSYNC .L09 LDA x CMP #3 INC x bcc .L07forx .L010 LDA #0 STA VSYNC .L011 LDA #1 STA x .L011forx .L012 LDA #0 STA WSYNC .L013 LDA x CMP #37 INC x bcc .L011forx .L014 LDA #0 STA VBLANK .L015 LDA #1 STA x .L015forx .L016 LDA #0 STA WSYNC .L017 LDA x CMP #192 INC x bcc .L015forx .L018 JMP .loop On the other hand, a more optimized version written in 6502 code might be: LDA #$94 STA COLUBK LDA #2 .loop STA VBLANK LDX #30 .front_porch STA WSYNC DEX BNE .front_porch STA VSYNC STA WSYNC STA WSYNC STA WSYNC STX VSYNC LDX #37 .back_porch STA WSYNC DEX BNE .back_porch STX VBLANK LDX #192 .raster STA WSYNC DEX BNE .raster JMP .loop Note how much more condensed the pure optimized 6502 code is. The bB code is probably easier for many people to understand, but it ends up producing lengthier 6502 code when it's compiled. And if you want to use bB's default kernel, the bB code is even easier to understand: COLUBK = $94 loop drawscreen goto loop However, bB's default kernel does a lot more than what the custom bB kernel did in the first example, because bB's default kernel includes code to automatically draw the playfield pixels, players, missiles, and ball on each scan line, which the custom kernel in the first example didn't bother to do. When programmers write Atari 2600 games, they usually go to great pains to squeeze the instructions into the smallest number of bytes and fastest execution time. Simply put, even if you could create a conversion utility that's smart enough to be able to examine 6502 code, figure out exactly what it's doing, and generate bB code that does essentially the same things, the equivalent bB code will compile into much lengthier 6502 code, which will take up more bytes and execute in more machine cycles. Additionally, bB uses a lot of the Atari's 128 bytes of RAM for bB's own "system variables" (e.g., the array for the playfield pixels, the variables for storing the x and y positions of the players, temporary variables that are used with bB's default kernel, etc.). So if we tried to convert a typical Atari game into an equivalent bB game, we probably won't have enough free RAM to use for all of the game's own variables. So even if somebody could create such a conversion utility (and it would certainly be very cool if someone could), there wouldn't really be much point in using it. But that doesn't mean we can't create bB games which are very similar to existing Atari games. Michael Rideout

Well, all you really need (absolute essentials) to develop games for the Atari 2600 are (1) a computer, (2) a text editor, (3) a 6502 assembler, and (4) an Atari 2600 emulator. Obviously, (2), (3), and (4) should work on (1). It could be argued that (4) isn't essential, since you can run your games on an actual Atari 2600 or 7800 if you have the right tools for doing that-- e.g., a Supercharger, Cuttle Cart, Cuttle Cart 2, or Krokodile Cartridge, and anything else required to load the game into said devices. But for the average person, an Atari 2600 emulator is probably more easily obtained and more convenient to use. As far as (3) is concerned, the DASM assembler is available for Mac OS X, so you can/should download DASM (http://www.atari2600.org/DASM/). As far as (4) is concerned, the Stella emulator is available for Mac OS X, so you can/should download Stella (http://stella.sourceforge.net/). That leaves (2). If you want to make the programming process easier, you'll want to use an IDE ("integrated development environment"), because you can set up any decent IDE to compile your programs, and to run your compiled programs, all from within the IDE. I read that there is a free IDE for Mac OS X called Xcode, but I don't know anything about it. If you've never used an IDE before, be aware that you generally need to set it up to work with any language that doesn't have built-in support, so you'll most likely need to set up the IDE to call DASM to compile your programs, and to call Stella to run your programs. An alternative to programming in pure 6502 assembly is to use batari BASIC. As far as I know, you'll need to "make" or build/compile batari BASIC to run on OS X, since an executable for OS X isn't already provided the way that an executable for Windows is. Compiling batari BASIC program code is a two-step process-- first you must compile the batari BASIC code into 6502 assembly code using the batari BASIC compiler, then you must assemble the 6502 assembly code into a binary file or "ROM image" using the DASM assembler-- so you still need to get DASM. And you'll need to set up your IDE so it calls a batch file that in turn calls the batari BASIC compiler and the DASM assembler. You can download the source for the latest "official" release of batari BASIC (http://www.alienbill.com/2600/basic/), or you might prefer to download the "bleeding-edge pre-release" of the next version (http://www.atariage.com/forums/index.php?showtopic=82011). It also goes without saying that you'll need good references on the Atari 2600 (its features, its memory map, and how its memory locations control its features), and on the 6502 assembly language. These are available here on the internet: http://atarihq.com/danb/ http://www.6502.org/ Michael Rideout