Search the Community

NATHAN has probably given up all hope, but never fear! I am actually working on it, though veeeeeeeeerrrrrrrrrrrrryyyyyyyy slowly... Most of what little I've done so far is simple stuff to help me understand the code better. I did, however, get one of Nathan's new hand graphic sets in, and I cleaned up the scanline counts and some of the transitions where the screen would jitter or jump. And I changed the copyright date. Lot's still to do: ; To do: ; ; fix scanline count so it is an even number and consistent all the time: ; PARTIALLY DONE - scanline count is good on title screen (262) and select screen (262) and transition between them is solid. ; note: screen rolls if you hold down RESET!!! ; note: scanline count jumps when you press SELECT - FIXED! ; get new graphics from Nathan Strum in. ; PARTIALLY DONE. male_ graphics in, need to add code to support two (or more?) sets of hand graphics ; rewrite music to make smaller (in terms of both ROM and RAM) and add it in ; modify title screen to reflect ; additional contributions, ; possible fancy graphic from Nathan (?) ; DONE - new date ; Make game options visible from the beginning (?) ; make default options single-player, medium difficulty (question: Are there different difficulties?) ; make controls more intuitive? With more feedback? Add prompts (e.g., "Hold trigger to begin") ; more sound effects? ; allow start of new game with fire button ; make hand movement more natural not just linear up-down-up-down-etc. ; add game-over state and logic (currently, game never ends, win or lose) ; add some kind of "campaign" mode (?), complete with boss (?) (get feedback from Nathan about alternate boss hands, ; like robot, monster, or just bigger. Add code to unlock that is shown if you beat the game.) ; AtariVox/SaveKey support? rps.bin rps_source.zip

SO IT'S been a while since I've posted anything...or coded anything. But I was inspired by...well, by something I can't talk about. Um. Anyway, I revived an idea that I kicked around almost two years ago and banged something out: 2kAVoxEditor20081209.bin I haven't tested it with an AtariVox myself - but Nathan did and it seems to work fine. What does it do? It's a way to quickly play with your AtariVox using your 2600. Add/edit/adjust sounds and control codes and then play 'em! Controls: Trigger switches between PLAY and EDIT modes. When in PLAY mode, up/down navigates the sound buffer. Right begins playing (i.e., sending codes to the AtariVox) immediately, from the cursor position. Left stops playing immediately*. When in EDIT mode, up/down changes the currently selected value. Left deletes the current value, right inserts a value at the current position. *Immediately is not entirely accurate - since the AtariVox has an internal buffer, the AVoxEditor will send 60 codes/second while playing; hitting left (to STOP) will only stop the sending of codes, but the AtariVox will continue speaking. So, for most code strings, it will send all codes to the AtariVox in less than a second, regardless of how long it takes to speak. A few other notes: switching to EDIT mode will stop the sending of codes. Hitting play will immediately begin sending codes from the cursor position. The buffer is 96 codes long. It might help to consult the SpeakJet manual for reference to what the codes are (see pages 15-16): speakjetusermanual.pdf Enjoy!

HERE'S what I've been working on, slowly, over the last few weeks. Well, besides the tile demos I've posted in the homebrew forum, which are mostly just a sideline - for now, anyway. Demo120080209.bin Demo220080214.bin Both are very rough and likely will roll on a real TV.

THOUGHT I'D REVISIT this topic again this year. -I have two big 2600 projects that have been kicking around in my head for a while; I'd like to make some significant headway on one or the other this year. One is an RPG for the supercharger, the other is a 32K+ Street Fighter II-ish fighting game. -I'd like to possibly do something for the A800. Though I might be satisfied just porting Squish 'Em to the 5200; I'm about halfway there already. -Create a PAL60 version of Elevators Amiss. -Possibly write something for the GBA. I've been kicking this around for a while, but the graphics-requirements are so much higher that it's hard to pick a good project. I've been thinking about porting Elevators Amiss or Go Fish!

