SeaGtGruff

When batari BASIC was first released, batari referred to it as the "Atari 2600 BASIC Compiler" (see the "README.txt" file for version 0.1, for example), which is why this forum has the name it does. As I recall, it wasn't until everyone in this forum told him that he should name it after himself (meaning his screen name) that it became known as "batari BASIC." But even so, the compiler executable is still named "2600basic.exe"! Michael Rideout

Personally, I never heard of it until just now. Thanks for the link! Michael Rideout

Is that from just the latest class of students, or did it include the students in the previous class, too? I think it's a great idea, especially if the source code is available so people can see how the game programmer(s) did something. Michael Rideout

Did you mean to say 40.5 bytes? If there are nine digits-- but some squares are empty, so let's call it ten digits (0 for "empty"), then with BCD it would take 81 nybbles, or 40.5 bytes. And I'll have additional bytes for storing whether a particular square was pre-filled, in which case that square will have a different background color, and the number in the square will be brighter. And if I store the numbers in the extra row and column (plus in the corner), and have an eleventh value to indicate "nine dots" (for "check all nine digits at once"), then I'll need 100 nybbles (50 bytes) for the board, plus another 81 bits (10 or 11 bytes) to store the "pre-filled" indicators-- 60 or 61 bytes in all just for the grid data, and that doesn't include any other variables needed for game play or game settings. So yes, I think it can be done, but it could get scrunchy, plus the timing may be difficult. For example, right now I'm shifting the players left and right 7 pixels from one row to the next, but I may not have time to do that in the actual working kernel; I may need to do the left-right shift between frames rather than between rows. Michael Rideout

Yep, I sure do! Here's a mockup I drew in MS Paint to show the general direction I'm headed in. There's a 9x9 grid, with some brighter/bolder lines to separate it into nine 3x3 grids. Then there's an extra row above the grid, and an extra column to the left of the grid, with an extra box in the upper left corner. The squares that are already filled in with numbers (i.e., when you first start out) will have a different background color or shade than the empty squares or squares that you've filled in, and the numbers in those "pre-filled" squares will be brighter. The squares in the extra row, extra column, and in the corner will be used to help solve the puzzle, as shown. For example, if you put a "1" in a square in the extra row at the top, then any square in that column which could possibly be filled in with a "1" will get a tiny dot in it, in the position that would represent the number "1." Or, if you put a "5" in a square in the extra column to the left, then any square in that row which could possibly be filled in with a "5" will get a tiny dot in the position that represents the number "5." The extra square in the upper left corner will be used to check all rows and all columns at the same time. And besides being able to check for individual numbers (whether in a specific row or column, or all across the board), there will be an extra symbol of nine dots, which means "check for all digits at once"-- either in a specific row or column, or all across the board. Within the actual playing grid, any dots in a particular square will indicate that those numbers could possibly go in that square, where the position of the dots within a square represents what numbers they are-- i.e., the dots will have a 3x3 arrangement, as shown in the upper left corner square in this mockup. following the same pattern as the buttons on a telephone: 1 2 3 4 5 6 7 8 9 Michael Rideout

Build number 3, which is the last one for tonight. I've got the basic grid, although it still needs a lot of tweaking. Right now I'm using loops, but I'm 99% certain that I'll have to "unroll" the kernel a bit for an actual working display, and the addressing modes of the LDA instructions aren't right yet. I'm including two screenshots this time, one with just empty boxes, and one with the digit "1" in all of the boxes. As you can see, the basic grid still needs a lot of work. And some of the lines are going to disappear. There will be a 9x9 grid for the actual puzzle, plus an extra row above the grid, and an extra column to the left of the grid, plus an extra box in the upper left corner. The extra row and column will be used in solving the puzzle-- i.e., if you put a "1" in one of the boxes in the extra row, then you'll be shown all of the boxes in that column of the grid which could possibly contain a "1." That may sound a little confusing, but it should become clear as the game screen continues to take shape and I can eventually post screenshots showing what a game in progress might look like. Michael Rideout Sudoku.bas Sudoku.bas.bin

"Finally," nothing! It's got a lllloooonnnngggg way to go yet! And it still remains to be seen whether it can be achieved within the restrictions of the 2600. I'm not sure about the number of puzzles. My plan includes having an "input" mode, where you can enter a puzzle from a newspaper or book and work on it, even saving games on a MemCard. And I certainly would like to have some puzzles built into it, and hopefully the ability to generate random puzzles (if I can work out a decent algorithm for that). It's all still very much in the planning and experimenting stages. Right now I'm strictly focused on getting the basic display worked out. Michael Rideout

