Keyboard response progressively slows down

[larsbrinkhoff]

Reported by @kidmirage, and I have also seen something similar with the Knight TV console emulator.

(I have only seen this when run on Raspberry Pi, but then I rarely keep the emulators running long on a PC.)

[guidol70]

I also did see this behavoir fast... the first keys come quick, but then it take "ages" in 60Hz Mode
With 15Hz Mode it does work for me including commit 94f8bbd (sync) and 9443748 (OpenGL display).

On the latest commit from the 17th of June vidoe.c with 15Hz doesnt help anymore :(
I cant input anything but cursor blinks normally :(

Also my Ordroid C2 (S905-CPU QuadCore 1.54Ghz) couldnt handle the 60HZ in all versions.
So I think the "problem" could be on another place in the code? ;)

[larsbrinkhoff]

When I try the latest commits on a Raspberry Pi 4, it will not handle 60 Hz either. I seem to recall I tried the GPU shader at some point and it seemed fine at that point.

With the new option -N2 (30 Hz update rate) the Pi 4 is ok. Running top the CPU is far from overloaded at -N1 (60 Hz), so I don't understand what's going on. The Raspberry Pi GPU shares memory with the CPU, so maybe affects the system. But other programs seem responsive.

[guidol70]

Thanks for the new commit.
I did try "./vt100 -Q -N2 bash"
This did work in the window, but mostly get also stuck for input in fullscreeen mode (F11). :(

I dont know if its really supported (or its a feature-bug :) ) BUT when I try
"./vt100 -Q -N4 bash" or "./vt100 -Q -N6 bash" I didnt got the problem that the fullscreen do get stuck for input.

With "./vt100 -Q -N6 bash" I got a working htop and a long "ls -l /usr/bin" without errors
and also Ctrl-C seems to have effect on htop and the ls-command (OK ls takes a few seconds longer because of more output).
It seems that the balance of the emulation is more optimized for output than input.

Could we also have an option to disable the sound?
I do get only correct a start-beep while opening the terminal, but then mostly only cracking sounds - also while idle with no output/input. Couldnt hear a difference between root or ormal user (root sometimes on some system doesnt have rights for audio (pulseaudio))

For me htop seems to work better than top :)

[guidol70]

so I don't understand what's going on.

and it has nothing to do with the following compile-warning? :

main.c:60:13: warning: ‘throttle’ defined but not used [-Wunused-function]
 static void throttle (void)

[larsbrinkhoff]

Yes, sound could also be disabled. The cracking noise is really indicative of a deeper problem but as a band-aid or if you just don't want the sound it can be silenced.

The warning is harmless. It's just an unused function I have kept around. It's for disabling sound, actually.

[SegHaxx]

Heads up I'm working on a fix for the sound crackle/sound disable, but still needs a little more work to be 100% accurate.

The slowing keyboard response seems to result from the emulator falling behind "wall time", for the moment you can increase "frameskip" -Nx until it stops, but even then if the emulator falls behind due to say, some momentary lag from a large gcc compile on the same machine, it can still fall behind and have trouble catching up. Still wrapping my head around whats happening there and how to fix it.

[larsbrinkhoff]

Thanks!

As you may have noted, the simulator relies on the sound output to synchronize simulated time (8080 cycles) against real time.

I suspected the slowdown could be because of falling behind as you describe, but since the main/SDL thread is rarely at 100% I didn't look into it.

[n7275]

I'm probably quite late to the party but I will note the slowdown occurs roughly an order of magnitude sooner If I disable audio output. I'm also running this on a laptop from 2010 that struggles to run Firefox, so probably the fault of my slow hardware.

[larsbrinkhoff]

@rricharz discovered that patching the LOG calls in keyboard.c to printf seems to alleviate the problem.