itch.io

The gameplay is always the most difficult part of any game to RE. For most of the code, you can see on the screen what it's doing, or otherwise know what it is supposed to do. But for game logic, you don't know the algorithm that was implemented - it may not even be anything sensible - so there's no point of reference. I've had a few projects where there were still parts of the original code that I couldn't quite understand, but it didn't prevent a transcode because all that matters is that the same logic is implemented.

I'm not surprised that AI is starting to get to the point where it can RE software. Recently a core was released on MiSTer that was written by AI, and I know from experience that it's no trivial process. I suspect a transcode by AI would be fairly straightforward... I'd like to try one on a simple program one day. RE would be more difficult but I can see how even now it would do quite a bit of it.

I just had to educate myself on Godot. Looks pretty cool. I also had to Google Torvak; despite having an Amiga back in the day, and hundreds of games, I'm not familiar with this one. Interestingly my 11yo son has to develop and showcase a 'game' next week at school as a special project, and I have no idea what to advise him to do. Maybe Godot is the answer...

Hah, funny you mention Ghidra... I've been using IDAPro for many years, owning a paid copy I bought for my business. When I started Xevious, I decided to give Ghidra a go, just to see how it compared and to see if there were any features that I could use that were missing in IDAPro. However one session I discovered that it had suddenly lost several hours of my work. Thinking I had done something stupid, I went back and re-did it all, only to find a few sessions later that even more of my work had disappeared. To say I was pi**sed was an understatement. I'm not 100% sure but I think it was related to some undocumented Z80 instructions being used. So yeah, wouldn't touch it again if you paid me.  YMMV. Besides, I didn't find any good reason to use it over IDAPro, which has been rock-solid for me for decades.

The games I RE are generally games that I really like and so my process has as much to do with revealing how it was coded as it does about being able to transcode it. For that reason they're all done by hand. I generally like to finish the RE before I start transcoding, but it doesn't always turn out that way, especially if I get to the point where the remaining RE effort is generally just cranking the handle. That mostly happens with well-written code BTW. And Xevious was well written IMHO.

Again my transcoding has been all hand-coded up until this point. So it's a very long and drawn-out process, but you end up with commented code with meaningful labels and a 1:1 correspondence with the original "source".  I always structure the transcoded file exactly the same way as the original, and comment each routine's original address. You can see my sources on github. I've done a few transcodes to C as well, together with some other projects I haven't made public at all. As you can imagine, only well structured assembler lends itself to a C transcode. I would have loved to have done Space Invaders in C, but I don't think anyone could possibly manage it in any meaningful way (other than a single function with goto's everywhere) because the code is spaghetti. Would be interesting to see what AI makes of it though.

Moving forward I'm looking at automating the transcode process at the very least. jotd666 has been a prolific author over the last few years with his transcodes. Automating negates the need to do a lot of RE, so it will depend on my own personal goals for the project.

Right now Frogger has stalled but that has a lot to do with my lack of time. I started it because I wanted to understand how it worked. Not the best code I have ever seen, and there are several well-known bugs in the game, plus one that I found in the code during an RE.

So to summarise on the tools; IDAPro and MAME mostly, and obviously whatever compiler/assembler I'm targeting, running under windows.

Vulgus I got stuck with the game logic, couldn't really follow it. But an automated transcode would work.

Tutankham I did a very, very long time ago, and IIRC only enough to patch it to run on the CoCo3. The hardware is bitmapped graphics, so it wouldn't work on the Neo Geo. At least, not without a lot of changes to how things are done.

Mappy I like, Grobda I'm sure I've seen it but can't recall it off-hand. There is a 68K version of Mappy on Namco Classics Vol 1. Would love to dive into that one day and see how they've implemented the old games on it... I wonder whether they wrote C versions of the code???

Hi SirVH! Very, very busy with Real Life atm, I'm afraid I won't get to look at retro stuff at all for a few months at least. In fact I'll be busy packing away most of it for a house move. But love the work you're doing! Once day I'll get more time again!

Awesome work, congratulations!

Can you please link my itch page on yours; I've linked yours on mine, thanks!

https://tcdev.itch.io/xevious

I've considered it. It's already 68K of course. I actually did the MAME driver for it (Namco Classics PCB) many many years ago, so I know - or at least knew - quite a few technical details about it. I have also started on a MiSTer core for it. But I haven't looked closely at what it would entail, or even if it's feasible on the Neo Geo.

This is top shelf CoCo software! My only complaint is that it's a little too easy... as others say I'd love to see this extended, maybe more screens and maybe a little more complex gameplay to make it harder - bats harder to dodge etc. But the graphics, animation and gameplay mechanics are absolutely top notch! Well done!

Hi! Who do I ask about technical details of the game, and a possible port to the TRS-80 CoCo 3??? TIA!

That is entirely possible. It may well be that the sprite coordinates are not placed exactly where they should be. Early hardware had known nuances with some (eg. 1 or 2) sprites being offset a few pixels with respect to the other sprites. In fact, I'm currently working on Frogger (same hardware) and did have to tweak the sprite routines that I lifted from Galaxian; Frogger has the advantage in that the background can be used as a reference, though of course the background is also subject to its own nuances. I'll finish up on Frogger and revisit Galaxian to see if there are any changes I should back-port.

I'm also thinking it may be possible to implement a non-tate mode for Galaxian as well!

Thanks! I'm hoping I can do a non-tate version too!

Again, nice, thanks!

Nice, thanks!

Xevious, doubtful. I've tried to think how scrolling would work in non tate mode, but I just don't see how it could be done. But maybe I just need to think about it again after coming back from a break. Will need scaling to fit the entire screen though...

Galaxian, maybe. Similar issue to Xevious, but less demanding. I'll think about it. 

Awesome work. I know you don't take requests yourself, but you may want to consider getting in touch with jotd (https://jotd666.itch.io/) who has done some amazing transcodes/ports to the Amiga. He'd hit the ground running with your source base...

Added (untested on real hardware)

Let me know what I can do!

I can help with coins/credits if you like!?!

Yet to try it, but you should add your own entry into the hash/neogeo.xml file so you don't need to masquerade as Super Side Kicks.

Never seen Xevious (puzzledp) hang in MAME and I've run it literally hundreds of times!?!

Blog entry

That is way cool!!!

'mame puzzledp' or 'mame neocdz -cdrom xevious.iso'

Beta2 will remove the need for masquerading as puzzledp