SeaGtGruff

The last version was 2.7, you can get it here: http://www.bjars.com/tools.html (Scroll all the way to the bottom of the page.) Michael Rideout

It was supposed to be "m" for "magic." I tried to do a star, but it looked terrible. Anyway, I figured that if Shawn liked any of them, he would probably create his own sprite using one of my attempts as a basic guideline-- and he could easily color in the "m" if he didn't like it. Michael Rideout

The conversion is a little more complex than that, because the player or missile's height will affect its vertical positioning, and it's impossible to get a perfect vertical alignment in some cases. Ignoring the playfield for a moment, a player's vertical position value (e.g., player0y) determines the location of its bottommost row of pixels. And you have to keep in mind that each row of player pixels is actually two scan lines, or one "double line." If player0 is only 1 (double) line tall, then the topmost vertical position will be player0y = 2; anything below 2 (i.e., 1 or 0) will move player0 off the top of the screen. If player0 is only 2 (double) lines tall, then player0y = 2 will position the bottommost row of pixels at the top of the screen, and the topmost row of pixels will be off screen, so player0y = 3 will put the topmost row of pixels on the first visible line. So the general formula for determining the player0y value is 1 + h, where h is the height of player0 in (double) lines. For example, if player0 is 8 (double) lines tall, the highest position that keeps all of player0 on screen will be player0y = 9. In all cases, the lowest position that keeps all of player0 on screen will be player0y = 89; anything over 89 will start to move player0 behind the score lines. On the other hand, in the standard bB kernel, the playfield pixels are 15 lines tall, with 1 blank line between them, so you could say that they're 16 lines tall, or 8 double lines tall, except that 1 of the lines (or half of a double line) is blank. Thus, if player0 is 8 (double) lines tall, then you can position player0 so that it covers up an entire playfield pixel from top to bottom, except that the topmost row of the player0 pixels will extend slightly above the playfield pixel (or over the blank line). Furthermore, assuming that the playfield isn't being scrolled, the topmost portion of the playfield is just a tiny bit off of the screen in Stella-- that is, the first (double) line of the playfield pixel is the blank scan line, followed by a non-blank line, but you can't see that first double line in Stella (but you can see it in z26). So if player0 is 1 (double) line tall, and you use player0y = 2 to position player0 as high as it can go without moving off screen, then the topmost edge of player0 won't reach the topmost edge of the playfield pixel. In Stella it will look like they're lined up, but in z26 you can see that there's actually a single scan line of the playfield pixel that extends above player0. On the other hand, if player0 is 8 (double) lines tall, and you use player0y = 8, then the bottommost edge of player0 will line up exactly with the bottommost edge of the first playfield pixel row, but you won't be able to see the topmost pixels of player0. The following program draws a full playfield in yellow, and draws player0 as a red checkerboard pattern. The player0y value is shown in the score. You can use the joystick (or cursor keys) to move player0 up and down, and see the different player0y values as it moves up and down. You can increase or decrease player0's height by moving the stick left (decrease) or right (increase). This lets you see how player0y determines the position of player0's bottommost edge, rather than the position of player0's topmost edge. In this program, player0 cannot be decreased to less than 1 (double) line tall, or to more than 8 (double) lines tall. You can also see that the blank lines between each row of playfield pixels are just a single line, or half of a player pixel. The missiles and ball are a little quirky, as I'll demonstrate with another program in another post. Michael Rideout player0y.bas

Heh, I guess we were doing it at the same time! Michael Rideout

It looks like the only thing c is ever set to is 0 or 1. The square brackets ([ and ]) that you think you're using for the bit operations are actually for variable arrays. To do bit operations, use the curly set brackets ({ and }). Also, checking the bit settings in an if...then is done a little differently-- you can't use an equals sign or you'll get compile errors, so you just say "if c{3} then" or "if !c{3} then" (or whatever variable and bit you're checking), where the first case means "equals 1" (or is "true"), and the second case means "equals 0" (or is "not true"). I've made the appropriate changes in your code so you can see how to do it. Michael Rideout asteroids.bas

