Hochkomma auf deutscher Atari-Tastatur

[Mado]

Ich bin gerade dabei, ein Keyboard-Mapping für Hatari zu erstellen. Dabei ist mir aufgefallen, dass ich auf der deutschen Atari-Tastatur gar kein Hochkomma finde: '

Ein weiteres Problem ist, dass Hatari alles in Scancodes umwandelt. Die atari-seitige Kombination aus Modifyer (Shift, Control, Alternate) und der jeweiligen Taste ermögicht aber nicht, dass ich alle Zeichen der PC-Tastatur tippen kann. Zum Beispiel mappt Hatari # korrekt, drücke ich aber Shift dazu, lande ich bei ^ und nicht beim Hochkomma.

Dazu wäre es aus meiner Sicht nötig, auf der TOS-Seite einen eigenen Tastaturtreiber oder ein eigenes Mapping zu haben, der/das einfach nur die PC-Tastatur-Scancodes reingesteuert bekommt und dann die korrekten Zeichen herstellt. Also Atari mit echter PC-Tastatur sozusagen.

Gibt es da vielleicht schon Lösungen? Vielleicht im Zusammenhang mit PS/2-Tastaturadaptern?
Dafür wäre es dann nötig über Native Features oder so einfach direkt den Scancode vom Emulator-Host/PC empfangen zu können, ohne, dass SDL da was umwandelt.

Wie geht Ihr mit dieser Thematik um bzw. habt ihr hier für euch Lösungen gefunden?

[Mado]

Die XBIOS-Funktion 16 Keytbl erlaubt ja sogar das Verändern der Tastaturbelegung. Interessanterweise taucht bei mir da CAPSLOCK als Modifyer auf, aber nicht ALTERNATE. :-/ Wilde Sachen dieses XBIOS.

http://toshyp.atari.org/de/004014.html#Keytbl

Ah, offenbar gibt es ab TOS 4 auch die Alternate-Taste berücksichtigt. Aber nur in der KEYTAB-Struktur, nicht in der XBIOS-Funktion. :-/

http://toshyp.atari.org/de/004016.html#KEYTAB

Frage: Kann ich mit Keytbl (oder anders) einen Zeiger auf die KEYTAB-Struktur bekommen, ohne, dass ich deren drei Pointer über angegebene Parameter verändern muss? Liegt die originär im ROM oder kann man die in-place verändern?

[Arthur]

Ich bin gerade dabei, ein Keyboard-Mapping für Hatari zu erstellen. Dabei ist mir aufgefallen, dass ich auf der deutschen Atari-Tastatur gar kein Hochkomma finde: '

Bei mir geht das ' auf der PC-Tastatur in Hatari mit der Taste nach dem (ß?\).

[Mado]

Ja, stimmt. Aber dafür sind dann wieder die Accents nicht da oder wieder woanders.

Ich schau mal, ob ich dafür eine Lösung programmieren kann... Ist ein schönes kleines Anfänger-Projekt.

[Thorsten Otto]

Die XBIOS-Funktion 16 Keytbl erlaubt ja sogar das Verändern der Tastaturbelegung. Interessanterweise taucht bei mir da CAPSLOCK als Modifyer auf, aber nicht ALTERNATE. :-/ Wilde Sachen dieses XBIOS.

Ja, für ALT gibt es in alten TOS Versionen keine Tabellen. Erst MagiC/MiNT/EmuTOS unterstützen das, aber ansonsten ist das Mapping in verschiedenen sprach-abhängigen TOS-Versionen im BIOS hard-kodiert. Das ist im übrigen (abgesehen vom dargestellten Datums-Format im Desktop) praktisch der einzige Unterschied zwischen den verschiedenen offiziellen sprach-spezifischen TOS-Versionen.

Für Hatari gibt es verschiedene Möglichkeiten das zu umschiffen. Zum einen gibt es eine keymap.cfg mit der man einige codes ummappen mappen kann. Mein sieht z.Z. so aus:

Code: [Auswählen]

45,53     # _/-
91,26     # Ü
93,27     # +
92,41     # #
96,43     # ~
121,44
122,21

