RevEng

The DOWN arrow makes you heavier, and they add cumulatively, which helps when the screen scrolling gets very fast. I think the rest of the prize boxes were placeholders. I ran a quick graphics rip script on the rom, and I only see the regular items...

In financial terms it's called arbitrage. You make money by buying in one market where product is demand is lower, and selling in a market where demand is higher. The usual solution (not that it's strictly a problem) would be for Andrew to sell to the high demand market himself, at the same high prices.

The majority of the 7800basic frame-based housekeeping happens after the top of the visible screen, via a display interrupt. There's a few things that happen before the fire-button reading, like the user's top-screen routine, any long controller reads, sound effect servicing, and any music tracker servicing. So the exact screen position depends on what options you've enabled. In terms of your program flow, it should happen "right" after drawscreen.

I'm having a lightbulb momement... When you test for joyXfire in your game, 7800basic tests against fire-button state variables, rather than INPT1 or INPT2 directly. Every frame, the registers get polled and those variables get updated. The reason behind that is the firebuttons are virtualized. i.e. devices, like mice and paddles, still cause joyXfire signals, despite being wired differently than joysticks. The end goal for this is to make the game's controller handling code simpler. So every other frame should work with joyXfire and QuadTari, for now. Or work with the registers directly, as you have.

Ah, I see. Thanks for the clarification on your involvement. Very cool project regardless, and thanks for posting about it!

I'm sure the devs appreciate your support, but please don't endanger your health over the hobby. There are other ways to help, if you want to do so, like testing wips, sharing releases on social media, adding reviews to the AA store, or just generally being supportive. FWIW, the economy has me in the same shoes as you, without a hobby budget at all. Just participate in other ways, and look after yourself.

Drelbs was one of those "weird in a good way" games, that I kept going back to as a kid. This remake feels entirely like the original, but with a lovely facelift. Really well done - great job, Kelly!

"shove it" isn't gentle by any stretch, my dude. Set those untested suspicions aside, and try again without telling people to insert things inside themselves. You get what you give. When everybody around you is suddenly indignant and prickly, surely the problem must be them! /s

I have to ask... while the device is very cool on it's own and needs no other justification, I can' help but think that it makes it convenient for A8 folks to dip their toes into 7800 development and/or perform cross-development work. Was that intentional? Either way, cool beans!

To manage expectations, no, it's not a new level. I think it's pretty cool, but it's nothing that big. I really wanted to do a new level, and even laid one out roughly... But in the end, I ran out of space. Maybe I'll finish it some day, as part of a DLC pack.

Regular game pricing went through a race to the bottom some decades ago. Before someone counters with $70 xbox games or similar, consider the game development team and commensurate budget. The race to the bottom was largely fuelled by a glut of game devs (and shenanigans with regard to the labour) and the crapification of game profitability strategies. (dlc, in-game ads, pay-to-win, subscriptions, web3, etc.) None of that is accessible to the retro game dev, thank heavens, and there is no glut of retro game devs. It's a boutique market, with boutique pricing. TBH it's obscenely low as far as boutique pricing normally goes, with "free" or "demo" often being an option. Really it's charity work that retro game devs are doing. So I'd say your pricing expectations are just wrong, since you're comparing two very different markets. It's the same as expecting Amish furniture at Ikea pricing, or those Amish "can shove it!"

"should" is a bit of a strong word, but every other device and emulator that can run 7800 Activision roms uses the old AM scheme, and doesn't support OM. I don't know why it's flipped in DF. [edit - I'm told that Mame team recently flipped to using the OM scheme, based on Rafal's info.]

Agreed. Users shouldn't look for support of the OM layout as a desired feature in emulators or flashcarts, because it gives them nothing - this is exactly the reason we didn't even bother allocating a flag for OM in the a78 header. Trebor has the OM dumps in the pack as documentation that the old AM dumps used an unnatural bank order, but other than that, there's no value to their existence.

I played around with this for a bit, while developing the open bios in the first place. The bios files are all checksummed, and anything not-matching the checksum is rejected. The behaviour is inherited from Mame, and there isn't a way around it presently. (other than manually adding a new bios entry with it's own checksum)

A good man died and left behind a wife and daughter. I think you should drop the regrets of how his death has put a cramp in your hobby wants.

Yeah, correct - RMT is a POKEY based tracker. The dmf2asm converter and bundled XMYM tracker I wrote works with yamaha ym2151, and comes with examples in assembly and 7800basic. Take heed that you need to steer the authoring tool, Deflemask, in a particular way to generate tracks that will play back correctly on the 7800 XMYM tracker - see the README for more info. Fair warning that the dmf2asm/xmym code is a bit beta at this time. It was written when XM looked to be nearly ready to release, so we had a reasonable way to produce carts with optional yamaha support. Since this is no longer the case, I haven't spent any development effort on it, nor have I looked at integrating it more tightly with 7800basic; I'd rather spend my limited dev time on stuff that works with retail carts.

Rumour has it that the full version of this game has an easter egg.

If anyone is looking to play with existing RMT songs, I added some basic RMT info at the POKEY section of the 7800 wiki, including a link to a downloadable SAP-wrapped RMT song collection. 7800basic and it's included RMT tools can deal with SAP wrapped RMT files directly. If you wish to strip the SAP part and work directly with RMT files, you can use provided 7800rmtfix program to do that. If you're wanting to use an existing song in a game for sale, it would be a good idea to contact the author and get permission first.

I dropped a new v0.27 7800basic release at github. Changes include... feature: RMT tracker import and playback feature: significantly faster boxcollision when using constant height+width feature: misc 7800header updates In case anyone is wondering why... the version skipped ahead due to interim 7800AsmDevKit releases. (they're from the same code base, and have version parity)

There have been challenges.

Right, there's no registration for a mark. But if they've been doing actual trade with the character mark, so that would be covered by common law rights, no?

Unlike copyright or patents, trademarks don't have a time limit, and don't expire. The registration on a mark can expire (you need to renew it periodically) but registration just makes court proceedings easier. To own a trademark, you only need to do trade with that mark. To keep the mark you need to do trade with it within a 3 year period, or it can be considered abandoned. Complicating things is the fact that characters (descriptions and depictions) are also covered by copyright. My non-lawyer non-legal-advice observation would be be that Bentley Bear is definitely copyrighted, and almost certainly covered by trademark.

Tested out, and the fix for 7800rtm2asm seems to be working great. I've pushed it to the master repo.

That seems to be a great lead - thanks! The $FE,$00 flag I took from this format description and this comment in the latest RMT driver. The ported RMT driver code (and the latest RMT driver code) doesn't seem to do anything with the byte after $FE, so I'm guessing maybe that byte can vary, for some unknown reason.

Heads-up that there's some kind of relocation bug for a good chunk of RMTs (say 1/3) where they don't loop or end correctly if they're not located at $4000. I've been trying to track down this bug, which is why I haven't released the RMT tracker integration in 7800basic yet.