Okay, here is build number 2. It's still nothing much to look at, but you can at least see the grid beginning to take shape. I redid the basic kernel a bit, putting it inside the main loop, instead of calling it from a gosub. I split the kernel into two bB sections (overscan and vertical blank) and two assembly sections (vertical sync and active video). I moved the player positioning into the vertical sync section. And I'm now using INTIM to wait for the proper moment to begin the vertical sync and the active video, instead of using WSYNC for every line. In these earliest builds, I'm not going to worry about any game logic per se, because the first order of business is to get the basic framework of the kernel ironed out. And I should point out that so far the kernel is strictly for NTSC, but I'll be adding PAL/SECAM support eventually-- which will be very simple, since it should mostly be a matter of sticking different values into TIM64T. Anyway, I'll try to be sure that there are visible changes in these early builds, so that you can see the board taking shape. And I expect to be using extra RAM, because I seriously doubt that 128 bytes will be enough. Michael Rideout Sudoku.bas Sudoku.bas.bin

I was very hesitant to reveal the name of this game, because it has such a strong following, and I don't want to get everyone's hopes up unreasonably high. I was thinking of calling it "Undisclosed Atari 2600 game," but sooner or later it would have become obvious what it is, so there doesn't seem to be any real reason to be secretive about it. I'm not sure if it will get entered into the 2006 contest, but just in case, I'll post my progress on it in this thread. It's going to be developed in a mixture of batari BASIC and in-line assembly, but the final version may end up being coded in pure assembly. In this first installment, all I did was create the beginnings of a custom kernel that uses flickering Venetian blinds, and try to get the players positioned more or less correctly. There's really nothing to see yet-- it isn't even colorful, just bleah. This was actually written Monday night. I didn't get to work on it last night, because I went to the 10 PM advance showing of "Superman Returns," and didn't get home until about 1 AM! I hope to post another installment later tonight, but it will mostly be tweaks to the basic kernel. Michael Rideout Sudoku.bas Sudoku.bas.bin

I've already been communicating with Richard via email, and he is shipping me a Memcard! Michael Rideout

