bjbest60

Good gravy, am I pulling my hair out. I'm trying to add audio code to a game I've created. The audio code itself works as its own 4k game, playing the tune. The game code works as its own 8k game (it's a skydiving thing). When I change the romsize to 16k, I've been getting all sorts of weird errors. In the attached version, I'm told "=" is an illegal keyword. In other iterations as I've been attempting to isolate the problem, I've been told there's been an error (illegal address, I think) with "sta". Sometimes "FASTFETCH" is unrecognized. Nothing seems consistent or enlightening to me. The common denominator is that bank 3 makes things screwy. I have a feeling this has to do with bankswitching and/or the kernel options, but the options should be valid together. When I cut the audio code entirely from the file, the game compiles and the kernel options behave as expected. But if I add the audio code back in, I get an error at the "musiccounter = musiccounter + 1" line (which, again, works normally in a standalone program). Right now, no code even switches banks explicitly. The audio isn't called by anything yet, and the game code is self-contained in bank 2. Maybe I'm missing something super-obvious because I've been staring at it for too long. But I'd really appreciate some review. I've tried compiling on two separate machines, current bB software, same result. Thanks for any advice. EDIT: In the attached file, the first set of commands in bank 3 (under the "nextline" heading) might be overindented, though I've never had that as an issue before. But, trying some other fixes, here's the other error I get if the compilation doesn't crash upon hitting bank 3: --- Unresolved Symbol List FASTFETCH 0000 ???? (R ) 3185 bytes of ROM space left in bank 1 684 bytes of ROM space left in bank 2 2275 bytes of ROM space left in bank 3 1879 bytes of ROM space left in bank 4 C:\Documents and Settings\Desktop\bB\fall\fall12.bas.asm (5084): error: Illegal Addressing mode 'sta '. fall10test.bas

This is incredible!

Thanks for both suggestions. I have a feeling they're both probably more efficient than what I came up with. But the file I posted above does seem to work, so I went with those strategies. I'll make a more complete post as RT suggests with a "final" version of my code, but I'll also link here. Thanks!

Three other things: 1.) tl;dr version: It's an idle game for the 2600. 2.) I'm not sure the bitmap minikernel gets the love it deserves. 3.) If you'd prefer to silence the sound effects, you can turn off the sound by setting the color switch to BW. As always, I look forward to comments / bugs / etc. Happy point procuring!

Hey kid, welcome to PointCo and your first day on the job as a Junior Point Procurer. As you know, point procurement is a rapidly growing field and demand for points has never been higher. That’s why the company motto of PointCo is “We make it a point to make the points.” (Yeah, I don’t really get it either, but HR says I’m supposed to tell every new employee the company motto.) Anyway, see that big green helicopter? We call them “choppers” in the industry. And for every chopper you crush, you get a point. So take that Joystick Controller over there and use our patented MissileBall™ technology to hover over the chopper. Press the Fire button. Boom. You just crushed a chopper and made a point. Your quota for the day is 999,900 points—you’ll have to ask the foreman why it isn’t an even million. And as you might guess, that’s a lot of hovering and launching of the MissileBall™, if you get my drift. So we’ve got a pretty slick system where you can use points to buy other things that make points. See that smaller blue chopper that’s flying around? That’s an Automated Chopper Crusher®. If you buy one of those, it’ll automatically crush a chopper once every twelve seconds. Sure, that’s not much, but you can buy more than one, and soon the points will start rolling in almost like they’re free. (But they’re not free, kid. We spend a lot of points on R&D and manufacturing around here. So treat the equipment nice, okay?) And those other things. Yeah, they're even fancier. There’s a Ghost Grabber®. You get a point for every ghost you grab, about once every eight seconds. There’s a Duck Dodger®. You get a point for every duck you dodge, and that’s even faster. And the fastest is the Phone Finder®. You get a point for every phone you find, too. But kid, you can't just be spending your points willy-nilly. I don’t have to tell you that the competition for procuring points has never been fiercer. For every Automated Point Procuring Item® you purchase, the next one’s gonna be more expensive. To keep costs contained, every new recruit can only purchase 64 of any single thing. So spend wisely, alright? Once you procure all the points, you’ll get a report about how long it took you in hours, minutes, and seconds. Just remember: when you’re done, you get to go home, sleep, and dream about procuring more points! The restroom’s down the hall. You get a fifteen-minute lunch. Good luck, kid. Point Procurer beta 1.bin

