Fort Apocalypse

Be careful if you do any gotos from within a subroutine (that you gosub'd to) that you call "pop" as many times as the subroutine is deep before calling goto from within a subroutine. Otherwise each time you do that puts the game within a less and less stable state - first shown by degradation of the pflives and then finally by just locking up (after a few times). Also, I've noticed (see the ufo traffic game I wrote) that when using the lives icons, even without the goto from within subroutine without pop stuff, it doesn't act correctly. this may be because of the bB kernel I'm using (the latest development kernel posted to the bB bugs thread by Fred Quimby (batari) having some issue with lives that isn't in the "normal" last formally released version of bB. However, in other ways (like bgnd and pf row colors) the newer kernel is better. I haven't tested the lives thing with the older kernel tho.

Be careful if you do any gotos from within a subroutine (that you gosub'd to) that you call "pop" as many times as the subroutine is deep before calling goto from within a subroutine. Otherwise each time you do that puts the game within a less and less stable state - first shown by degradation of the pflives and then finally by just locking up (after a few times).

You have to set COLUP0 and COLUP1 before every drawscreen. See "Ephemeral Variables and Registers (short-lived)" in http://www.randomterrain.com/atari-2600-me....html#ephvarreg I think that might help you.

Hmm... I'm not getting any flickering. You may want to try the latest bB kernel from the bB bugs thread in the bB forum. It plays great! You may want to make it 2-player optional and use the player scores minikernel. (search for that thread and you'll find it- works great.) Note: there is one bug, which is when the ball gets stuck going back and forth in basically a straight line at the very bottom of the screen. I think it is either validly going straight across or is getting stuck somehow in playfield collision stuff. It is probably fairly hard to reproduce.

Yes, basically it doesn't set the paddle variable until you call drawscreen, so if you change the currentpaddle and expect it to read the paddle value into "paddle" variable, you have to call drawscreen before the paddle variable will be set. In the Ultimate Indy 500 game (based on 4 paddles) I 1/2 finished (being gracious to myself by saying 1/2 finished ) I had four drawscreens - one after each currentpaddle set. If you have only one paddle, you need only one drawscreen, but you should set currentpaddle before you do the drawscreen, and paddle will be read during that drawscreen. I don't know if you only have a one player game whether you'd need to keep setting currentpaddle, though. But I'm assuming for 2 players, you'll need to set currentpaddle then drawscreen then do something based on paddle value that was read, then set currentpaddle then drawscreen then do something based on paddle value that was read.

In addition, you must call Stella with argument: -bc paddles $(FilePath).bin (that is the exact copied and pasted value I have for the "argument" field value in the paddles user tool I created in crimson editor)

there is a trick to it. you have to set currentpaddle then call drawscreen. drawscreen will then set the paddle variable.

Thanks, Michael! I also messed up by overgeneralizing and using bad grammar and saying I should have added a second case for goto. goto seems also to be the only good choice for one way trips like: if nomonster=1 then goto mylabel0 rem monster code ... mylabel0

If you aren't reusing code in an environment like the 2600 where space is at a premium, don't use gosub or goto blocks unless they are called in two places. If they are called in two places, then share the code. More info: See what Michael wrote in this thread about the amount of cycles that is taken up by gosubs. From what I gathered from that using gosub then return bank1 takes up the least amount of cycles (37). However, in terms of space, here is the breakdown (I don't know whether this is constant, but I've seen this in my testing). goto and goto = 6 bytes gosub and return = 4 bytes gosub and return thisbank = 4 bytes So if the goal is to take up the fewest amount of bytes but cycles don't matter much, gosub and return are best. But if the goal is to take up the fewest amount of bytes and cycles matter, use return thisbank (when calling in same bank) according to Michael's post, and see Michael's post in that thread for detail. In bB, goto mostly seems to only make sense when you need to break out of a block that you've gosub'd too (known as a "subroutine"), and when you use it there you must call pop as many times before the goto as the subroutine is deep, for example: mainloop ... gosub mylabel1 ... gosub mylabel1 ... goto mainloop mylabel1 ... if danger=1 then gosub mylabel2 ... return thisbank mylabel ... if died=1 then pop : pop : goto died ... return thisbank

label

Just posted in other thread, but posting here also in case anyone finds it useful as an Atari 2600 paint program. Warning: flashing colors. Click and drag to draw. Double-click to erase a dot. Stays red when it is waiting on double-click. Please feel free to extend and repost the full bas program and binary with your change. It's a collaborative paint program! doubleclick.bas doubleclick.bas.asm.txt doubleclick.bas.bin

obligatory screenshot

Attached is a sample drawing program which uses double-click. You click and drag to draw or double-click to erase a dot. I've also made the playfield stay red during the double-click check to make it obvious how long it is waiting on the double-click. I didn't look at previous source examples so I may not be doing things in the optimal way, but maybe it will help you. doubleclick.bas doubleclick.bas.asm.txt doubleclick.bas.bin

We had a discussion in the forum some months back and most of us decided that temp4-6 were almost always safe. temp3 is borderline and using temp1 and temp2 can be dicey since function calls involve those two more often (calls to pfread, etc.) I'm probably oversimplifying it and would really look forward to the full scoop on that (like these commands will use temp1/2 so you can't expect they'll be the same value that they were before the command after the command is called, etc. somewhere on http://www.randomterrain.com/atari-2600-me...c-commands.html ).

I only wish I visited it enough to pick up something. My guess for something that I could purchase outside of that, a garage/yard sale, or someone who was selling on ebay that didn't know it's worth, would be something like a famicon clone that would have a ton of games.

What is the best value TV plug-n-play game/game system? Number and quality of games counts, price counts, ability to withstand a little abuse helps.

I still like the demo. Awesome! Great job on the sprites and movement.

Yep, but see the OneStation thread. Looks like they have a high failure rate. I'd be interested if it worked reliably, and much more so if it let you easily load games on it. The thing I don't like about the VC is that there is no way to get homebrew games onto it yourself, right? You have to have a Wii and buy the games from Nintendo. That's nice, but I'd rather have something I could put my own homebrews and other games on. And I know - legal issues, etc. I like the idea of portability, but am more interested in a dedicated gaming console that I could load my own games onto. And I'm too cheap to spend more than $50 on it. It's interesting how many times people say this, and that no one outside of Asia has the balls and $$$ to follow through on such a project. The VC is convenient, but I think everyone would be surprised at the number of people that would by a dedicated retrogaming emulation console if you could load whatever games you wanted to on it.

The ticket to be a real winner would be a cheap (<$50), widely distributed (target/walmart), easy to use multi-system emulation game console. Yes, I know - legal issues, technical issues, blah, blah, blah. I think it is time for this to happen though. There is a limited time for people to get on that bandwagon and make it happen before no one really cares anymore.

See the code that Michael gave me in the later/latest version of Titan Diamonds. The only wierd thing is having to go into the asm generated by the compiler to get a number out of it when it doesn't compile, but other than that is relatively straightforward to use. (Thanks, Michael!)

Hmm. I must have misremembered that. Sorry!

I will change the name for all future versions. Thanks for the suggestion!

Tony, The trick is that you have to drawscreen before it will play. Note that there are two channels for sound, but you can switch back and forth for the tone/etc. of channel 0 and 1 to simulate more channels by setting the tone/etc. of both channels via AUDC0, AUDF0, AUDV0, AUDC1, AUDF1, AUDV1, then doing drawscreen, and then setting AUDC0, AUDF0, AUDV0, AUDC1, AUDF1, AUDV1 to something else and then again setting AUDC0, AUDF0, AUDV0, AUDC1, AUDF1, AUDV1 and doing drawscreen. This is similar to doing the same switching back and forth with sprites for each drawscreen - there is probably some limit to the number of simulated channels you could emulate via switching without it sounding too muddy, but I don't know what that limit is. My guess is that you could only simulate 4 without it sounding muddy. See more on sound at the page batari wrote that Random Terrain maintains here: http://www.randomterrain.com/atari-2600-me...c-commands.html Hope this helps, Gary

now with sound! ufotraffic1.15.bas ufotraffic1.15.bas.bin

Try this out. Missile looks like a missile - is slow and glowing. Seems to work well! ufotraffic1.9.bas ufotraffic1.9.bas.bin