NES VERSUS 5200, how does the hardware compare? This question is interesting to me, so I did some research this morning, refreshing my memory and digging a little deeper. I was going to post this in the (latest) thread on the subject in the 5200 forum but it had degenerated into name-calling So, anyway, here's what I've got. Please let me know about any inaccuracies or errors! I'm going to use the term "5200" to stand in for the the 5200 as well as the 400/800 line of computers, so I will be ignoring controller issues. Colors 5200: 256, 16 luminances of 16 colors (including grays) NES: A little confusing, 52 is the number most commonly given, but it looks higher than that. There are 12 colors (not including gray) with 4 luminances. There are 4 different "gray" colors, each with 4 luminances. There is some overlap between those grays, but I'm not sure how much - I think there are something like 6 shades of gray. So, my reading of the technical docs is that there are 54 colors (including grays). But! You can also change the "color emphasis," which apparently changes the color of all the colors slightly. I.e., if you select to emphasis green, then all colors will be slightly greener. I'm not sure how much of an effect this has and according to some docs there is overlap between the palettes, but there are 4 settings for the "color emphasis:" normal, green, brown, blue. So the total number of colors is probably at least 100 and as many as 416. Playfield 5200: Lots of modes to deal with here. We'll start with bitmapped modes, since they don't correspond to anything on the NES, AFAIK. Leaving aside the special GTIA modes, which I don't think I've ever seen used in a game (I'm probably wrong, of course!), there are basically two bitmapped modes: a 320x240 mode and a 160x240 mode. I'm going to use 240 as the vertical resolution for both the 5200 and the NES since they both are capable of outputting that many visible lines, even if neither machine really uses that many. Anyway. The 320 mode is 1.5 color (foreground and background are the same color, with different luminances) and the 160 modes are 5 color including background. Next, of more interest for direct comparisons: Tile (or character) graphics. The 5200 has several modes, but I will just explain the main four. The first is a screen of 40x30 tiles that are 8x8 each. You can define up to 128 different tiles and display them normal or inversed (as a "negative") (or upside down, for that matter, though upside-down and rightside-up tiles cannot be displayed simultaneously). This is based on the 320 mode and shares the color scheme of that mode: 1.5 colors. The others are all 5-color modes: First, the two 2-color tile modes. Each tile can be 2 colors, foreground and background, where there are four different foreground colors to choose from. You can define up to 64 tiles, but each one can be displayed in any of 4 foreground colors. I.e., you can display AAAA. There are two variations of this mode, one with twenty 8x8 tiles across each line (pixels are double width) and one with, again, 20 8x8 tiles across each line but with the pixels double-height as well (so only 15 rows of tiles rather than 30). Finally, there is a 5-color tile mode (including background). These tiles are 4x8 and each pixel can be any of 4 different foreground colors. These 4 foreground colors are the same for all tiles on the screen. There are 40 tiles across the screen and 30 rows. You can define up to 128 of these tiles; I'm not sure whether they can be displayed inversed or upside-down. NES: Much, much, much more simple. No bitmap mode that I'm aware of. A single tile-mode: A screen of 32x30 tiles, each 8x8. You can define up to 256 tiles. Each is 4-color, including background. The 4 colors are not independently set, though - you can choose from four foreground palettes, so you have 13 colors, including background, to choose from but which of the 12 you choose depends on where on the screen the tile is. Each palette corresponds to certain areas of the screen in, apparently, an odd checker-board pattern (each 32x32 pixel area of the screen is quartered, with each quarter using one of the four palettes). A note about tiles: though the NES supports many more tiles (256 vs. 128 or 64), you can't easily swap out one set of tiles for another - to do so requires rewriting up to 8K of RAM! On the other hand, you can very easily swap tile sets on the 5200, you just change the base address of your tile set. So you can have as many tile sets as you have memory (RAM or ROM) for and then switch between them as often as several times per frame. It is very easy to animate your tiles this way - you don't even have to rewrite any screen memory, just tell ANTIC to look somewhere different for the tile set. Scrolling 5200: Supports fine-scrolling of all graphics modes in all directions. NES: Supports fine-scrolling in all directions - note that a stock NES only has enough RAM to scroll horizontally or vertically, but not both at the same time. This is only a RAM limitation and could probably be worked around with some fancy trickery. Or more RAM, of course. Sprites 5200: Eight sprites, half of which are 8x240 and half of which are 2x240. Each sprite is 2-color (foreground and background) and each smaller sprite shares its color with a matching larger sprite. Or you can combine the 4 smaller sprites into a single larger sprite and then it gets its own color, sort of - it then borrows a color from the playfield. I suppose at this point we have to finally mention interrupts. Using display list interrupts (DLIs) you can do a lot of things, but for sprites you can do two main things: you can change their foreground color line-by-line and you can change their horizontal position in the middle of the screen - you can, essentially, "re-use" a sprite, increasing the number of sprites you can show onscreen. So the 5/8 sprite limit is a hard limit for each scanline but not for the entire display. Finally, with a special setting you can get an additional color: You can overlap sprites and the overlapped pixels will have a blended color, combining the color of both sprites. NES: 64 sprites (8 per scanline), each 8x8 or 8x16 and each is 4-color (including background). Each sprite can use one of four palettes and can use 3 foreground colors from each palette. I believe you can use DLIs with the NES as well but it is much trickier and not as flexible as the 5200. So, to sum up some of the color stuff: The 5200 can display 9 colors on each scanline (4 sprites, 4 playfield, and background) or a few more with overlapping/blending and the NES can display 25 (12 sprite colors, 12 tile colors, and background). Audio 5200: POKEY has 4 audio channels. Each plays a square wave with varying amounts of noise, including a setting which is basically pure noise. The frequency has 8 bits of resolution, the volume has 4 bits of resolution. Can also combine 2 channels into a single channel with 16 bits of frequency resolution. Each channel can also be set to a special mode to play digitized samples, though you have to feed it the raw sample data at the desired frequency. It accepts 4-bit samples. NES: Here we have more flexibility, and more complexity. Five channels. Two play a square wave, one plays a triangle wave, one plays noise, and one is dedicated to playing digitized samples. The square wave and triangle wave channels each have 8 EDIT: 11 bits of frequency resolution and four bits of volume resolution. The noise channel's frequency has 4 bits of resolution and its volume also has 4 bits of resolution. Also - the noise channel and square channels also have a volume envelope with looping, and the two square channels also have a "sweep" register, which I think increases/decreases the frequency a specified amount at set intervals. Very cool! The channel reserved for playing samples has two modes - in one mode you feed it the raw sample data (7-bit) at whatever frequency you want, in the other it will automatically stream the sample, though the digitized data has to be in a special form. I'm not sure how good the auto-streaming samples sound, but it is a cool feature. And that's it! The NES clearly has better capabilities - though the lack of a bitmap mode kinda hurts - but, actually, I'm surprised how well the 5200 stacks up against it. I think the main thing that hurts is the resolution difference and having fewer colors to work with. Fewer sprites is another biggie, but not as big as I anticipated - 5 vs. 8 per scanline - though it is easier to handle the 64 independent sprites on the NES versus all the DLIs on the 5200, you can in theory have many more than 64 sprites on a 5200. Also, I think the NES will automatically flicker them for you if you put too many on one line. EDIT: The NES will not automatically update them for you, you have to do that manually.

