SeaGtGruff

The colors blend nicely! Good job! Michael Rideout

You forgot the 16th color-- black! Or if you prefer, black plus 15 colors. You could try blending the colors more by alternating the colors on frames-- odd frames having black/gray/red/cyan (even lines) and black/gray/purple/gold (odd lines), and then even frames having the odd/even line colors swapped. I'd like to see what that looks like! Michael Rideout

batari BASIC lets you use inline assembly in your programs, so in theory there is nothing that assembly can do that batari BASIC can't do-- but you might have to write your own kernels, compile without any bB include files, etc., to get "full assembly" capabilities. Michael Rideout

Thanks! I knew that some games have been disassembled and commented, but I had lost the bookmark to that page. Michael Rideout

I've also been planning a game (shelved for about a year now) that will be NTSC, PAL, and SECAM compatible. But I plan to use the difficulty switches for this. The left difficulty switch would control the number of scan lines (262 or 312), and the right difficulty switch would control the color palette (PAL vs. SECAM when there are 312 scan lines, and possibly NTSC color vs. black-and-white when there are 262 scan lines). The reason I chose the difficulty switches is because some 2600 models put them on the back of the unit, in which case they aren't easy to change in a hurry during a game-- and once they're set a certain way, the player wouldn't need or want to change them mid-game. I plan to use the color/black-and-white switch for pausing/unpausing the game. It's really the only reasonable choice for a pause switch, since the other switches are either potentially on the back of the unit (i.e., difficulty switches), aren't designed to be flipped one way or the other (i.e., select and reset), or are hardwired for a specific purpose (i.e., power on/off). SECAM 2600s have the color/black-and-white switch permanently "wired shut" in the black-and-white position? Bummer, that means anyone playing my game on a SECAM 2600 wouldn't be able to pause it. Michael Rideout

Great idea! I finally got my 7800 working again, and fired up my Cuttle Cart 2 for the first time last night, so I'll see how much I can contribute. (I presume that the Cuttle Cart and Cuttle Cart 2 work the same way as far as the menu files go.) Michael Rideout

I disassembled Donkey Kong last night to look for the movement routines, but I didn't have time to unravel what's going on. I'll give it another stab this evening. Michael Rideout

The first group of lines are "equates" that define what and where specific memory locations are. This is really optional, as you can write assembly code that gives the memory address rather than using an equate, *BUT* equates make it a *LOT* easier to understand the code. The locations of those particular memory addresses are fixed, they never change (although they do have "mirrored" locations at other memory addresses that can also be used), and the names used (e.g., "HMOVE") have been agreed upon through long usage and convention, plus whatever they were called by the original designers and in the original documents about what the locations are and how they're used. If you want to know more about those lines, refer to the "Stella Programming Guide": http://www.atarihq.com/danb/a2600.shtml - then scroll down to "Technical Files" and it's the third link. The second group of lines is more difficult to understand. First, you need to know about 6502 assembly code, you can start here: http://www.6502.org/tutorials/6502opcodes.html But it isn't as simple as just looking up what a given memory location and 6502 opcode does, because when you do a disassembly of a ROM image, Distella can convert some of the memory addresses to "English" using the standard equates, but it can't convert the memory addresses for subroutines and variables. You have to study the code carefully to see how specific memory addresses (variables) are being used-- for example, maybe one particular memory address is being used to store the vertical position of a given sprite-- and to figure out what the various subroutines are doing, and either add more equates and disassemble again using the additional equates, or edit the disassembly to add labels and comments, etc. Note that there are already some commented disassemblies for some games. I can make some intelligent guesses about the specific code lines you posted: LF005: STY WSYNC LDA ($D0),Y AND #$0F AND $EE STA PF1 The first line starts with an address ("LF005", which is a label created by Distella to indicate that this line starts at address $F005), then a 6502 opcode ("STY", which means "store the value of the Y register"), and a memory address ("WSYNC", the equate name for the TIA register that tells the Atari 2600 to "wait for horizontal sync"). So what it's doing is storing the value of the Y register in the location that makes the Atari twiddle its thumbs until the RGB raster beams have reached the right edge of the playfield and need to be swept back to the left edge of the screen to begin drawing the next scan line. This is done to keep the graphics drawing for each scan line all lined up nice and neat. The second line starts with an opcode ("LDA", meaning "load the accumulator"), then an indexed address ("($D0),Y", meaning "the address that's being pointed to by addresses $D0 and $D1, offset by the value in the Y register"). Based on what the fifth line says, this line is loading the graphics data that will be used for part of the playfield, and the Y index is probably holding either the scan line number or some similar value (e.g., a row number, where each row actually consists of several scan lines). The third line starts with an opcode ("AND", meaning "perform a logical 'and' with the bits of the value in the accumulator"), then an immediate value ("#$0F", which is the hexadecimal value of the number 15). What this is doing is taking the value in the accumulator-- which is the playfield graphics data that was just loaded in the second line-- and ignoring or "zeroing" the left half of it. The fourth line starts with an opcode ("AND" again), then an address ("$EE", which is a zero-page address located in the 128 bytes of RAM). What this is doing is taking the value in the accumulator-- the playfield graphics data that just had the left half "wiped out"-- and doing another logical 'and' with the value that's in address $EE. The fifth line starts with an opcode ("STA", meaning "store the value of the accumulator"), then a memory address ("PF1", the equate name for the "playfield 1" register, which holds part of the playfield data). So this is taking the graphics data that was just processed in the preceding lines, and storing it in one of the playfield registers so that it appears on the screen. Michael Rideout

