SeaGtGruff

Clever solution!

As batari mentioned, CS1 is active high, whereas /CS0, /CS2, and /CS3 are active low. To expand very slightly on what he said... CS1 is connected to power (always high if the power is on), and /CS2 is connected to ground (always low), so they don't contribute anything to the addresses. /CS3 is connected to A7 and should be low to address the TIA. /CS0 is connected to A12 and should also be low to address the TIA. However, the TIA schematics are a bit confusing, as they don't specify what the chip select pins are connected to, and there's a note on sheet 2 (where the address decodes are shown) stating that CS1 and /CS3 were deleted in chip revision E. That would make sense if CS1 and /CS3 are connected to power and ground, respectively, since they would always be high (CS1) or low (/CS3) as long as the machine is turned on, hence there's not much point in checking them. Yet the 2600 schematics show that /CS2 is connected to ground and /CS3 is connected to A7, so it appears that perhaps the note on TIA schematics should have read that CS1 and /CS2 were deleted in chip revision E. Note that the TIA schematics also show the pin numbers for L0 (LUM0) and L1 (LUM1) as being switched around from what all other sources show-- which has no bearing on the address issue, but does suggest that the TIA schematics may contain a "typo" or two. Of the remaining address lines, only A0 through A5 are connected to the TIA. A0 through A5 are decoded for the write addresses, but only A0 through A3 are decoded for the read addresses. There's no way to restrict the TIA's address range to $0000 through $003F inside the TIA itself. You'd need to do it outside the TIA, presumably by checking A6 through A15 and redirecting the address access request to some other destination if any of those address lines are 1, and letting the request go through to the TIA only if all of those address lines are 0. I have no idea how you would go about doing that, though-- I'm not a hardware guy-- but I assume it would involve some sort of "internal surgery" or hardware modification to the 2600 (i.e., I don't see how you could do it with just some sort of special cartridge since the 6507 and TIA connections are inside the console and-- as far as I know-- can't be "trapped" by the cartridge). Of course, there are no pins on the 6507 for the A13 through A15 address lines, so I don't know how you could prevent the TIA from accessing "mirrors" above $1FFF.

Again, I'm not sure about this-- but it looks like the color table for the Green Goblin may start at $FE55, loaded using ABS,Y addressing, so the actual colors are offset from $FE55 depending on the value of Y.

According to Stella (looking at the TIA tab in debug mode), the building (playfield) color is $1C and the sky (background) color is $8A. That's for the first screen; I don't remember, but I think the colors may change. Looking at the code in DIS6502, it looks like the color table for the building starts at $FF8E, and the color table for the sky starts at $FECB, but I'm not certain about that, and the colors are loaded from the tables using ABS,X and/or ABS,Y addressing, and I'm not sure what the ranges for the X and Y registers are when reading the tables.