WELL, THAT was a whirlwind! Finished up Squish 'Em with just days to spare. I posted the list of differences vs. the A8 version in the Squish 'Em thread, but I thought I'd recap here and try to collect my thoughts about my next project(s). First, Squish 'Em - this turned out waaaay better than I thought. It was easier than I hoped (and a lot of fun ) to disassemble the A8 source, which allowed me to get the timings to match exactly and the sounds to match very very closely. I still had to make some compromises but they all turned out to be minor ones, so I'm happy and pleased with the result. I'm also very happy that I was able to squeeze it into 4K. Wow - two games released this year. Busy busy. Though, once again, I took the summer mostly off, so I squeezed most of my coding into intense bursts in the spring and the fall. And I just remembered - I also modified Go Fish! to allow a 6-digit score. So, enough looking back - what's next? A couple of minor projects: -convert Elevators Amiss to PAL (or, likely, PAL60). -possibly convert Go Fish! to use Econobanking or whatever that cheap 8K banking scheme is called. A couple of big projects are also in the works: -I've been thinking about picking up the Supercharger RPG I was working on a year or two ago and trying to bang that into shape -I've also been toying with a big project for a while now, bugging Nathan for sprites, and writing kernels (on paper). I'll keep this one under wraps for just a bit longer - but I will say that the possible availability of a 64K cart has revived my interest... -Something for the A8? It's kind of a dream of mine to write an A8 game, but the difficulty is picking a project, of course. Anyway, if you've read this far, thanks for indulging a little navel-gazing and have a good Christmas!