Yes, it's only NTSC.

Ok, I think I've figured it out. It's a matter of keeping everything decimal all the time. So every mathematical operation needs to be preceded by dec, and every number needs to be preceded by a dollar sign. "Carrying the one" is a bit tricky. So, for 1234 - 57, you have to reduce the number 12 by 1. That's easy (and needs to be done with a dec statement and a dollar sign). But then you need to add 100 to the 34. This needs to be done in two terms because $100 isn't a valid BCD. So instead it's $99 - 57 + 34 + $01 (where 57 and 34 would actually be variables). I'm attaching the files that show how this works; press fire to "buy" a rectangle when hovering over it. (It changes color when you hover, and then again when you buy.) I'm hopeful this is the correct and robust solution, but I will post further if I find mistakes. priceexample2.bas priceexample2.bas.bin

Every time I've tried to add a variable to a score, I feel like I've quickly gone wrong because I can't seem to figure out BCDs and the dec statement. Often my solution is a simple loop: for x = 1 to level : score = score + 50 : next That works well for small, repeatable instances. But I've got a game concept I'd like to implement where the score can be large, and with that amount (let's assume it's money), you can purchase things that have variable prices and are larger than 255. So, for example, with a score of 25,000, I could purchase an item that costs 9,876. The question is how to make this work. I understand the _sc1, _sc2, and _sc3 parts of the score. My idea would be to store prices in data arrays similarly named, with two digits per price. So, for something that costs 9,876, item1 would have an entry of $00 (first two digits), item2 would be $98 (second two digits), and item3 would have an entry of $76. I also understand how to store _sc1 et al. into other variables and replace them when necessary. But I can't figure out the math and the proper way to store things to have the calculations come out correctly. Ideally, I'd like the score to display the cost upon hovering over a graphic of the item to be bought (by using a missile as a mouse pointer, say), then you could press fire to buy the item, and then upon leaving the correct new score would display (old score - price of item). I'm trying to do this by comparing each pair of digits and subtracting where appropriate (and "carrying the one" when necessary). I've fought with BCDs and dec statements and trying to parse how the score works and I can't seem to get anywhere. I'm running into some hex issues where if I store $10 into my data array and load it into _sc3, It's actually hex 10 = decimal 16. (And I think I've tried every combination of dec statements and dollar signs to combat this, to no avail.) So there's some definite hex / dec conversion issues I'm failing to navigate. Anyway, I'd really appreciate any assistance in trying to make this work. I've looked at RT's page, sample programs, the forums, etc., and haven't found the right combination of operations yet. Thanks.

I would love it if this could also work with the multisprite kernel. Consider me a beggar and a chooser. Thanks again!

Awesome! This looks great--can't wait to use it. Thanks so much!

Yes, a minikernel would be awesome. I think functions for score2 could definitely work. As for color, personally I think it could just be static. My understanding from a few pages back is that a second score might cost some variables, so I'm not sure one for a second score color would be worth it. Thanks for looking into it!

Repeating a request that was made earlier in this thread: is it possible to have two six-digit scores? I'm willing to sacrifice variables!

Hot tip: Stella screenshots make for great mouse pads. (Printed via Shutterfly.)

HSSBSB is again available as a physical cart through 8-Bit Classics!

The game is now available at 8-Bit Classics with a spiffy new label! As an added surprise, one out of every ten carts sold will instead have a limited-edition classic text-style label. Thanks again for the interest, all!

I just downloaded the .bin and flashed it to my Harmony cart via the Harmony Programming Tool, and it works. Not sure about putting the .bin in a folder with other .bins--maybe someone else could try that? (I don't have a spare card for multigame purposes.)