That sounds odd-- had you meant to say "within a specific range"? I like the box analogy; that's one of the analogies they used a lot back when I was learning about computers. Re: strings-- bB doesn't have string variables per se, but there's the "def" command that lets you assign a string to a logical name-- except that "string" in this case isn't quite the same as a string variable or string constant; it's closer to a string constant, but its purpose and use are different than the purpose and use of a string constant. Also, values are assigned to constants as well as variables. I don't know if RT mentioned "constants" yet (I didn't see them mentioned), but it might be a good idea to mention constants and variables before mentioning ROM and RAM. Then an analogy could be drawn between constants and ROM, and between variables and RAM. The following may be kind of messy or too long/complex, but it's just a first attempt. Constants, variables, and values: Constants and variables are like boxes that can hold things, and values are the things that are stored inside the boxes. In the Atari 2600, each box is normally one byte, but you can also divide a box into smaller sections (bits or groups of bits), and you can combine two or more boxes to make a larger box. These boxes have addresses within the Atari's memory, but we give them names so they're easier for us to use. For example, "address $83" tells us the address of that particular box, but doesn't tell us what "lives" at that address. If we're going to be using that box to store the number of lives a player has remaining, then it's easier to write our program (and to read and understand it later on) if we call it something like "lives_remaining" rather than "$83." Constants: A constant is a box that contains a value which will never change and that can't be changed once the box has been filled. For example, if we've taken a box, named it "three," and then put the number 3 in it, we can use the constant "three" in places where we want to use the number 3. That may sound silly, and that particular example is-- why not just use 3?-- but constants can be very useful in programming. Suppose you want the space ship in your game to be yellow. You can define a constant named "ship_color" and put the value for the color yellow in it. Then anywhere you want to refer to the ship's color you say "ship_color." Later on you may decide you want the ship to be light blue instead of yellow. All you have to do is change the definition of "ship_color" to be the value for light blue and it will change everywhere "ship_color" was used in your program-- you don't need to go searching for all the places it's used and change them individually (potentially missing some places). Variables: A variable is a box that contains a value which needs to be able to change while the program is running. For example, if we've named a box "lives_remaining," then we can store the number of spare lives the player starts with in that variable. As the game is being played, we can reduce the value of "lives_remaining" by 1 whenever the player loses a life, or increase it by 1 whenever the player earns an additional spare life. Values: Values come in two basic flavors-- numbers (numeric values) and characters (alphanumeric values, meaning letters, numbers, or other symbols). However, batari Basic doesn't have alphanumeric values, so all we need to understand in batari Basic are numeric values. A constant or variable is limited in the values it can contain. A single byte can hold any whole number from 0 to 255. A single bit can hold a 0 or a 1. So depending on the size of the box (how many bits wide it is), it can hold a value ranging from 0 to 1 (1 bit wide), or from 0 to 7 (3 bits wide), or from 0 to 255 (8 bits or 1 byte wide), or from 0 to 65535 (2 bytes wide), and so forth. Memory, ROM, and RAM: A memory location is like a box with an address. Memory is used to store constants, variables, and the programming instructions that tell the Atari how the game works. Memory comes in two basic flavors-- ROM and RAM. ROM: "ROM" stands for "Read-Only Memory," and is memory that can't be changed once it's been written to. In other words, a ROM address is like a constant. You can't store a variable in ROM, because then you wouldn't be able to change its value. However, you can store a constant in either ROM or RAM-- although on the Atari 2600, constants are normally stored in ROM so the RAM (what little there is) can be used for variables. Still, there are certain instances when constants are stored in RAM, such as if you're using a Supercharger and the program is being loaded from a tape and stored in the Supercharger's RAM. But in the case of games that are stored on a cartridge, the ROM inside the cartridge holds the constants and programming instructions for the game. RAM: "RAM" stands for "Random-Access Memory," and is memory that can be changed. RAM is used to store variables and other information that needs to be able to change, such as a screen display. On the Atari 2600, there's no "screen memory" per se, and screen displays are often defined in ROM. But in its standard kernel batari Basic sets aside some RAM to use as "screen memory" for the playfield. The Atari 2600 has only 128 bytes of RAM, but some game cartridges have extra (or expansion) RAM on them so more variables or more detailed screen displays can be used in the game. Registers, Read-Only Registers, and Write-Only Registers: A register is a special memory location that's used for some particular purpose by the Atari 2600. Registers are found on the three chips that make up the Atari's "brain"-- the 6507 or CPU (which performs the game instructions), the 6532 or RIOT chip (which supplies the RAM as well as the timer and interfaces with the input/output devices like the console switches and game controllers), and the TIA or "Television Interface Adapter" chip (which handles the video and audio). A few of these registers-- such as the accumulator and the X and Y registers inside the 6507 chip-- don't have memory addresses, but we can store information in them by using specific instructions. But most of the other registers-- those found inside the RIOT and the TIA-- are mapped to memory addresses so we can read from them or write to them. Most registers are like RAM addresses because their contents can change, but some registers-- particularly many of the ones in the TIA-- are less than 8 bits, so they can hold only specific ranges of values. And a few of the TIA's registers don't even have any bits at all-- they're called "strobe" registers that make something happen whenever we write to them. The TIA's registers come in two different flavors-- read-only and write-only. Read-Only Registers: A read-only register is one you can read, but you can't write to it. The TIA's read-only registers are used to read collisions between the graphical objects-- for example, reading the CXM0P register lets you see if missile 0 has overlapped (collided) with the player 0 sprite or the player 1 sprite. There are also read-only registers for reading the paddles or the joystick buttons. Write-Only Registers: A write-only register is one you can write to, but you can't read it. The TIA's write-only registers are used to draw the game on the screen, play sounds, or perform some specific action like clearing the collision registers or moving the sprites to the left or right. You can write a new value to a write-only register-- for example, writing a color value to the COLUPF register will tell the Atari what color to draw the playfield with-- but you can't read a write-only register to see what value it's currently set to.

How about something like "ROM and RAM are two different kinds of memory. ROM is memory that's already filled with information you can't change. In an Atari game cartridge, the ROM contains the program instructions and the data for the graphics and sounds. RAM is memory you can change. It's used to store data that needs to be able to change, such as your game score or the positions of the sprites."

Actually, a "built with batari Basic" logo/icon was designed a few years back... http://www.atariage.com/forums/topic/78676-official-batari-basic-logo/?do=findComment&comment=959796

My first computer was also a VIC-20 with a datasette. I got it for Christmas, so I don't know where my parents bought it-- possibly at Sears or K-Mart. I had wanted an Atari 800, so I was somewhat disappointed to get a VIC-20 instead, and I wasn't thrilled that the display had only 23 rows of 22 characters. Nevertheless, I had a lot of fun playing the Scott Adams' text adventure games, or adapting some of my programming assignments in college to the VIC-20 (my first adaptation was a program to calculate the first weekday for any given year and display a monthly calendar). I also typed in a lot of programs from magazines and books. I bought the 16K RAM expansion/BASIC programming extension for it, as well as "Mapping the VIC-20," and experimented with writing interrupt routines to switch screen colors at specific scan lines. I also wrote my own 6502 assembler and disassembler for it. I was just learning how to wedge my own "commands" into the BASIC interpreter when coverage of the VIC-20 was essentially dropped by the magazines. (I actually submitted an article for the VIC-20 to Compute! magazine and got a "nice" form letter rejection, which really bummed me out at the time.)

On the other hand, it doesn't work so well if you're printing the web page. Just today at work I printed out a web page that had some info I needed for a Payroll project, and the printout took 7 pages when the material would have easily filled up only 1 or 2 pages if each of the margins hadn't been wider than the actual text-- the text filled up less than one-third of the page horizontally! It looked great on the screen, but was a horrible waste of space and paper when printed out. (And sadly, the page didn't have a "printer-friendly version.") On the other hand, I printed another page from the IRS web site that looked more intimidating on the screen, yet when I printed it to paper it took up less than 2 pages because of the font size and the formatting of the text.

