[Fixed] The emulator only handles one key event at a time, and it interferes with mouse/joystick input

[DragWx]

The quickest way to observe this is:

1. At the ready prompt, type MOUSE 1
2. Try waggling the mouse while repeatedly mashing keys on the keyboard.
3. Observe that the mouse movement becomes very choppy.

The offending code is in video.c, where keyboard, mouse, and joystick events from SDL are handled. While the event handler is set up as a loop, it exits early whenever a keydown or keyup event is received, which blocks any additional key events or mouse/joystick updates until the next frame of X16 video is rendered. Mouse and joystick events don't block, it's just the keyboard.


So, how did I find this?
I noticed the kernal had a limitation where kbd_scan only reads one scancode at a time, so for games, you need to repeatedly call kbd_scan in a loop or else all keyboard input will be buffered as one-change-per-frame. I think this is fine in many cases, it's just that game developers will need to be aware of this and how to work around it.

I used the codex to write a simple test (attached): a scancode handler which INC's a memory address (i.e., how many times the scancode handler runs per kbd_scan call), and a custom IRQ handler which repeatedly calls kbd_scan until it detects that the scancode handler ran 0 times (i.e., when the i2c keyboard buffer is empty).

To use this test, extract the contents of the attached ZIP file somewhere the X16 can access it, then open the codex and load "KBDTEST.ASM". Exit back to BASIC, then type SYS $4000 to install the hooks (a side effect is, you lose the flashing cursor, but you can still type like usual). Now, mash the keyboard, then type PRINT PEEK($3003). This value represents the maximum amount of scancodes that were received in one IRQ. In the emulator, this is always "1", but on hardware, I imagine this number will get larger.

...and that's why I looked at the emulator source and found what I found.

[TomXP411]

This should be fixed in R42 or R43. Would you re-check and let us know?

[DragWx]

Thank you, this does appear to be fixed with r43; the mouse movement isn't choppy when mashing the keyboard, and I was able to get the test in the ZIP to report "3" after a bunch of keyboard mashing.