e1will

Lots of things: - You can use it to set the V flag, since there's no SEV instruction analogous to CLV - You can use it to skip bytes (see this page for a helpful summary on how) - And most importantly, like cd-w says, you can test bit 7 or bit 6 of a memory location while keeping the A, X, and Y registers intact. Its usefulness may not be immediately obvious from its description, but I've found it to be extremely helpful in the coding I've done so far. --Will

Seems like there are probably still some opportunities for combining RAM bytes, at the expense of some outside-the-kernel cycles to manipulate them. For example, all 5 gate states could probably be combined into two bytes, freeing up 3: BYTE 1 bit 7 = yellow gate open bit 6 = white gate open bit 5 = black gate open bit 4 = green gate open bit 3 = flashing gate open bits 0-2 = which gate is currently being opened or closed (000 = none, 001 = yellow... 101 = flashing) BYTE 2 bits 0-2 = state for currently opening/closing gate (8 positions) bits 3-7 = free You could then use bits 3-7 of the second byte to store CarriedObj, since there are (I think) less than 32 objects that can be carried. Or maybe you've made some of these optimizations already... I'm just going off the Adventure(asymmetrical).asm. --Will

A compare, or a load, or a variety of other things. For example: LDA #55 ; sets the Z flag to 0, since 55 is not zero LDY #0 ; sets the Z flag to 1 LDX #33 ; sets the Z flag to 0 CPX #33 ; sets the Z flag to 1, since X=33 CPY #33 ; sets the Z flag to 0, since Y is not 33 BEQ Someplace ; does not branch, since the Z flag is 0 (as set by the CPY immediately above.) Hope this helps. --Will

I really like the idea of Indenture on the 2600... Sounds like the idea of a using a 3-line kernel for it was a non-starter, so I took the liberty of trying a 2-line kernel that might work without having to interlace. It's actually a hybrid 4-line/2-line kernel: P1/P0/ball updates each 2 lines + PF updates each 4 lines (of course, 6 PF writes each line since it's asymmetrical.) The pros are it works, and there are actually 20+ cycles free each loop for additional logic. And it's not TOO much of a RAM hog (doesn't require a PF index, for one thing.) The cons are it requires a page per graphic image, which is a huge waste of ROM. On the upside, those 20+ cycles might be used to re-work it so it doesn't have to do that. Thoughts? asymtest.zip

Another screenshot: this shows the maximum number of extra lives you can earn (15). Get to 15 and instead of green 1UP balloons, you get yellow balloons worth 5000 points each (very handy for racking up points.) --Will

