e1will

Unfortunately you can't do that without a code change... Everything but the hot dog and the chef are either missile or ball sprites, so they take whatever color the hot dog, chef and playfield take. If you wanted them different colors you'd need to rewrite the kernel. --Will

A somewhat-unrelated Harmony question (I apologize if this has been already answered elsewhere): With the 32k F4SC bankswitching examples I've seen, the extra RAM bytes are padded with $FF, which I assume is because the traditional hardware used volatile memory for that. Is there any reason a 32k F4SC game couldn't be created to run on Harmony that was pre-loaded with game code or graphics (rather than $FF padding bytes) in that 128 bytes of RAM? And if that's feasible, would it be possible to extend that scheme to a 128k flash so that it contains 64k of code in the RAM portion, which could then modify itself? For example, addresses $F000-$F7FF in each of the 32 4k banks are the RAM "read" addresses preloaded with game code, and $F800-$FFFF are write addresses which the code would use to modify itself... assuming the bankswitching triggers were handled by a zero-page RAM write (e.g. LDA #desired_bank STA $3F). --Will

Are there any thoughts/plans for doing a version of the Harmony cart with 64k flash memory instead of 32k? I know 32k is sufficient for practically all the games that now exist, but since some of the recent homebrews have been maxing that out I wonder how feasible it would be to stretch the maximum supported ROM size, if only in a deluxe or limited edition. --Will

Here's a new idea I had for the death animation. Thoughts? --Will

Something like one of these? I tried a few different animations (well, just color changes) but I'm not sure which of these I like. What do you think? --Will

Hello all, New version attached: v0.15. The biggest change in this version is that it is MUCH easier. Specifically: * The ducks appear more gradually: only 1 duck in Level 1, 2 ducks in Level 2, etc. * The recharging station is now available starting in Level 1. * The blue balloon is now available starting in Level 2. * The game no longer speeds up both the ducks and projectiles (fireballs, tanks, etc.) on Level 13; now the projectiles speed up on Level 28 but the ducks do not. To compensate I've changed the right difficulty switch to control the speed of the ducks: Set to B for normal-speed ducks, set to A for fast ducks. This difficulty switch previously controlled whether you could successfully struggle against the current in a river. The "yes, you can struggle" setting is now permanently on. I've also added an idle/screensaver mode. If you don't move the joystick for about 8 minutes, the screen will turn off. To turn it back on just move the joystick. I've also implemented Nostalgic's suggestion to pause after losing a life before the game returns you to the score room. Now when you lose a life, the screen will stay up for about a second and a half before switching to the score room. Enjoy! Please keep the comments and suggestions coming! --Will

This looks pretty neat. I especially like the sprite graphics. Good work! I look forward to seeing more of this as it develops. (I do agree with cd-w and the others about the death-by-falling-off-the-screen, though.) --Will

Quite possibly. Maybe I'll call it Dragon Attack! --Will

Right now it's just left or right. Would adding up and down be a useful feature? I think so... quite often there's a duck above or below me that I'd like to zap, and can't. OK, I wasn't sure if I could find enough spare ROM bytes to pull this off, but somehow I did. Version v0.14 attached: the zapper can now be thrown up (there's probably a better way to phrase that) or down. --Will

You could make the different shapes different colors! (Just kidding. I mean, you could, but that would definitely be an ASM project. And even then, it would be a pain to code.) Regarding the score, I'm not 100% sure you couldn't do that in bB. If putting them side by side isn't doable, you could always do something like this: P1SCORE P2SCORE P1LINES P2LINES I don't know enough about how bB works to say for sure, but one of the bB experts might be able to comment. I'd offer to code some ASM for it, but I've got too much on my plate right now as it is, unfortunately. --Will

New version, v0.13, attached. Just some minor tweaks in this version: 1. Per Nostalgic's request, I have made it possible to escape the "wide" river room in Level 1. There is now a door in that room that you can use to exit if you get stuck there (see screenshot). 2. Per Nostalgic's request (and a poll which seems to confirm this would be a popular change), I have removed the light gray bars from the top and bottom of rooms. 3. Per Nathan Strum's comment that the zapper was getting stuck in walls, I have moved the location of the magnet so that it now appears starting in Level 2. The magnet can fish just about anything out of walls. Keep the feedback coming! Thanks, --Will

