Jump to content

bjbest60

Members
  • Content Count

    161
  • Joined

  • Last visited

Community Reputation

133 Excellent

About bjbest60

  • Rank
    Chopper Commander

Profile Information

  • Gender
    Male
  • Location
    Space Cactus Canyon
  1. 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
  2. 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
  3. 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
  4. 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.
  5. 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!
  6. 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!
  7. 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!
  8. 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!
  9. Nice! My playthroughs usually ran between 20 and 24 hours, though I usually wasn't very attentive to the game. My hope is that with actual attention the game could be completed in eight hours, like an 9-5 kind of job. I think it's possible, but alas my real job often gets in the way of my fake point-procuring job. Thanks for playing!
  10. I'm not quite sure how a single channel would work ... you need two separate notes to create a harmony. You might be able to "flicker" the music on one channel (one frame is bass, the next is melody, the next is bass, etc.) though I imagine that might sound choppy. A better strategy might be to always have both channels doing what they're currently doing and then have a sound effect override a particular channel for a set period of time. I'll experiment a bit when I have some time. EDIT: I tried the "flicker" effect just to hear what it sounds like. To me, it sounds like a very insistent ringing telephone, but maybe it would be useful for the right project? Both one-frame (that is, the sound changes every frame; this uses one bit of a variable) and two-frame (which requires a variable that can count to three) examples are attached. songtestproceduralflicker1frame.bas.bin songtestproceduralflicker2frame.bas.bin
  11. Well, "music" might be a strong term. "Sufficiently harmonious tones" might be better. Attached is a .bin and .bas file of a program that generates, well, sufficiently harmonious tones in the key of A major. It's fairly compact and efficient. I've tried to include a lot of comments. I thought I might use it in a game, but it doesn't really suit the project. I'm posting it here in case it might benefit someone else. Basically it picks a random bass note and a random melody note and plays them. It keeps track of note length and plays things in correct time. (The bass moves in quarter notes, the melody moves in eighth notes, with some variations possible.) It's very basic but could be built out for more interesting (and perhaps musical) results. I'm happy to answer any questions. Enjoy! songtestprocedural.bas songtestprocedural.bas.bin
  12. I applied bogax's changes to my current draft of the game, and it now compiles and the sound routines are functional. It's so weird that semicolons would be throwing things off. Thank you so much to all of you who looked into this and offered comments and advice--I don't think I would have figured this out on my own. I'm excited to be moving forward again, and appreciate that you took the time to wade through my code.
  13. Cool. Thanks for looking at it! The code now compiles for me, too. I see you've added underscores to the variable names and labels. Can you describe what other things you did? The file I attached was a simplified case of my actual file (I'm actually on draft 12), so I'd prefer to make changes to the new file. But I can do a side-by-side comparison and change lines one at a time if necessary. Yeah, I'm still baffled by what's actually going on. I've fought with this for a long time now and haven't gotten anywhere. I wish I had a clearer idea of the specific problem.
  14. Thanks. That's at least somewhat heartening. But after uninstalling and reinstalling bB and vbb, I still can't compile. I actually have the same bytes reported as your compilation, but I'm still getting an error which is more mysterious than before as there's even less to go on. There are no unresolved symbols listed anymore. --- Unresolved Symbol List 3997 bytes of ROM space left in bank 1 585 bytes of ROM space left in bank 2 2333 bytes of ROM space left in bank 3 2030 bytes of ROM space left in bank 4 C:\Users\Owner\Desktop\bB.1.1d.reveng41\fall10test.bas.asm (4599): error: Illegal Addressing mode 'sta '. I get the same results trying to compile from the command line rather than bB. What setup are you using (OS, using Vbb or not, etc.)? Could someone else try compiling with whatever setup they've got and report results here?
×
×
  • Create New...