Hello again! I'd like to thank everyone for your kind words and helpful suggestions. I've been able to incorporate several of the suggestions into version 0.03. I really appreciate the feedback! v0.03 has several significant improvements, including: - An arcade-style "attract mode" where the computer controls the robot to demonstrate how the game is played. - A pause feature: use the TV Type switch to pause the game (B&W position) or unpause it (Color position) I also incorporated 7800 detection code (thanks to Nukey Shay for posting how to do this) to handle the 7800 Pause button. - Most importantly, you can now win the game! All the levels are in place, as are all 25 eggs. If you somehow manage to complete Level 12, the egg count resets and the ducks speed up. - The scanline counts should be (mostly) stable now. Thanks to Nukey for pointing out one case where they weren't... a little digging let me to discover that there were a lot of other places too. I've had to do a major overhaul of the code to get rid of the timing problems, but it should now be a constant 262 scanlines for NTSC and 312 for PAL. (There are three exceptions I know of where it does roll: pressing Reset from the Select screen, pressing Select from within the game, and a serious jitter if you pick up a bonus item while carrying both the zapper and an egg. I know why it's doing this, but fixing it is going to be a major task, and may take a while. In any case the first two cases (Reset & Select) may not be visible on an emulator, and the third does not occur in the PAL build. If you see any other jitters or rolls in the game, please let me know.) - The "arcade" zone, behind the pink door, has some new (yet familiar) characters to attack you. - The "warp of death" is now present. You can sacrifice your current life to advance to the next level if you can't figure out a way to finish it. - I've added some levels where the river actually helps you rather than just sweeps you to your death. You'll have to jump in at least one river to get an egg, and doing so will take you someplace useful. Don't just hop into rivers indiscriminately, though, they are still (mostly) deadly! - You no longer have to re-collect eggs you collected in the previous level. Each level from 1-11 now only requires you to collect 2 eggs to advance to the next level. You need to collect 3 eggs on Level 12, and 5 on Level 13 and higher. - The magnet behavior is now different: if you're carrying objects, the magnet ignores them and attracts "uncarried" objects. This should make the magnet much more useful. I'm really excited about the new version... I hope you enjoy it! Let me know what you think. --Will

Yep, the main kernel in the game I'm working on takes exactly 228 cycles, and the WSYNC was the first thing that got dropped once I started needing to squeeze more code into it. Granted, you have to be much more careful about branches that cross page boundaries (and branches in general, since they have to "meet up" in both the same point in code AND the same elapsed cycles without WSYNC) and any indexed data (without a WSYNC you'll usually be able to tell really quickly if something's unexpectedly crossing a page boundary since the screen will be completely out of whack from that line down, especially if you use HMOVEs.) But it definitely can be done. --Will

The thing the magnet is most attracted to is the egg, followed by the balloon, so if you're holding those things it won't attract anything else in the room. I may change that though, now that you mention it... it should be easy enough to code it so the magnet only attracts things you're not already carrying, and more intuitive too. There are a few doors that will take you back to the beginning, or to various other places that you might not expect. There are a couple of really nasty doors in a later level, but I'll leave those for you to discover (they're not visible in v0.02). I'm putting the finishing touches on v0.03 now; I hope to post that by Monday. It's got more levels, along with an arcade-style attract mode (demo mode that shows you how to play) and a pause feature. --Will

Or maybe even being able to use the river to your advantage. But very risky! I like this idea. I think I'll include a level where you have to hop in a river to get to a certain egg. It could sweep you into the egg, then into an exit door if you time it right. --Will

I agree, having to playing through the previous level is redundant; I've changed that in v0.03 (which will be posted once I work out some bugs in the attract mode.) You need either the balloon or super-speed (from picking up the pink balloon) to complete the level you mention. Since you'll no longer have to get through the previous levels, you should be more likely to have super-speed by the time you get to that level in the next build. At any rate, I will be putting more pink balloons around to pick up, probably in v0.04. I know there are a couple of rooms with borders that are too thin, that let you peek through to the next room without actually being able to get in. That'll get fixed too. The golden egg has a better location in v0.03. Where it is now is just an artifact of it not having a "location" at all (e.g. it's in room 0, horizontal location 0, vertical location 0). The flashlight will be required in later levels, but you can use it on earlier levels too (e.g. the room with the black door, and the rooms behind the black door.) As for the shield, pick it up and run into a tank for a good demonstration of what it does. Hope this helps! --Will

Ah, you have stumbled on the 'debug key'! The right joystick fire button does what you describe (switches to the next room), but the left joystick button should throw the zapper. Perhaps you have your fire buttons mapped to the opposite joysticks? --Will

Well, if weird random mash-ups aren't your thing, you probably won't like these screens either. The vast majority of the screens are entirely new, but I do slip in a few homages to my favorite games behind the pink door. Everything outside the pink door is (mostly) homage-free. --Will

Thanks! Yep, the text is done using the standard 6-digit score logic. There isn't any "text" logic per se, it's all just 8-bit-wide sprites put next to each other. --Will

Hmm... which emulator/version are you using? I'm seeing 262 scanlines for all of them in Stella 2.8.4. Z26 version 2.13 (I dunno if it appears in more-recent versions). The scanline difference does not show up immediately. The way that I'd seen it was to go to the tank screen to the left, pick up the balloon, and get killed by the tank. The player returns to the lives screen with a high probability that the scanline count will be short by 1. When this difference is active, it appears to give a slight jitter when moving between other screens as well. Running out of time in overscan? Ah, I see it now! How weird. It must be the values I'm stuffing into TIM64T for the vsyncs... I'd been fiddling with them to get the scanline count right for PAL. I'll have to take a closer look. Thanks! --Will

Ah, I need to clarify in the manual that only the blue ones give you the ability to coast over the walls... other-colored balloons will indeed appear in earlier levels, but they do different things. --Will

There are some on the manual page, but here's another. I like this one because it demonstrates one of the things I was trying to do: get three interesting-looking sprites on the same line at one time (robot, tank, duck) without flickering. The tank is drawn using the ball sprite, which is resized and moved every third scanline. The poison arrows are done the same way. Here's another example, with the robot, a chomper and a bonus item (key) all on the same scanline. This is from a room behind the pink door... there are a few more rooms that should look familiar behind that door. --Will

Hmm... which emulator/version are you using? I'm seeing 262 scanlines for all of them in Stella 2.8.4. --Will

2010-09-02 update: Duck Attack! is now complete: you can now find it in the Atari Age store. Hello everyone! First off I want to thank everyone on these forums (especially Nukey Shay, batari and supercat) for being so helpful whenever I've had questions. And I'd especially like to thank stephena for the work he's put into Stella; it's really a phenomenal emulator and a simply indispensable development tool. I've been programming for many years, and I finally decided to take the plunge and attempt a homebrew game for the 2600, written in assembly from scratch. It's far enough along that I think it's ready to show people... I'd love to get some feedback on it, good or bad. The game is called Duck Attack! and its premise is simple: collect radioactive duck eggs for points while avoiding giant, mutant, fire-breathing ducks. I've written the first draft of a manual for it here, with some screenshots: http://willnicholes.com/duck The game is about 60% done: 81 of the 135 planned rooms are in place, and you can get as far as Level 5. A few of the features listed in the manual aren't done yet (e.g. the pause feature) and I've still got a lot more features to put in (the big one is 'demo mode') but the basics are in place and (I think) working pretty well. It's been a lot of hard work, but it's been pretty fun too. I hope you like it. --Will EDIT: Adding some screenshots. The latest binaries are here.

Looks nice! Another option would be to switch to a 3-line kernel; the playfield could be solid, and identical to the original if you change the frequency of playfield updates, although the player sprites would be stretched vertically. --Will

IMO 7 would be neat but 4 is probably sufficient if the ability to toggle each one on and off individually remains. (And is available from 'pause' mode.) Unrelated, is there a way to "unfreeze" the CPU after it runs over a "KIL" opcode (e.g. $02)? 'reset' sends the program counter back to where the reset vector points but I can't figure out if there's a command to "really" reset the CPU and get the PC moving forward again without exiting and reloading the ROM. --Will

I just ran into this same issue. I had some code at $FEF6 that I was trying to jump to from $FF42, and kaboom! It switched banks from #5 to #2. I sure wasn't expecting that. I'm glad somebody posted about this so I'd know what's going on. I presume this means that for F4 and similar bankswitching schemes, there's a certain chunk of ROM space in each bank where it's unsafe to put branching code, say around FF00-FF80? --Will

I put in a trapwrite for $01F4, and that caught the writes to $F4 that were from the stack. So this might just be a case of the user (i.e. me, in this case) needing to trap for both $nn and $01nn when trying to catch modification of those zero-page RAM locations. But I agree, it would be a handy option to trap all writes that end up changing zero page memory, whether it's the stack or some errant code that's trying to store to some weird address that ends up mirroring to $80-$FF. --Will

Sure, no problem. I'm attaching the version of the bin (in-progress homebrew) where I noticed this. Load the bin, then press reset. Enter the door on the left. A new screen will appear: the player will be carrying two objects, a lightning bolt and a flashlight. At this point you can see in the debugger that memory location $F4 (which holds a pointer to what object(s) the player is carrying) contains $E3. Put a trapwrite for $F4. Toggle out of the debugger and press the fire button to drop the two objects. Dropping the objects resets the "carrying" pointer at $F4 to zero, and triggers the trapwrite. Toggle back out of the debugger, and then press Select. The trapwrite will again trigger as the STA $00,X in the "clear all variables" logic is called. It's essentially replacing the zero in $F4 with another zero. Toggle back out of the debugger. Toggle back in, and you'll see $F4 now contains $B5, even though the trapwrite was never triggered for that change. --Will DUCKNTSC.BIN

I suppose I wasn't so much concerned with Stella telling me why the memory modification occurred (since I could figure that out based on what the code is doing) as long as it would break when the modification occurred for addresses I'd set up watches/trapwrites for, which it wasn't doing. I can get around the problem by putting in a "breakif { *$F4 != 0 }" since I know the value should be zero unless it gets tromped by the stack or by some other bug elsewhere in the code, but it just seemed odd that the watch and trapwrite diddn't catch the modification. --Will

Interesting, I hadn't considered that. So that raises the question that if I had a bit of code that writes to $0180 (for example), would that change the contents of $0080 but not trigger a trapwrite or condition on $80? --Will