Zum anderen hängt es auch von der Einstellung ab ob symbolische- oder Scancodes benutzt werden. Je nachdem (und je nach SDL Version) funktioniert mal das eine oder das andere besser.
Ausserdem hat es wohl zuletzt In Hatari ein paar Änderungen gegeben die ein paar mehr Möglichkeiten beinhalten, hab ich mir aber noch nicht angeschaut.

Frage: Kann ich mit Keytbl (oder anders) einen Zeiger auf die KEYTAB-Struktur bekommen, ohne, dass ich deren drei Pointer über angegebene Parameter verändern muss?

Ja, mit Keytbl((void *)-1, (void *)-1, (void *)-1)

Problem ist das die zurückgelieferte Struktur je nach TOS-Version 3-10 Pointer enthält. Die Struktur liegt aber nicht im ROM und kann geändert werden.

[Mado]

Die Struktur liegt aber nicht im ROM und kann geändert werden.

Bist Du sicher? Hatte ich versucht. Ich habe die Pointer auf die 128-Byte-Arrays genommen und da rein geschrieben. Gab nen Bus-Error. Mir scheint, die Pointer selbst liegen nicht im ROM, damit sie bei den größeren EmuTOS-Versionen dynamisch geändert werden können. Aber die Tabellen selber, die ich ja verändern will, liegen offenbar im ROM. Nützt mir also nichts.

Daher mühe ich mich gerade ab, ein TSR-Programm zu bauen, was die geänderten Tabellen dann im .data Segment enthält und resident bleibt. Später vielleicht mal dynamisch änderbar:

https://forum.atari-home.de/index.php/topic,17144.msg261784/topicseen.html#msg261784

[Mado]

Zum anderen hängt es auch von der Einstellung ab ob symbolische- oder Scancodes benutzt werden.

Meine momentane Idee ist, den Hatari auf Scancodes zu schalten, die 1:1 durch zu leiten und dann das TOS so zu konfigurieren, dass es dann quasi mit der PC-Tastatur arbeitet und schön pc-gerecht die Tasten wirklich so nutzen kann, wie sie sind. Heißt, dass es selbst bestimmen kann, dass die Taste, auf der das # liegt, mit Shift dann das ' ergibt und nicht das ^. Das finde ich viel sauberer.

Das würde ermöglichen, dass man PC-Tastaturen am Atari ohne jede Kompromisse nutzen könnte.

Mein Programm momentan ist in C geschrieben und funktioniert auch schon. Ich habe allerdings momentan die Tabellen aus dem EmuTOS geklaut und nur zum Test a mit b vertauscht. Also, wenn man ein a drückt, kommt ein B. das klappt auch. Nur ist das C-Programm im Speicher momentan noch viel zu groß.

[Thorsten Otto]

Bist Du sicher? Hatte ich versucht. Ich habe die Pointer auf die 128-Byte-Arrays genommen und da rein geschrieben.

Ja, bin ich Andernfalls könnte man ja über die Funktion die Pointer nicht ändern. Genauer gesagt: die eigentliche Struktur liegt im RAM, sodaß man die Pointer ändern kann. Die 128-byte Tabellen auf die sie zeigen liegen allerdings im ROM.

[goetz @ 3rz]

Nur ist das C-Programm im Speicher momentan noch viel zu groß.

Das liegt wohl eher an manchen Library-Funktionen als an C. Andere Funktionen nehmen, oder andere Library.

[Thorsten Otto]

Wenn du es mit gcc übersetzt, solltest du auf jeden Fall den startup code ersetzen, ansonsten wird die halbe mintlib eingelinkt, was in dem Fall völlig unnütz ist. Auch solltest du printf() durch Cconws() ersetzen (ist ja nur ein konstanter String). Auch eine dummy __main() Funktion ins programm einzubinden (wie in Markus Beispeil) hilft. Danach sollte das Programm nicht viel grösser als 1K sein.

[Mado]

Andere Funktionen nehmen, oder andere Library.

Noch eine interessante Aufgabe: Mal gucken, wie klein man mit C werden kann. -nostdlib oder so habe ich einige Male gesehen, aber was man alternativ dann braucht, muss ich noch auskundschaften...

[mfro]

Wenn man das geschickt anstellt, ist es (fast) egal, wie groß das eigentliche Programm ist.

