bjbest60

After more than a year of being lost in the desert of space, I'm happy to report that the Space Cactus Canyon BBS is back, firmly planted on Mars and living on a Raspberry Pi 3B. You can telnet to it at spacecac.synchro.net (new address) or use this page as in the past--just click Connect to be whisked away. Perhaps unwisely, the Canyon had traveled in a vessel piloted by a laptop running Windows Vista. Who knew (besides everyone) that perhaps Vista was not the greatest OS ever? The laptop crashed, but this week I was able to salvage the files. I did a fresh install on a Raspberry Pi and transferred over as much previous content I could, which was almost all of it. So, the BBS is good as new, with even a few small additions, and it seems like a Raspberry Pi is the perfect device for this kind of project. Yes, and I was pleased to learn the Raspberry Pi install process on their wiki works exactly correctly. See you all in the Canyon!

Space Cactus Canyon relies heavily on procedural generation. Each canyon is generated based on a modified version of a random walk (the modification is that the walk can never move to the left; it can only go up, down, or right, and if I recall, right is weighted more heavily). The enemies are then placed according to the canyon to ensure that their placement is sufficiently fair to the player. Sometimes that means reducing the number of enemies that are the default (or, in the bonus screens, the number of available pickups). So in theory there is a nearly infinite number of canyons and enemy placements.

Yes. I plan on making a few carts and then I think the game will be available at 8-Bit Classics as well.

Mercy. Apparently it's been just over a year since an update. But I'm happy to say that attached to the top post is Beta 3, which I hope is the final .bin. Of course, I'm still looking for final testing / bug reports. Biggest change: Tombstones and Disc Donk are now one! The Select switch is the ruling switch here. Pressing Select at any point (in either game) will return you to the title screen, where you'll be able to cycle between the three games by pressing Select: Tombstones Electric, Tombstones Normal, and Disc Donk. Pressing Reset will start a new game in whatever mode you're in. Changes for Tombstones: The default mode is now Electric. (Touching the tombstones or the sides will kill you. In Normal, there's no effect.) The main sprites are now what were previously the alternate sprites, and vice versa. Various small tweaks. Changes for Disc Donk: Reduced the volume of the saucer. Made the saucer start randomly from either the left or right side. The saucer gets slightly higher with each level and each round. Various small tweaks. Overall, I feel the games are solid--good controls, no flickering or screen rolling, etc. But, as before, I'd appreciate any final input before I burn these onto carts. Thanks! I also just wanted to say that I love this idea and might explore it as a standalone game at some point.

It's the Bliss gallery at Carroll University, Waukesha, Wisconsin. The show doesn't open until the end of the month, but it's cool to see the game and TV in full operation. I powered it up on Tuesday, and I'll be back on Monday for a first review of things. I'm actually hoping some of the screen burn does occur over time, as the game's title promises. Should be an interesting experiment.

Well, the Atari is installed and the game is running! I wound up with a Vader. I think it looks pretty good in a gallery setting. Fingers crossed for a failure-free show!

Thanks for the info about how the table is set up. Yes, realigning / reconfiguring the storage and/or pointers would be ideal. But something like that is well beyond my asm / bB knowledge, though. I'd welcome anyone's advice / code! That being said, here's an updated example that can change ten lines (with no skipped lines) independently. It basically maximizes the span of the accessible memory map, starting with the 12th row of the playfield (so pf scrolling wouldn't work / make sense), and ending with temp7 and aux3. Can monkeying with temp7 have unintended consequences elsewhere? I'm not sure if it's used by bB somehow behind the scenes. I feel aux3 is fairly safe if you don't need to do anything beyond displaying a basic score, but I'm willing to be corrected there, too. The eleventh line points to stack1 in the memory map. I've tried to directly alter that variable, and no matter what I change it to, that final playfield line is always gray. I imagine it's unwise to try to change it at all, so I'm not sure there's anything that can be done there. Were I to use this code, I'd probably probably just zero out var40-var43 and not have an eleventh line. Code and binary are attached. It's kind of mesmerizing to look at. minimal_pfcolors_in_ram_test_2.bas minimal_pfcolors_in_ram_test_2.bas.bin

Unfortunately, that code doesn't work when I run it. I don't get a playfield at all. I tried something similar in asm last night and couldn't get it to work out. I tried again this morning with a minimal test. I started the colors with variable a for ease of use. I discovered a few things: set kernel_options pfcolors is necessary. The constant to subtract in the lda's should be 83, not 84. I have no idea why, other than I saw it in some variations of the assembly output. (In some it's 84, in others it's 83.) It is possible to control several lines of playfield colors independently. The pattern is: Line 1 of the playfield is a. Line 2 is b. Thereafter, each line is four letters after the previous one. So line 3 is f, line 4 is j, line 5 is n, etc. Line 9, which should be aux2 according to the memory map, doesn't work. I think this is due to using the pfcolors kernel option. But line 10 as aux6 does. I have no idea why the colors would be every four variables. Maybe it's related to the fact that each playfield line is four bytes long? I'd have no qualms about using the weird use-every-fourth-letter pattern, except you run out of letters before you can control each line. I can't work with line 9 and don't know where to try to control line 11. Code and binary are attached, and they show independently cycling lines. Is there some additional assembly code that could somehow load / redirect each pfcolor variable to something more sequential? Thanks! minimal_pfcolors_in_ram_test.bas.bin minimal_pfcolors_in_ram_test.bas