Looks good, 1005220[/snapback] Aside from the very minor changes that I made-- mostly just adding the Atari 2600 color clock counts, and "fixing" the links so they still work even if the page is saved to your computer-- the entire document is by John Pickens, although the copy that's posted on the 6502.org web site says "Updated by Bruce Clark": http://www.6502.org/tutorials/6502opcodes.html Michael Rideout

First you need to find the code where the joystick is being read for that purpose (moving the man), and then just change the value it's checking for. Alternately, you could swap the addresses for the subroutines it's branching to, but swapping the values it's checking for would probably be easiest. I don't know how to say it any simpler without seeing the actual code you're trying to change, since the way the code is written will determine what you'll need to do to change it. Michael Rideout

You should get a copy of the Stella Programmer's Guide, which is available on the internet as a PDF document: http://www.atarihq.com/danb/ - bookmark this page - go to Atari 2600 - go to Tech files - go to Stella Programming Guide (PDF) This document is also available from other web sites, and one web site even has a very nice, updated (spelling-error-corrected) HTML version of it. Just go to Google and search for "stella programmer's guide" (in quotes). Anyway, the short answers to your questions are that SWCHA is stored at (or read from) address $0280, and no, the values cannot be "hacked" per se. Or rather, it depends on what you mean by "hacked" (see below). You cannot "hack" an Atari game so that pushing the joystick in a given direction causes SWCHA to read differently than usual. However, you can certainly change the way the game responds to the different values. To use your example, if the game checks to see if the joystick is pushed left, and if it is, then moves the man left, then you can change the code so the game is checking to see if the joystick is pushed right, and if it is, then move the man left. Actually, I'm glad you brought this up, because it reminds me of something I was thinking about the other week, namely right-handed and left-handed joysticks. As we all know, joysticks (and everything else in this world) are designed for people who are right-handed. Since I'm right-handed, I don't usually give this a second thought. I think I remember that some left-handed joysticks were made-- the fire button is on the other side of the stick-- but I don't know if they're still made or still available. I was thinking it might be interesting to add a setting in a game to let the player specify that he/she is left-handed, and then respond to the joystick differently. In other words, the player could rotate the joystick so that the button is in the upper right corner, and then the game would treat left as up, down as left, right as down, and up as right. The only problem is, the cable or wire would then be coming out of the "right" side of the joystick instead of out the back, so it would get in the way of the player's right hand. Michael Rideout