Am Ende willst Du ja möglichst nur die Key-Tabellen im Speicher behalten und Ptermres() zählt immer vom Start der Basepage (Du kannst also "nur hinten" Speicher freigeben).

Sorgt man dafür, dass die Tabellen ganz vorne im Textsegment des Programms liegen - z.B. so:

Code: [Auswählen]

       .text
        .globl  _space
_space:
        .fill 2048-256,1, 0
(und als erste Datei auf der Kommandozeile aufführen)

ist es egal, "wieviel Programm" dahinter noch kommt, Ptermres() gibt den Speicher ja ans OS zurück.

Wenn Du willst, kann die Tabelle auch ein - mit
 

Code: [Auswählen]

__attribute__((section(".text")))
"verschönertes" C-Array sein.

[Thorsten Otto]

Mit gcc musst du die Tabellen nur mit "const" deklarieren, dann landen sie auch im Text-Segment.

Davon auszugehen daß sie am Anfang des Text-Segmentes liegen würde ich aber nicht, solange C-Code im Spiel ist. Man kann nie wissen was der Compiler dann anstellt, solche Tricks sollte man wirklich nur in Assembler benutzen.

[Mado]

ist es egal, "wieviel Programm" dahinter noch kommt, Ptermres() gibt den Speicher ja ans OS zurück.

Das ist für mich die Herausforderung: Ptermres gibt ja nicht allen Speicher zurück, sondern nur vom Anfang der TPA + angegebene Größe "keepcnt". Wie ich diesen letzten Wert dann beim Aufruf von PTermres errechne, das wäre das Interessante. Hier: http://toshyp.atari.org/de/00500b.html#Ptermres steht:

"keepcnt    Anzahl der Bytes, die resident gehalten werden sollen (gilt ab Anfang der Basepage und schließt die Länge des TEXT, DATA und BSS Segments des Programms plus der Länge des Stacks ein; Minimum sind 128 Bytes)."

(Nebenbei, das in der Klammer verstehe ich nicht. Wenn ich es selber angebe, dann ist es doch so, wie ich es angebe. Nur, wenn es selbst etwas errechnet, dann kann es die entsprechenden Segmente mit einschließen. Weil, dann entscheidet "Ptermres" und nicht ich.  Die Formulierung ist missverständlich, zumindest für mich. Es müsste vielleicht heißen "... und schließt unter Umständen die Länge... ")

Ich weiß aber in C immer noch nicht, wie ich diesen Wert errechnen kann. Momentan habe ich einfach ordentlich Speicher spendiert. In Assembler kann ich nen Label setzen. Aber in C? Auch ein Label?

Zudem: keepcnt ist ja ab Null. Das Programm ist ja relozierbar. Ich müsste also keepcnt errechnen aus:

Ende des Arrays minus Anfang der TPA? Wie mach ich das? Am besten mit Label-Adressen, oder?

Oder wird der Beginn der TPA immer mit Null gezählt, so dass das Ende des Arrays nichtmehr die TPA (=0) abgezogen bekommen muss?

Sorry, wenn ich so frage. Aber ich bin da noch nicht so bewandert...

[Mado]

Wenn die TPA immer bei Null beginnen würde, dann wäre es einfach:

keepcnt = Anfang des Arrays + Länge des Arrays.

[mfro]

Compiliere dein Programm mit

Code: [Auswählen]

-Wl,-Map -Wl,mapfile
Das erzeugt eine Link-Map (in der Datei ab der Zwischenüberschrift "Linker script and memory map"). Du kannst so kontrollieren, ob deine Tabellen auch da gelandet sind, wo Du sie haben wolltest.

Was die Adressberechnung angeht: gängige Startup-Codes (zumindest der der mintlib und von libcmini) speichern einen Zeiger auf die Basepage in der globalen Variablen _base.
Mit _base + <Offset deiner Tabellen von dort> + <Länge deiner Tabellen> solltest Du den Wert für keepcnt leicht errechnen können.

[Mado]

Super, danke für den Tip!

[czietz]

Dabei ist mir aufgefallen, dass ich auf der deutschen Atari-Tastatur gar kein Hochkomma finde: '

