![]() |
1 Attachment(s)
Quote:
I'm running OS 3.9, maybe a different OS is causing the problem? Tried it with 'keyboardlayout' set to both 'us' and 'gr' and neither caused a crash with the latest Aminet version 0.74.032. Code:
# This is the configurationfile for DOSBox 0.74. |
As I wrote earlier, I'm running a fresh install of 3.1.4. If the port is OS-friendly, which I assume, it should work the same way as with OS 3.9.
Maybe it's not the character "ö" sent to DOSBox, but the scancode? Are the scancodes of a German keyboard different? Also note this issue has been reported by others in this thread: https://eab.abime.net/showpost.php?p...9&postcount=50 (OS 3.1) https://eab.abime.net/showpost.php?p...5&postcount=78 https://eab.abime.net/showpost.php?p...&postcount=114 And yes, keyboardlayout is not related to the issue. But it also does not fix it when set to the "correct" layout. |
Check my configuration file posted above, scan codes are set to false.
|
I know, that was not the reason for my question.
I'm just trying to think what could cause the crash. Also, if I'm not mistaken, that option only controls the mapper, but at some layer in the code, it has to deal with scancodes anyway when processing the input, doesn't it? Not sure if that helps finding the culprit, but the crash does not happen in the mapper. I can press "ö" or any other non-standard key there just fine. But the mapper has no name for the key(s) and just says "key unknown". Trying to assign anything to one of those unknown keys results in a freeze and a GURU. |
I assume you were not able to find anything that could be the cause of the keyboard/freeze issue?
Also, I noticed that "vgaonly" does not work. It complains about not finding a suitable screen mode, even when fullscreen is set to false. Seems like some checks are in the wrong order. In windowed mode, there's no need to search for a suitable screen mode. In fullscreen, I can have about 1250 cycles before it starts to struggle. This is with svga_s3. I would guess vgaonly could allow a few more cycles. |
Quote:
Quote:
Quote:
A long time ago we tried to improve the core emulation speed with a JIT compiler but it proved too difficult and the dosbox community weren't too interested in helping, that's the only way to make this port faster. |
Quote:
Quote:
As for speed, I'm not blaming you. It seems something in the design of DosBox makes it slow, but certainly not the interpreter approach. PC-Task 4 in the interpreter version has no issue performing like a 486 @ 33-40 MHz on Emu68, whereas DosBox only reaches AT speed (286, 6-8 MHz). I still want to be able to use it due to sound emulation, which PC-Task lacks. |
Quote:
|
You always only read half of my posts, do you? :D
PC-Task comes with both. As I wrote, I was refering to the non-jit interpreter version. The jit version can not be benchmarked, as its speed is all over the place. |
As for "vgaonly", I sorted that. Seems like in your port, the option is just "vga".
|
After lots of testing, I think I found the root for the keyboard issue: the mapper file is *completely* ignored.
I noticed other strange behavior first, like that y and z are swapped when they shouldn't. So I edited the mapper-0.74.map and made key_y use 122 instead of 121 and key_z 121 instead of 122. But nothing changed, the keys were still swapped. Did the same using the included mapper and it worked. Well, almost. Despite clicking on "Save", the change was gone on next start. No changes were written to mapper-0.74.map (which, as just described, would not have worked anyway), and I can even delete the file completely without any feedback from DOSBox. The file is simply not used. Conclusion: without the mapper file being used, one can never fully adapt the keyboard to a non-English one. The freeze when pressing e.g. the "Ö" key can most likely be solved if key_ö would be added to the mapper file. But that requires that it is actually used... |
Quote:
When I get the time I'll take a look at the code. |
Let's hope it is an easy fix. :)
|
All times are GMT +2. The time now is 04:16. |
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.