I was thinking that a good way to approach "Logan's Run" might be sort of like an adventure game, but not quite-- something along the lines of "Krull," in the sense of being a series of scenes or mini-games that you must get through to progress to the end of the story, perhaps picking up necessary items along the way. I went out and bought "Logan's Run" on DVD to refresh my memory, but I haven't watched it yet. However, I would start by listing the key scenes that tell the story or move it along in a necessary fashion, and try to see which ones could be made into mini-games, or could otherwise be fit into a type of adventure scenario. But some scenes could be more to lend atmosphere than to contribute to attaining the end goal. For example, there could be a mini-game involving "riding the Carousel," or however they referred to it, where you play a person who must "swim" or climb through the air and reach the top, earning points based on how well you do (i.e., how fast you reach the top and explode as compared to the other people). I might also throw in some humor. For example, when Logan and Jessica(?) are trying to escape the robot, and he tells them that he freezes people because he used to freeze the fish for food (to feed the city), but the fish stopped coming, I'd like to have a man go running across the screen yelling "Soylent Green is people! Soylent Green is people! Um, isn't this soundstage 5? Oh, sorry, wrong movie!" Using that sort of approach, your "Thought Police" game could be included as one of the mini-games. However, I believe the author of "Logan's Run" has been working to get the movie remade, and I have a feeling that he wouldn't approve of an unlicensed "Logan's Run" game being made. Michael Rideout

I recently bought a "heavy sixer," serial number 74606G, made in Sunnyvale. The sticker is the original white one. Sorry, I don't have a scan or picture of it, and I'm not inclined to open it up unless something goes bad and I have to! Michael Rideout

I don't know how hard it is to get a "heavy sixer," unless price is a factor. I just bought one online the other week, but it was a little pricey ($425 after shipping) because it was a "collector's special" that came with 51 boxed games. This sucker seems heavier than I remember our old 2600 as being, which makes me wonder if we'd had a "light sixer." I always assumed it was a "heavy sixer." But come to think of it, based on the year we got it (I think it was at Christmas in 1980), I guess it must have been a "light sixer"! Too bad I let my older brother talk me into letting his kids borrow it, and someone (presumably one of the kids in their neighborhood) broke into their house and stole it! Michael Rideout

Interesting! I actually started knocking around with a somewhat-similar game over the holidays, a bB conversion of the old "Blitz" game. I was inspired to do so by a version of "Blitz" that I saw someone else working on for the 2600, and I wanted to see what could be done using bB. However, I stopped working on "bB Blitz" (as I was calling it) out of deference to the other programmer. My version was also partly influenced by "Blitz World Tour," a Flash game that I found and played on the internet. In "Blitz World Tour," there are bonus rounds where you have to bomb famous landmarks (e.g., the Statue of Liberty and the Taj Mahal). In "bB Blitz," I planned to have bonus rounds where you have to bomb Atari-related landmarks, like the "Fuji Towers" and the Yellow Castle. Michael Rideout

Ouch. I think my logo creation skills just got p'wned. JR 999359[/snapback] Don't worry, you didn't see how stinky mine were, because I didn't post them! I was going to use the font that was originally used for Atari cartridges-- it was ITC Bauhaus-- but when I looked for somewhere I could download it from, I found out that it's a commercial font and must be purchased/licensed, so I didn't mess with it. Michael Rideout

Oh, I didn't realize that. "BASIC" is an acronym, or a word that's sort of like an abbreviation, made up of the first (or first few) letters in the (primary) individual words-- in this case, "Beginner's All-purpose Symbolic Instruction Code." Technically speaking, I believe acronyms are written with all letters capitalized-- like USA, NATO, TV, DNA, BASIC, COBOL, etc. However, I have been seeing BASIC spelled as "Basic" for many years now, as well as COBOL spelled as "Cobol." But I don't think that's proper, just as we don't write "Usa," or "Nato," or "Tv," etc. On the other hand, I see that "LASER" is also an acronym, yet I don't think I've ever seen it spelled that way; I always see it spelled "laser"! So I guess it's just a question of whichever is the most common form of usage. Michael Rideout

batari likes his name to start with a lowercase b. So yeah, it's batari Basic (bB). 999162[/snapback] Or, if you want to be really picky, it's "batari BASIC"! Michael Rideout

