Xevious

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.

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!

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.

Again, nice, thanks!

I tried running the puzzledp.zip in MAME, which booted the Neo Geo screen but then just hung on black :(

Will hang on for beta 2.