RevEng

I think it's enough to just have XM flagged in the A78 header. Dragonfly doesn't do the whole XM register thing, so no need to hit $470 or any of the XM CTRL registers. Just use $460/461 for the YM as usual. IIRC your game probes XM memory as a sort of XM detection, which is why the guys are talking about forcing memory on in the Dragonfly. I've also added a couple bits to the A78 header for just indicating YM or second pokey, without indicating a full-blown XM This was announced in the header thread, but I don't know if Dragonfly itself is yet parsing those header bits.

I really do appreciate the heads up, so thank-you. Honestly I'm not sure it's entirely warranting a new release here. IMO Concerto is actually the correct place to fix this one. Both the NTSC and PAL BIOS explicitly set the background color to black before booting the cart ROM. 7800 games shouldn't need to replicate things the BIOS has already done on their behalf, simply because a flash cart has inserted itself into the boot chain and left things otherwise. I'm not talking about memory patterns that happen to be left behind by the bios, but rather, registers the BIOS has intentionally hit with specific values before jumping to the cart. I'm not objecting to explicitly fixing this in the future with new releases. I've already updated 7800basic to default to black, since it costs a few bytes of ROM in a reserved area. But it's a work around for a situation that's the fault of the loader.

I don't believe there's currently any browser based emulator for the A8 that's non-buggy enough to do the job. The OpenEmu core for A8 is based on the Atari800 emulator, which is only somewhat accurate. Not sure if it's up to the task here. The accurate and most up-to-date emulator for A8 is Altirra, which is Windows based, but it runs well under Wine.

Looks like OpenEmu uses an old Prosystem Emulator based core. Modern games will very likely experience problems and glitches. The browser based emulation in JS7800 is a more up-to-date cross-platform alternative, with a nice interface, and shared high score tables. (courtesy @raz0red)

Some of the bB commands are using the ARM to do things that would either be too expensive or plain impossible for the 6507, so from that perspective it is giving you some "extra" processing time in overscan. But the game logic is still driven by the 6507, instead of driven by the ARM like with John and Darrell's stuff. (I think this may not be true of some of Darrell's earlier stuff... IIRC the switch to ARM-driven code was driven by the limitations he experienced with 6507-driven attempts) Splendidnut is quite correct that you can't follow the ARM-driven paradigm with bB, and likely this won't change, as generating ARM-driven code from bB would require an overhaul of pretty much everything. If driving the ARM from a higher level language is desired, it would be better to investigate SpiceC. (though I'm not sure where @SpiceWare is at with that project) vblank cycles are pretty much used up by prep for the bB DPC+ kernel, so you actually have fewer cycles there than compared with using the standard kernel. I believe the overscan cycles are a bit reduced too, as is the available RAM. In that light, it makes what bB coders do with DPC+ all the more impressive.

This particular one has been discovered and rediscovered a few times... every time a new emulator or device with pokey comes along, someone reports that they get no pokey music in Commando.

You can keep the design at 16x24, and just increase the png to a height of 32 (without scaling). i.e. add transparent padding to the bottom. Even if 7800basic didn't have the palette/comment feature, this is exactly what it would need to do internally, when it imported the remainder portion.

Is your png height an even multiple of the zone height? Any remainder pixels are ignored, so that they can be used for palettes, comments, etc.

done

I've allocated some extra bits to represent hardware ([email protected], [email protected]/462) that has been implemented in the dragonfly cart. The new header asm is attached. a78header.asm 7800header and the docs at 7800.8bitdev.org have been updated.

Yeah, you're right. It looks like that detail got missed in the docs somehow, likely because nobody has actively coded a homebrew in either of those formats. bits 2 and 3 it is.

Since a78 is a bit of a pact between active homebrewers and emulator authors (and now flashcart creators) the usual protocol is to announce your extension in a78 header changes thread, ideally with an updated header example. If there's no pushback (there rarely is) then I'll update the header spec at 7800.8bitdev.org. You can implement with bit 8 of the cart-type word at offset 53. (i.e. the low bit of 54) I think we also likely need to implement the next bit up as a flag for stand-alone YM2151 at $461/2. I'll put in the announcement when I get a sec, if you like.

Since you're working on movement and collision detection, you might consider smooth cornering - if you move the player character toward a corner with an opening nearby, you can nudge the player position over to align with the opening. It's easier to try it out and see for yourself, than to explain it in more detail. Check out how @Atarius Maximus's Adventure Demo deals with walking toward blocks that are partially blocking your path. This sort of scheme is more forgiving, and Tanya might even be able to play it with the prolines.

I wouldn't expect spectacular corruption failure in that case, like you're getting, but instead just a failure to recognise the button press. The game rom load happens before my RIOT reset does... once it's running, changing RIOT shouldn't do anything that dramatic.

That thread is instructive, for sure. 👍 The current Concerto problem with One On One and the others is easily fixed, as evidenced by my One On One hack working with Concerto; once I reset the RIOT back to it's regular init state, the game works fine with Concerto. I passed on the exact init sequence I followed to Fred. Of non-Concerto concern is the fact that the RIOT reset I followed screws up One On One when running with the CC2. This deviant controller usage is probably the culprit, and it may just be a matter of the CC2 using more power than Concerto, or something along those lines, and RIOT doesn't actually reach the same precarious internal state the game relies on.

Thanks for the kind words, guys.

Yes, there's just the one version right now. Your edge case may be with 48k roms, like One On One... you might give Donkey Kong, Donkey Kong Jr, Hat Trick, and Mario Bros a check to see if any of those fail. (I won't add insult to injury by suggesting to try Karateka)

I'm still looking at this, but it may take a bit longer than expected. There's something in the way the CC2 leaves the state that's messing it up, but I'm not yet sure what. I've set the RIOT port back to what should be the default state. This is good enough for Concerto, but not CC2. Very strange. If I can't figure it out soon, I may punt and just wait for the next Concerto firmware that has it's own port reset. That would allow me to remove my added bit of port reset in the game, which will hopefully keep CC2 happy. For sure, will do. That's next on the list, after I figure out the weirdness causing the joystick init compatibility, so I don't need to duplicate fixes to multiple bins. I would have released a PAL hack before, but I actually didn't realise that One On One had a PAL release. It's running fine on my Concerto, along with John Stamos Mullet's Concerto, so I think this is one of the console-specific Concerto glitches. I really don't do much more to the game than change the start vector to small routine I stashed in an unused section of the rom. If the original One On One works on your Concerto, then it's possible this area I'm using is still corrupted on load, but it doesn't matter since it's unused.

You're most welcome! I'm glad if it helps anyone get a leg up on their TIA sound. Your post reminded me that I had a few sounds that I developed for Millie&Molly that didn't wind up being used, so I've added them to the library. 👍

I saw this project featured on hackaday and had similar thoughts. The nice thing about this solution would be the ability to apply a custom colour curve, which could compensate for the fact that modern HDMI LCDs use a colour space that differs a fair bit from our old CRTs. Since most of the old Atari systems fundamentally use the same colour generation technique, a single device should be able serve them all... A8, 5200, 2600, and 7800.

Ah, I stand corrected on the design source. You're still a gift.

Wow, that's awesome! And thanks for releasing the project under an open license, providing schematics, etc. Both you and this project are a gift to the community, Lewis. 👍

Interesting. I'll have a look in the next couple days, and see what's going on.

No worries, and thanks. DrVenkman was able to confirm, and I just needed the one counter-example.

Yep, that's what I meant. Game loads but is messed up. I noticed a lot of mentions of socketed Sally's with these reports, so I was wondering if there was a pattern there. Thanks for confirming it's not.