sdltrs: display of typed characters lags keyboard, sometimes permanently by one character

n2185x

Pi Model or other hardware: Raspberry Pi 4, 2GB model
Power Supply used: CanaKIt USB-C 3.5 amps
RetroPie Version Used: 4.6.9
Built From: Pre-made SD card image from RetroPie web site
USB Devices connected: Keyboard, mouse, Atari joystick via Monster Joystick adapter (shows up as "Van Ooijen Technische Informatica Joystick" in "lsusb" output)
Controller used: Atari 800 joystick (keyboard for Emulationstation navigation)
Error messages received: none
Emulator: sdltrs (executable file name is sdl2trs)

If one uses the TRS-80 Model 1 emulator (with either level1.rom, which has MD5 checksum of 1136f64e2c249848f956343862742e1e, or level2.rom, which has MD5 checksum of ca74822ebc2803c6635a55116ecd9539), when one is typing, it won't be long before the emulator "falls behind" what one is typing by one character, such that the emulator doesn't display the character one typed until one types another character. Once this happens, it stays behind no matter how long one waits.

This issue does not happen with the Model 3 or Model 4/4P emulators.

There is one thing that is notable about the Model 3 and 4/4P emulators: the cursor they display blinks, while the Model 1 cursor does not. I've noticed, too, that when typing in the Model 3 and 4/4P emulators, the character I type can be delayed for a small period of time until the cursor blinks, at which point it'll appear.

This suggests that the display refresh in the emulator is dependent upon something being drawn to the display, as if there's a drawing queue that isn't being flushed or something.

I'll happily supply logs and configurations if asked, but this should be trivially reproducible.

mitu

@n2185x I think this is an emulation option, controlled by the keystretch option:

Fine-tune the keyboard behavior. To prevent keystrokes from being lost,
SDLTRS "stretches" the intervals between key transitions, so that the
Z80 program has time to see each transition before the next one occurs.
Whenever the Z80 program reads the keyboard matrix and sees an emulated
key go up or down, SDLTRS waits cycles Z80 clock cycles (T-states)
before it allows the program to see another key transition.
Key transitions that are received during the waiting period or when the
Z80 program is not reading the keyboard are held in a queue.
The default stretch value is 4000 cycles; it should seldom if ever be
necessary to change it