THINGS ARE MOVING ALONG, though my self-imposed deadlines are looming and looking more and more unrealistic the closer they get! Unsurprisingly. I'll keep plugging away, though, and we'll see what happens. The Latest! Big changes: -Scrolling now works, though the kernel isn't completely tightened up yet. -Randomly generating girders, monster colors and positions. -Moving monsters. -Player movement constrained. Now pressing up scrolls the screen, down does nothing. -Matching up things to the original: starting location of player is correct. Brick falls at correct speed (and speeds up to fall at same relative rate when you are climbing). Monsters "fade in" when they appear. Scroll stops at correct place. A few notes: -I have to scroll two lines at a time, rather than one. It looks a little chunky compared to the original, but I think I'll have to live with it. -Realized that the girder colors change during the game! They are hardcoded in the kernel now; have to see if I can change that. -I think the falling brick is ok. -_Fandal_ helpfully disassembled A800 Squish 'Em for me so I'm hoping to extract the sounds. I think the sound hardware is mostly the same, except with the BIG difference that the A800 has 8 bits of frequency resolution, compared to the 5 bits that the 2600 has. Are any of you experienced uncommented-asm readers able/willing to help me partially disassemble this? -Still have 48 free bytes of RAM! I don't want to count my chickens before they hatch and all that, but this just may be my first project where RAM wasn't an issue. Would be nice...

YET ANOTHER update. Changes: Biggest changes are -adding the climbing animation. The animations are mostly done now, though I need to tweak things a little - the climbing animation is a little goofy when you start with your left hand up. -major cleanup on the kernel. This is very close to being complete. Enemies no longer jump around when the screen is scrolling and there are many fewer graphic glitches at the top and bottom of the scroll area. EDIT: Just glanced at the screenshot I took for this post and noticed a graphic glitch in the player!

SQUISHING IN FULL EFFECT! New update. Still not technically playable, since you can't die, but pretty close now. Changes: -Player now moves at correct speed in all directions and is animated when he moves sideways. -Only can squish enemies by actually stomping on them. -Enemies are generated correctly (i.e., 1 blank row, 15 rows of 1st enemy, 16 rows of 2nd enemy, 1 row with bonus item, 15 rows of 3rd enemy, 1 row with suitcase, repeat). To do: -clean up kernel transitions, tighten up all SLEEPs, and finalize all page-crossing locations -decide whether or not to stripe brick (Or girders?). And then do it if so. I'm leaning towards not doing this. -finish add enemy/girder data generator. Enemies and items are pretty much done, the girder generation needs all the special cases taken care of. -finish enemy movement schemes -finish collision detection -finish animating player -death animation (scroll player off bottom of screen) -add sfx -add music -finish scoring -finish level transitions -all gamestate transitions -console controls -testing/polishing So, there's a lot. But I'm getting there!

YOU GOTTA LOVE WORDS WITH CONSECUTIVE 'u's in them, even if they are made up. Anyway, I gave it the ol' college try, but I couldn't quite get a playable version done last night. Changes: -Added legs-up animation when you press the button. -Enemies can be squished! Er, just by touching them. The timing on this needs work also. -Constrained player movement. This is now done, except for animating the little bastard and getting his left/right speed correct. -Added some of the scoring; you gain 10 points for climbing one level. I think that's it. I might try to make this sort-of playable and then post a new version tonight, otherwise I probably won't post any new versions until next Monday.