I agree, it would be great to be able to use pfpixel and 4way scrolling with the msk. I want to be able to do something like Ikari Warriors. Well, I'm rather ignorant of what's possible for homebrew carts as far as extra RAM is concerned, so I may have spoken too soon-- although once supercat gets his bankswitched carts with extra RAM finalized and in production, it might be feasible to enhance bB to exploit the new possibilities. In the meantime, if we're going to create bB games that are intended to be run on emulators, or on a 7800 with a Cuttle Cart 2 for example, then we can create our own custom kernels that make use of any existing bankswitching scheme or extra RAM. As far as the classic game carts, I know there were at least three varieties of extra RAM-- Atari's 128-byte Super Chip, CBS's 256-byte RAM chip, and M-Network's 2048-byte RAM chip. For example, before batari added Atari's bankswitching schemes in bB 0.99, I had modified bB 0.35 to allow M-Network bankswitching. Michael Rideout

Here are a few attempts I made. If it's going to be against a black background, you'll probably want to use a nice golden or silvery color. Michael Rideout

I took a look at the code. The easiest fix would be to limit movement to four directions by simply skipping the rest of the joystick reads once a valid direction is found. If you want to allow diagonals, probably the easiest way would be to remember which of the 8 directions you moved last, and if there's a collision, just move the player the opposite way. First of all, I notice that the collision detection seems to be fine if the movement is in certain diagonal directions, such as up and left, so you should look at how that situation is being handled, versus the way the other situations are being handled. I haven't studied your code yet, but batari's comment about keeping track of your last direction is the way I did it in my unfinished Reventure game. First, I moved the man in one frame, and saved the x and y directions, then at the start of the next frame I checked for a collision between the man (player0) and the playfield, and if one occurred, I moved the man back in the opposite x and y directions, like this: dim horizontal_motion = h dim vertical_motion = v dim hero_x = x dim hero_y = y hero_x = 93 hero_y = 51 horizontal_motion = 0 vertical_motion = 0 loop player0x = hero_x player0y = hero_y drawscreen if !collision(player0,playfield) then not_touching_wall hero_x = hero_x - horizontal_motion hero_y = hero_y - vertical_motion not_touching_wall horizontal_motion = 0 vertical_motion = 0 if joy0left then horizontal_motion = 255 if joy0right then horizontal_motion = 1 if joy0up then vertical_motion = 255 if joy0down then vertical_motion = 1 hero_x = hero_x + horizontal_motion hero_y = hero_y + vertical_motion goto loop Obviously, the above code is incomplete, but it should give you an idea of how I did it. In particular, you must check for a collision and bump the man back *before* you determine the new values for the x and y movements, so you can apply the opposite of the previous movements before moving again, if you see what I mean. I've made a few changes in your code, but just for player0, and now the collision detection works better. Unfortunately, the code still needs work, because if player0 drops a new block, he can get stuck on it! But hopefully you can tinker with the code to get my changes working correctly. Michael Rideout Construction6.bas

It might be good to enhance bB to behave as if extra RAM were installed. For example, if cartridges with the "Super Chip" are reasonably common, then it might be nice to have a SET command that would indicate to bB that there is a "Super Chip" present, and then the extra 128 bytes of RAM could be used for the playfield. Of course, then all of the statements to read/write the playfield RAM would require absolute addressing, but it's just a thought on how bB might be enhanced so that a multi-sprite kernel could also have a RAM-resident playfield. Michael Rideout

I vote for Millipede. Michael Rideout