Auch wenn der Aufdruck auf der Tastenkappe etwas anderes suggerieren mag, ist das Hochkomma (ASCII 0x27) sehr wohl auf der unten markierten Taste vorhanden.

Wie geht Ihr mit dieser Thematik um bzw. habt ihr hier für euch Lösungen gefunden?

Überall 1-zu-1-Mapping auf Atari-Layout. Egal, ob ich am echten Atari mit Atari-Tastatur arbeite, am Atari mit USB-Tastatur (via Lightning ST/VME) oder am PC unter Hatari. Damit ist z.B. der Backslash immer auf [Shift]+[Alt]+[ü]. Alles andere empfinde ich als eine viel zu große Umstellung.

Für mich ist das perfekt, wer das aber nicht mag: Es gibt viele Programme, um die Tastatur auf dem Atari zu "personalisieren". Mir wurde von Nutzern der USB-Tastatur CKBD ans Herz gelegt: https://www.chzsoft.de/site/hardware/diverse-kleinigkeiten-fur-den-atari-st/#ckbd-1.6-composed-characters-keyboard-driver (Funktioniert natürlich auch mit der Atari-Tastatur.)

[Mado]

Interessant. Sowohl das Programm, wie auch die Sache mit dem Hochkomma. Ich hatte mich am Atari-Zeichensatz in der Wikipedia orientiert:

https://de.wikipedia.org/wiki/Atari-ST-Zeichensatz

Dort gibt es alle drei Zeichen, Hochkomma, Accent Grave und Accent Degue. Und ich wäre nie auf die Idee gekommen, dass Atari beim TOS ein Accent Degue aufdruckt und aber ein Hochkomma ausgibt.  :-/

Das Programm ist so in etwa, was ich gerade bauen wollte, offenbar nur in schön. :-)

Momentan habe ich das Problem, das Hatari zwei Tasten auf meinem Notebook offenbar mit einem ungewöhnlich hohem Symbol mappt, auch noch zwei Tasten, mit dem gleichen. Sieht man bei mir, wenn man hatari --trace keymap nutzt. Links die Taste ^° und links neben dem Backspace '` geben das gleiche SDL-Symbol bei mir aus:

Code: [Auswählen]

key down: sym=1073741824 scan=53 mod=0x0 name=''
key map: sym=0x40000000 to ST-scan=0x0d
key up: sym=1073741824 scan=53 mod=0x0 name=''

Code: [Auswählen]

key down: sym=1073741824 scan=46 mod=0x0 name=''
key map: sym=0x40000000 to ST-scan=0x0d
key up: sym=1073741824 scan=46 mod=0x0 name=''
Ich möchte wie schon geschrieben erreichen, dass ich alle Notebook-Tasten wie gewohnt benutzen kann und möchte TOS so konfigurieren, dass es das schluckt.

[mfro]

...
"keepcnt    Anzahl der Bytes, die resident gehalten werden sollen (gilt ab Anfang der Basepage und schließt die Länge des TEXT, DATA und BSS Segments des Programms plus der Länge des Stacks ein; Minimum sind 128 Bytes)."

(Nebenbei, das in der Klammer verstehe ich nicht. Wenn ich es selber angebe, dann ist es doch so, wie ich es angebe. Nur, wenn es selbst etwas errechnet, dann kann es die entsprechenden Segmente mit einschließen. Weil, dann entscheidet "Ptermres" und nicht ich.  Die Formulierung ist missverständlich, zumindest für mich. Es müsste vielleicht heißen "... und schließt unter Umständen die Länge... ")
...

Vielleicht das noch aufgelöst: 128 Bytes ist der vom System genutzte Teil der Basepage (ohne die Kommandozeile), der auf jeden Fall bleiben muss, damit ein vom System nutzbarer PD bleibt (wobei das natürlich ziemlich sinnlos wäre, wozu soll ein Programm ohne Code und Daten und nur einer Basepage noch gut sein?) - das ist das Minimum.
Und Basepage + Code + Data + BSS + Stack ist eben das Maximum (allerdings auch nicht ganz richtig - wenn der Startupcode kein Mshrink() aufruft, gehört dem Programm zum Zeitpunkt des Ptermres() die gesamte TPA, man kann also durchaus auch mehr übrig lassen - mein FOLDRXXX macht das so).