SQUISHING CONTINUES! Oh, I slay me. Anyway. Did some more work last couple of nights. Changes: -Rewrote part of kernel to use actual enemy graphics (without 13 trailing zeroes) -Animating enemy graphics. This, as I mentioned before, is amazingly easy. Even easier than I thought it would be: I just take the frame counter variable and write it to REFP0. That's it. -Added six-digit score -Got girder color-changes into the kernel, looks much nicer now. -Moving the brick. I'm not sure whether or not the brick is visible enough or not. I think it might be ok, since it is in motion. When the game gets closer to release I'll solicit opinions on whether or not to stripe it, I think. That will be a very easy change. -Fixed the issue that was goofing up the enemy graphics; it wasn't a timing issue - I had forgotten to set VDELP0! Also, I wrote myself a to-do list/schedule. It's in the source, but I'll reproduce it here: ;--------------------TO DO: ; ; -*DONE*re-write main kernel loop into two loops: top loop doesn't draw enemy ; bottom loop does (save gfx ROM) ; -*DONE*use actual enemy graphics (and animate) ; -add multiple entrance points to kernel with appropriate timings ; -*DONE*add girder color changes? ; -clean up kernel transitions, tighten up all SLEEPs, and finalize all page-crossing locations ; (and get scanline count at steady 262 [or?]) ; -stripe brick? (Or girders?) ; -add scrolling ; -add enemy/girder data generator ; -add enemy movement schemes ; -constrain player movement ; -add collision detection ; -animate player ; -add squishing (start thread in homebrew forum here? Or earlier?) ; -----------need to be at this point by Thanksgiving!------------------ ; -death animation (figure out how to scroll player off bottom of screen) ; -add sfx ; -add music ; -add scoring ; -all gamestate transitions ; -console controls (including pause? 7800 detection/support? music toggle?) ; First thoughts: yes yes no ; -testing/polishing ; -----------aim for December 1 at this point!-------------------------- ; -SaveKey/AVox? ; -PAL conversion? TJ to help?

RETURN OF SQUISH 'EM! I haven't forgotten or dropped this project! Here's the latest code and binary. Where I'm at: -Kernel is mostly there, just needs a few things here and there and some tightening up. I think I introduced a page-crossing error last night which is why the "enemy" graphics are messed up a little. -Converted all graphics to data. Discovered something interesting in the process: all enemy/item animation is done by flipping the reflection register. Very nice! It's also used for the player animation as well. To do: Everything else. Main goal right now is getting a sort-of playable binary working; at that point I'll start a thread up in the homebrew forum and continue all development discussion/news there. Immediate to-dos: --get scrolling working. --Rewrite kernel slightly so it can use enemy graphics. --Get score display working --get correct movement scheme in for player --add movement routines for enemies --randomly generate building to climb I'm worried about: -Getting the music/SFX to sound right. -The player seeing the brick. It might blend in with the backgrounds too much, since it shares a color. Big goal: have final binary by December 1 2007....okay, stop laughing. No, seriously, that's my goal. I'm...cautiously...optimistic about that deadline, but we'll see. I hope to have a shiny, labelled copy wrapped and under the Christmas tree for my oldest son to open on December 25th. We'll see if I can do it. EDIT: Here's a screenshot of the original A800 game, for comparison purposes:

YOU, TOO, CAN MAKE your Atari talk! Nathan wanted a ROM that he could modify/play around with that would make the AtariVox speak, so I jumped at the chance to get coding again. Here it is: SpeechTester20070802.bin SpeechTesterSource.zip The ROM currently supports up to 4 different speech strings, though only one has anything in it right now: the "go fish" from the game of the same name. Switch between speech strings with SELECT, start/restart a speech string with the trigger, and reset everything with RESET. Hmmm. Just realized I should allow using the joystick to switch speech strings. Maybe I'll change that.

I HAD AN UTTERLY RANDOM thought this morning, an idea for a game: What if you took Missile Command, flipped it upside down and put it under water? I.e., rather than protecting a city from missiles, you would be protecting a ship from torpedos/etc. You would drop depth charges (and...?). Has this ever been done?