I no longer have my old 2600-- which was a "light sixer" if I'm not mistaken-- because I foolishly let my older brother borrow it for his kids to play on, and apparently one of their neighbors broke into their house and stole it. I also gave a few of my most cherished games (like Adventure and Superman) to my oldest sister's son, because I figured I would easily be able to replace them. But other than that, I still have a lot of my original games, plus my old Supercharger (although I'm not even sure if it still works), my Trakball controller (which I never got the hang of), and my 7800. A few months ago, I bought a "heavy sixer" to replace my old "light sixer," and it came with a pretty big collection of games, some of which I already have, including a copy of Adventure to replace the one I gave away (but no Superman ). And I bought a new 7800 power supply to get my 7800 working again, seeing as how I bought a Cuttle Cart 2 last year. I'm not really a collector, though, just a gamer. There were plenty of titles I had no interest in buying back when they came out, and I still have no interest in them! But one thing I always did was keep the boxes and manuals and catalogs, and I always tried to open the boxes so they didn't get torn up. I still have my old magazines, too, although most of them are in storage and I'm not sure what kind of shape they're in. (The little storage shed in my parents' back yard had a big tree limb fall on it, punching a hole in the roof and letting the rain in, which totally ruined a lot of my old paperbacks and who knows what else. ) Michael Rideout

Here is the map for Maze "D." It has one location (in the upper left quadrant) where two corridors actually cross each other-- I guess one of them goes underneath the other. Since the N-S corridor is a dead end, I put thicker walls on the upper and lower sides of the square where they cross, because the E-W corridor ends in a monster's lair. Michael Rideout Maze "D" -- Levels 4, 8, 12, 16, etc.

I think an Ultima-style RPG would be difficult with bB, unless you could develop a custom kernel that could handle the graphics display. (See Supercat's blog for a demo he wrote-- but not in bB-- which ought to work well with an Ultima-style game.) However, you could much more easily create an Adventure-style RPG, a Raiders-style RPG, or even a Dragonstomper-style RPG. Michael Rideout

Something I once read in an article on the internet made it sound like one reason for overscanning the TV picture was so people wouldn't complain to TV manufacturers that their sets were "defective" because there were black areas at the edges of the screen where the picture wouldn't display! When I was a kid, our family had TV sets with controls in the back for adjusting the horizontal and vertical picture dimensions. The way I remember it, we even had one set with separate adjustments for the three electron beams for the red, green, and blue pixels! I don't remember if I could adjust the convergence of the beams, but I remember being able to adjust their intensities. The red, green, and blue adjustments were recessed into holes in the casing so they couldn't be adjusted "by hand," but they could be adjusted with a flat-head screwdriver. On the other hand, the knobs for the vertical and horizontal adjustments stuck out and could be easily twisted with one's fingers, but they were still hidden in the back. The way I remember it, these controls in the back were in addition to the usual brightness, contrast, and tint controls on the front of the set. Michael Rideout

Yes, the controls are difficult. One thing that's always been hard for me to do is switch actions (i.e., choose a weapon or make a U-turn) and then switch back to where the action is "locked" and I can move back and forth to get into a decent attack position. It seems like if you choose the action, and then press the button and push "up" while pushing the button, it's easier to "lock" the selected action or weapon and switch back to where you can move again. Here is the map for Maze "C," which is a little bit quirky. That is, there is one spot (on the far left, in the bottom half) where a lair is at the end of a corridor, and there is another corridor going N-S that goes "through" the backmost square of the lair. I put a thicker wall there to show that the lair doesn't connect with that N-S corridor, but the lair actually extends "into" (or let's say "below") the square of the N-S corridor. I haven't started on the map for Maze "D" yet, but I'm guessing that it may be even more quirky, since it seems like the programmer tried to make each maze more tricky than the ones before. For example, Maze "B" has more dead ends at the end of corridors than Maze "A" does, and Maze "C" has more dead ends than Maze "B." Michael Rideout Maze "C" - Levels 3, 7, 11, 15, etc.

