How to get rid of keyboard latency in atari800 emulator?

Question

I use the atari800 emulator v. 4.2.0 on windows 10 and linux in latest version. (https://atari800.github.io)

I notice an annoying keyboard latency of up to 100-200ms (keypress-to-click and appearance of the letter, rough estimation), which is not present on real hardware. How can I get rid of the latency and make the emulator behave like a real Atari 800XL machine?

Additional Info / Update:

I testet it with the build-in roms, also with real atari 800 XL OS and atari basic rom both on windows 10 on a pretty powerful machine (Surface Book 2) and also on Linux Mint deb-package (older version - three.something. I uninstalled it and don't remember the exact version number)

I also compiled a version myself as a pure fb-console programm (emulator v.4,2,0) against SDL 1.2 (2.x does not support fbdev anymore, sooo sad...).

Same issue on all OSses and machines.

Games, demos run fine, it is just the annoying delay between each keypress and the click sound/character appearance. It is not much but noticeable, especially when I type faster.

2nd Update

There is no keyboard delay in the Altirra Emulator. (http://www.virtualdub.org/altirra.html) but this is only available on windows.

core question

Do I need some special settings on atari800 to remove latency or is it just an issue with the emulator?

Answer 1

From what I can make out, that emulator has its endless loop performing a simple:

• read keyboard;
• emulate whole frame;
• display frame;
• repeat.

The project actually has multiple main functions, but they're all similar.

Latency for keys once they've entered the application should therefore be between one and two frames — 'emulate whole frame' blocks until the end of the frame in real time so it's always going to be at least true that the thing shown at the end of a frame period is based on the key state at the start of it.

If you're unlucky enough to press a key exactly after the emulator has read the keyboard, that won't be factored into the current frame, it'll be factored into the next but not cause any visible effect until the end of the next frame. So that's just less than two frames.

There'll also be some latency in a key getting to the emulator, as it traverses the Bluetooth or USB stack and is eventually subject to a scheduler to reach the intended process. But there's little the emulator can do about that.

Unfortunately large swathes of the emulator seem hard-coded around the fixed whole-frame cadence; see e.g. this section of calls to Devices_Frame(), INPUT_Frame(), GTIA_Frame(), etc. So I'm not sure that a solution exists if you're seeing better behaviour from other emulators on the same system. But if you fancied the engineering challenge, the solution is what you'd guess — use much smaller time slices.

If the emulator ran half a frame and a sync between every keyboard poll, you'd have a maximum of one frame of internal input latency. If it ran a quarter of a frame, you'd be down to a maximal half a frame of input latency. Etc.

The competing issue is precision in your OS's scheduler for timers or, to match the current implementation, ad hoc sleeping.

Speaking of SDL at least, I found that its built-in timers were very imprecise when I tested earlier this year; a requested 2ms resolution timer frequently showed variations of several ms under macOS. On the same computer a native dispatch source timer offered pretty good adherence to nanoseconds. So you may also find yourself boxed in by the emulator's abstraction layer.

What you might do is use the RetroArch port of Atari800 since that's one cross-platform library where the developers specifically seek to minimise latency. Inevitably there are a lot of negatives with such a project, but it might at least help with that issue.

Answer 2

Hard to give a definite answer without real measurements.

For Windows there may be a few optimization about how a keyboard is handled:

Disable "Filter Keys" option

"Filter Keys" is part of the accessibility system for handicapped users. When enabled Windows ignores quickly typed keystrokes. To disable open the Windows Control Panel's "Ease of Access Center". Select "Change How Your Keyboard Works" and uncheck "Turn on Filter Keys". Select "Set Up Filter Keys" and disable "Turn on Filter Keys when Right Shift is Pressed for 8 Seconds".

Throw Away All Wireless Mice and Keyboards

Just do it.

Reduce USB Load

While it's not a big thing, having USB devices sharing a single USB controller may add lag. This is especially true if sound (*1) or storage devices are involved.

• Remove all unnecessary devices.
• If the system got multiple controllers, use one only for the keyboard.
• Remove all hubs between keyboard and controller

---

*1 - In your case, using USB sound output would essential doubles the perceived USB lag.