Right now it's just left or right. Would adding up and down be a useful feature? Yes. Stay tuned... --Will

Same here... I never had a copy back in the day (and none of my friends did either), so the first time I played it was in an emulator in the 90s. It's super-addicting. --Will

You know when, in Adventure, you're eaten by a dragon, then the bat picks up the dragon with you in it, and takes you on a tour of the kingdom? Back in the early '80s, I thought that was the coolest thing in the world. The only problem was, while you could sometimes pick up the bat and move it around, it was difficult to really control where to go, especially at the edge of the screen. I thought the perfect addition to the game would be an object you could pick up that would let you float above the walls and explore the kingdom. So my first try at a hack, back in 2003 or so, was to add a hot-air balloon to the game. If you found the hot-air-balloon and pick it up, you could float above the walls. While I was at it, I tweaked a couple of the room layouts and added a room in the white castle (it always bugged me that there was an "exit" in there that didn't lead anywhere.) Now, this was back before I figured out how to actually assemble, so the changes I made were extremely tedious: instead of just disassembling, adding some code and reassembling it, I was actually using a hex editor to hack in the instructions using machine language (e.g. $4C $7E $F6 to jump to a patched-in subroutine). So even though I came up with some more ideas after that (like having the dragons breathe fire at you; adding a shield the player could use to defend against the fire, adding a torch to see better in the catacombs), the idea of hacking in all those instructions, byte by byte, was so daunting I just shelved the idea. I did submit the hot-air balloon hack here a few years ago, but I made a fairly dumb rookie mistake in making the hot-air balloon so darn hard to find that it wasn't obvious to a casual player that it was even in there. So tonight I'm finally fixing that mistake. Attached is the new-and-improved Adventure hack, with a much easier-to-find hot-air balloon. Enjoy. (On a related note, a few months ago, I figured out how to compile assembly, and wrote a whole new game to make use of the fire-breathing, shield and torch (flashlight now) ideas. Except they're fire-breathing ducks, instead of fire-breathing dragons. If you like this hack, you might like that game too.) --Will Adv28B.bin

Hello everyone! I wanted to get some feedback on a couple of aesthetic issues, and was also curious how far you've gotten in Duck Attack! if you've played it. Here are the pictures the poll questions refer to. --Will

I meant to reply to this earlier... Thank you for that tip, I will give that a try. My development computer doesn't have OpenGL, unfortunately, so I'll have to find one that does. --Will

Thanks. The fruit/key/pill position does change between zones. Right now I'm doing all the repositioning in the 2-line gap between fruits. The problem with firing RESP0 midline is that in about half the cases it's fruits + something else (keys, power pills, super pills), and I don't think there's enough time to both switch graphics and reposition. The super-pill line, for example, takes 72 cycles to do this: 1. Load fruit graphic/color into P0 2. Load pill graphic/color into P1 3. Load pill graphic/color into P0 (now that the P0 fruit has been written) 4. Set left vertical door color (on or off) in PF 4. Set right vertical door color (on or off) in PF 5. Restore normal maze color in PF 6. Load fruit graphic/color into P1 7. Increment/loop to step 1 Squeezing anything else in there will be tricky. I may have to resign myself to making this an emulator-only game if non-interlaced 30Hz won't look decent on real hardware. Finding enough cycles to interlace might be beyond my programming capabilities. :/ --Will

