RevEng

You could always use semi-colons with data, even in the old bB. It was a bonus feature due to the way bB converts the data lines to assembly. RT's bB page has a note that it doesn't work with sdata, but I just tried it out with sdata in both the old and beta versions, and it works just fine in both.

It looks to be happier if you add spaces... "sdata musicData = x"

Nothing so far!

Ok, you asked for it. The first byte of PF data on the screen isn't aligned with the other bytes. I took the sample program and changed the PF data to horizontal lines to illustrate...

Very nice! I've been kicking around the idea of a MAME coffee table for a while... think I might need to take a trip to Ikea!

Wow, that's a heck of an update. Lots of amazing new stuff in there - just when we thought it couldn't get better! The stack based DPC ram is interesting, and I think the first post I made on AA was a request for C style comments in bB.

Died after the 3rd level getting to the 4th. I made what I thought was a perfectly fast run through the underwater portion but still ran out of air.

Sega Genesis controls + one 10 cent pull-up resistor can get you 4 buttons too, maybe even 7. A cheap adapter consisting of nothing more than a DE9 male+female and the resistor could also be made so the Genesis controllers could remain stock. Harmony uses an inexpensive usb->serial interface for USB, and giving it full USB host capability would require more hardware and precious flash space for the USB drivers.

Mission accomplished!

No problem - glad you're enjoying it! Al was cool with an uncensored release, so I've added the latest release to the first post. The game is pretty much done now I think, except for the remaining AtariVox work in progress.

Really I'm leaving with Al to make the call. It's his forum, so it's up to him if and how it gets posted. The PM has been sent. In my mind Custer's Revenge is more objectionable than my little homebrew, but I respect that other people may feel differently.

So far the only release without the bars was a "sneak preview" Atari User did with the last issue. I'm not against releasing the full goods in the thread, if Al is good with it. I'll send him a PM and see what he says.

Quite correct. Further, there's case law (Atari v JS&A) with a ruling that cartridges with mask rom aren't covered by the software backup copyright exemptions. I think a fair-use defense might be explored. But in any case, the copyright holders aren't complaining, and I can't imagine any realistic damages they could claim, so really the point is academic.

Let me be the first to say: very nice PMR! Single-line artwork definitely takes up more time, but with results like these it's worth it!

Yeah, left/right on the joystick is a better idea. It's less likely to be falsely triggered and will save me some debounce code. You're welcome, and thanks back at you. I'm always glad when people take the time to share their ideas!

The only requirement should be placing the graphics data into the last bank, as you noted. I switched over your example code to 8k, and it worked for me. I did need to throw a "includesfile multisprite_bankswitch.inc" at the top of the basic to get it to compile, but after that it ran ok. Are you getting a normal sized binary file?

Sounds good! I'm getting tight on rom space where that code is, but I'll give it a shot. And the lose sound can definitely be sped up. A red+black card display would be tricky. The cards are drawn with players, which are a single color per line - white in this case, with the black number part of the card just being the playfield showing through. While it's possible to put red playfield blocks in arbitrary places (aka asymmetric playfield), there aren't enough cycles in the scanline to do that and draw all 6 cards. I tried a green background before in one of my tests, but I wasn't happy with the card numbers being dark green. Thanks, slim!

The <> operator is bB's logical "not equal to" operator. !== isn't valid bB syntax. ! is the "not" operator, but it only works on booleans (e.g. if !joy0up then ..., if !switchselect then ..., etc.) not on other operators.

Thanks! As Thomas has answered, (1) isn't possible without additional flickering on the image. If I tried to make the girl image wider, she'd be as blinky as the Pac-Man 2600 ghosts. Unfortunately technical reasons prevent most of (2) as well. The vertical separation between the command-line and the scores is intentional. The 48-pixel maximum Thomas mentioned comes into play, so to avoid flickering it needs to be spaced vertically. The cards having suit would be a nice detail, but having no suits was one of the memory trade-offs I made so I could have each card tracked in memory and still have some left over for stuff like splits and sound effects. Your pacing comment is interesting. I tried to more or less keep it paced similar to a real blackjack game, with pauses to the player can read the dialog. (and count cards, if that's their thing) Are you thinking (1) overall timing of interactions should be faster, (2) the player should be able to speed up the prompts by pressing fire, or (3) it takes too long to get her clothes off?

Interesting visual effects... can't wait to play the binary!

In multisprite_kernel.asm I changed this... ifnconst userscore_flag jsr setscorepointers endif ...to this... ifnconst userscore_flag jsr setscorepointers else lda userscore_flag bne skipsetscorepointers jsr setscorepointers skipsetscorepointers endif ...and your basic then worked as expected. So the score pointers are being stepped on somewhere.

See the "Has actiplaque ever been successfully removed" thread

Hah. My inner artist is wounded! Ok, I'll give the last page some love. The first page is an inner cover, and the image might even be a placeholder at that. For the cart/manual image I was planning to do the contest thing. Thanks for looking it over!

I've taken a first crack at the real manual. I'd appreciate any and all feedback! [removed - the updated manual is in the first post]

Jeff is right. You need to try compiling it from command-line. There's at least one condition I know that will cause bB to hang during the compile attempt (dividing by zero) and there could be more.