Hello all, I'm wondering if it's possible to change pfcolors (using that kernel option) via variables. I know it's been alluded to / discussed in various other posts, always with the claim that pfcolors needs to be defined with constants. Attached is an example that borrows / steals most of its code from others. Press fire to scroll and randomly create a sprite, using bogax's code in this thread. Each line of the sprite can change colors randomly, using SeaGtGruff's code here. Press Reset to cycle through random colors. I added a feature that takes the random sprite and translates it to playfield pixels. Press Select to render the sprite in the third "column" of pfpixels. Since I already have the variables set aside for the random colors of the sprite, I'd like to use those same variables to make the pfcolors the same as the sprite's colors. I see on the memory map that the pfcolortable pointer is at $F0, but I don't know how to manage that meaningfully, and the assembly code mentions a pfcolorlabel13, and I don't know what that is or what to do with it. My code and binary are attached. Are there any possibilities here? Thanks! world4.bas world4.bas.bin

Is the concern that it would become too hot / melt something over time? Or is it something else? I have a new-in-package off-brand power supply (Gemini) that's from 1987. But, as it notes on the back of the package, "It is recommended to unplug the adapter from wall outlet when not in use to prolong its life." If heat is the issue, do you think somehow affixing a heat sink would help? Thanks again.

Thanks, all, for the thoughts. I'd be willing to try a clone but I'd really like to keep the CRT. And going from the HDMI of a Retron 77 to RF seems a bit silly. Basically, I'd like the physical cart to be shown inside a functional system--any other recommendations for clones? If not, I roll the dice with a fresh-looking Jr. off of eBay. Thanks!

Hello all, I'm happy to share that my experimental game High Score Screen Burn Slow Burn will be exhibited as part of a gallery show this coming fall. The game isn't necessary a game as much as an experience where you watch a square randomly traverse a screen and occasionally pick up an object for some points. There are some hidden-ish uses for a joystick, but they're not necessary, and a joystick won't be included in the exhibit. I plan to display the game with a real 2600 and CRT TV. My question: what sorts of problems might I encounter if I turn on the game / TV and leave them on for six weeks or so? The game is meant to be "played" over a long stretch of time--something on the order of months rather than minutes--so I'd like to leave things run for as long as possible, and I'd also prefer to not have to go through the hassle of having everything turned on / off every day. I'd also really like to avoid emulation or a new clone console. Am I in danger of destroying the 2600? Is something likely to catch fire? Is some model more likely to be robust than the others? I'm willing to risk sacrificing a console, but I don't want to have to anticipate buying a new one off eBay every week, either. Destroying the TV is fine (especially screen burn, as the title implies) as long as it doesn't destroy anything else. I'd appreciate any advice anyone has about presenting a 2600 and TV in a museum-type setting with the intention of keeping the system and screen constantly on. Thanks!

Looking at this more closely, it think there are a lot of costs that are actually identical in the early part of the game--I didn't pay attention to my sorting. First purchase (120 seconds recovery time): Chopper 1 Second group of purchases (144 seconds): Ghost 1 Chopper 2 Third group of purchases (168 seconds): Ghost 2 Chopper 3 Fourth group of purchases (192 seconds): Duck 1 Ghost 3 Chopper 4 The numbers start to spread out after that, though there are occasional overlaps, such as the third phone and eighth ghost being the same. I like the idea of lower point goals, so I'll look into that. I also like the idea of tracking manual points, but I'm out of variables. I can turn some of the current variables into nybbles, I think, which would allow to at least offer different point total options. Thanks for the suggestions!

Cool! You uncovered a lot of the tradeoffs in the game--cost vs. time. There is an optimal order of purchasing the items in order to minimize how long it takes to recoup the cost of the item. The first chopper, for example, takes two minutes (10 points * 12 seconds / point) to start turning a profit. The optimal break-even order for the first twenty purchases is: Chopper 1 Ghost 1 Chopper 2 Ghost 2 Chopper 3 Duck 1 Ghost 3 Chopper 4 Duck 2 Ghost 4 Chopper 5 Duck 3 Ghost 5 Chopper 6 Duck 4 Ghost 6 Chopper 7 Phone 1 Duck 5 Ghost 7 But, of course, that list doesn't take into account the future profit of the item once it's past the break-even point. Each cost increase is exponential, as you discovered, though the prices are impacted by rounding. The cost of each additional chopper is 15% higher than the previous cost, for example, although that percentage doesn't settle in until about the twentieth chopper. Basically, it is a large math problem, as you say. There does have to be a point where it doesn't make sense to purchase any additional items and instead just keep crushing the green chopper, but I don't have even a rough sense where that would be. The 64th chopper costs 70,232, and I'm not sure that'd ever be worth it. But it's available for the completist to purchase! A side note: there is an actual end to High Score Screen Burn Slow Burn, but I roughly calculate it'd take about six months to reach. Thanks for playing and diving into the mechanics!