I've finished the map for Maze "B" (levels 2, 6, 10, 14, etc.), and I also modified the map for Maze "A" a little bit to be more accurate. Specifically, I noticed that the monsters' lairs extend back one more square-- that is, they're two squares "deep," but you have to fight a monster and can collect the treasure in the first square. And some of the "dead ends" are really more like niches, because if you go "into" the so-called "dead end" and do a U-turn, you'll see that you didn't really go "into" a new square at all. For example, if you're in an intersection facing what appears to be a dead end, and move "forward," the "side exits" disappear; but if you then do a U-turn, you'll find that you're still in the intersection. So I changed those "niches" from full "dead end" squares to just orange "half squares." And finally, the screen turns red for the "down staircase" two full squares before the actual staircase, so I colored three squares red-- the two squares before the staircase, then the actual square containing the staircase, which is the square I put a "D" in. In both the up staircase and down staircase, you can't really go "into" the staircase square per se, because when you move "into" that square, you are taken up or down a level. I'm posting the maps in this thread, since this is the thread that has "maps" in the subject line! Michael Rideout Crypts of Chaos - Maze "A" (Levels 1, 5, 9, 13, etc.) Crypts of Chaos - Maze "B" (Levels 2, 6, 10, 14, etc.)

What do you mean by "datasheet"-- a list of op codes, or something else? Either way, you'll probably find them at http://www.6502.org! Michael Rideout

That's a good observation! Actually, the easiest way to tell them apart is to notice that on the down staircase, there are two little lines (playfield pixels) at the top of the opening, one on either side. It looks like if those playfield pixels had been extended all the way down the sides of the opening, the opening would have been just as narrow as the opening in the up staircase. Michael Rideout

Here's a better map of Maze A (levels 1, 5, 9, 13, etc.), drawn to scale. Note that the colors of the locations can change, depending on which direction you're facing. I'm working on a map for Maze B. Michael Rideout

I had high hopes for it when it came out, and bought it right away. I was disappointed, but thought it showed promise... it just had some problems. For example, the dot that represents the player moves very slowly across the screen, making it rather tedious to turn left or right, or to move into position for attacking a monster. And the graphics were cruder than they needed to be, in my opinion. But the overall idea was pretty neat. I've posted a map of Maze A in the other thread, and screenshots from Stella showing what the illustrations in the manual look like. Michael Rideout

I started playing it on Stella last night after I read your post, and had to dig out my cartridge so I could refer to the printed manual. I was making a map many years ago, but if I ever finished it, it's lost to the dustbunnies of time. Anyway, if you want to know what a stairway looks like, just do a U-turn as soon as you begin the game, because you start each level beside the up stairway. So if you do a U-turn on game 4 and take the stairs, you end the game! Here are some screenshots from Stella, to show you the pictures that are missing from the text-only online copy of the manual: #1 CORRIDOR #2 WARNING -- You are approaching a Dead End, T-Intersection or Lair #3 WARNING -- You are approaching a Dead End or a T-Intersection #4 T-INTERSECTION #5 DEAD END #6 4-WAY INTERSECTION #7 WARNING -- You are approaching a Lair #8 MONSTER'S LAIR #9 UP STAIRCASE #10 DOWN STAIRCASE The map for Maze A (levels 1, 5, 9, etc.) is very simple, something like the following (which is not drawn to scale): I hope this is enough to get you started! Michael Rideout

I've noticed a couple of similar bugs. On "My Posts," it keeps showing the topmost entry as new, but I've viewed it several times trying to make the "new" setting go away. If I read it and click on "My Posts" again, it changes to blue, but the next time I visit AA it's orange again (same thread, same reply). On "View New Posts," usually most of the posts are orange, but there will be a few scattered here and there that are blue, even though I haven't read them yet. Michael Rideout

You're welcome to post the map I made for Atari 2600 Pitfall! II: http://www.atariage.com/forums/index.php?s...ndpost&p=916365 And although it isn't a complicated map, here's one I did for Atari 2600 SwordQuest: FireWorld. Michael Rideout

Very cool, thanks for sharing this! Michael Rideout

That's what I was thinking, too. I work for a software company, and most of our programs are written in AcuCobol. We used to compile them with a "native code" switch for Intel processors, which helps them run faster. But one of our clients got a new computer with a dual-core processor, and our programs wouldn't run on his workstation anymore, so we had to recompile every single program in our system without using the "native code" option. But then again, we bought a new workstation with a dual-core processor for our office, and it runs our system just fine using the "native code" option! Michael Rideout