Running the original in an emulated PC when Wine on the host fails

What to know

Try Wine on the host first. When it fails in a way that no patch to the game fixes, move to an emulated x86-64 PC: QEMU, a Debian cloud image, Wine with real 32-bit libraries, Xvfb and a window manager. POD's software build ran there at close to full speed under QEMU's TCG on an M3 Max. Wine under Rosetta on the same Mac froze every few runs (measured). ./gameframe run emupc init DIR --image QCOW2 --key KEY.pub --disc DISC.iso writes the whole setup.

What each part fixed in POD:

• The disc as a CD-ROM device. Wine on Linux reads a drive's type and label from the device. A folder mapped as D: is a fixed drive there, so the game asks for its CD. Cut the data track out of the BIN/CUE (discinfo.py IMAGE --iso DISC.iso) and attach it as a CD-ROM (CD drive under Wine on Linux).
• A window manager with Xvfb. Without one, no window becomes the foreground and DirectInput reads no keys (window manager).
• 32-bit OpenGL. Wine runs a 32-bit game with 32-bit libraries. Install libgl1:i386 libglx-mesa0:i386 libgl1-mesa-dri:i386. Mesa's llvmpipe draws in software. LP_NATIVE_VECTOR_WIDTH=128 roughly doubled its speed under TCG.
• rsync over SSH to copy files. Debian's cloud kernel has no 9p modules for shared folders.
• SSH with IdentitiesOnly=yes. Without it, the agent's keys use up the server's tries (too many authentication failures).
• Root for memory. Reading the game's memory (memrec.py) needs root in the VM. sudo drops DISPLAY (sudo and DISPLAY).
• One VM per game. Give each game project its own VM, in its own derived/vm, with its own port and name (emupc.py init refuses a port in use and names the VM after the project). Hardwar first ran in POD's VM: it tied one game to another's machine and load, and put one game's files inside the other's.
• Sessions of one game sharing its VM. Give each session its own display and Wine prefix. Stop only your own processes (pkill and a shared VM, pkill over SSH). Keep a note of who is using the VM: emulock.py take gf-vm --who SESSION --why TEXT, run inside the VM, and free after.
• Colours. The two routes drew POD's menu in different colours. The VM showed the true ones. Compare against a second, independent run before trusting colours.