AtariX => MagicOnLinux

[ragnar76]

Erster Versuch, nicht so geil geworden wie ich mir das vorgestellt habe.

[AndreasKromke]

Sehr schick! Insbesondere der dunkle Hintergrund ist sehr viel seriöser als das gräßliche Gritzegrün. Das könnte ich auch mal ändern.

Wo hast Du die andere Schriftart her? Ich kann mich dunkel erinnern, daß man unter macOS, das damals noch MacOS hieß, die Schriftarten des Gastgebersystems verwenden konnte; das geht jetzt nicht mehr. Ich hatte damals auch, glaube ich, einen proportionalen Systemzeichensatz verwendet. Ist mir entfallen, welcher das war. Lang ist's her.

[AndreasKromke]

Es ist immer wieder putzig, was so alles an alten Fehlern bzw. Unschönheiten auffällt. Im Vierfarbmodus nimmt das AES eine Schriftgröße von 8x16, wenn der Bildschirm mindestens 320 Pixel hoch ist (das gilt wohl für alle Modi). Andererseits sind die Fenster- und andere GUI-Elemente dann horizontal gestreckt. Der VT52 verwendet aber den 8x8-Zeichensatz. Und das WINFRAME.SLB kann nur breite Rahmen, d.h. beim 8x8-Zeichensatz und mindestens 16 Farben bleiben die Fensterrahmen breit.

Upps: Bei 640x320x16M verwendet AES die 8x16-Zeichen, VT52 die 8x8-Zeichen, aber (!) die Abstände zwischen den Zeilen sind 16 Pixel, und der der Cursor blinkt 8x16 und erzeugt smutts. Der Fehler tritt auf bei weniger als 400 Pixeln Bildschirmhöhe.

[ragnar76]

Wo hast Du die andere Schriftart her?

Das ist der Monaco Font der bei NVDI mitgeliefert wird.

[AndreasKromke]

Der Grund für die horizontal gestreckten GUI-Elemente im Modus "vier Farben" war relativ einfach zu finden. Das AES ist nämlich schlau und versucht, einige Elemente quadratisch zu machen, bei vorgegebener Höhe. Dazu braucht es die tatsächliche Pixelgröße. Die kommt vom VDI und wird in Mikrometern (Merkel sagte mal "Mühkrometer", aber die hat ja auch sonstwo sonstwas studiert ...) angegeben. Das VDI wiederum kriegt die Pixelgröße vom Bildschirmtreiber. Die VDI-Bildschirmtreiber geben üblicherweise 278 µm Pixelgröße an. Zum Vergleich: Ein 32-Zoll-4k-Monitor hat etwa 180 Mikrometer pro Pixel.

Nun gibt es zwei Ausnahmen: Der 16-Farb-Interleaved-Treiber verdoppelt die Pixelgröße in beide Richtungen, ein Relikt vom ST (niedrige Auflösung). Und der 4-Farb-Interleaved-Treiber verdoppelt die Pixelgröße vertikal, ein Relikt von der "mittleren" Auflösung des ST, und dadurch ergibt sich die Streckung.

Ich habe jetzt den Vierfarbtreiber so geändert, daß die vertikale Pixel-Streckung nur bei 640x200 ausgeführt wird, und - voilá - jetzt sieht es in den anderen Auflösung ordentlich aus. Dabei habe ich auch gleich ein paar sehr imposante Assembler-Befehle entfernt, die völlig überflüssig waren.

Was bleibt? Bei "ST-mid" ist der Mauszeiger häßlich gestreckt. War das beim ST auch so? Muß mal Hatari konsultieren. Und das CHGRES-Fenster darf man nicht verschieben, dann gibt es nämlich smutz. Vielleicht war der weiße Bildschirm die ehrlichere Lösung. Ich nehme an, daß sich Magxdesk beendet, um CHGRES statt seiner zu starten, und damit verschwindet der Desktop-Hintergrund. Vielleicht gibt es keinen Default-Hintergrund, das weiß ich nicht mehr.

[ragnar76]

Wie sieht es egtl. mit der Unterstützung vom Mausrad aus? Ich stolpere jedesal darüber dass das nicht geht 

[AndreasKromke]

Leichen über Leichen im Keller, diesmal stand "Behne" drauf    ...

Die Bildschirmtreiber für 16M, 32k und 16 Farben hatten eine kaputte Routine zum Zeichnen des VT52-Cursors. Der entsprechende Code war bei allen dreien von irgendwo her kopiert worden und totaler Quatsch. Das fiel nur auf bei weniger als 400 Bildschirmzeilen und abgeschaltetem VT52.PRG, denn dann verwendet der VT52 den 8x8-Zeichensatz. Im Taskmanager sah man es auch nicht, weil der Cursor hier abgeschaltet wird.

Die Reparatur war relativ simpel. Gut, wenn man den Quältext hat.