WHEN I SHOULD HAVE been working on my Elevators/Maids game during the past week, I was instead working on this: RType20070329.bin EDIT: Fixed a bug or two: RType20070329.bin I was inspired partially by Manuel's post about the NES' lack of R-Type clones and partially by the idea of writing one for the 2K minigame competition. I started with my Metroid code, since it conveniently had an asymmetrical playfield plus intelliflickered sprites. I've pared it down from 32K to about 3K (and halfway given up on a 2K minigame) and instituted randomly generated terrain. The tricky part was, first of all, when placing any new blocks they can't close up a pathway! The routine either: adds to the floor/ceiling, subtracts from the floor/ceiling, starts a new "island" in the center, adds to the top/bottom of the island, or subtracts from the top/bottom of the island. It kinda works. One bug I've noticed is that sometimes it erases a block from the middle of a group of set blocks, like this: EDIT: Fixed this bug, see above. Other than that, it looks ok, though I think I need to tweak it so that there are fewer shorter islands. I *think* that, at the shown scrolling speed it will randomly generate terrain for about 35 minutes before repeating. My planned scrolling speed is half that, so it should go for over an hour before repeating. That's the hope, anyway. Thoughts? Oh yeah - here's the source, if anyone wants to take a look: Rtype20070329.zip

I DON'T THINK I've ever shared this unfinished project. FD20061003.bin The concept: You man an anti-aircraft turret located in the center of a besieged city. It is up to you to defend your city from enemy aircraft. Very loosely inspired by Fighter Pilot. Details/dreams: -would use a crosshair to aim. The crosshair would be free-moving, the screen would scroll when the crosshair reached the edge of the screen -use 24+ pixel width sprites for enemy aircraft -changing weather/visibility conditions -have a very robust 3D engine underneath it all, enemy fighters would approach from the horizon, pass over the city, bombing buildings that they passed over, and then fly back over the horizon. -city buildings stored in RAM so that you can see which buildings are still standing. When they're all gone: game over. Why I stopped working on it (besides usual reasons of lack of time, etc.): -I really, really, really wanted the city buildings to have a parallax effect. I could not figure out how to do it (with the playfield). Any brilliant insights on how to display (at least) three rows of parallax-scrolling cityscape that (a) doesn't constantly flicker and (b) spans at least 80% (128 pixels) of the width of the screen?

AN OLDIE but a goodie? I was looking back through my super-sprite-multiplexor demos and I realized that I never shared the latest revision of the space shooter demo. So here it is: spcinvdr.bin It handles 12 sprites (two are used for the player) plus 2 missiles flickered for 4 bullets. It also detects collisions, both missile-to-sprite and sprite-to-sprite. gac.v10.zipgac.v12.zipgac.v121.1.zip EDIT: Attached source: gac.v10.zip I'm not actively working on this right now (and I haven't for about a year, judging by the date on this), but I welcome any brilliant improvements. Writing a Raiden-style shooter* for the 2600 is one of my dream projects. *I.e., free-moving player, lots of bullets, lots of enemies, powerups.

HERE'S SOMETHING I've been working on...can't decide if I like it or not. r1k.bin Screenshot. Background color is different in screenshot. EDIT: New version attached. Has 24 sprites instead of the 16 previously. Also added more boundary checking and changed the movement routine. r1k.bin New screenshot. For some reason Stella hates this binary...??? Runs fine in z26 at a (95%) constant 262 scanlines, so I don't know what's up. I think it has something to do with the RIOT timer.EDIT II: New version attached, that works with Stella. Will eventually crash. Still 24 sprites (I think that's the limit of RAM) but some are different now. r1k.bin And screenshot:

...AS LONG as no bugs crop up. GoFishExtended20070221.bin Changes: -modified title screen -changed eel colors to be more visible Issues: -Eel flashing doesn't show very well when eels are in the very top row. Oh well. Unless any bugs show up, this is done.

