RevEng

I don't see why you couldn't. It should just be a matter of changing your double pokey driver to access the pokeys where dragonfly has them.

Yeah, for sure. This would require a new bit allocated in the a78 header, and emulator+device support coded. While it's doable for a7800 in theory, I don't have time to take it on right now.

To all new or would-be Concerto owners, you should check out Trebors 7800 ROM PROPack for proper A78 games, homebrews, hacks, and demos. It's convenient, and you'll save yourself a lot of hassle. There are a lot of bad 7800 rom files distributed here and there on the net. @Trebor spent a good deal of time sorting out good roms from garbage, making inquiries with homebrew authors, figuring out the correct headers, and enforcing a decent and consistent naming convention. He does this on an ongoing basis, as occasionally new issues are discovered, reported, and cleaned, and of course new homebrews, hacks, and demos are added as time goes on. If you do grab the pack, be sure to pass on your thanks to him! 👏

Heads up the last 7800basic release added support for hiscore.asm to be inlined in a non-permanent bank, provided you only call the high score routines from that same bank.

It may just be that you're loading the DLs more heavily or unevenly in the recent build. The paddle read happens during the visible screen, and while the driver is quite good at coping with moderate DMA, heavy DMA in certain zones can cause a bit of jitter in certain paddle positions. To mitigate, you can alot more time to the paddle read. i.e. don't use paddlescalex2 if you are, or increase thepaddlerange value to give more time to the paddle reads and scale down the result as needed.

I'm not seeing anything there that should cause freezing or crashing. (assuming your "gosub loadlevel" is being called from the same bank containing loadlevel. Feel free to shoot me some source in PM, so I can track down the source of the crash.

Yup, It's used internally.

I think this is the exciting part of this project, so I'm glad you're going this way. It's a super basic game, but good bones on which you can try out your own gameplay twists and ideas. If things wind up interesting, you can even re-skin it and make it your own.

It's the same physical port, but there's a circuit within the 7800 that effectively changes how those 7800 controller fire buttons are connected, via a couple RIOT port B bits. Loosely speaking, half of the 7800 controller two button functionality is in the controllers, and half is in the console. So both it's the console and controllers that are different. Not sure about omega race. Genesis controllers muck up with the 7800 two-button scheme, and omega race just has one button inverted from two-button genesis, so I wouldn't hold out a lot of hope. [edit] also, technically if a game is in 7800 2-button mode, and it reads the regular 1-button fire button as being pressed, the game is supposed to disable 2-button mode. Otherwise it's allowing a short in the previously mentioned 2-button console circuit.

Technically an add-on or adapter, but fair enough. I always forget about booster grip. 👍

The 2600 can't read both buttons on a 7800 controller. The controller was designed to fall-back to dual single-button operation when plugged into a 2600, or when the 7800 console is in 2600 mode. The 2600 two-button hacks and homebrew are based on genesis controllers, where two buttons can be read in 2600 mode. Why? I guess Atari thought that making the gamer solely use one of the buttons in 2600 mode was confusing. This leaves the genesis pad as the only unmodified/un-adapted controller with two button support on the 2600.

They're fairly excellent on the 7800 too; I developed the 7800basic drivers using them. They're also more reliable than mixing old mice with this old console. (uncovered by @SmittyB's tireless testing) I'd love to see someone do a 7800 port of the arcade game Quantum some day. Mouse and trakball support for that one would be perfect.

I've been holding my tongue, because I didn't want Harvey's thread to continue with this garbage, but it doesn't stop. It's crap form to go in someone else's project thread and start posting about a competing project. You start your own thread and drum up your own damn interest. It would be like me noticing that Walmart was out of some item, so I setup my stand and start selling that good right in their store. They're have no competing product at the moment, so fair is fair, right? It would light a "necessary fire" under their feet to get the product back in, so really I'd be a hero. This is hobby project space, and six months is a blink of an eye. But I get it... people want screens so badly they're willing to overlook bad manners. Whatever. Go light your necessary fires somewhere else.

FWIW, if a mouse game for the 7800 does come to pass, ps2->amiga/st adapter kits are like $15 shipped. So it's no big hardship, and as a bonus you can use a modern-DPI LED mouse.

This game would be an impressive feat for a 7800 veteran to pull off. Consider now that Darryl started his little Popeye demo in August as an exercise to learn 7800 coding, and now three months later he has the game looking and playing like a dream...

Just add "hsdevice=0" to the beginning of your game source, to fool 7800basic into thinking no device was detected.

Bupsystem seems to have an issue with the 7800basic high score code, but it's not reproducible in any other emulator or on real hardware. I thoroughly investigated the issue when it came up with Dragon's Cache. Since the emulator is closed source and has no debugger, that was the end of the line in terms of what I can investigate.

My condolences too, Matt. Take care of real life... put this stuff aside and spend time with the family.

Ok, thanks.

So I just want to clarify if that "statute of limitations" thing cuts both ways... if we've raised our hands early on in this thread, it doesn't earn us a spot in line when the orders are able to be fulfilled; it will just be first come, first serve, once you make the announcement the product is in your hands. Is that right?

Well congrats, because you nailed it. 👍

Yeah, that can't happen, but it's easy to get fooled when you're sorting indexes, doubly so with 320 modes and their pixel pair limitations. If you're having trouble with a 320 mode, try incgraphic'ing them all with just "1" and see if you get a proper blob shape... if not then you're running into pixel pair issues. Other than that, I'd say start with "0 1 2 3" as your incgraphic indexes, and swap one pair at a time instead, without assuming you just need to swap 1 and 3.

Speaking to the 7800basic-specific bits of your questions... The color indexes are pulled from the indexes within the png files themselves, so it's up to the editor how that's organized. I'll let Matt answer for ADS specifically, but in gimp it seems to auto-sort them from transparent first, and then from darker to lighter. The samples have the line of colors in the lower lines of the graphics for a couple reasons. First, if you have a bunch of sprites in different png files, it ensures that all of your sprites contain the same colors, even if the actual graphics don't in all frames. This means you don't have to re-order the indexes differently for those oddball frames. Second, it makes it handy to switch between your chosen colors in an ordinary graphic editor (don't apply to ADS).

Thanks RT! Here's an updated PDF where I've given a section to "set breakprotect", and expanded the "altgamestart" section a bit and added an example. 7800basic Guide.pdf

Glad it's useful to you!