Die Mausrad-Unterstützung ist kniffelig, weil man dazu die vertikalen Fenster-Scrollpfeile simulieren muß, soweit ich verstanden habe. Die Nachrichten müßten wie Mausbewegungen oder virtuelle Tasten verschickt werden, über entsprechende Pakete. Weißt Du, wie EmuTos das macht? Da müßte ich wohl mal in den Quelltext von EmuTos schauen. Das ist langwierig und aufwendig. Aber ja, ich stolpere inzwischen auch darüber, daß das nicht geht, weil es jedes andere BS kann.

PS: Der Mauszeiger in "ST mid" sieht tatsächlich bei Hatari genauso schaise aus...

[ragnar76]

Weißt Du, wie EmuTos das macht?

Ich hab von nix ne Ahnung aber dafür jede Menge 
Thorsten Otto weiß das aber bestimmt

[AndreasKromke]

Ich hab von nix ne Ahnung aber dafür jede Menge 
Thorsten Otto weiß das aber bestimmt

Und Christian Zietz müßte es wissen, er ist der Spezialist. Die Netzsuche spuckt für Scrollrad nichts aus, aber dank Quelloffenheit (https://github.com/emutos/emutos) kann ich ja selber mal suchen. Hoffentlich ist der Code so gut kommentiert, daß ich da durchsteige. Dreiundzwanzig Megabyte! Uff! Ich kann ja erstmal nach "wheel" suchen ..

[ragnar76]

Ich hab von nix ne Ahnung aber dafür jede Menge 
Thorsten Otto weiß das aber bestimmt

Und Christian Zietz müßte es wissen, er ist der Spezialist. Die Netzsuche spuckt für Scrollrad nichts aus, aber dank Quelloffenheit (https://github.com/emutos/emutos) kann ich ja selber mal suchen. Hoffentlich ist der Code so gut kommentiert, daß ich da durchsteige. Dreiundzwanzig Megabyte! Uff! Ich kann ja erstmal nach "wheel" suchen ..

Eine schnelle suche bei Google hat das hier ausgespuckt:

Code: [Auswählen]

SDL_Event event;
while (SDL_PollEvent(&event)) {
    if (event.type == SDL_MOUSEWHEEL) {
        if (event.wheel.y > 0) {
            // Scrollen nach oben (Wheel Up)
        } else if (event.wheel.y < 0) {
            // Scrollen nach unten
        }
    }
}


[czietz]

In EmuTOS selbst eingebaut ist die Unterstützung für das Eiffel-Interface, das eigene Scancodes für das Mausrad nutzt: https://github.com/emutos/emutos/blob/04bac280c67c0f440020bb45f2473fb8e292dce5/bios/ikbd.c#L748. Diesen Code habe ich mangels Eiffel aber nie genutzt/getestet.

Hatari geht einen anderen Weg und simuliert Cursor-Keys: https://github.com/hatari/hatari/blob/25209273095ff6ad6191cd17d47955815452ce5f/src/sdl/gui_event.c#L219. Das hat den Vorteil, auch mit Atari TOS zu funktionieren.

[czietz]

Eine schnelle suche bei Google hat das hier ausgespuckt:

Code: [Auswählen]

SDL_Event event;
while (SDL_PollEvent(&event)) {


Das ist aber mit Sicherheit nicht aus EmuTOS. 

[Thorsten Otto]

Was bleibt? Bei "ST-mid" ist der Mauszeiger häßlich gestreckt. War das beim ST auch so? Muß mal Hatari konsultieren.

Ja, war beim ST auch so. In Hatari fällt das nicht so sehr auf, weil dort auch der Bildschirm vertikal gestreckt wird, aber man sieht, daß der Mauscursor über zwei Textzeilen geht. Das kann man wohl auch kaum umgehen, es gibt zu viele Stellen an denen ein Mauszeiger von genau 16x16 angenommen wird.

[AndreasKromke]

Hatari geht einen anderen Weg und simuliert Cursor-Keys: https://github.com/hatari/hatari/blob/25209273095ff6ad6191cd17d47955815452ce5f/src/sdl/gui_event.c#L219. Das hat den Vorteil, auch mit Atari TOS zu funktionieren.

Aha, Danke! Ich hatte jetzt nur Hatari mit dem EmuTOS-Desktop ausprobiert, und da scrollt das Mausrad die Verzeichnisfenster. Deshalb nahm ich an, daß das aufwendig gelöst wurde. Jetzt habe ich aber mal QED gestartet, und, voilá, das Mausrad löst einfach nur Cursor hoch/runter aus. Das wäre auch mein erster Ansatz gewesen, aber ich hielt das für eine Art Billig-Lösung. Ich kann's ja mal einbauen, bis mir etwas Besseres einfällt. Das ganze IKBD-G'lump ist so verkorkst, daß ich durch meinen eigenen Assembler-Code im BIOS nicht mehr durchsteige.