AFTER ALL MY WHINING earlier, it ended up not being too difficult after all: GoFishExtended20070220.bin Changes: -six digit scoring -single, six-digit high score -high score is saved to AVox EEPROM at a different location than the regular Go Fish! high scores -added (previously PAL-only) fish color changes: fish are darker at bottom and lighter at the top. Thomas' suggestion; this helps the fish be more visible - he suggested it too late for the NTSC version Issues: -Eels are practically invisible (oops!) when they aren't flashing, especially on real hardware -Should I add some kind of indicator to the title screen? [EDIT: Forgot to mention - playtesting of this would be very appreciated! Especially looking at the fish colors, if they look good, and also general bug checking. I had to use a little more RAM and I'm slightly worried about the stack overwriting RAM, though I don't think it is ever a problem.] As for how this will be distributed - well, I dunno. I do not want a general release of this, since the changes will only affect a very minor subset of players (namely, those, unlike myself, who can max the score at 9,999) and I don't want to be seen as trying to squeeze $ from collectors who feel compelled to buy one of everything. So, I am considering offering this on a cartridge for a reduced (i.e., royalties-free) price (possibly with a very slightly modified label) to anyone who can verify, with a picture, that they have maxed the score on a regular Go Fish! cart. Thoughts? Realistically, the only copies I will likely sell will be those that were specifically requested in the first place, but I figured since I did the work I might as well make an open offer.

SO AFTER A LONGISH hiatus from 2600 coding I've begun to dive back in. This coincides with finishing the first new (to me) Zelda game I've played in about 4 years. Complete coincidence. So, a few days ago I got some of the rust off by writing a buzzer program. I'll probably get back to that and add some sounds a tweak up the controls a little for Murph74, but last night I returned to Go Fish! And boy has it been a while. I spent about two hours last night trying to, essentially, hack a six-digit score into the darn thing. Why, you ask? Well - to my surprise, and pleasure*, a few people are good enough at Go Fish! to max the score. A little while later, that same person contacted me with a request: He really enjoyed the game, but wanted a further challenge. He wanted to know, was there any way to add another digit to the score (making the max 99,999) or to make the score roll back to zero after surpassing 9,999. I responded, "Sure, but you'll have to wait until the new year" (this was in Nov/Dec last year) since I was in the middle of Christmas hustle and bustle as well as finishing up my part of Toyshop Trouble. Now, making those changes to Go Fish! requires overcoming some technical problems: 1. The reason the score maxes in the first place is because the high scores are saved to the AVox; if the scores rolled that wouldn't work properly as the highest scores wouldn't necessarily occupy the top spot in the high score list. So the simplest solution, allowing the score to roll, would be less than optimal. 2. Obviously, all current 4-digit display routines would have to be rewritten to use 6-digit display routines. This includes the game-play screen and the title screen. 3. RAM. Is tight. A six-digit score would require an extra byte to store the score, plus an extra byte for each saved high score. Plus extra bytes for the extra pointers necessary for the six-digit display routine. 4. ROM. All these changes will likely require ROM, which is limited. 5. A bunch of routines will have to be updated to handle a six-digit score rather than a four-digit score. My goal was/is the following: increase the score to six digits and decrease the high-score table to a single (six-digit) entry, which is saved to a different part of the EEPROM block assigned to Go Fish!. I started doing this last night and...wasn't very successful. My coding style of two years ago was a little different (read: sloppier) than it is now, that plus the fact that it is two years old made it difficult to follow at times. Also, I quickly ran into ROM-space issues, which required a bunch of code/data rearranging/optimizing. All in all it was rather frustrating and I didn't really get anything to work right. By the time I finished I was ready to give up and just remove the AVox EEPROM routines and make the score roll (i.e., the easy solution), but after talking it over with Rebecca a little I think I may give it another chance before giving up entirely. So we'll see. I really want to do this, but I don't want it to turn into a 40-hour, 3-month project that saps my will to live. *Pleasure because I wasn't entirely sure how possible it was to max the score, so I'm glad to find out that it is possible to "beat" the game. Also pleasure for the more obvious reason: that someone liked the game enough to get that good at it. P.S. Here is the binary, and screenshots, of the Atari Buzzer. AtariBuzzer20070202.bin