Ah, after reading more closely, I see that. Thanks for pointing that out. I'll send him a PM. 998994[/snapback] If for some reason you can't reach John, or he no longer has it, he had sent me both the source and executable files, and I can email them to you if need be. I think John also sent them to other people who had PM-ed him, so *someone* may already have it up on the web. But it certainly wouldn't hurt for you to host it as well, especially since I don't think any future updates will ever be made for it (at least not by John). Michael Rideout

Just a thought... A "new" version of PCAE was just recently released, but it hasn't exactly been posted anywhere that I know of, so maybe you could host that latest PCAE release on your site? Michael Rideout

That looks fantastic! But what's the thing in front of "bB" that looks like a cross between an "S" and an "l"? Michael Rideout

That's true, of course. But as I pointed out before, the effect actually looks very good, since the men look like they're climbing into the chopper on whichever side they're running from. Michael Rideout

Am I really the only 40-something Atari programmer here? Michael Rideout

I haven't analyzed your program listing, but you're correct-- the random number generator isn't really random, it always produces the same sequence of numbers, although the sequence can start with any number between 1 and 255. If you seed the random number generator with the same number every time (as you're doing with the statement "rand = 44"), you'll always get the same numbers in the same order. (By the way, I think this is how other BASICs work, too.) To get different results each time you run your program, you need to either not seed the random number generator at all, or else seed it with a random value ("rand = rand"). Note that seeding it with 0 will break it, but "rand" never returns a 0 anyway (unless you break it by seeding it with 0), so "rand = rand" will never seed it with 0. Also, you might want to try using a different method for reducing the result to an acceptable value, because I don't think that masking the bits is the best way. The method I like to use it to subtract a given value until the result falls within the desired range. For example, to get a random value between 0 and 31: x = rand : rem * x will be between 1 and 255 inclusive x = x - 1 : rem * now x is between 0 and 254 inclusive reduce_x if x > 31 then x = x - 32 : goto reduce_x rem * after exiting the loop, x will be between 0 and 31 inclusive To understand why I think this is a better method for reducing x, consider what will happen if you want x to be between 0 and 3 inclusive. Masking x with %00000011 will produce 0 an inordinate number of times, because if you start with an x that has 0 in bit 0 and in bit 1, it will always reduce to 0. But if you keep subtracting until you get a value in the desired range (i.e., reducing x with a "mod" function), you won't get 0 an inordinate number of times, if you see what I mean. We can even define a "mod" function in bB, as in the following example: rem * test of a mod function rand = rand COLUBK = $04 scorecolor = $1A rand_loop x = rand : rem * x will be from 1 to 255 x = x - 1 : rem * now x is from 0 to 254 x = mod(x,32) : rem * now x should be from 0 to 31 score = 0 if x > 0 then for t = 1 to x : score = score + 1 : next display_loop drawscreen if joy0fire then goto rand_loop goto display_loop function mod rem * the second parameter should be > 0 temp3 = temp2 - 1 mod_loop if temp1 > temp3 then temp1 = temp1 - temp2 : goto mod_loop return temp1 end In this example, the "mod" function will return a value in the desired range, as long as the second parameter is greater than 0. For example, "a = mod(b,16)" will return the mod 16 value of b, and store it in a: If b = 0, a will be = 0. If b = 1, a will be = 1. If b = 2, a will be = 2. If b = 3, a will be = 3. If b = 4, a will be = 4. If b = 5, a will be = 5. If b = 6, a will be = 6. If b = 7, a will be = 7. If b = 8, a will be = 8. If b = 9, a will be = 9. If b = 10, a will be = 10. If b = 11, a will be = 11. If b = 12, a will be = 12. If b = 13, a will be = 13. If b = 14, a will be = 14. If b = 15, a will be = 15. If b = 16, a will be = 0. If b = 17, a will be = 1. If b = 18, a will be = 2. If b = 19, a will be = 3. If b = 20, a will be = 4. etc. Michael Rideout

That sounds like a plan! Michael Rideout