The Walking Dead LE slowdown on 64 bit / add AT91 JIT to non-x86-32bit path

[RobbyKingPin81]

At the start of the game everything runs fine. But after a while the dmd shows massive slowdown. It is possible the crossbow has something to do with it. The ball will not launch, crossbow goes back to the base position and after a while the ball spits out from the pivotpoint of the crossbow. After that the game froze down so hard nothing seems to work right anymore and the game is virtually unplayable. On 32 bit version no issues at all.

[toxieainc]

This is unfortunately for now the 'normal' behavior.
On 64bit, or non-x86 platforms in general, the AT91 JIT code path is non existant, so some machines relying on that emulation will be wacky or incaccurate.

[RobbyKingPin81]

Thanks for the reply. I hope it's something fixable in the future because I want to release a mod in the future when this problem is solved. I can use the 32 bit because I mixed both versions in my install but I have seen many people that just went for the 64 bit versions of VPX and VPinMame and didn't look back to the 32 bit versions anymore. You guys knocked it out of the park with the 64 bit stuff, most games work perfect. Are there more Stern tables with simular issues that you know off? Asking this to help me select a new table to mod while I delay this for now

[mjrgh]

If anyone wants to implement a stop-gap (pending someone getting motivated enough to do an i64 translation), I have a suggestion that might be relatively low effort. Have the 64-bit PInMame kick off a child process running a 32-bit .exe that only runs the sound board emulator. That would let the existing JIT code run, since that part would be in 32-bit space, while making everything transparent to the 64-bit host process (VP). The two can communicate via a pipe (or any other IPC mechanism, but a pipe is probably easiest). That would only require some mucking around with PinMame build configurations, and not much new code; the only really new thing would be the communication mechanism.

[toxieainc]

The thing is that we're now also multi-OS/platform. So going forward, we should either make the non-JIT version behave the same as the JIT version (at cost of CPU cycles :/), or make the JIT code also work on 64bit and Arm.

[mjrgh]

The thing is that we're now also multi-OS/platform. So going forward, we should either make the non-JIT version behave the same as the JIT version (at cost of CPU cycles :/), or make the JIT code also work on 64bit and Arm.

Certainly, which is why I called it a stopgap. If a comprehensive solution is in the works, a stopgap obviously isn't necessary. I just got the impression from your earlier comment that it might be a while. If that's the case, then at least Win64 doesn't necessarily have to wait as long as everyone else, since there's this potential way to extend the JIT functionality to this one additional platform, in the near term, with relatively little work (compared to building out the JIT for IA64, ARM, Linux, and MacOS).

[toxieainc]

Is there some library (and i hope the answer is not LLVM ;)) that could help in making emitting code a bit less platform/OS dependent, maybe at least for x86/64?

[toxieainc]

Maybe something like https://asmjit.com/ ? That includes even Arm, and seems to be used by quite some multi-platform larger projects (e.g. GZDoom).

[wiesshund]

Are there more Stern tables with simular issues that you know off?

A lot of Stern and some newer williams, perhaps others
Results vary from just flat out crashing to things seeming ok at 1st and then the DMD becomes out of sync with the table

depends on the rom, and sometimes how long your game lasts

[iaakki]

Getting that asmjit in would be wonderful. That would make it work also for the standalone version.

[djrobx]

Another option is to update the interrupt handling code to be more accurate in the C++ emulation.

At the time I worked on this, it was prohibitively slow to check if IRQs need to be serviced at all the correct times in the interpreted version, but processors are much faster now and have many more cores. I'm possibly hazy on the details, but I think on every POP call you ought to check to see if IRQs need to be serviced. The interpreter didn't do this, but when I implemented it in the JIT code it solved the stalling issues.

Might also be worthwhile playing with the timing constants in the AT91 code. You might find some that work better with different games. ACDC and Metallica were actually the harder ones to get working correctly as they use a more "brute force" technique to write to the serial port.

Option 3 is to just look at replacing the ARM emulator with a better one. Better emulation would probably help SAM as well as future hardware we will undoubtedly want to support at some point.