I think I read somewhere that YouTube uses 29.97 or 30 frames per second, so that would mean every other frame from the emulator gets dropped. Stella lets you set the frame rate, so you can set it to 30 FPS-- but then the game plays like it's in slow motion.

I opened Trebor's palette in Multi-Edit in the binary mode, with a record length of three bytes, then defined a macro to remove the lines for the odd-numbered colors, so creating the NTSC palette was easy and I can redo it quickly. It was a bit more work to get the PAL palette, because I had to cut and paste the lines for the NTSC palette to rearrange them in the PAL order-- but it shouldn't take too long to redo that for the corrected palette.

I would go with the two's complement approach.

There are some 6502 assembly math routines at http://6502.org/source/.

1 microsecond = 1/1,000,000 seconds 1 color clock = 1/3,579,575 seconds 1 machine cycle = 1/1,193,192 seconds 400 microseconds = 400/1,000,000 = 4/10,000 = 1/2,500 seconds 1,193,192/2,500 = 478 machine cycles 478/76 = 6.3 scan lines I posted some code in the batari Basic forum for reading the keypad controllers, and someone else cleaned it up and posted an improved version.

Did the folder already exist?

One thing I noticed about the VIC pinouts is that the chip select lines are in reverse order from the TIA chip.

Just a note-- I played around with the TV effects in Stella (3.7.3), and while they do let you tweak the palette like on a TV by fiddling with the brightness, contrast, and hue, the palette you start with still makes a difference.

