SeaGtGruff

Here is one more screenshot that I found, which is from a program I wrote using an Atari 800 emulator showing all 128 even-numbered colors. I had even added labels to show the luminance and hue values. The palette should be very similar to at least one of the Atari 2600 emulators. In fact, you could chop off the emulator window in a graphics editor, and replace (or fill) the colors with the ones from the 2600 emulator of your choice. In particular, notice how hue 15 is a definite brown in this image, whereas hue 15 in my other 256-color image from an actual Atari XE computer is more of a green or slightly-brownish-green. I haven't used Snappy in a long time, so I don't recall if I'd adjusted the tint at all. I think I used the default settings, so the colors would be as "true to life" as possible. Michael Rideout 128color.bmp

Okay, here are two zipped files-- one with 16 screenshots, each with all 16 (Atari 800 GTIA) luminances of a given hue; and the other with 8 screenshots, each with all 16 hues for a given even-numbered luminance (except hue 0 is always black). But be warned, these zipped files are rather large. Michael Rideout 16hues.zip 8lums.zip

Thanks. After comparing the images and knowing that Atari on video looks darker and crappier, between Stella and z26, I think Stella is closer for the most part. 908913[/snapback] You may be right about that, although one thing I've noticed is that Stella seems to use more idealized colors. What I mean is that, for example, the 2600 can't show color 15 (hue 0, luminance 15), which is the brightest white on the 800. Yet if I remember correctly, Stella shows color 14 (brightest white on the 2600) as pure white, when it should actually be a very light gray (just a tad darker than white). This isn't really a problem with 2600 emulators, because we could just pretend that we've adjusted the brightness and contrast to get pure white for color 14. But on an 800 emulator, some palettes give pure white for both color 14 and color 15, which is a problem if you're trying to use the GTIA mode that shows all 16 of the luminances, since colors 14 and 15 come out as the "same" color. Ideally, I would prefer color 14 to be displayed as not-quite-white on any Atari emulator (2600 or 800, or even 7800). But more significantly, the palettes for some emulators don't always reproduce the other hues as closely as I'd like. Color was always my biggest obsession with the Atari computers, so I spent a lot of time trying to get more colors through flickering and so forth. If the hues are not reproduced closely enough on an emulator, it can adversely affect the results of flickering between two colors to get a third color. For example, certain values of yellow and blue can be flickered to get light green, but the results can vary a lot depending on the emulator's palette versus the real thing. Of course, the biggest difference may be using a color TV versus a computer monitor, because colors tend to blur together better on a TV than on a monitor. Consequently, any game which relies on flickering to get more colors will need to be programmed carefully when using an emulator, because the final result may look completely different when the finished game is played on a real Atari. Michael Rideout

Hang on, that bitmap may be one I cobbled together from 16 separate ones, but I did have a program which displayed the same thing. The problem is, my hard drive had crashed, so I had to type a simple program to create the images which I captured, and I don't think I had typed in the program that used DLIs to display all 16 hues at once. (Incidentally, the way I got the black border on all of the lines was to position some black players on either side of the color grid, as otherwise each line would have luminance 0 of the hue being displayed, instead of black.) I do have a complete set of other screenshots, though, and I can zip them up and e-mail them to you if you wish. One set is 16 screenshots, with each screenshot showing all 16 luminances of a given hue, displayed as vertical stripes. The other set is 8 screenshots, with each screenshot showing all 16 hues of a given (even) luminance, again displayed as vertical stripes. However, the GTIA mode which can display all 16 hues at once does not display shades of gray; hue 0 is always black, no matter what luminance the other hues are being displayed in. And of course, the 2600 can't display the odd-numbered luminances, so if you are applying these screenshots to the 2600, you should ignore the 128 odd-numbered color values. I had tried to use the screenshots to determine the ideal RGB values for all 256 colors, but the grainy images drove me crazy. For example, I had also captured some screens showing single colors, but when I loaded them into a graphics program, it said there were hundreds, thousands, or even millions of different colors being used in each image! Michael Rideout

I doubt that it is. I'm almost done updating my color chart and Stella colors look closer to me. For example, Stella yellow looks more like official Atari 2600 yellow. And I remember the reds being more like Stella colors too. z26 colors seem odd and darker than how the real ones looked on the color TVs I used over the years to play Atari 2600 games on. 908530[/snapback] One thing to keep in mind is that the color on a real Atari can be greatly influenced by the color TV, especially the tint/brightness/contrast settings. Some years ago, I ran an 8-bit Atari computer through a VCR so I could hook it up to a Snappy screen capture device on my computer, and I captured actual Atari screenshots of all the colors-- the 16 luminances of all 16 hues (one hue at a time), plus a screen display I had created which shows all 256 colors at once. I'm posting a bitmap of the 256-color screenshot, so you can compare it with the palettes of the Stella, z26, PCAE, and other emulators. Unfortunately, on a real Atari the colors aren't very "solid," because NTSC television has such a problem with color stability (hence its nickname, "Never The Same Color"). Anyway, I hope this helps! Michael Rideout 256color.bmp