I forgot to say, if you are using hexadecimal numbers then it's easier to pick the colors you want. The values will be something like #$HL, where "H" stands for both "hue" and "high nybble," and "L" stands for both "luminance" and "low nybble." The "H" values for the basic colors go something like this: H = 0 ... gray (black-and-white) H = 1 ... yellow H = 4 ... red H = 6 ... purple H = 9 ... blue H = C ... green H = F ... brown If you memorize those numbers, then the numbers in between are the colors in between: H = 1 is yellow, and H = 4 is red, so H = 2 ... yellowiswh orange H = 3 ... reddish orange H = 4 is red, and H = 6 is purple, so H = 5 ... violet H = 6 is purple, and H = 9 is blue, so H = 7 ... bluish purple H = 8 ... purplish blue H = 9 is blue, and H = C is green, so H = A ... greenish blue H = B ... bluish green H = C is green, and H = F is brown, so H = D ... brownish green H = E ... greenish brown Then, for the luminances, we have L = 0 ... darkest L = 2 ... very dark L = 4 ... dark L = 6 ... medium dark L = 8 ... medium L = A ... medium light L = C ... light L = E ... very light Thus, $7A would be "medium light bluish purple," whereas $42 would be "very dark red," etc. In the screen shot I posted, the L values go across the screen, left to right, from 0 to E, whereas the H values go down the screen, top to bottom, from 0 to F. So for example, the color in the fourth column of the sixth row would be $56. I've added the values to the picture, to make it easier for you. In the picture labels, "x" means the part of the number that changes-- for example, row 3 says "2x," which means the high nybble is "2," and the low nybble is variable. So to get a particular color value, find the color you want in the grid, then combine the row and column labels together-- such as, "4x" combined with "x8" would be "48" (or #$48 in hexadecimal assembly notation). Michael Rideout

The Atari 8-bit computers have 256 colors if you use a couple of the GTIA graphics modes, but for most graphics modes there are only 128 colors-- and this includes the 2600, which dosn't have the GTIA graphics chip. It may look like you can set the color registers to any of 256 different values, but bit 0 is ignored-- which means the odd-numbered color values produce the same colors as the even-numbered values that are 1 less than them (i.e., 1 is the same color as 0, 5 is the same color as 4, 19 is the same color as 18, 123 is the same color as 122, etc.). Here's a simple little program I wrote for the 2600 that displays all 128 colors in the palette-- 8 different luminances of 16 different hues. The screenshot is from the Stella emulator, and might not look exactly like the colors on a real 2600 on a real NTSC TV set-- especially since the colors you get on the TV set can be affected by the TV settings (brightness, contrast, color saturation, and tint). Also, when I saved the screenshot as a GIF image, it made the picture get kind of "spotty." Michael Rideout palette.bas palette.bas.bin

Not 100% on topic, but just wanted to say that PayPal totally stinks. I don't have a PayPal account, and I don't want one. So I try to buy a Memcard through PayPal with my credit card, and PayPal keeps telling me that my payment session has expired, and I'll have to reenter the information to complete the transaction-- so I keep reentering my information, and it keeps telling me that my payment session has expired. I guess I won't be getting any Memcards anytime soon, after all! Michael Rideout

Okay, I had intended to search the forums for information about the memcard for the 2600, but I got sidetracked, then when I finally remembered why I'd logged onto AA in the first place, it's time for bed. So instead of searching, I'm going to post some general questions. Basically, I'm wondering about the feasibility of developing a game that uses-- no, requires-- the memcard. In fact, I'm thinking the memcard would actually be sold with the game cartridge, rather than "strongly advising" that the player purchase a memcard. Who makes the memcard? How much does it cost? Where can I buy one for development uses? And are there enough available so that if I wanted to create and sell a cartridge, I could also include a memcard with each cartridge? I'm not saying that this is going to happen-- heck, I might get run over and killed tomorrow!-- but I'd like to know what my options are and whether such an idea is even feasible. And even if I don't actually create a game cartridge for sale, I'd still like to buy one or more memcards for personal use. Thanks! Michael Rideout

I had a lot of game ideas, but I'll just mention five of them. Keep in mind, I'm not saying that all of these would actually be doable on the 2600. (Back then, I had absolutely no clue about what the Atari 2600's actual capablilities and limitations were!) There's an ELEPHANT in the BATHROOM! You're a young child who's been told that you must take your bath and get ready for bed. But when you go into the bathroom to take your bath, you discover that there's an elephant in the bathroom! Naturally, you run to your parents and excitedly shriek that there's an elephant in the bathroom, but no one will believe you (they think you're just playing "pretend" again). Your dad even goes into the bathroom to prove to you that there's no elephant, and he doesn't see the elephant (it conveniently tippy-toes back and forth behind his back, just when he's turning to look this way, then that way). When your dad leaves you in the bathroom to take your bath (or else!), you talk to the elephant and discover that it's a baby elephant who somehow got separated from its parents. Now it's up to you to help the lost elephant get through the city and make its way back to the zoo where its parents are-- without causing too many traffic accidents (funny how an elephant walking down the sidewalk causes drivers to slam on their brakes!), starting riots, getting arrested by apoplectic police officers, and otherwise creating too much panic and mayhem in the streets. Oh yes, you must do all of this and return safely home before it's time to get up and go to school in the morning, so you don't get in trouble with your parents (but of course they find out anyway, since the reporters in the helicopters are televising the whole thing, to the stunned amazement of your parents). Zoo Keeper This was going to be an educational game. You're a zoo keeper, and the monkey (or chimpanzee?) has somehow gotten hold of your keys. There are cages all over the screen, with a simple maze of paths connecting the cages (the number of cages and the maze of paths changes for each level.) The monkey/chimp lets himself out of his own cage, then runs around and unlocks the other cages to let the other animals out. Unfortunately, some of the animals are carnivores, and are only too happy to eat the other animals-- or fight each other to the death. So now you have to run around after the monkey/chimp, catch him, get your keys back, lock the monkey/chimp back in his cage, round up the other animals one by one and lock them back in their cages, before they all eat each other, kill each other, or get eaten/killed. You score points based on each animal that's safely returned back to its cage-- with different animals having different point values (e.g., the dangerous carnivores are worth more points than the meek herbivores), so any animals that get eaten or killed will detract from your total possible score in each round. You also get a bonus if you safely return all of the animals to the cages within a time limit. Between rounds, there are educational segments where you learn a little bit about different animals, such as where they live, what they eat, etc. Then, after a certain number of rounds and educational intermissions, you're given a quiz to test your knowledge of the animals, such as having to match up the animals with their correct continents, or with their correct foodstuffs. Unfortunately, several months after I'd thought up this game, I was watching "Starcade" on TV (or whatever it was called, the show where kids competed against each other on arcade games), and lo and behold, I saw that someone had created an arcade game called "Zoo Keeper"! I was thoroughly upset, especially since I thought the "Zoo Keeper" game they'd made was nowhere near as good as my own game idea. Quest for the Lost Pyramid of Atlantis You're trying to find the lost pyramid of Atlantis, which the refugees from Atlantis built somewhere in the desert near the Great Pyramid of Cheops and the Sphinx (but those were built much later). This is loosely based on the readings of the famous American psychic, Edgar Cayce, who said that the Atlanteans left three "time capsules" filled with artifacts and historical information from Atlantis-- one in Egypt near the Sphinx and Great Pyramid, one in Yucatan, and one on the island of Poseidia (which sank in the vicinity of Bimini). My original game idea was very simple-- a grid of desert locations which you must navigate around, with a few special locations scattered around the desert, such as an oasis, the Great Pyramid, and the Sphinx. And of course there are dangers in the desert, such as deadly poisonous snakes-- not to mention thirst! If you successfully locate and open the lost pyramid of Atlantis, you must then find your way through the tunnels and traps to reach the treasure chamber and end the game. I developed my original idea long before games like "Raiders of the Lost Ark" and "Riddle of the Sphinx" (with their inventory strips) were released, so the game play was patterned more along the lines of "Adventure." Over the years, I've revamped and expanded the original idea to include an inventory strip, locations other than the desert, and a series of three "Lost Pyramid*s*" games-- one in Egypt, one in Yucatan, and one in the Atlantic Ocean near Bimini (i.e., in sunken Poseidia). Also, there's another person searching for the lost pyramids of Atlantis at the same time that you are, but he's evil and wants to use the Atlantean artifacts for world domination. You're the reincarnation of the High Priest of the Children of Light, and he's the reincarnation of your arch-nemesis, the High Priest of the Children of Baal. So it's partly an adventure quest, and partly a race against time (who will find the lost pyramids first?), with a showdown between you and your arch-nemesis at the end of each game in the series. Along the way, you must awaken and develop your psychic talents (what D&D-style adventure games would call "magic" and "spells"), plus you must build up good karma and avoid generating bad karma. Reventure, and Super Reventure This was going to be very similar to "Adventure," only bigger. And besides having the objects strewn randomly around each time a new game is played, the locations themselves would be positioned randomly as well, such that the game would be more interesting or have a higher replay value. The original idea was to have a kingdom for every color of the rainbow, and then some-- yellow, orange, red, purple, blue, green, brown, black, gray, and white-- and there were going to be teleportation disks in the different kingdoms to help you more quickly travel around between them. The name "Reventure" was inspired by my nephew, who had trouble pronouncing "Adventure." After I'd thought up the basic concept for "Reventure," I later came up with ideas for making it bigger and better, so I planned to have a "Reventure" game, followed later by "Super Reventure" (that name basically came from "Breakout" and "Super Breakout"). Unfortunately, I don't remember the details of how the two games were going to be different from each other. Last year I started to write a "Reventure" game using bB, but that game is very different from my original "Reventure" concept-- it's actually based more on a game idea I'd called "Dungeon Escape," where you're stuck in a dungeon maze and have to find your way out. My current "Reventure" idea loosely takes the "Dungeon Escape" idea and adds a different story to it-- you've entered a maze of underground dungeon levels and must find the remains of your dear, departed father (who went into the dungeon mazes when you were a wee baby), then return his remains to your mother so the two of you can give them a proper burial. And my idea for "Super Reventure" is to add more quests and locations to "Reventure," with the eventual goal being to save the kingdom and reclaim the throne from the evil despot who had tricked your father into entering the dungeon mazes and getting killed in an ambush. (It turns out your father was the king, and hence you are the rightful heir, but your mother spirited you away before you could be assassinated in your crib, and waited until you were old enough to overthrow the evil despot before revealing your true family history to you.) Whodunnit: Murder at Mystery Manor This was going to be a 3D-perspective game where you have to search through a manor, discover evidence, and stop your fiance and her family from being murdered one by one and cheated out of their father's inheritance. I planned to have a whole series of "Whodunnit" mystery games, all using the same 3D-perspective style. I had a lot of fun coming up with game ideas, but I also became very upset when I discovered (after writing down my own ideas and naming my games) that somebody else subsequently came out with a game of the same name, or games with different names that were otherwise similar to my own ideas. I even became paranoid about it, wondering if people might be rooting through my trash and stealing ideas from papers I'd thrown away! "Vanity of vanities; all is vanity... and there is no new thing under the sun." Michael Rideout

Okay, I put it back to the way it was. I guess I misunderstood what you meant by "stay where it is" when you said... That would be cool. To do that, I'd like for one point to score after the alien disappears. Okey dokey! Since the alien's movement is connected to the Atari's screen rate-- i.e., it moves one pixel each time the screen is drawn, or roughly 60 times a second-- the way to make it move slower is to move it one pixel every two screens, or one pixel every three screens, etc. So you'd need to add a variable to be a frame counter, and a variable to count how many times the alien has been hit, which I've added for you. The only semi-tricky part is where it checks frame{0}, or the lowest bit (bit 0) of the frame variable. If bit 0 is set, then it means that frame is an odd number-- in this case, 1 or 3, since frame is always from 0 to 3. Michael Rideout Shooting_game_question_2c.bas Shooting_game_question_2c.bas.bin

In adding or fixing the things you requested, I ended up revamping the code a bit, as follows: I replaced all of the 1-letter bB variables with more self-explanatory variable names, and I revised which 1-letter variables are being used (e.g., the x position of the ship is no longer given by variable x). The advantage of using more self-explanatory variable names is that it makes the code easier to understand when you're reading it (i.e., instead of the reader saying "x = x + 1? What's that do?", a statement like "ship_x = ship_x + 1" is easy to understand). And by assigning (dimming) each of the variables in alphabetical sequence (i.e., first a, then b, then c, etc.), it's easier to see how many of bB's variables are still available (e.g., "Now I want to add another variable, and I see that the last variable I dimmed was m, so this one will be dim new_variable = n"). I also changed some of the variable names I'd already dimmed so they would be more self-explanatory(e.g., m1_fired is now alien_missile_fired). I took the longer if...then statements and changed them to use gosubs, so the statements don't trail off the right side of the editor's screen (at least, on the editor I'm using, with the font settings and window size, etc.). I spaced the lives-remaining indicators apart, so it's easier to see how many of them there are. I added a "GAME OVER" screen for when the game ends. I rearranged the order of some of the statements, because I was having various quirky problems, and some of them turned out to be caused by the order that things were being done (e.g., the score was increasing by 2 or even 3 points at a time when the alien was hit). Anyway, the actual game play is otherwise as you'd had it, or as you requested it. But do you really want the player's ship to become immovable after it's hit? That means the alien can hit the ship two more times without the player being able to do anything about it, and then the game is over. Here are a few suggestions I'd like to offer, as an alternative: When the ship is hit the first time, it could damage the ship a bit so that it moves slower (i.e., at half of its normal speed), rather than destroying the ship completely and ending one of the lives. When the ship is hit the second time, it could damage the ship even more, so that it moves slower still (i.e., at one-fourth speed, basically a crawl), but still isn't destroyed yet. When the ship is hit the third time, it could totally damage the ship's engines (i.e., the ship can't move at all), but the ship still isn't destroyed yet. When the ship is hit the fourth time, then it's destroyed and the player loses a life. If the player has any lives remaining, then of course the new ship starts out at full capacity. Likewise, you could do the same sort of thing with the alien. Hit it once, it moves at half-speed. Hit it again, it moves at quarter-speed. Hit a third time, it can't move. Hit a fourth time, it's destroyed and a new alien appears. Another idea, for when the ship has become immobile, is to let the player aim the ship's missiles so the ship can shoot toward the alien while it's approaching, or while it's moving away (i.e., if the ship is immobile, then firing a missile while the joystick is pushed left or right will make the missile fall in that direction). Or you could even do that while the ship is still mobile (i.e., the ship can always fire the missile in one of three or five directions-- straight down, towards the right, towards the left, and maybe also towards the left or right just a little bit). What do you think? Michael Rideout Shooting_game_question_2b.bas Shooting_game_question_2b.bas.bin

Okay, this adds player1 firing missile1 at player0. I took out all unnecessary line numbers because it wasn't compiling correctly, and removing the line numbers was an act of desparation. Since doing do fixed the compile error, I presume that I had accidentally used a duplicate line number somewhere. You can line numbers back to it if you prefer. To change the distance between player0 and player1 which will trigger player1 to fire at player0, just change "distance = 5" to some other value, but it should be greater than 0. Michael Rideout Shooting_game_question_2.bas Shooting_game_question_2.bas.bin

Are you trying to do something like this? 1 set smartbranching on dim missile0_fired = z 10 player0: %0111110 %1111111 %1111111 %1111111 %0111110 end 20 player1: %01000010 %00100100 %01000010 %00100100 %00111100 %00111100 end 40 x = 80 y = 20 a = 60 b = 60 c = x + 4 d = y - 1 scorecolor = 30 missile0_fired = 0 45 COLUP0 = 14 COLUP1 = 30 COLUBK = 0 COLUPF = 64 50 player0x = x player0y = y player1x = a player1y = b if missile0_fired = 0 then missile0height = 0 if missile0_fired = 1 then missile0height = 4 missile0x = c missile0y = d 60 pfhline 0 5 11 on 62 pfhline 21 5 31 on 70 if joy0left then x = x - 1 : if x < 31 then x = 31 80 if joy0right then x = x + 1 : if x > 150 then x = 150 85 if missile0_fired = 0 then c = x + 4 : d = y - 1 90 if joy0fire then missile0_fired = 1 100 if missile0_fired = 1 then d = d + 1 105 if d > 70 then missile0_fired = 0 110 a = a - 1 120 if a = 31 then a = 150 195 drawscreen 200 goto 45 I didn't want to add that yet, because I'm not sure I understand what you want it to do-- fire over and over again continuously, or fire when it gets to a certain horizontal location, or fire when it's within a certain horizontal distance to player0, etc. Okay, I lied. The truth is, I didn't even see that part of your question until just now, when I was posting the updated version of your code. But I also don't know what you want exactly. Anyway, let me know and I'll add some more code. Michael Rideout Shooting_game_question_1.bas Shooting_game_question_1.bas.bin

That will be great, z26 doesn't have that! Michael Rideout

I don't know how easy it is to find used copies of the Supercharger or Cuttle Cart, but you could get in line to buy a Krokodile Cart. And if you have a 7800, you can buy a Cuttle Cart 2. Michael Rideout

That sounds like it might be a little easier to work into the existing kernel than your first request (alternating colors every other scan line). Michael Rideout

Both use the same keys. Under Windows use ALT+key (the other ones are probably for other OS). Weird! I tried that last night in Stella 2.2 and it didn't work, but tonight it's working! Okay, I didn't look there, I looked in the two HTML documents. Thanks again! Michael Rideout

'Alt/Shift-Cmd' z, x, c, v, b, n keys to enable/disable the P0, P1, M0, M1, BL, PL bits in the TIA, respectively. Well, those are the Alt keys used by Z26, and I had tried them on Stella (2.2 I think, or is it up to 2.3 already?), but it didn't do anything in Stella. So when you say "Alt/Shift-Cmd," are you saying I have to hold down Alt, Shift, and Cmd (which I presume is the Windows key?) all at the same time when I am pressing z, x, c, v, b, or n? And where is this documented in the Stella docs so I don't have to keep asking dumb questions? Thanks! Michael Rideout

That screen isn't part of a working game, it was just a static display I made while I was trying to work out the kernel for my "Quest for the Lost Pyramids of Atlantis" game a couple of years ago. That project is currently on hold, and never got much past a few static test screens and a pair of working title screens (the first title screen says "Quest for the Lost Pyramids of Atlantis," and the second title screen says "Part I: The Lost Pyramid of Eqypt"; they cycle between each other every few seconds). I was creating the game using the M-Network 16K bankswitching with extra 2K RAM, and the display data for the kernel is stored in the extra RAM. When I eventually resume working on the game, I'm planning to use supercat's bankswitched cartridge with extra RAM. The only thing that makes sense is that there are three copies of both players, with player 0 starting where the second swirly is, and with player 1 starting where the fifth swirly is. That is, the first swirly is the second copy of player 1 (I'll call it "P1B"); the second swirly is the third copy of player 1 (P1C) as well as the first copy of player 0 (P0A), positioned precisely on top of each other; the third swirly is the second copy of player 0 (P0B); the fourth swirly is the third copy of player 0 (P0C); and the fifth swirly is the first copy of player 1 (P1A); as follows: [font=Courier New] P1B P1C P1A P0A P0B P0C Michael Rideout