Yeah, some of the information seems a little too detailed to have been discovered through reverse engineering. It makes me wonder if they'd managed to get their hands on the TIA schematics? As for the different names used for the registers, maybe they did that so they could say their chip was different? "Your Honor, Atari's TIA chip had the registers shown in Exhibit A, whereas our VIC chip has the registers shown in Exhibit B. Clearly we did not plagiarize their TIA chip!" I also think it's interesting that the document uses the NTSC color frequency-- ca. 3579545 Hz-- rather than the 3579575 Hz frequency shown in the 2600 schematics. I wonder if Coleco's 2600 clone used a 3579545 Hz crystal instead of a 3579575 Hz crystal like Atari did?

I sometimes change my preferences from day to day, but in general I use all uppercase for register names (VSYNC, INTIM, etc.) and also for assembly opcodes (LDA, STX, etc.). I use all lowercase for batari Basic commands (if, then, for, next, etc.) and variable names (a, b, player0x, lives_remaining, etc.). And I generally (but don't always) use a mixture of uppercase and lowercase for line labels or routine names (Move_Player, Check_Collisions, etc.). But I don't stick with these conventions religiously, because it can be a hassle to have to remember whether some label was supposed to be all lowercase or a mixture of uppercase and lowercase. The only convention I stick to religiously is that register names and assembly opcodes are all uppercase. Aside from that, I always put each program instruction on its own line, rather than squeezing a bunch of instructions onto the same line with colons-- unless there's some reason to put multiple instructions on the same line, such as when setting several variables to the same value (to help optimize the compiled code for space), or when the instructions are part of an if-then-else construct. Also, I put spaces around mathematical symbols (a = b + c * d, not a=b+c*d), because otherwise I think the "mathematical sentence" istoohardtoread, since the individual parts don't stand out like separate words. Likewise, I space after the comma in a multi-dimensional array or list of parameters, such as a = my_usr_function (b, c, d). I indent 3 spaces at a time when coding for the Atari. I think single-space indentation sucks, because the line labels don't stand out enough, and if nested indents are each indented a single space per nest level (um, am I coining new gibberish terms?), then I think the lines look sloppy when you glance at the code, as if the programmer couldn't be bothered to indent the same amount each time-- the different levels of nesting don't stand out enough. I think it takes at least 3 spaces for the line labels to stand out from the code lines, and since I do use nested indents in batari Basic where appropriate (such as in a for-next construct), I think more than 3 spaces per indent level starts to use up too much line space for the indents. That's really more of a bother in assembly programs, because I like to devote the right half of the line to a detailed cycle count (number of cycles for the instruction, total number of cycles since the beginning of the last horizontal blank, running color clock count (cycles times 3), current screen position (color clock count minus 68), and effective horizontal position (if I'm strobing a sprite's position register-- current screen position plus 4 or 5). As for comments, it depends. If I'm writing a lengthy explanatory comment that consists of multiple sentences, then I write them as though I were writing sentences-- lowercase except at the beginning of a sentence or line label, or all uppercase for register names or opcodes, with a period to end each sentence. And I usually start the next sentence on the same line if possible, just as if writing normal text, except when I want to begin a new paragraph (yes, some of my comments are that long!), or when I'm including a bulleted list in a comment, etc. But if it's just a brief comment-- not even a complete sentence, just a quick aside-- then I usually type it in all lowercase (except when referencing register names or line labels) and omit any period at the end.

The following is a bit involved, so I hope it isn't too difficult to follow. You might want to print this post so you can refer to it as you follow the steps. You can install batari Basic and the other programs wherever you want-- it doesn't matter, as long as set up your scripts and tools so they look in the necessary folders. If you want to keep them together in a common folder, you can create some folder with the name of your choice (e.g., "C:\Atari2600," or "C:\batariBasic," etc.). Note: It's a little simpler if you make sure your folder names have no spaces in them, but it's okay to include spaces if you really want to, as long as you modify your scripts so they can handle the spaces. Then when you install Crimson Editor you can change its default installation directory from whatever it is (probably something like "C:\Program Files\Emerald Editor Community\Crimson Editor 3.72") to wherever you want to install it (e.g., "C:\Atari2600\CrimsonEditor," or "C:\batariBasic\CrimsonEditor," etc.). Likewise, when you install the Stella emulator you can change its default installation directory and install it in a subdirectory under your main folder (e.g., "C:\Atari2600\Stella"). After you've installed batari Basic itself in your main directory, you might want to create some additional subdirectories for it so you can move some of its files into the subdirectories to help organize things. For example, there may be some .C files in batari Basic's main directory, and you can create a "Source" subdirectory and move those .C files inside it if you want, along with the .H and .SH files. For the remainder of this post I'll assume you've already installed everything, and not necessarily under some common folder. First of all, you need to realize that you can't just "run" batari Basic by double-clicking on the EXE file, because it doesn't work that way-- it uses command-line parameters. There should be a 2600BAS.BAT file in your batari Basic directory, and you'll probably need/want to customize the BAT file a bit to make sure it's looking for stuff in the right places, as well as to make sure some of the command lines are using a proper Windows syntax. To customize the BAT file, right-click on it and select "EDIT" (if you double-click it or try to "OPEN" it, Windows will try to run it instead of opening it for editing). After you've got the BAT file opened for editing, look through the command lines for places where there's a slash ("/"). Some of these are okay, but the ones that are part of a directory path should be changed to backslashes ("\"), because Windows uses backslashes in its directory paths. For example, in the line that says "if exist %bB%/sed.exe goto havesed" the slash is part of a directory path, so it should really be a backslash ("if exist %bB%\sed.exe goto havesed"). Likewise, in the DASM command lines there's a slash that should be a backslash ("dasm %1.asm -I%bB%/includes" should have a backslash in it rather than a slash). However, all of the slashes that are inside quotes should be left alone, because they do need to be slashes (e.g., "/Label mismatch/d" should have slashes, so don't change them). In addition to changing some of the slashes to backslashes, you should look through the command lines for places where there are redirection symbols-- ">" or "<"-- and make sure that each of them has a space on either side of it. For example, "preprocess <%1 | 2600basic.exe -i %bB%>bB.asm" needs a few spaces added to it so it looks like "preprocess < %1 | 2600basic.exe -i %bB% > bB.asm." (If you're wondering why you need to make these changes, the BAT file works fine as it is in UNIX-- I think-- and some of these edits might not be absolutely necessary in Windows, but different versions of Windows can be quirky about these things, and I've found that it's best to edit the BAT file in this manner just to be on the safe side.) Likewise, check for the pipe symbol ("|") and make sure it has a space on either side of it. After you've made the edits decribed above, you may want to add a couple of lines near the top of the BAT file, just after the "@echo off" line. The BAT file expects you to have an environment variable defined, and you can either add it to your Windows environment variables (if you know how to do that), or simpy define it inside the BAT file. I personally like to define it inside the BAT file, because that way you could have multiple versions of batari Basic installed under different folders and set up each one's BAT file to define the environ variable as needed. So assuming you want to define it inside the BAT file, add a blank line just after the "@echo off" and type the following on the new line: set bB=whatever where "whatever" is the full directory path to your main batari Basic folder. For example, if you've installed batari Basic in a folder named "C:\Program Files\batari Basic," then the line would be set bB="C:\Program Files\batari Basic" (the directory path needs to be typed inside of quotes if it contains any spaces, and the quotes are okay even if the directory path doesn't contain any spaces). Then press ENTER again to make another blank line just below that one, and type the following on the new line: set Path=%Path%;%bB% This will add your batari Basic directory path to Windows' search path. Now you can save and close the 2600BAS.BAT file. Next, you'll need to set up two user-defined tools in your Crimson Editor program-- one for compiling your batari Basic game programs, and one for running your compiled games with the Stella emulator. Start up Crimson Editor, click on the "Tools" menu, and select "Conf. User Tools..." In the "Preferences" popup window, click on the first line inside the "User Tools" list box (in the upper center of the window). This will select the first user tool so you can configure it. Below the list box are five entry fields: Menu Text Command Argument Initial Dir Hot Key Click inside the "Menu Text" field and type some descriptive text of your choice that will remind you what this tool does-- for example, "Compile batari Basic Program." Then click inside the "Command" field and type the directory path and name of the 2600BAS.BAT file. This will vary depending on where you installed batari Basic. For example, if you installed it inside "C:\Program Files\batari Basic" then the command would be "C:\Program Files\batari Basic\2600bas.bat" (you can put quotes around it but they aren't necessary in this instance). There's a browse button ("...") to the right of the field, so if you need to you can simply browse to wherever the 2600BAS.BAT file is and "open" it to populate the entry field with the correct command. Next, click in the "Argument" field and type the following (put quotes around it as shown, just to be safe): "$(FilePath)" Finally, click in the "Initial Dir" field and type the directory path where your batari Basic include files are located. (The batari Basic installation process should have created an "Includes" folder for you.) For example, if you installed batari Basic in the "C:\Program Files\batari Basic" directory, the initial directory would be C:\Program Files\batari Basic\Includes (you can put quotes around it, but they aren't necessary in this case). Below the fields are some check boxes. Check the box that says "Capture output," as well as the box that says "Save before execute." Uncheck the other two boxes if they're checked ("Close on exit" and "Use short filename (8.3)"). Then click on the "Apply" button to save the setup. Next, click on the second line in the "User tools" list box to select it. (By now the first line should have changed to say whatever descriptive text you entered for the first tool.) You want to set up the second tool for running your compiled programs. After selecting the second user tool, click in the "Menu text" field and enter some descriptive text of your choosing-- for example, "Run Stella." Click in the "Command" field and enter the command line for starting Stella. Again, the simplest way to do this will be to click on the "..." button to the right of the field, browse to the folder where you've installed the Stella emulator, and "open" the STELLA.EXE file, which will populate the "Command" field with the correct command line. Next, click in the "Argument" field and type the following: "$(FilePath).bin" (put quotes around it as shown, just to be safe). Click in the "Initial Dir" field and enter the directory path to wherever Stella was installed. Check the "Close on exit" box and uncheck the other three boxes. Then click "Apply" and "OK" to close the popup window. Now you're ready to try out your installation. After you type in a program-- or load an existing program (e.g., the "default.bas" program)-- click on "Tools" and select the one you configured for compiling. After the program has been compiled successfully, click on "Tools" and the select the one you configured for Stella to run your program.

Thanks, very interesting!

Well, just for the record my guesses were going to be (1) a really ugly sprite; (2) a secret; (3) a puzzle; (4) a really short program; (5) a really short secret puzzle program; or (6) a really short secret puzzle program with a really ugly sprite. The reference to a 128-byte demo in the first post led me to think this was supposed to be program code, so I converted the bitmap into 8-bit binary values, then into hex, then into 6502 opcodes, but to quote the movie Chicken Little, "it's just gibberish-- gibberish of an insane person." Ah, well, the yolk was on me, but it was a fun little exercise.

Just a thought-- If the color bars are for comparison with the artifacted colors, then it might be good to rearrange things as follows: Even bit positions: <line of artifacted color (even bits)> <line of color bars> <line of artifacted color (odd bits)> Odd bit positions: That way the color bars can be easily compared to both lines of artifacted colors.

I should think so, but it wouldn't help if you're using labels: address = $80 lda address

When I view the picture I posted and hover the mouse over those colors while running the Color Detector program, they do have different RGB values. Granted, they're close in color to each other. When I run my 128 color palette program on my heavy sixer, some of the darkest and lightest colors do look very similar to each other for some of the hues. Somewhere on my computer I have a screenshot I captured from my heavy sixer, but I'm having trouble finding it right now. I think I posted it in another thread a year or two ago; if I find it I'll link to it or repost it here for comparison. Edit: I found my heavy sixer screen capture. It looks kind of dark on my computer monitor-- a lot darker than it looked on my TV (TVs usually have a higher gamma setting)-- so I had bumped up the brightness and contrast in a paint program to try to get brighter brights while keeping the darks dark. The two screenshots are shown below-- the untouched original (well, I did scale it down a bit, but no adjustments to the colors), and the modified one: But to get back to your original question, the colors you see may look a little different than the colors other people see, due to differences in the monitors, the settings on the monitors, and the color depth of your desktop display. For example, I have two monitors side-by-side at work, and it's nearly impossible to get identical colors on them, even if they're both set to the same settings as each other. Welcome to the wonderful world of "AARGH!!!" Second edit: This screen capture shows hue 15 with a decidely green tinge. The interesting thing is, if I play DVD recording that I made of my heavy sixer, the color of hue 15 changes from frame to frame-- on some frames it's greenish (as shown here), but on other frames it's more brownish (as in Trebor's palette). I see the same phenomenon in the video I captured from my 7800 running the same palette program.