Hello everyone! Here's the latest version: v0.12. This version has another feature for SaveKey and AtariVox users: a high score table. Now, whenever you finish a game, your score is automatically added to the high score table (if it's good enough, of course) and saved to the SaveKey or AtariVox. The high score screen appears after a game (once the "game over" screen disappears). You can clear the high scores by holding the joystick "up" and pressing Reset while the high score screen is being displayed. When a game is not being played, the program will loop through Title Screen > Demo > Game Over screen (last game's score and level reached) > High Score Screen > Title Screen. If you don't have a SaveKey or AtariVox, the High Score Screen will be skipped. Another SaveKey-related change: the "save game state" feature is now invoked when you press the fire button in the credits room (previously it was the egg shelf room). Similarly, to load a saved game, press "reset" in the credits room. If the save or load is successful, you will be moved to the score room, if unsuccessful you will be moved to the egg shelf room. In addition, all the game/score save/load screen rolls should be fixed: there shouldn't be a frame in the game that's not a constant 262 or 312 scanlines. Please let me know if you see otherwise. I have a couple more tweaks and minor bug fixes to make, but that's probably it as far as major features are concerned. I have almost completely filled all 8 banks of the 32k, with just a handful of bytes free, and the remaining tweaks and fixes will probably use up the rest. Enjoy! Let me know if you notice any bugs or have any other questions/comments. Thanks, --Will

I thought I'd make a feature request... When Stella encounters an unknown ROM, I believe it performs some heuristics to determine the bank-switching method used. Could it also perform some heuristics to determine what type of controller(s) should be used? For example, the presence of LDA/LDY/LDX INPT2 would suggest paddles, the presence of STA SWCHA would suggest a SaveKey, etc. Ideally there could be a configuration option to turn off the heuristics and just assume joystick as it does now. Thanks, --Will

Hmm... would that even be possible with Super Pac-Man? I'm trying to think of how to reposition (for example) the P0 sprite from the arbitrary Blinky location to the fruit location and back within 2 lines. Are there any examples of games that do something similar? If so I can look through the debugger and see how they do it. Unfortunately I don't have a Harmony cart yet... it's on my wishlist, though. --Will

Thanks for all the feedback! That's a good suggestion about the collision logic... I'll add that info to the manual. I'll also make a note in there that when the robot's antenna and boots are black, that means you're in a safe room, when you can rest without fear of any enemies coming along. (The actual reason they're black is so that I can use an all-black missile sprite on the right side of the screen to make those rooms symmetrical.) I haven't named them, but they do have different personalities. Aside from having different vertical and horizontal speeds, they actually have different AI logic, although it's hard to notice in the game, since they just seem to come at you. I may add something about their personalities in the manual now that you mention it. Yep, they're stacked like that precisely to avoid adding flicker. Good suggestion! I'm a big fan of fanciful explanations for technical limitations. Yeah, I've gotten stuck there myself a few times. On the other hand, avoiding getting trapped is part of the challenge of the game... maybe I'll just stick a duck in there. I'll have to give that some thought. Good suggestion... I may get rid of the light gray walls... they were originally a coding accident that I happened to like the look of, so I kept them, but I may drop them if they're confusing. Yep, that's by design... I wanted to have it so when the robot held items, it extended its reach. Similarly if you have the zapper and something else, it will let you touch the outlet from a greater distance (at less risk of getting shocked.) Good observation! Yep, that's because the object display logic cycles the player sprites as robot/snake, robot/door, door/snake. I may reverse that so that it's the snake that wiggles and not the door. I had originally designed a complicated "death animation" where the duck ate and swallowed the robot, but thought that it would irritate the player having to wait for it, so I dropped it. I know in (for example) arcade Donkey Kong, it is extremely frustrating for me whenever I lose a life because it won't let me jump back in there immediately. Interesting idea... unfortunately I probably don't have enough ROM left to squeeze that in. Thanks again for your feedback, you've given me a lot to consider! --Will

Is it rolling, or just flickering? If turning on phosphor mode makes it stop, it's probably the CPU not having enough cycles to update every frame. --Will

Thanks for testing it out. My plan was to turn off PF0-2 in Frame 1 for the rows where the ball was enabled, and to possibly increase the luminance of those rows in Frame 2 to compensate somewhat (if I could find the cycles.) That would of course increase the flicker on those rows, but I wanted to get an idea if the "best-case" flicker was good enough before coding that, since there wouldn't be much point in coding it if even the best-case was unacceptable. That looks very handy! I'll give that a try if the consensus is to go forward. As best I can tell, the only way to further reduce flicker would be to run the Frame 1 logic on those rows where there isn't either a ghost or Pac-Man, and possibly tamp down the luminance on the fruits and doors that are being drawn on both frames. I wonder if that would be an improvement, or if it would be a more distracting visual artifact than a consistent 30Hz flicker on those elements? --Will

OK, here's (I hope) an improved version. I've rewritten the kernel so that the blue maze does not flicker at all. The doors (and everything else) flicker at 30Hz. I've included screenshots of the 2 alternating frames. Is this better? Worse? Better but still too flickery? --Will SUPERPAC.BIN

Thanks! Yes, this was very much inspired by Adventure... it's long been my favorite 2600 game and I used to play it so often I'd actually dream about it. --Will