The game is responding promptly to keys for me, but the problem might be how you use keys. Try pressing and releasing the cursor keys, don't hold them down -- this is because keys are read through BIOS and thus subject to auto-repeat and buffering. If the key buffer fills up with auto-repeat cursor keys then it will be awhile before other keys are acted on, which could account for the delayed response mentioned in the thread title.

The man you control continues moving in the current direction without input, so there's no need to hold keys down; however, if you "about face" then you need to press and release the key again to start moving in that direction. IMO, the keypad works better than the enhanced cursor keys because the center (5) key can be used to stop moving without doing an "about face".

You might be interested to know that holding cursor keys down works better if the keyboard hardware repeat rate is minimized. This can be done with MODE from real DOS, or a more specialized utility like Turbokey (using the command "turbokey z1" in this case).

Yeah, I was using it wrong, continues button presser here 😉
At least I'm consistent as I was never good at it.

Thanks for Turbokey, going to check it out.

I got back to this game, and man it still felt trippy to me 🤣

So I did some investigation (from the wiki):

The game was originally programmed by Andrew Challis for the Commodore 64, and by Kevin Parker for the Amiga, Amstrad CPC, Atari ST and ZX Spectrum platforms, with graphics provided by Robin Chapman for all formats. It was initially released in 1987 by Pandora in the United Kingdom. The game was also licensed by Mindscape for release in the United States, who handled the Apple II port by Andrew Pines and IBM PC port by Visionware Inc.

So I launched a copy of the C64 version, and the movement there is proper, albeit with a joystick. So the character starts moving when the poke is pushed in any direction, but stops moving when the poke is released.

Concluding that the Visionware Inc port is a bad one 🙁 considering keyboard controls. INT16 is used to detect keypresses, what a nightmare.

I'm thinking of rewriting the keyboard handler, but I have never done this before. So I have some questions to see if this can go anywhere:

I assume there is a loop that periodically checks for a key press (the only redirections in the IVT are 1Ch and 24h). It invokes INT16 to determine the key press, so I could intercept that. But I need a way to differentiate between key press and key release which points me to INT09.

Any idea's are welcome 😁

You could make an IRQ 1 (INT 9) handler, taking control of it away from BIOS, and put keys into the BIOS key buffer according to your own design. I guess you'd only write a cursor key into the buffer when it is first pressed, not if it repeats, thus disabling auto-repeat; and then write a center keypad key when the cursor key is released in order to stop movement. Seems a small programming exercise, not too difficult.

However, before bothering with that, you could try a DOSBox-oriented solution. According to MobyGames, the game supports joystick input, so there appears to be the option of using a joykey mapping. I use the term "joykey mapping" to refer to mapping keys to joystick axes and buttons in the mapper, which then acts like a d-pad input.

I thought I had some time on my hands to give this a go, unfortunately that was not the case. So this has to wait a bit. Thanks for the pointers.