I have it set to default (4000) and I don't get any 'lost' keys, though there's a noticeable delay between typing and the display of characters. Can you check which value you have set (it's in the "Miscellaneous Settings" section of the settings) ?

n2185x

@mitu I have that set to the default of 4000, but I've played with it and it makes no difference whatsoever what value I set it to. Note that I don't see the problem immediately. You can reproduce it by typing relatively quickly. Just a line or two will do, generally.

Also note that I've seen a similar phenomenon with hatari (not lr-hatari), with respect to its configuration GUI (which you get into via F11). There, clicking on a button that is supposed to bring up a second dialog will often result in the second dialog not showing up unless you press a direction key or something that would cause the display to change.

Both are linked against SDL2. This makes me think we're up against a fundamental bug in SDL2 on this platform (or, at least, the version that sdltrs requires).

Note, finally, that there should be no noticeable delay between when you type a key in sdltrs and when the character appears on the screen. That alone is a bug, and I fully expect it's being caused by the same thing. The Raspberry Pi 4 has so much more power than the TRS-80 that it can easily emulate it in full with an enormous amount of room to spare, enough that it is supposed to be able to easily get cycle-exact emulation. The original TRS-80 did not have input or display delays like this, so the emulator shouldn't either.

mitu

@n2185x said in sdltrs: display of typed characters lags keyboard, sometimes permanently by one character:

Both are linked against SDL2. This makes me think we're up against a fundamental bug in SDL2 on this platform (or, at least, the version that sdltrs requires).

Sure, if you can reproduce the issue standalone with a simple SDL2 program, a bug can be submitted to that project.

I don't get the behavior you're seeing with my current config though.

The Raspberry Pi 4 has so much more power than the TRS-80 that it can easily emulate it in full with an enormous amount of room to spare, enough that it is supposed to be able to easily get cycle-exact emulation.

Sure, but that's up to how the emulator is using those resources and implementing the emulated system.

n2185x

@mitu Are you able to see the behavior of hatari that I'm seeing?

Also, what hardware are you using with this? It could easily be that this is limited to the Raspberry Pi 4.

mitu

@n2185x said in sdltrs: display of typed characters lags keyboard, sometimes permanently by one character:

@mitu Are you able to see the behavior of hatari that I'm seeing?

I haven't tested hatari.

Also, what hardware are you using with this? It could easily be that this is limited to the Raspberry Pi 4.

It's a PI4 (4Gb), should similar to your setup.

n2185x

@mitu Which ROM are you using for sdltrs, and what's its md5sum?

If I had some inkling as to how sdltrs functions and makes use of SDL, and spent enough time familiarizing myself with how to build SDL applications, I might be able to write something that can reproduce the issue. But without any of that, and most certainly without any indication as to what could possibly be behind the problem, I can't come up with anything useful as far as a simple test program goes.

n2185x

@mitu I tried the same thing on a different Pi 4, and got the same results.

I'm astonished that the problem doesn't reproduce for you. I don't know how fast you type (I type about 100 words/minute), but I'm able to easily reproduce the issue at will. I can reproduce it by typing a single word followed by a space. The space will often be what puts it into its "delay display by one character" behavior. Once that happens, characters that I type don't show up until I type another character. Sometimes it "recovers" itself but I haven't found the conditions under which that happens, but even after it "recovers" it will easily go back to the errant behavior.

n2185x

@mitu Oh, by the way, if you'd like I'll download a stock Pi4 RetroPie image, update everything to current, then install sdltrs using retropie_setup.sh, and see if it reproduces immediately. You should try the same if you're willing.

mitu

@n2185x said in sdltrs: display of typed characters lags keyboard, sometimes permanently by one character:

@mitu Which ROM are you using for sdltrs, and what's its md5sum?

I'm usig a level2.rom for BIOS and booting a NewDos disk image.

md5sum /home/pi/RetroPie/roms/trs-80/NEWDOS_jv1.DSK
6f624bdbf4b410cfbe8603fa3bef44fa  /home/pi/RetroPie/roms/trs-80/NEWDOS_jv1.DSK

n2185x

@mitu What's the md5 checksum of your level 2 BIOS?

n2185x

@mitu Ah, that's why you can't reproduce the issue! Newdos blinks the cursor.

You need to reboot your TRS-80 Model 1 without a disk. Then you should be able to reproduce the problem. The built-in level 2 BASIC doesn't blink the cursor.

mitu

Yes, without the disc, there seems to be some character 'swallowing' and queueing going on.

n2185x

@mitu Ah, excellent. So I'm not crazy after all. :-)

OK, given that this is reproducible at will, what's the next step here?

mitu

I guess we'll try to find the bug in the emulator. On Windows it doesn't seem to suffer from this issue and it doesn't seem to be a SDL2 input problem.

n2185x

@mitu My suspicion is that it's either a platform-specific display bug (do you already have a Raspberry Pi 3 set up? If so, what happens there?), or a platform-specific timer bug.

As I mentioned, I've seen something very similar to this with the hatari emulator (not lr-hatari, however), with respect to its configuration GUI, wherein the state of the displayed dialog box seems to lag behind by one action (e.g., you click on a checkbox and it doesn't seem to change state until you hit an arrow key or something that would cause it to change the display, or you hit a button and the corresponding sub-dialog doesn't come up until you hit an arrow key or something that would cause it to change the display). This is what makes me conclude that the issue isn't in the emulator itself, but rather is in SDL2 on the Pi 4 at least.

mitu

I've enabled input debugging in the emulator and I can see all the keys presses as registered without any issue, it's the emulator that doesn't seem to react to them. Since the input works fine if a disk image is loaded - or with a Model3/4 - I don't think it is a SDL2 issue.

n2185x

@mitu The input works "fine" if the cursor is blinking (see below). Try it with Model 1 emulation and TRSDOS version 2.3. That version does not blink the cursor and the end result is the same problem.

The issue has nothing to do with whether or not there's a disk image involved. It has everything to do with a blinking cursor, i.e. continuously changing output to the screen. This is why I believe we're up against an SDL issue -- because the same phenomenon is visible in multiple emulators that link against SDL2.

A note about it working "fine": in reality it's not really "fine" as such. There are delays in display of things to the screen that shouldn't be there at all. For instance, in Model 3 emulation (the md5 checksum of level3.rom is ecd0a5a83fca19ea860fe565fad4b061), in BASIC, it will often delay halfway in the display of "READY", e.g. it will display "REA", then delay a little, then display "DY". This isn't completely consistent but the overall behavior and feel of the emulator is such that it's apparent that there are internal delays that simply shouldn't be there, and probably aren't in the same emulator on other platforms.

I think it may be worth testing this on a Pi 3 to see just how much of a platform dependency there seems to be.

n2185x

@mitu It's possible that this isn't an SDL2 issue, but whatever it is, it has the following characteristics:

It is common across multiple emulators (hatari and sdltrs, at a minimum)
It is absent from the same emulator in libretro form (lr-hatari)

That means that whatever it is, it exists in code that is common between two completely different emulators and is simultaneously absent from a different variant of one of the emulators. The only thing I know of that is present in both hatari and sdltrs and is simultaneously absent from lr-hatari is SDL2. Maybe there are other relevant things that qualify, but I don't know what they'd be.

n2185x

@mitu I downloaded the Pi 3 version of RetroPie and put it onto a Pi 3 B+. I then performed a full update of it, then installed sdltrs via retropie_setup.sh (from binaries), then copied over all of the .rom files in the BIOS directory from my Pi 4 as well as the entirety of the trs-80 subdirectory of the "roms" directory. In short, everything on the Pi 3 is identical to how it is on the Pi 4.

The issue does not reproduce on the Pi 3, which means this is almost certainly an SDL2 issue or graphics driver issue (or something else that is specific to the Pi 4). And seeing how plenty of other emulators work just fine, I'm skeptical to the point of disbelief that it's a graphics driver issue.