A NEW YEAR! TIME TO MAKE plans! What...February already? Oh well, better late than never. Anyway, my plans for the year have come into focus only recently, so I thought I'd share. Major Projects: 1. Finish the Maids+Elevators game. 2. Port Squish 'Em to the 2600. Minor Projects: 1. Modify Go Fish! to allow higher scores (or allow the score to "roll") for a few folks that can actually max it out. 2. Mystery project that I'm working on with Nathan Strum. Details: Squish 'Em is going to be a Christmas present for my two boys, or maybe just for my oldest. So for the year as a whole this is the top priority. However, I'd really like to finish the M+E game so I'm going to work on that first - but I'm going to start working seriously on Squish 'Em in mid- or late-spring, so if M+E isn't done by then it will have to wait. However, before all that I'm going to make the modifications to Go Fish! This should be a relatively easy project - - I just need to get off my duff and get busy. The mystery project only exists in some mockups that Nathan has done (and is working on) and, on my end, on paper. He will have more time in the summer to work on this and I'll probably fit some time in then as well to whip up some demos. But this project, assuming it happens , is really a 2008 project. I.e., it is as tentative as it is possible to be. So that's that. I'd still like to write something for the GBA and the A800, but I just don't see that happening.

SO. I had plans for 2006: Oh-fer! I rock! In more detail: I came up with an idea and did maybe 15-25% of the programming. Got a little bogged down with the SC's/2600's limitations and didn't really have time last summer for much programming. I am thinking about picking this up again, but other projects have a higher priority. Started a bunch of stuff but didn't really come close to finishing anything. Made a big push to get the Elevators+Maid game done by Christmas but my involvement with Toyshop Trouble pretty much sunk that idea. I did contribute to a couple games, though. Yeah. I still would like to develop something for the 800, but other than a lot of reading I didn't get anywhere with this. Again, my busy summer killed all chances of submitting something to the competition. Maybe in 2007! So...what the hell did I do? I'll quickly review partly to motivate me, partly to cheer myself up. Contributed to several homebrews. Did the most work for BlipFootball; wrote the kernel and music driver. Tommy did the music for that, by the way. Did the music for Four-Play; composed the tune (with help from Tommy) and wrote the driver for it. With Tommy, again, wrote music and driver for RPS homebrew. The music may not make it into the game and the game wasn't released, though. Also helped with Toyshop Trouble. Got maybe 50% done with the Elevators+Maid game. Wrote many demos: Metroid is probably my favorite, also several different music drivers, tried to develop an intelliflicker routine that used both sprites - which kinda worked, and a four-player shooter (using paddles). Started the NES High Score Club. Wasn't a lost year for sure, but didn't quite go the way I hoped a year ago. Shocking, I know.

OK, NOT THAT DIFFERENT. But I did free up seven bytes of RAM, which is pretty huge. I finally wrapped my mind around supercat's fractional-position replacement - it was a little tricky because, unlike his example (16 speeds between 0 and 2 lines per frame) I wanted 64 speeds between 1/2 and 2 lines per frame (LPF). I ended up going with 64 speeds between 1/2 and 2 1/2 LPF, using a counter which goes from 0 to 32 and a 128-byte table (i.e., thirty-two 32-bit entries). I realized about halfway through coding this that, since my counter tops out at a power of two, I could just use the frame counter (which is a byte of RAM that is decremented every frame, going from 255-0 continuously). So I ended up saving all seven bytes which were being used for fractional elevator position. So no apparent changes except that all the elevators except the slowest are a little bit faster: ElevRep20061109.bin

BACK TO STRIPED elevators, based on feedback. I thought this would give me lots of RAM back - but it wasn't to be. I really wanted to add stairs on either side of the screen, and I just couldn't fit it into the old kernel. So I've gone back (again) to the RAM-hungry kernel that supercat suggested. And so now RAM is an issue. Probably can make it work, though. So new binary: still isn't playable - I was too tired last night to add the code back in that moves you up a floor and increases your score - but the status stuff is back at the bottom of the screen: ElevRep20061105.bin Thoughts on the stairs? Other changes: I fixed the maid sprite and increased the height of the elevators. I also completely revamped the routine that moves the elevators. There are 64 elevator speeds; the one on the left is the slowest and the one on the right is the fastest. I wrote special-case kernels for the top and bottom of the screen, so the kernel needs 65 bytes of RAM for the elevators, which isn't so bad - however, I also need 3 bytes for each elevator (Y position, fractional Y position, and velocity/direction); 21 bytes total. Features requiring RAM that I want to add: -AtariVox support -MemCard support and high score support -a second player (might be able to overlay other RAM for this) -music -sound effects I probably need between 10 and 12 free bytes to add all that; right now I have 3 free bytes. So we'll see what I can do.