I did discover a bug in the above commands when I was rewriting these commands to allow indexed variables. I expect that these commands will work properly for the upcoming Alpha 0.3 release, which should be soon, I hope! 908139[/snapback] I expect there will be quite a few bugs that need to be fixed in the early releases of Batari BASIC, and I hope you don't get discouraged about it, because I think Batari BASIC is a fantastic tool that puts Atari 2600 programming within the reach of just about everyone! I don't want to deluge you with bug reports, but there's another bug I noticed last night which I didn't mention yet. Namely, when using GOSUBs, the program may not compile correctly. For example: loop if a=1 then gosub routine1 goto loop routine1 b=4:return routine2 b=3:return This gives a message "return without gosub," but it compiles anyway, so I guess it's just a warning message, rather than an error? But here's another example: loop if a=1 then gosub routine1 if a=2 then gosub routine1 if a=3 then gosub routine1 if a=4 then gosub routine1 if a=5 then gosub routine1 goto loop routine1 b=4:return This gives a message "Max. nested gosubs exceeded," and results in a fatal error, even though the program should be RETURNing each time, such that there actually aren't any nested GOSUBs. Another thing I noticed is that COLUBK and COLUPF can be set outside of the main loop (such as when those colors will be constant throughout the program), but if you set COLUP0 or COLUP1 outside of the loop, the players will be black; you must set COLUP0 and COLUP1 within the loop, even if they're never going to change, or else the players won't be set to the desired colors (or else they're getting reset to black each time DRAWSCREEN finishes executing; I haven't checked the compiled code to see what's happening). Michael Rideout

I agree with s0c7 that you should take it slow. Pick just a few commands at a time, and play around with them until you get the hang of how to use them. Obviously, DRAWSCREEN and GOTO will be two essential commands, because you need to draw the screen, and then keep looping back to redraw it. You don't need to try for anything fancy, just do simple little programs at first. For example, play with the PFHLINE, PFVLINE, and PFPIXEL commands to see how they work, and then you'll be able to design different playfields. Then try adding a player to see how that works. (Note that player shapes must be defined upside-down.) And once you can draw a player and position it wherever you want on the playfield, try moving the player around with the joystick commands, as in the sample program that comes with Batari BASIC. Maybe we should do a tutorial series for Batari BASIC, as was done in the past for programming the 2600 in assembly? I'd be willing to contribute to such a series. In fact, I've started working on a simple adventure game, so maybe I could turn that into a tutorial, if anyone is interested? Also, I'm curious how everyone is using Batari BASIC-- that is, on what kinds of computers, compiling manually or with a batch file, etc. For example, I'm using Windows, and the 2600IDE program. Michael Rideout

I'd go with showing two or three color charts-- one for z26, one for Stella, and even one for PCAE (which, if I remember correctly, uses colors which are a little different from z26 and Stella). That way, we can compare the colors for the various emulators, to be sure our colors will look good no matter which emulator people play our games on. Also, you might add color charts for PAL and SECAM, too (especially PAL). By the way, here are two programs I wrote to display all of the Atari's colors at once. The first one shows the 128 colors arranged in an 8x16 grid, and the second one uses screen-flipping to get in-between luminances, for a total of 240 colors. You can also use screen-flipping to get in-between hues, or in-between hues *and* in-between luminances. Michael Rideout 128COLRS.BIN 240COLRS.BIN

I don't know if anyone else has mentioned this already. If you create all of your programs in the main Batari BASIC directory, it quickly fills up, and becomes very cluttered. You can keep things better organized by creating a subdirectory for your programs, so that just the main Batari BASIC files are in the main directory. For example, my directories look like this: C:\Atari then C:\Atari\2600 C:\Atari\5200 C:\Atari\7800 C:\Atari\800 etc. And inside each of those I have more subdirectories, like this: C:\Atari\2600\docs C:\Atari\2600\emus C:\Atari\2600\roms etc. So naturally I added another directory for Batari BASIC: C:\Atari\2600\Batari BASIC And then I added a directory inside of it for my programs: C:\Atari\2600\Batari BASIC\Programs I should mention that I'm using the 2600ide program, which is inside the main Batari BASIC directory. Anyway, when I load a program into 2600ide and compile it, I get an error because it can't find the programs. To make it work, all you need to do is edit the 2600baside.bat file, and add a "cd .." command, like this: @echo off cd .. 2600bas.exe<%1>%1.obj copy /y /a 2600basic.asm +%1.obj +2600basicfooter.asm %1.asm>nul dasm %1.asm -f3 -o%1.bin Note that you must do this with the 2600baside.bat file that's in the subdirectory where your games are. Once you do this, the compiles will execute correctly. Michael Rideout

