Add support for Ghost Squad

[ThielHater]

Hi argonlefou, after quite some time the emulation of Ghost Squad arcade runs relatively smoothly on my machine.

Here is the setup for you to reproduce:

• Xemu 0.7.118
• MCPX Boot ROM = mcpx_1.0.bin (d49c52a4102f6df7bcf8d0617ac475ed)
• Flash ROM (BIOS) = bios_debug_4627.bin (19b5c6d3d42a707bba620634fe6d4baf)

I was able to find out that the X values range from -320 to 319 and Y values range from -240 to 239. They are stored as 4 byte signed int. The address always ends with 74EC and 74F0 but I could not manage to find a static pointer there.

What I found is that the X and Y values come from registers r14d and r15d. I investigated the code that fills these registers and found a promising pointer candidate ("xemu.exe"+00E86518 => +B08 => +1C) but it acts strange. The pointer is resistant against restarts of Xemu but not at runtime. I guess that Xemu iterates over the input devices each frame and this is the pointer to the current input device. There is just a limited set of variations and when the X and Y values are written, the pointer is correct.

However, the game is controlled like this:

• Enter = Start
• E = Up, D = Down, S = Left, F = Right
• A = Shoot, B/W = Reload
• X = Action
• 1 = Switch shooting mode

[argonlefou]

Hello,

Thanks for the search and information. Took me a couple of hours but I managed to run Ghost Squad with XEMU.

Unfortunately this pointer was ineffective on my computer.

Usually with that kind of always-changing-memory-address, I'd rather find the code instruction writing to them and add a man-in-the-middle patch in here.

Unfortunatelly, unlike Cxbx which is loading the game's original code and make it run (that's why Cxbx patch is kind of still working despite the updates versions), It look like Xemu is doing that differently and there's some kind of dynamic-allocated-memory-process acting on the memory values. So the code we could easily use to get/set data is also based on a pointer value, changing at each start of the program .....

This is based on a very quick look at it, as I'm about to leave for some time and I'm currently very short on free time.

I also quickly looked at the debug console of Xemu, there are ways to get some addresses between "guest" and "host" mapping of memory, but this is nothing I have knowledge of (as far as this emulator is concerned)

And, as I always say about emulators like this : even if we manage to find some kind of reliable way to handle that, any upcomming updated compilation of Xemu.exe will break everything......

I'm still keeping this out of curiosity to spend some time on it when I'll be back :)

You're welcome to fill-in more details if you have, untill then

[ThielHater]

Thanks for the feedback.

Of course, the more dynamically the memory is allocated, the more difficult it becomes and I know that everything can (and likely will) change when a new version is released. Honestly I didn't think that it is a big problem, as you already reference specific versions for other softwares to be compatible with DemulShooter.

It is interesting to hear about the guest and host mapping of memory, I did not look into that.

If we can not get a decent pointer by now, then maybe any of these options could do the trick:

• Xemu is open source, the code can be read and we could derive more information from it. => The project is massive, I just had a sneak peak.
• Write a plugin for Xemu to support mouse input in general, maybe it already exists. => Not possible.
• Write a plugin for Xemu that helps DemulShooter, like an interface for writing X and Y values or just exposing their memory addresses.
• Search the process memory for a byte sequence of instructions and manipulate that. => Game crashes, I guess because of a security mechanism.