Hallo! Ich versuche auf meinem Raspberry-Pi (ein alter 1B) mit Raspbian-Buster-Lite DOSBox v0.74-2 zum Laufen zu bringen. Das System ist frisch installiert und aktualisiert, es soll nur im Konsolenmodus laufen, keine grafische Oberfläche. DOSBox habe ich mit apt-get installiert. In der Konfigurationsdatei von DOSBox habe ich usescancodes=false gesetzt (ansonsten ergibt die Tastatur nur Müll) und keyboardlayout=gr850. Jetzt bekomme ich zwar eine QWERTZ-Zuordnung, aber einige Tasten bleiben ohne Funktion (z.B. ü, ä + * # ß) und andere sind weiterhin falsch (z.B. / wird zu &). Im normalen System (ausserhalb der DOSBox) funktionieren alle Tasten. Kennt jemand dieses Problem und hat eine Lösung? Gruß Erni
Ich kenne DosBox nicht vom Nutzen. Gibt es dort config.sys und autoexec.bat ? Klassisch wurde die Keymap in der ersteren festgelegt.
:
Bearbeitet durch User
Hallo Walter, die autoexec.bat ist ein Teil der DosBox-Konfiguration. Eigentlich sollte in dieser Konfiguration keyboardlayout=gr ausreichen, um die deutsche Tastaturbelegung zu bekommen. Bei mir blieb bei allen Einstellungen die QWERTY-Belegung, erst gr850 ergab QWERTZ, aber mit teilweise fehlenden oder falschen Tasten. Eine Ergänzung im [autoexec]-Teil der Konfiguration mit "keyb gr" führte wieder zu der QWERTY-Belegung. Sehr rätselhaft! Gruß Erni
Hallo Erni, ich habe folgende Einstellungen in der Datei "dosbox.conf" vorgenommen: Hier ein Auszug für die zwei Sektionen: [sdl] usescancodes=true [dos] keyboardlayout=auto VG Leo
Hallo Leo, gerade dieses "usesscancodes" musste ich auf false setzen, da ansonsten ein absolutes Wirrwarr von der Tastatur kommt! Es ist nicht mal mehr möglich der DOSBox zu entkommen ausser Stecker ziehen... Dieses Problem ist auch bei Google zu finden. Ich vermute, daß die Voreinstellung mit "usescancodes=true" unter der grafischen Benutzeroberfläche funktioniert, aber ich möchte nur die Konsole starten. Verwendest Du Dosbox im Fenster einer grafischen Oberfläche? Gruß Erni
War nur ein Schuß ins Blaue. Ich hatte unter MSDos immer die nackte Keymap 850 ohne irgendwelche Buchstaben.
Hallo Erni, ja ich verwende Dosbox im Fenster einer grafischen Oberfläche. Versuche mal folgende Einstellung, wie es Walter T. auch vorgeschlagen hat: [sdl] usescancodes=false [dos] keyboardlayout=850 https://www.dosbox.com/wiki/Dosbox.conf https://www.dosbox.com/wiki/KEYB VG Leo
Nein, leider kann DosBox mit Keymap nichts anfangen. Nachdem ich nahezu alle 3-stelligen Codetables durchprobiert hatte, habe ich jetzt wieder keyboardlayout=auto eingestellt und bekomme die gleiche QWERTZ-Anordnung wie zuvor mit gr850. Leider fehlen immer noch die gleichen Tasten, darunter # + * Wenn ich in der DosBox "keyb gr" eingebe wird die Umschaltung auf Codepage 850 bestätigt, die Tastatur ist dann aber QWERTY. Eine Neuinstallation der DosBox hat nichts gebracht... Gleiches Resultat mit "keyboardlayout=850" Ergibt QWERTZ, fehlende Tasten, falsche Tasten (< ergibt \ usw.). Vielen Dank für die Antworten! Erni
Nur um sicherzugehen, Deine Situation richtig verstanden haben: In der Linux-Konsole funktionieren diese Tasten, in der DosBox nicht?
Hi, Auch nur ein Schuss ins blaue aber vielleicht einen Versuch wert: Ist die Tastaturbelegung an der Konsole selbst passend eingestellt? Also funktionieren Umlaute u.s.w. direkt an der Linux-Konsole? Und falls ja -- evtl kommt die Dosbox auch gerade damit nicht zurecht und erwartet eine US-konsole?
Hallo und Danke für die Unterstützung! Richtig, die Tastatur funktioniert in der Konsole problemlos. Die DosBox scheint unabhängig von den Einstellungen in Raspbian zu sein. Komme so leider nicht weiter, werde erstmal aufgeben. Ein glückliches Neues Jahr wünscht Erni
keyboardLayout=auto funktioniert nur auf Windows ;) Ich würde mir einfach mal die Anleitung durchlesen, da steht das auch drin.. hatte damit keine Probleme. https://www.dosbox.com/DOSBoxManual.html#KeyboardLayout The default keyboardlayout=auto currently works under windows only. ->>>>>The language is chosen according to the OS language, but the keyboard layout is not detected.
:
Bearbeitet durch User
Hast du es mal mit einer anderen Tastatur versucht? Ist deine Tastatur vielleicht so eine Multimedia-Tastatur die einen Haufen Media-Tasten mit nicht-standard Tastencodes erzeugt und für die das Linux einen speziellen Treiber auswählt (auswählen muss)? Läd Linux den Treiber? Kommen bei einer anderen Codepage, wie 437, fehlende Zeichen wie #, +, & etc. (auch wenn sie auf den falschen Tasten liegen)?
Ansonsten gäbe es noch den Tip im Debian Forum bei Google mit "Dosbox Umlaute Debian". https://forum-raspberrypi.de/forum/thread/26895-dosbox-keine-umlaute-ae-ue-oe-deutsche-tastatur/?postID=220971#post220971 wenn bei / ein & geschrieben wird, ist es definitiv kein Deutsches sondern ein Englisches Layout.
Ein frohes Neues Jahr! Ja, ich habe es mit zwei verschiedenen Standard-Tastaturen probiert. Mit dem gleichen Ergebnis. Laut Google besteht das Problem wenn DOSBox nicht im grafischem Desktop läuft sondern in der Konsole. Leider hat keiner der ergoogelten Tipps zum Erfolg geführt. Auch die Keyboard-Treiber von FreeDOs, welche empfohlen wurden, zeigen das gleiche Verhalten. Obwohl beim Einstellen der deutschen Tastatur QWERTZ erzeugt wird, sind / und & sowie weitere Zeichen falsch zugeordnet bzw. garnicht verfügbar (*+#). Der Link von Philipp endet mit "... vollkommen verrückt ???", so sehe ich das auch, ich bin ratlos... Gibt hier jemanden der DOSBox unter Raspbian ohne grafischen Desktop mit deutscher Tastatur am laufen hat? Gruß Erni
Habe jetzt eine Raspbian-Buster-Desktop Version auf SD-Card kopiert und DOSBox installiert - läuft auf Anhieb prima, Keyboard OK, alle Tasten richtig. Es bleibt das Problem mit der Konsole-Version. Ersatzweise unter Raspbian-Buster-Lite einen Versuch mit rpix86 gestartet. Soll ebenfalls ein DOS-Emulator sein (benutzt 4DOS). Es ist eine spezielle Version für den Raspi, sollte also klappen - leider kommt beim Start von rpix86 sofort die Fehlermeldung, daß die Library libncurses.so.5 nicht gefunden wurde... Kenne mich mit den Dateien unter Linux nicht aus. Schade. Hat hier jemand schon Erfahrung mit rpix86? Gruß Erni
apt-get install libncurses5 löst das Problem mit der fehlenden Library.
Noch eine Spekulation: Vielleicht sind nicht die Codepages kaputt, sondern die Tastaturbeschreibung. Du kannst dir, soweit ich weiß (nie selber gemacht), unter FreeDOS mit KC eigene Tastatur-Layouts definieren. Vielleicht lohnt es sich mal in eine funktionierende (englische?) und die deutschen Tastaturbeschreibung rein zu sehen um zu verstehen warum bei der einen Zeichen kommen, bei der anderen fehlen. Dann mit dem Gelernten eine eigene Beschreibung aus der funktionierenden Tastaturbeschreibung bauen, die die Zeichen dort hin legt, wo sie auf einer deutschen Tastatur sind.
Zu rpix86: Danke an Kristallkugel für die Hilfe. Die fehlende Lib habe ich nachinstalliert und rpix86 lässt sich nun starten. Neben dem Terminalfenster öffnet sich kurz ein leeres Fenster welches sofort wieder geschlossen wird. Es erscheint diese Fehlermeldung im Terminal: pi@pi-targa:~/rpix86 $ ./rpix86 ./rpix86 -a1 -d/home/pi/rpix86 -f1 -w640 -h400 libEGL warning: DRI2: failed to authenticate rpix86: /home/pi/rpix86/source/gles_video.c:514: gles_init: Assertion `surface != ((EGLSurface)0)' failed. Abgebrochen Als root mit sudo su passiert das selbe. (Unter Raspian-Buster-Desktop) Linux ist keine Fertigsuppe und ich bin kein Koch. Gruß Erni
Mit der Desktop-Version hast Du es an der grafischen Konsole probiert und nicht an der Text-Konsole, oder? (Hatte ich beim Lesen zuerst anders verstanden und mich gewundert, daher die Frage) Ein wesentlicher Unterschied zwischen der üblichen Konfiguration der grafischen und der Text-Konsole ist der Typ der Terminal-Emulation, d.h. welche Codes die Tastatur sendet und welche Codes das Display verarbeiten kann. Dazu gibt's die Variable TERM, mit der eine Applikation den Typ der Konsole ermitteln kann, um sich dann entsprechend zu verhalten. Probier mal an beiden Konsolen: echo $TERM Da kommen wahrscheinlich unterschiedliche Werte raus, vermutlich xterm oder linux Falls ja könnte das schon mal ein Ansatzpunkt sein um es weiter einzugrenzen...
Erni schrieb: > pi@pi-targa:~/rpix86 $ ./rpix86 > ./rpix86 -a1 -d/home/pi/rpix86 -f1 -w640 -h400 > libEGL warning: DRI2: failed to authenticate > rpix86: /home/pi/rpix86/source/gles_video.c:514: gles_init: Assertion > `surface != ((EGLSurface)0)' failed. https://pi3d.github.io/html/FAQ.html
Ich hatte gehofft, daß bei einem frisch installierten Raspbian und der durch den Raspi vorgebenen Hardware bekannte Voraussetzungen für ein zu installierendes Programm vorliegen. Die Raspbian-Installation und das anschliessende Update liefen problemlos. Auch FreePascal läuft, soweit ich es bisher benutzt habe (USB4all (sprut) mit Synaser), sowohl von der Konsole (Buster-Lite), im Terminal (Buster-Dsktop) und Remote(SSH). Das Problem mit DOSBox habe ich nicht alleine, aber eine brauchbare Lösung scheint es nicht zu geben. Bleibt nur die Möglichkeit es unter dem grafischem Terminal zu nutzen, was auch gut funktioniert. Ich hätte meinem alten Raspi gerne die grafische Oberfläche erspart, gegenüber einer flotten Textumgebung. Ev. ist auch das aktuelle Raspbian nicht optimal dafür und eine ältere Version besser geeignet. Danke an alle Unterstützer! Erni
Erni schrieb: > Das Problem mit DOSBox habe ich nicht alleine, aber eine > brauchbare Lösung scheint es nicht zu geben. Hast Du das mit dem TERM noch probiert was ich oben vorgeschlagen hatte? (falls noch nicht bekannt: die Text-Konsolen kannst Du aus der grafischen per Ctrl-Alt-F1 bis -F6 erreichen -- zurück dann per Alt-F7 -- brauchst also nicht das Lite-System zu booten)
Hallo Mathias, ich habe es noch nicht probiert, werde es morgen machen. Aber ich wüsste auch nicht, wie mir die Ergebnisse weiterhelfen. Ich habe leider zu wenig Ahnung davon. Ich vermute die Ursache des Problems in DOSBox selber. Wenn DOSBox schon in der Konsole funktioniert hat, dann vielleicht in einer frühen Version von Raspbian (Buster ist ganz aktuell). Ich habe mehr Hoffnung wenn ich es mit einer älteren Version von Raspbian noch einmal probiere. Oder siehst Du eine Möglichkeit es in der jetzigen Konfiguration ans laufen zu bekommen? Gruß Erni
was macht denn "dpkg-reconfigure locales" bzw. bei "sudo raspi-config" das Tastaturlayout?
Ist jetzt zwar sicher schon 10 Jahre her, aber ich meine mich zu erinnern, dass DOSbox und dosemu nie vernünfig an der Konsole liefen, also auch am PC nicht. Ist deutlich einfacher den Inhalt der simulierten VGA einfach in ein X11-Fenster zu rendern, als aus den Änderungen im RAM wieder Escape-Sequenzen bzw. ncurses-Befehle zu basteln, um damit dann eine Terminal-Emulation zu füttern. Hing aber auch von den verwendeten EXEs ab, also davon wie diese ihre Text-Ausgaben bewerkstelligt haben.
Erni schrieb: > Ich vermute die Ursache > des Problems in DOSBox selber. Wenn DOSBox schon in der Konsole > funktioniert hat, dann vielleicht in einer frühen Version von > Raspbian (Buster ist ganz aktuell). Ich habe mehr Hoffnung wenn > ich es mit einer älteren Version von Raspbian noch einmal probiere. Hat es früher in Raspbian schonmal funktioniert? > Oder siehst Du eine Möglichkeit es in der jetzigen Konfiguration > ans laufen zu bekommen? Falls das TERM in beiden unterschiedlich ist, sehe ich da einen Ansatzpunkt -- man müsste dann entweder dosbox beibringen, mit dem Terminal-Typ der Linux-Konsole umzugehen, oder umgekehrt die Linux-Konsole auf einen Typ umkonfigurieren den dosbox versteht. Ob und wie das geht hab ich jetzt noch nicht geschaut, falls beide TERM nämlich gleich sind bräuchte man in diese Richtung garnicht weitersuchen ;-)
Aluhutträger schrieb: > Ist jetzt zwar sicher schon 10 Jahre her, aber ich meine mich zu > erinnern, dass DOSbox und dosemu nie vernünfig an der Konsole liefen, > also auch am PC nicht. Ich denke auch, dass das kein Raspi-spezifisches Problem ist, sondern irgendwo auf den höheren Software-Layern liegt... > Ist deutlich einfacher den Inhalt der simulierten VGA einfach in ein > X11-Fenster zu rendern, als aus den Änderungen im RAM wieder > Escape-Sequenzen bzw. ncurses-Befehle zu basteln, um damit dann eine > Terminal-Emulation zu füttern. Hmm, die Linux-Konsole hätte ja auch einen Grafikmodus...und hier ist ja erstmal die Tastatur das Problem, wenn ich recht verstanden hab scheint die Anzeige zu funktionieren (oder wurde noch garnicht getestet weil die Eingabe schon nicht geht)...
@ Philipp K. Die Tastatur wurde mit "sudo raspi-config" auf deutsch eingerichtet, es werden auch alle Tasten richtig wiedergegeben, sowohl in der Konsole als auch im graf. Desktop, nur nicht in der DOSBox. @ Aluhutträger Es ist der Tastaturtreiber bzw. die Umsetzung auf den deutschen Zeichensatz. Dies funktioniert bei DOSBox in der Konsole nicht richtig. Ich habe per Google nur von ungelösten Problemen gelesen, kein Beispiel einer funktionierenden Installation. richtig laufen tut es wohl nur im graf. Desktop, oder im englischen Layout in der Konsole. @Mathias A. Das es ev. unter einer älteren Raspbian-Version laufen würde war nur meine Vermutung/Hoffnung. echo $TERM liefert LXTerminal : Xterm-256-color Crtl-Alt-F1 : linux Habe gerade folgendes getestet: DOSBox läuft im graf. Desktop mit der Einstellung "usescancodes=true". Ändere ich dies auf "false", so habe ich die gleichen Tastaturprobleme wie in der Konsole. DOSBox kommt also nur mit seiner eigenen Tastaturübersetzung zurecht, nur leider liefern die Scancodes in der Konsole absoluten Müll... Gruß Erni
Jetzt gibt es ganz neue Erkenntnisse! Habe nochmal die SD-Karte mit Raspbian-Buster-Lite (ohne graf. Desktop) eingesteckt und mit "sudo apt-get install libncurses5" nachinstalliert (Hinweis von Kristallkugel wg. rpix86) Jetzt lässt sich rpix86 starten und zeigt das DOS-Prompt. ABER es existiert das gleiche Tastaturproblem wie bei DOSBox! Also ist DOSBox unschuldig und es liegt an der Konsole? Ein Linux-Problem? Noch verrückter: Starte ich rpix86 aus mc (2-Fenster Filemanager) heraus klappt es wie oben beschrieben, rufe ich ./rpix86 direkt aus der Konsole auf kommt die Fehlermeldung: gles_init: Assertion'((EGLBoolean)0) != result' failed Immere ratloser... Erni
Philipp K. schrieb: > was macht denn "dpkg-reconfigure locales" bzw. bei "sudo raspi-config" > das Tastaturlayout?
Ups überlesen.. dann poste mal bitte Deine Konfigurationsdatei. Das sollte mit keyboardlayout=gr funktionieren.
Hallo Philipp, leider habe ich DOSBox inzwischen deinstalliert, aber die Konfiguration war "usescancodes=false" und "keyboardlayout=gr" als auch gr850, de... und weitere Vorschläge, alle ohne Erfolg. Mit "dpkg-reconfigure locales" war de_DE.UTF-8 UTF-8 eingestellt, ich habe jetzt noch de_DE ISO-8859-1 hinzugefügt - gleiches Resultat... (mit rpix86). Ich dreh' mich im Kreise...
Da DOSBox und rpix86 das gleiche Problem mit der Tastatur haben liegt es wohl nicht an dem jeweiligen Programm. Einen Fehler der Konsole oder von Linux schliesse ich auch aus. Es hängt wahrscheinlich mit dem jeweiligen DOS- Keyboardtreiber zusammen, da habe ich wohl etwas falsch gemacht. Ich suche weiter...
Erni schrieb: > Ich habe per Google nur von ungelösten Problemen gelesen, > kein Beispiel einer funktionierenden Installation. > richtig laufen tut es wohl nur im graf. Desktop, > oder im englischen Layout in der Konsole. > ... > Habe gerade folgendes getestet: > DOSBox läuft im graf. Desktop mit der Einstellung "usescancodes=true". > Ändere ich dies auf "false", so habe ich die gleichen Tastaturprobleme > wie in der Konsole. > DOSBox kommt also nur mit seiner eigenen Tastaturübersetzung zurecht, > nur leider liefern die Scancodes in der Konsole absoluten Müll... Da kommt mir noch eine Idee, vielleicht bringt es was wenn man die Konsole auf das englische Layout konfiguriert? Dann sendet sie auf jeden Fall andere Codes an DOSBOX -- wenn die Berichte dass es mit der englischen Tastatur auch in der Konsole geht stimmen, dürfte dann zumindest kein Müll mehr rauskommen sondern halt die Zeichen die die englische Tastatur hat. Und dann innerhalb der DOSBOX auf die deutsche Belegung konfigurieren... > @Mathias A. > echo $TERM liefert > LXTerminal : Xterm-256-color > Crtl-Alt-F1 : linux OK, wie vermutet also unterschiedlich -- ich schau mal ob man die Linux-Konsole irgendwie konfigurieren kann, das interessiert mich selbst auch -- melde mich dann später nochmal...
Das seltsame ist ja, dass beide Programme (dosbox und rpix86) nach dem Start schon auf QWERTZ arbeiten, was auf ein deutsches Tastaturlayout hindeutet - nur nicht bei allen Tasten. Da jetzt gerade nur rpix86 installiert ist, habe ich aus Verzweifelung mal das uralte K5.COM gestartet. Das hat rpix86 gnadenlos abstürzen lassen... rpix86 benutzt 4DOS.COM (als COMMAND.COM), ich weiß nicht wie ich dafür an Keyboardtreiber komme, MSDOS keyb gr funktioniert nicht und meldet falsche DOS-Version. Ist hier überhaupt ein Keyboardtreiber unter DOS erforderlich?
startest Du Dosbox als einzelne Xsession oder als Framebuffer etc.? Als XSession gilt das Keyboardlayout der XSession, wäre dann aber nicht "Headless". EDIT: Man könnte auch versuchen Dosbox als "SCREEN" Session zu starten um das mit dem Terminal auszuschliessen.
:
Bearbeitet durch User
Hallo Philipp, ich starte Dosbox direkt in der Konsole, also nach dem booten von Linux und dem Login durch Eingabe von "dosbox" (nicht "./dosbox"). In der Konsole selber sind noch alle Tasten vorhanden und richtig zugeordnet. Auch FreePascal mit einer IDE im Textmodus liefert korrekte Tasten. Erst nach dem Start von Dosbox (wenn das DOS-Prompt erscheint) ist die Tastaturzuordnung fehlerhaft. Das gleiche Verhalten zeigt aber auch rpix86! Schade, daß hier kein Linuxkenner mit eigenem Raspi dieses Problem nachvollziehen kann. Gruß Erni
Die DOS-Emulatoren benutzen wohl SDL für grafische Darstellungen, aber wohl auch für das Keyboard. Hier scheint die Übereinstimmung von DOSBox und rpix86 zu sein. Mein Gedanke: SDL ist schuld !? Kann das sein? Gibt es Abhilfe?
War zuerst nur so mein Gedanke, jetzt gerade gegoogelt und ich bin mir ziemlich sicher: SDL ist das Problem! Linux und Konsole sind OK! Hab' aber für mein Problem noch keine Lösung...
Da war doch mal was mit extra Tastaturtreibern fuer PC104-Tastaturen, die mit den extra Windowstasten? wendelsberg
Hallo wendelsberg, meinst Du im Zusammenhang mit SDL? Angeschlossen habe ich eine Standard-Tastatur mit nur der einen Windows-Taste unten links.
Erni schrieb: > Mein Gedanke: SDL ist schuld !? Wenn ich das richtig verstanden habe, werden die Ziffertasten immer besonders behandelt. Zumindest steht so was etwas in der SDL FAQ zu usescancodes
Das was ich bisher zum Thema SDL/SDL2 und Raspi ergoogelt habe, sieht für mich nach sehr schwerer Kost aus. Dieser Aufwand ist mir zu groß, da er nicht sicher zum Erfolg führt. Habe jetzt schon mehr Zeit als vorgesehen in dieses Problem gesteckt, da alle Änderungen im Raspi-System nur sehr langsam ablaufen. Sollte jemand eine "Out of the box"-Lösung zu diesem Thema kennen, wäre ich dafür sehr dankbar! Ansonsten gebe ich mich damit zufrieden, daß meine Wunschvorstellung nicht realisierbar ist. Vielen Dank an alle Ratgeber! Erni
Also ich habe das mehrfach gemacht, auch wenn schon länger her und hatte diese Probleme nicht. Vielleicht mit XSession versuchen.
:
Bearbeitet durch User
Hallo Philipp, was genau hast Du gemacht? Und wie? Dosbox auf dem Raspi mit Raspbian ohne grafischen Desktop mit deutscher Tastatur? Kannst Du dich noch erinnern welche Raspbian-Version und welche Dosbox-Version es waren mit der es ohne Probleme lief? Dankeschön, das gibt wieder Hoffnung :) Erni
Dosstyle :/ KEYB.EXE [FD-KEYB] KEYBOARD.SYS. https://retrocomputing.stackexchange.com/a/5195 KC http://help.fdos.org/en/hhstndrd/base/keyb-kc.htm http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/keyb/2.0/
Danke Pong! Hast Du unter DOSBox diese Treiber verwendet? Meine bisherigen Versuche mit DOS Keyb.-Treibern haben die fehlenden Tasten (z.B. #+* ) nicht erzeugt, diese Tasten blieben ohne Wirkung. Ich werde es mit den von Dir verlinkten Treibern morgen noch einmal probieren. Gruß Erni
Mathias A. schrieb: >> @Mathias A. >> echo $TERM liefert >> LXTerminal : Xterm-256-color >> Crtl-Alt-F1 : linux > > OK, wie vermutet also unterschiedlich -- ich schau mal ob man die > Linux-Konsole irgendwie konfigurieren kann, das interessiert mich selbst > auch -- melde mich dann später nochmal... So, habe nun ein bisschen deswegen recherchiert -- aber wie es aussieht kann man da leider nichts konfigurieren bzgl. Typ des Terminals. Siehe z.B. https://en.m.wikipedia.org/wiki/Linux_console: > The Linux console implements a terminal type of "linux" and the escape sequences it uses are in the console_codes man page. Kann auch nachvollziehen dass Du nicht beliebig lange damit rumprobieren willst -- trotzdem mal noch bisschen Hintergrund was ich gefunden habe, vielleicht interessiert es ja auch den ein oder anderen sonst: Der Ablauf vom Tastendruck bis zur Applikation wird hier ganz gut beschrieben: https://wiki.archlinux.org/index.php/Keyboard_input Demnach wird aus einem scancode ein keycode und daraus dann ein keysymbol -- und zwischen den beiden letzteren ist die Umsetzung der Tastaturbelegung. Mein früherer Vorschlag, die Konsole selbst auf US-Tastatur zu stellen, kam daher dass DOSBox offenbar ja selbst auch auf die deutsche Belegung umsetzt, und damit u.U. zweimal die Belegung umgesetzt wird. Das dürfte ziemlich sicher zu "Müll" führen... Wie ich jetzt sehe macht das also nur Sinn falls DOSBox keysymbols verwendet, bei keycodes oder den scancodes ist ja noch keine Umsetzung der Belegung erfolgt. Hattest Du eigentlich mal noch probiert ob sich was ändert wenn man die Konsole umkonfiguriert? Allzu große Hoffnung dass das was nützt habe ich nach diesen Erkenntnissen allerdings nicht mehr... ~~~ Im obigen Link fand ich folgendes auch noch interessant: > For USB keyboards, it is apparently necessary to use evtest(1) from the evtest package instead of showkey D.h. es scheint einen Unterschied zu geben zwischen USB- und anderen (vermutlich sind welche mit PS/2-Anschluss gemeint) Tastaturen. Bisher ging ich davon aus dass die aus Software-Sicht identisch sind. Nützt hier natürlich nix da der Raspi ja kein PS/2 hat, aber vielleicht hilft es ja mal bei ansonsten unerklärlichen Tastaturproblemen am PC...
Philipp K. schrieb: > EDIT: Man könnte auch versuchen Dosbox als "SCREEN" Session zu starten > um das mit dem Terminal auszuschliessen. Das könnte in der Tat helfen, ich hatte bei meiner Recherche irgendwo gelesen (hatte leider nicht notiert wo), dass dort eine ähnliche Umsetzung der scancodes/keycodes erfolgt wie unter X... Alternativ zu screen gibts auch noch tmux. Wäre beides recht schnell getestet, einfach dosbox mal darin starten -- wenn es nicht direkt geht nochmal mit usescancodes=true probieren -- wenn es geht gut, wenn nicht kann man das immerhin abhaken ;-)
:
Bearbeitet durch User
@ Mathias Danke für die Mühe! Ich werde morgen weitertesten. Dann liege ich mit meiner Vermutung, daß SDL die Ursache ist, falsch?
Erni schrieb: > Dann liege ich mit meiner Vermutung, daß SDL die > Ursache ist, falsch? Meine Vermutung ist, dass es eher eine Inkompatibilität ist, als ein Fehler in einer der beteiligten Komponenten -- aber eben auch nur eine Vermutung... So kam ich ursprünglich zu dem Ansatz, entweder das Terminal umzukonfigurieren -- was nun ja leider nicht geht -- oder DOSBox an das "linux"-Terminal anzupassen -- dort hatte ich jetzt zwar nur kurz in die Doku geschaut, aber konnte auch nix finden was man konfigurieren könnte, außer dem usescancodes. Insofern bliebe hier wohl nur, den Code von zumindest einem von beiden zu patchen...aber solange man nicht viel Langeweile hat, wäre sicher besser einfach beim grafischen Desktop zu bleiben ;-) Die Idee mit screen oder tmux finde ich dagegen in der Tat einen Versuch wert -- die beiden stellen gewissermaßen eine Zwischenschicht zwischen der Konsole und der Applikation dar, ähnlich wie auch X. Ach ja, nix zu danken, die Funktion von Konsole/Tastatur/usw. hatte mich eh schon länger mal interessiert, so war das eben ein guter Anlass dafür :-)
:
Bearbeitet durch User
Erni schrieb: > Hast Du unter DOSBox diese Treiber verwendet? Nein. > Meine bisherigen Versuche mit DOS Keyb.-Treibern haben die > fehlenden Tasten (z.B. #+* ) nicht erzeugt, diese Tasten > blieben ohne Wirkung. einfach zu probieren keyb.exe u. keyboard.sys kopieren C:\keyb de [oder halt de|gr , 437|850|852|...] FreeDOS KEYB 2.01 - (c) Aitor Santamaría Merino - GNU GPL 2.0 Keyboard layout : KEYBOARD.SYS:DE [437] (3) C:\keyb /u FreeDOS KEYB 2.01 - (c) Aitor Santamaría Merino - GNU GPL 2.0 Resident part of Keyb removed. ---- wenns prinzipiell funktioniert sich dem interessanten Teil widmen. "The KEY keyboard programming language" /DOC/KC/KEY.TXT gr.key oder gr453.key suchen /layouts/SOURCE/KEYB/
Guten Morgen! Habe jetzt Screen installiert, da es im System noch nicht vorhanden war: sudo apt-get install screen Abfrage mit screen --version ergibt: Screen version 4.0602(GNU) 23-Oct-17 Starten von DOSBox ergibt: DOSBox version 0.74-2 Copyright..... _ Exit to error: Can't init SDL Unable to open a console terminal Dieser Abbruch erfolgt unabhängig davon, ob ich usescancodes=false oder true gesetzt habe. Es wäre nett, wenn Philipp etwas genauer beschreiben würde, wie er DOSbox ohne diese Probleme installiert hat. @ Pong: Die Freedos Treiber habe ich auch probiert, KEYB.EXE, KEYBOARD.SYS und die KEYBRDx.SYS Dateien sowie das precompiled GR.KL aus dem Link von dir. Leider sind auch jetzt die fehlenden Tasten weiterhin ohne Funktion. Bin jetzt erstmal dabei Raspi, USB-Hub und die ganze Kabelage auf ein Kunststoffbrett zu montieren und dieses mit Abstandshaltern an die Monitor-Rückwand (VESA-Halterung) zu schrauben. Sieht ordentlich aus und schafft eine Menge Platz auf dem Arbeitstisch :) Gruß Erni
Sorry :/ Könntest evtl. schauen ob "keycode.exe" diese Tastendrücke registriert.
@ pong Guter Tipp! Keycode.exe liefert bei den fehlenden Tasten keinen Code! Andere Tasten werden von Keycode erkannt. Tastatur bereits gewechselt, gleiches Ergebnis. Ich werde die Sache jetzt erstmal beiseite legen, blicke da nicht mehr durch. Vielleicht habe ich später dafür einen klareren Kopf und besseren Durchblick... Allen ein schönes Wochenende! Erni
ich versuche mir mal ein VMWare Image zu erstellen, mein Raspi hats gesegnet.. ich habe zwar noch ein fertiges Image für den OrangePiPC, das lief auch für eine Industriemaschine allerdings mit Custom Kompilierung. Ich werde das mal nachbilden. ein Iso Deiner SD Karte soweit nix persönliches dabei ist könnte weiterhelfen.
Hallo Philipp, danke für das Angebot, aber ich möchte nicht, daß du dir extra Arbeit deswegen machst. Ich hatte nur gehofft, daß dir seinerzeit bei der Installation etwas aufgefallen ist, was ich bisher übersehen habe. Ich glaube, es ist unnötig die doch sehr große Image-Datei der SD-Karte hier hochzuladen, da ich eine frische Installation von Raspbian-Lite gemacht habe sollte der Download von https://downloads.raspberrypi.org/raspbian_lite_latest identisch sein. Bitte mache Dir keine Arbeit, geniesse das Wochenende! Gruß Erni
Ich finde das Problem so oder so interessant, habe ein eigenes DosBox SVN-Repo mit diversen Code Änderungen. Wenn der Schwerpunkt Dosbox ist, wieso nicht Pidora oder Ubuntu ausprobieren? das Image ist doch schnell gesichert und neu installiert.
:
Bearbeitet durch User
Nein, DOSBox ist nicht der Schwerpunkt, wäre nur schön gewesen... Raspbian-Lite habe ich gewählt, weil der mein alter Raspi doch ziemlich leistungsschwach ist. Für DOSBox habe ich alternativen, es läuft gut unter Windows und Linux auf dem PC. So gesehen ist alles in Butter, interessant wäre nur die Ursache meines Problems - "ist es nun mal so" oder mache ich etwas falsch? Danke für das Interesse!
Erni > Für DOSBox habe ich alternativen, es läuft gut unter Windows und > Linux auf dem PC. Die Tasten funktionieren auf dem PC Lin/Win bei gleicher Dosbox-version?
Ja, unter jedem grafischen Desktop, auch auf dem Raspi, gibt es keine Probleme. Nur nicht wenn von der Konsole gestartet.
... und noch einmal der Hinweis, daß es mit rpix86 genau das gleiche Tastaturproblem gibt. Und beide, rpix86 und DOSBox, benutzen SDL ...
Puuh, hab' davon leider keine Ahnung. Ich dachte SDL übernimmt die grafische Dartellung in der Konsole, so daß kein grafischer Desktop notwendig ist. Ein "startx" kennt Raspbian-Lite nicht. Und SDL übernimmt auch die Tastatur, deshalb mein Verdacht...
Das interessante ist, mit Scancodes=true sind zwar Buchstaben und Tasten quer durcheinander aber es verstecken sich Umlaute auf einigen Tasten. Dazu tritt das Problem allgemein bei "Debian Buster" auf, nicht nur beim Raspberry. Ich meine es lag daran das Dosbox der Kontext fehlt welcher eigentlich mit Screen vorhanden sein sollte, als Headless XSession (gab es glaube ich auch) wäre auch ein Kontext vorhanden.
:
Bearbeitet durch User
Für mich sieht es so aus als müsste man lediglich die Tasten in der mapper.txt neu zuordnen während scancodes=true ist.
:
Bearbeitet durch User
Hallo Philipp! Das betrifft sicher alle Konsole-Programme welche die SDL verwenden? Kannst Du sagen, ob es unter Wheezy noch funktioniert hat? Gruß Erni
Keine ahnung, also ich habe mir das mal angeschaut.. Mit Scancodes=true sind alle Tasten verschoben.. Quasi die Tastatur in der Mitte geteilt und die beiden hälften vertauscht. Ich habe dieses in den Dosbox sourcen gefunden:
1 | #if !defined (WIN32) && !defined (MACOSX) && !defined(OS2)
|
2 | /* Linux adds 8 to all scancodes */
|
3 | else key-=8; |
4 | #endif
|
Mit Scancodes=true wird beim drücken von "L" das "A" gedruckt. ;) bedeutet Headless die drei Zeilen auskommentieren und neu kompilieren.
:
Bearbeitet durch User
Noch kurz mein workaround in Debian Buster: apt-get install build-essential apt-get install apt-src apt-src install dosbox //Sourcen werden nach /root/dosbox_074BLA entpackt sed -i 's/else key-=8;//' /root/dosbox-074BLABLA/src/gui/sdl_mapper.cpp apt-src build dosbox dpkg --install /root/dosbox_0.74-2-3BLABLABLA.deb dosbox
:
Bearbeitet durch User
Uii, das war ja eine kriminalistische Meisterleistung, der Ursache auf die Spur zu kommen! Ein Versatz der Scancodes um 8 - seltsam. Will Dosbox hier einen Fehler der SDL geradebiegen, was jetzt Aufgrund inzwischen korrigierter SDL-Libs nicht mehr nötig ist und deshalb zu Fehlern führt? Danke für den Einsatz! Erni
Erni schrieb: > was jetzt Aufgrund > inzwischen korrigierter SDL-Libs nicht mehr nötig ist und > deshalb zu Fehlern führt? Ich denke mal eher das es im Gui mit Fenstermanager schon seinen Sinn hat, sonst wäre das bestimmt schon oft Thema gewesen. Ist halt nur Headless ein Problem, ich benutze Headless nur um die Dosbox direkt automatisch zu starten und dann als Vollbild auch schon ein Programm bereitzustellen. Das braucht sonst auch keiner.
Wenn ich https://www.dosbox.com/wiki/KEYB richtig verstehe gehört in die dosox.conf keyboardlayout=gr oder keyboardlayout=129 in DOS selbst kannst du dann ggf noch keyb gr 850 oder keyb gr 437 eingeben
JJ schrieb: > keyboardlayout=129 man schreibt das soweit ich gelesen habe in der neuen Version "keyboardlayout=de129". Klappt bei mir. Damit sollten alle Tasten funktionieren
@ Philipp und JJ Verstehe ich euch richtig, Dosbox laüft in der Konsole mit "keyboardlayout=de129" mit QWERTZ und allen Tasten? Oder nur nach den von Philipp beschriebenen Änderungen und Neukompilierung? Ich hatte "de129" zuvor noch nicht probiert, bekomme damit jetzt aber QWERTY und weiterhin fehlende Tasten. Habe das Workaround von Philipp aber noch nicht durchgeführt. Wenn es ohne Neukompilierung bei euch richtig läuft, ist mein Problem wohl nur ein Einzelschicksal. Ev. hilft es, das Image noch einmal neu auf die SD-Karte zu kopieren. Gruß Erni
Ich habe beim Dosbox Entwickler nachgefragt, das mit der Wirren Tastatur ist wirklich ein Bug im Headless Mode der noch niemandem aufgefallen ist oder umgangen wurde. de129 sollte man schon qwertz bekommen. müsste ich nochmal zuhause überprüfen.
Also nochmal zusammengefasst.. 1. Mit Scancodes=False fehlen die Umlaute, die sind ebenso nicht implementiert. Wenn ich keyboradlayout= Leer lasse habe ich qwertz bei scancodes=false, aber keine Umlaute. 2. Bei Scancodes=True subtrahiert Dosbox intern immer 8 vom Scancode ab weil es nur vom X Server der 8 addiert ausgeht. Entweder baut man sich einen Headless X Framebuffer wie xvfb X11 oder directfb drumherum. 3. Ich selbst bekomme auf scancodes=false keine Umlaute hin. Außerdem ist das mit den Keycodes etwas undurchsichtig. Mein Workaround dauert 5 Minuten.. nacheinander in die Konsole getippt und fertig.
Danke Philipp für deine eifrige Arbeit! D.h., nach dem Workaround arbeiten alle Tasten, ausser die Umlaute. Damit kann man leben, kein Problem! Die Tasten für # + * ' sind jetzt aber vorhanden? Und die Tasten < und > liefern die korrekten Zeichen? Ich werde morgen die Befehle nach deiner Anleitung eintippen - bin sehr gespannt! Jetzt wünsche ich aber erstmal eine Gute Nacht! Erni
Erni schrieb: > D.h., nach dem Workaround arbeiten alle Tasten, ausser > die Umlaute. Damit kann man leben, kein Problem! nein das geht schon mit usescancodes=false,keyboardlayout=none und ganz unten unter [autoexec] keyb GR 437 . Da funktioniert auch das Scharfe "S" nicht, aber das meiste in QWERTZ. Bei meinem Workaround funktioniert alles ausser den "Alt_GR" Sonderzeichen.
Also, gerade noch einmal probiert (ohne das Workaround): Usescancodes=false keyboardlayout=none (keyb GR 437 nicht in die autoexec der Config eingetragen) Dosbox-Tastatur ist: QWERTZ, jedoch sind einige Tasten falsch zugeordnet, z.B.: < wird \, / wird &, & wird ^ Gebe ich nun C:> keyb GR 437 ein, so wird dies bestätigt mit "Keyboard layout GR loaded for codepage 437" Jetzt passt es, < ist <, ist , & ist & aber Z und Y sind vertauscht (QWERTY)! Und in beiden Fällen sind die fehlenden Tasten weiterhin nicht vorhanden. Dieses gleiche Verhalten habe ich zuvor schon mit etlichen Kombinationsversuchen gehabt. Zum Workaround: Der erste Schritt wird nicht durchgeführt, mit der Meldung: "build-essential ist schon die neueste Version (12.6)." Der zweite Schritt wird ohne Fehlermeldung durchgeführt. Der dritte Schritt: sudo apt-src install dosbox "Sie müssen einige >>source<<-URIs für Quellpakete in die sources.list-Datei eintragen. E: No such source" Es scheint, als wären unsere Linux-Installationen nicht kompatibel zueinander oder ich habe wieder einen dummen Fehler gemacht. Wie zuvor schon gesagt, DOSBox ist nicht lebenswichtig für mich. Ich möchte dieses Thema beenden. sudo shutdown -h now! Erni:)
Erni schrieb: > "Sie müssen einige >>source<<-URIs für Quellpakete in die > sources.list-Datei eintragen. > E: No such source" > > Es scheint, als wären unsere Linux-Installationen nicht > kompatibel zueinander oder ich habe wieder einen dummen > Fehler gemacht. Weder - noch, einfach der Anweisung der Fehlermeldung folgen: > ... einige >>source<<-URIs für Quellpakete in die sources.list-Datei eintragen Also einfach in /etc/apt/sources.list zu jeder (relevanten) Zeile
1 | deb http://mirrordirector.raspbian.org/raspbian/ stable main contrib non-free rpi firmware |
eine Zeile für die Sources hinzuzufügen (oder den Lattenzaun entfernen, falls bereits auskommentiert vorhanden):
1 | deb http://mirrordirector.raspbian.org/raspbian/ stable main contrib non-free rpi firmware |
2 | deb-src http://mirrordirector.raspbian.org/raspbian/ stable main contrib non-free rpi firmware |
Schuss ins Blaue: Versuche mal, die Programme mit SDL_NO_RAWKBD=true davor zu starten. Vielleicht bringt das ja was. Ansonsten scheint es keine passenden Umgebungsvariablen für SDL selbst zu geben. Das Problem ist, dass gewisse Tasten schlicht ignoriert werden, das hat also mit der Tastaturbelegung nichts zu tun. Je nach Belegung fehlen halt unterschiedliche Zeichen.
So, ich habe das Problem gefunden keine ahnung wieso da noch keiner draufgekommen ist. Also in der Config einstellen: usescancodes=false keyboardlayout=GR mapperfile = path-to-mapper-file //Pfad zur hier angehängten Datei. Ich habe einfach über Strg+F1 alle Tasten zum DE Keyboard neu gemapped.. da muss man erstmal drauf kommen. Komisch das man dazu nichts findet.
:
Bearbeitet durch User
Philipp K. schrieb: > Ich habe einfach über Strg+F1 alle Tasten zum DE Keyboard neu gemapped.. > da muss man erstmal drauf kommen. Komisch das man dazu nichts findet. Hmm, das würde heißen, dass die SDL auf der Linux-Konsole andere Keycodes liefert als unter einer grafischen Umgebung. Klingt nach einem SDL-Bug. Theoretisch sollte "usescancodes=true" aber überall funktionieren, ansonsten ist das ebenfalls ein SDL-Bug.
S. R. schrieb: > Theoretisch sollte "usescancodes=true" aber überall funktionieren, > ansonsten ist das ebenfalls ein SDL-Bug. Ja der bug liegt in DosBox.. In X basierten Videotreibern wird zu den Scancodes 8 dazuaddiert.. Dosbox prüft beim kompileiren nur auf "Linux, Mac oder Win und subtrahiert nur bei Linux 8 von den Scancodes. Wenn man die Codezeile löscht klappt es Linux ohne X auch.
:
Bearbeitet durch User
> Ja der bug liegt in DosBox
und auch in rpix86 (dem anderen DOS-Emulator)?
Bitte nicht anfangen auch dort zu reparieren!
Erni
Erni schrieb: > und auch in rpix86 (dem anderen DOS-Emulator)? Ob es nun ein Bug oder egal ist weil sonst niemand auf die Headless Idee kommt. Erni schrieb: > Bitte nicht anfangen auch dort zu reparieren! Geht nicht! Das sind closed Sources, die kann man nicht selbst kompilieren. Dosbox nutze ich ja selbst, bzw habe dieses in einem Projekt genutzt... daher hatte die Problemlösung für mich einen Nutzen, interessant ist es auch ein komplettes MS-DOS manuell in der Dosbox zu installieren.
:
Bearbeitet durch User
Welch ein Wahnsinn, alle Tasten funktionieren,
selbst die Umlaute und die Zeichen über AltGr!
Nur bei mir noch ein winziges Problemchen...
Z und Y sind vertauscht.
Habe in der map-Datei jetzt die Einträge für
key 121 und key 122 vertauscht und alles ist OK!
Ein baldiges schönes Wochenende!
Erni
> ...weil sonst niemand auf die Headless Idee kommt.
Ja, ich bin schon ein komischer Vogel :)
Erni schrieb: >> ...weil sonst niemand auf die Headless Idee kommt. > Ja, ich bin schon ein komischer Vogel :) Ich hatte die Idee ja auch.. quasie.. Auf dem Raspi einen Schnellboot in die Headless Shell mit direktem Dosbox Start ohne Login. Hat man ohne viel Klimmbimm das Dos tool auf dem Schirm, total ohne Overhead.
> Auf dem Raspi einen Schnellboot in die Headless Shell mit direktem > Dosbox Start ohne Login. Hat man ohne viel Klimmbimm das Dos tool auf > dem Schirm, total ohne Overhead. Genau! Und ohne Platzverbrauch, da direkt an den Monitor geschraubt. Erni schrieb: >> ...weil sonst niemand auf die Headless Idee kommt. > Ja, ich bin schon ein komischer Vogel :) Passenderweise hätte ich hier kopfloser Vogel schreiben sollen :)
man kann echt alles im Mapper machen.. man kann x und y tauschen: Strg+F1: y im Bild drücken, dann "add" anklicken und y auf der echten Tastatur drücken. Für z das gleiche. Wenn du qwerty hast ist defintiv ob shell oder dosbox-config kein Deutsch eingestellt.
:
Bearbeitet durch User
Sehr komisch, sowohl raspi-config als auch dosbox-config sind auf deutsch eingestellt. In der Dosbox stimmten ja auch alle Tasten, sogar die Umlaute. Wenn die Tastatur nicht auf deutsch eingestellt wäre, würden ja auch ausserhalb der Dosbox falsche Tasten erscheinen, dies war aber nie der Fall. Es ist eine DELL-Tastatur in qwertz ohne spezielle Multimediatasten. Die Änderungen für z und y in der map-Datei waren mit dem Texteditor sehr einfach durchzuführen. Alles ist gut! Ich danke Dir für die Hilfe, Philipp! Erni
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.