There's a problem with the pfhline, pfvline, and pfpixel commands, sometimes they change too many pixels. For example, consider the following code: COLUBK=$08:COLUPF=$44 pfhline 0 0 31 on pfvline 31 0 3 on pfvline 31 7 10 on pfvline 0 0 10 on pfhline 0 10 31 on loop drawscreen goto loop What it *should* do is draw a border around the screen, but with a gap on the right side-- in other words, draw a room with an exit going "east." But what it actually does is fill the screen (or playfield, anyway) with solid red. Or try this: COLUBK=$08:COLUPF=$44 pfhline 0 0 31 on pfvline 31 0 10 on pfvline 0 0 10 on pfhline 0 10 31 on pfvline 31 4 6 off loop drawscreen goto loop It should draw a border or wall around the screen, then erase part of the east wall to make an exit. But instead, it erases the entire bottom right corner. I haven't tried to unravel the compiled assembly code to see what's going on. Here's another one, using pfpixel: COLUBK=$08:COLUPF=$44 pfhline 0 0 31 on pfvline 31 0 10 on pfvline 0 0 10 on pfhline 0 10 31 on for a=13 to 18:pfpixel a 0 off:next loop drawscreen goto loop Again, we're trying to draw a wall around the room, and then add an exit-- this time, in the north wall. But the pfpixel command in the for..next loop erases too much, and leaves a couple of pixels unerased. Oddly enough, if we change the "off" to "flip" in the last example, it works as it's supposed to: COLUBK=$08:COLUPF=$44 pfhline 0 0 31 on pfvline 31 0 10 on pfvline 0 0 10 on pfhline 0 10 31 on for a=13 to 18:pfpixel a 0 flip:next loop drawscreen goto loop Michael Rideout

I use delay counters, but not how you would think. The for-next loops you inserted really just consume inbetween frame time. Since your game still runs, you didn't consume enough to break anything. Remember the difference between this basic and an old 8bit basic is that the program runs every 60th of a second. If you take longer than that, in your gamecode, you won't get enough frames to display a stable picture. One good way to see everything happen slowly is to use what I call a skip counter. The program has to loop 60 times per second, but it does not have to do everything each time. That's the key to getting a nice slowdown. You set a counter and decrement it once each frame. When it hits zero, you do everything, if it's not zero then you jump over all your game code. That way, the picture still gets drawn every 60th of a second, but your game only runs on specific frames. The end result is a slower game with a stable picture. Try something like this: (Set the delay where you set other things at the start of your game) delay = 10 gameloop (This is where you set your player positions, etc...) drawscreen (Your game code lies after the drawscreen for the most part) delay = delay - 1 if delay <> 0 then goto skipaction if delay = 0 then delay = 10 (your game code goes here and only gets executed every 10 frames) (nice and slow, try smaller numbers for faster, bigger ones for slower) skipaction goto gameloop 907820[/snapback] I just wanted to add a comment here. As most of us probably know, one of the biggest challenges in programming the Atari 2600 (besides the tiny amount of RAM and ROM) is being able to do everything we want during the vertical blank. One way to get around that is to split up the tasks so that different things get done during different vertical blank intervals. For example, if your game logic takes up about three times as long as a VBI, then you could divide it up into three or more sections, such as (1) reading and processing the controllers, (2) moving the sprites and processing the collisions, (3) updating the score and doing other remaining tasks. Then you could do the group (1) tasks during the first VBI, do the group (2) tasks during the second VBI, and do the group (3) tasks during the third VBI. After all, if you're going to be skipping VBIs anyway just so your game doesn't run too fast, then you might as well split up your tasks so you don't have to worry about exceeding the length of a single VBI! Michael Rideout

First of all, thank you for creating Batari BASIC; it's a great concept! The compiled code for the FOR..NEXT statement has a bug if the STEP isn't 1, which causes the loop to end before it should. For example, the following compiled code runs as intended-- three playfield pixels are drawn in a diagonal line: .L01; for a=1 to 3 step 1:pfpixel a a on:next LDA #1 STA a .L01fora LDX a LDY a LDA #0 jsr pfpixel LDA a CMP #3 INC a bcc .L01fora Note that the CMP statement occurs *before* the variable gets incremented, which is okay, because the STEP is 1, so there's no chance the INC statement will go beyond the final desired value. However, this next compiled code does *not* run as intended-- only one playfield pixel gets drawn: .L01; for a=1 to 3 step 2:pfpixel a a on:next LDA #1 STA a .L01fora LDX a LDY a LDA #0 jsr pfpixel LDA a CLC ADC #2 STA a CMP #3 bcc .L01fora Note that the CMP is done *after* the variable has been increased, which is the way it should be-- except the BCC statement branches only if the result is *less* than the final desired value, but the loop should repeat if the result is less than or *equal* to the final desired value. So to correct the bug, the compiled code needs to include a BEQ to the label, either before or after the BCC: bcc .L01fora beq .L01fora Until the bug gets fixed, the workaround is to add 1 to the final desired value (i.e., "FOR A=1 TO 4 STEP 2" when we actually want to stop after 3). The only problem would be if the final desired value were 255. Michael Rideout