I tried doing something like this about 15 years ago but specifically for audio by routing NES NSF rom audio data (square, triangle, PWM, etc) to virtual midi cables attached to VSTs so you could play any old school Nintendo game with modern instrumentation. Was a pretty fun project.

The closest thing I can think of for graphical rehauls is probably shader pack type stuff - Minecraft is a great example of this.

https://www.sonicether.com/seus

Bochs and MAME both have superb and widely-used debuggers, while Qemu is more limited but still has some debugging capabilities in its monitor, as well as a gdb integration. (Can’t say anything about PCem/86Box.) It seems that developers of emulators targeting good coverage of old stuff simply can’t not build a debugger, because it’s an integral part of their task to figure out what the hell the devs of the latest failing thing did to make it fail. Bochs is (was?) also quite popular in the OSDev scene as a debugging tool.

From my brief experience, it seems that reversing old games is one of those disciplines where there is no good step-by-step course. One can start learning some theory (I did so by reading “The Art of Assembly Language Programming” – if I had more time, I'd try “Reverse Engineering for Beginners”) but then one has to get his hands dirty. Real-life games are typically not simple, but one usually just needs to reverse some small parts to produce new interesting modifications.

But surely reading tutorials is useful to learn techniques and tricks. I recommend this article to start: https://www.lodsb.com/reversing-lz91-from-commander-keen (not totally for beginners, but very friendly, and it can help to get used with the jargon). I am also publishing war stories on this topic on my blog (marnetto.net).

Tutorials are hard, but there are some great writeups like this which discuss some of the specific problems and trial/error involved

https://neuviemeporte.github.io/category/f15-se2

In this case one hard part was trying to get code to compile to identical byte for byte output. Which meant working out which compiler options were used, and which specific compiler too. That gives you a hint of what kinda things are involved.

You can, it's just harder, sometimes.

Very roughly spoken, the older the platform, the "weirder" stuff that happens at runtime gets in order to make the best of the measly hardware.

I'm looking at a many decades old C64 game right now, and the way I'm doing it is by having taken a memory snapshot when the game was in the state that I'm most interested in at first.

Starting with just the "binary" on disk would be much harder, since there's so much code that just loads, decompresses, initializes overlays etc. which isn't particularly interesting from an actual game logic point of view (though may be very interesting for other reasons), and only exists because the whole game just doesn't fit into all of memory.

There's also a bunch of loading and overlay magic at runtime of the game, but by looking at a snapshot of the game in the state that interests me, I don't have to dive into that (yet).

there are so many reasons for that

-there is sometimes not a single statical exe (that means all code inside) but overlays(DOS like DLLs) or serveral other ways of loading code at runtime (example for sound/gfx-drivers) - DOS allows technicaly nearly everything so everything is done in games :)

-many game loaders combine code/data parts of a game in memory - for keeping floppy releases smaller

-self modifying code, also hard to disassemble statically with Gidrah/IDA

-good old segment/offset 16bit realmode games - a complete different beast compare to 32bit linear DOS games (Ghidra isn't very good at this, IDA is much much better)

some examples:

the Stunts loader combines several (in itself non valid) files in memory to create a exe (the single files are packed and the result in exe in memory is also packed) - not that easy to static disassemble something like that

Alpha Waves also got an loader and self modifying code that is not easy to reverse statical

its good to have the best disassemblers available and the best (or better dedicated) debuggers around to keep your reversing project shorter then decades :)

Obfuscation and compression are two potential extra hoops to jump through. It's easier to let the executable run for a bit and start from there.

I believe part of the problem is the fact that Aa.exe fil B is created BY packaging multiple library files And or graphics , arrays ETC. and there is no default order into which part of the EXE file they land. there are some Tools ... hex editors come to mind. I seem to recall NOPING out A jump or two in my younger days edit: the these days that probably wouldn't work due to CRC checks... but there was a time... Then again that may be just the perfect place to start riverus engineering;) smile I have some good memories of playing a Medal of honor in which I changed all the door Textures to transparent window textures and having to work around CRC protection... good times smiley :)

x86 segmentation makes it very hard to statically analyze anything. In real mode, any byte can be referenced in 4096 different ways. It is even messier in protected mode, since now every selector is an entry in a table, so its value itself is meaningless. So, without runtime analysis, there is no way to tell if 04:1234 is or is not the same byte as fa:1204

I don’t think the language is necessarily chosen for the project. I think C# is just a main stream language that a lot of people know.

My guess is portability, then obviously performance.

edit: actually there is a specific answer for this particular project - "We had to rewrite the project in C# to add automated code generation (java doesn't have the goto keyword, making automated ASM translation challenging)". There you are.