AtariX => MagicOnLinux

[AndreasKromke]

WTF! Jetzt habe ich einen Riesenaufwand betrieben, um herauszufinden, warum das vermaleidete GFABASIC 3.6 mit einem weißen Bildschirm hängenbleibt und wie ich das verhindern kann, und jetzt finde ich heraus, daß jemand im Jahre 2022 (a) das gleiche Problem hatte und (b) die gleiche Lösung gefunden hat: https://www.atari-forum.com/viewtopic.php?p=432805

Die Diagnose "Someone else added that GFA Basic sends a command to query the joysticks" kann ich aber erstmal nicht bestätigen. Ich finde keinen XBIOS-Ikbdws()-Aufruf, und zwar weder in meinem disassembly noch im trace von Hatari. Deshalb bleibt diese Schleife für mich unverständlich.

Mit dem Patch läuft das Programm im "single mode" in ST-high und ST-mid. Von ST-low aus versucht es - leider vergeblich - auf ST-mid umzuschalten, natürlich mit Registerzugriff statt XBIOS, wäre ja auch zu einfach. Bei anderen Auflösungen stürzt GFABASIC ab und reißt das gesamte System mit.

[Thorsten Otto]

Ich finde keinen XBIOS-Ikbdws()-Aufruf, und zwar weder in meinem disassembly noch im trace von Hatari.

GFA benutzt nicht ikbdws, sondert sendet ein einzelnes Byte mit Bconout(4):

Code: [Auswählen]

[0001a7de] 7016                      moveq.l    #22,d0
[0001a7e0] 6100 851a                 bsr        $00012CFC
...
[00012cfc] 3f00                      move.w     d0,-(a7)
[00012cfe] 5140                      subq.w     #8,d0
[00012d00] 13c0 0001 2d16            move.b     d0,$00012D16
[00012d06] 4879 0003 0004            pea.l      $00030004
[00012d0c] 4e4d                      trap       #13
[00012d0e] 5c8f                      addq.l     #6,a7
[00012d10] 4e75                      rts

Das Kommando was da gesendet wird, dient zum Abfragen beider Joysticks.

[AndreasKromke]

GFA benutzt nicht ikbdws, sondert sendet ein einzelnes Byte mit Bconout(4):

Heißen Dank und Frohes Neues!
Ich hatte bei der Masse von beobachteten Bconout-Aufrufen schon so etwas vermutet, die Theorie dann aber verworfen.

Die Adressen scheinen sich etwas verschoben zu haben. Bei mir sieht es so aus:

Code: [Auswählen]

lblA7C2:
 move.w   #$22,-(sp)          *00A7C2=3f3c0022
 trap     #$e                 * xbios Kbdvbase *00A7C6=4e4e
 addq.l   #2,sp               *00A7C8=548f
 movea.l  d0,a3               *00A7CA=2640
 adda.w   #$18,a3             *00A7CC=d6fc0018
 move.l   (a3),-(sp)          *00A7D0=2f13
 move.l   #lblA7BA,(a3)       *00A7D2=26bc0000a7ba
 clr.l    lbl2D12             *00A7D8=42b900002d12
 moveq    #$16,d0             *00A7DE=7016     <==== BCONOUT
 bsr      lbl2CFC             *00A7E0=6100851a
lblA7E4:
 tst.l    lbl2D12             *00A7E4=4ab900002d12
 beq.s    lblA7E4             *00A7EA=67f8       <====== ENDLOSSCHLEIFE

Mein Disassembler kann den versteckten Bconout-Aufruf hier natürlich nicht finden.

[MJaap]

( Der Fortschritt von EmuTOS gegenüber Atari TOS ist erheblich. Vielleicht weniger im AES, wo der Hauptfokus eben auf der kompatiblen Nachbildung von Atari TOS liegt. Aber bei Open-Source-Software gilt schließlich: nicht meckern, selbst machen.

Richtig. Ich störe mich halt an Äußerlichkeiten, ich bin ein Augen-Mensch. Aber im Museum schaue ich ja auch nicht hinter die Bilder, ob die stabil befestigt sind. 

Ist zwar etwas OT, aber auch mit Blick auf MagiC wurden in EmuTOS einige AES-Erweiterungen eingebaut (Nicelines und Dialogtitel)

[AndreasKromke]

Prima! Mußte erstmal Suchmaschine bemühen, was "Nicelines" und Dialogtitel sind. Ist zu lange her. Ich mußte direkt mal KAOS und EmuTOS vergleichen, in ST-high.

Und ich habe - nach Thorstens endgültiger Analyse - das vermaledeite GFA-Basic endlich zum Laufen gebracht -- ohne Pätsch! Dabei schwingt immer die Hoffnung mit, daß auch andere Programme davon profitieren. Meistens wird diese Hoffnung enttäuscht.

Technisch: Das Programm schickt per Bconout() zwei Befehle an den IKBD: Eine Joystick-Abfrage, und dann wird die Maus auf den relativen Modus umgeschaltet. Letzteres ist harmlos, aber bei ersterem wartet das Programm auf das Antwortpaket vom IKBD, dafür hängt es sich mit Kbdvecs in die Joystick-Behandlungs-Routine. Ich habe bei der Gelegenheit gleich alle Bcon***()-Aufrufe für IKBD und MIDI an den Emulator geleitet, der kann dann den Interrupt simulieren und die Datenpakete liefern. Ein ziemlicher Aufwand. Unklar ist mir, ob der Atari dann zwei Pakete à zwei Bytes liefert, denn er müßte ja beide Joysticks berücksichtigen. Das "Profibuch" ist hier lückenhaft.

[RealLarry]

[...]
Technisch: Das Programm schickt per Bconout() zwei Befehle an den IKBD: Eine Joystick-Abfrage, und dann wird die Maus auf den relativen Modus umgeschaltet. Letzteres ist harmlos, aber bei ersterem wartet das Programm auf das Antwortpaket vom IKBD, dafür hängt es sich mit Kbdvecs in die Joystick-Behandlungs-Routine. Ich habe bei der Gelegenheit gleich alle Bcon***()-Aufrufe für IKBD und MIDI an den Emulator geleitet, der kann dann den Interrupt simulieren und die Datenpakete liefern. Ein ziemlicher Aufwand. Unklar ist mir, ob der Atari dann zwei Pakete à zwei Bytes liefert, denn er müßte ja beide Joysticks berücksichtigen. Das "Profibuch" ist hier lückenhaft.

Ich werde langsam alt und verliere allmählich die Lust am Sammeln und Benutzen (von Atari-Zeugs) - damit mache ich mittlerweile zu wenig damit. Aber 2025 war für mich ein Atari-Jahr. Atari macht wieder Atari-Dinge und Merch, Der Atari800-Core des MiSTer wurde erwachsen (und weit darüber hinaus), MoL und was-weiß-ich-nicht-noch alles. Zusammengefasst: Atari-Porno pur. Überschwänglich tausend Dank an alle Beteiligten!

[Thorsten Otto]

Unklar ist mir, ob der Atari dann zwei Pakete à zwei Bytes liefert, denn er müßte ja beide Joysticks berücksichtigen. Das "Profibuch" ist hier lückenhaft.

Nein, er schickt ein Paket, bestehend aus 3 Bytes. Das erste Byte ist $fd, die anderen beiden Bytes sind die Status-Daten für die Joysticks (bits 0-3 Directions, bit 7 fire-Knopf wenn ich mich recht erinnere). Für die Status-Daten sollte es momentan reichen, zwei $00-Byte zu schicken, solange nicht wirklich ein Joystick simuliert wird.

Zu beachten ist auch daß Joystick-0 des IKBD eigentlich ziemlich unbrauchbar ist. Wenn der aktiviert wird, ist die Maus ausgeschaltet, und umgekehrt. Das Abfrage-Kommando liefert aber trotzdem beide Bytes.

[AndreasKromke]

https://www.atari-wiki.com/index.php?title=Keyboard_Protocol#Joystick_Event_Reporting

Das Profibuch ist da offenbar nicht ausreichend. Danke!

[Thorsten Otto]

Doch, das Paket ist da ja auch erklärt. "Joystick Event Reporting" ist allerdings was anderes, das bekäme man bei Senden von 0x14. GFA schickt aber 0x16 Joystick Interrogation

[don_apple]

@AndreasKromke Hallo!

Vielen Dank für die Wiederaufnahme der Entwicklung von MagiC. Ich habe vor mehr als 25 Jahren MagiCMac intensiv benutzt (u. a. hab' ich meine Diplomarbeit damit mit Papyrus auf einer Quadra840AV geschrieben).

Habe jetzt mal die aktuellste Version von MagicOnLinux von gitlab auf macOS Sequoia 15.7.3 auf einem MacBook Air M3 getestet. Funktionierte im großen und ganzen recht problemlos, allerdings sind mir ein paar Dinge aufgefallen:

- In der Anleitung zum compilieren auf macOS (MACOS.txt) fehlt der Hinweis das das sdl2_mixer Paket installiert werden muß. Ohne das scheitert das "cmake -G Xcode .." Kommando ("brew install sdl2" installiert nicht automatisch sdl2_mixer)

- das install_rootfs.sh bricht mit der Fehlermeldung "cp: illegal option -- -" ab, da das cp von macOS die option "--update=none" nicht kennt die im LOCALISE.SH script das von install_rootfs.sh aufgerufen wird das cp zweimal mit dieser Option aufgerufen wird

- in der default-Konfiguration die mit "./Release/magic-on-linux -w" erstellt wird sind die folgenden Zeilen enthalten die dazu führen das die Ausgabe von MagicOnLinux auf das doppelte skaliert wird was etwas komisch aussieht:

Code: [Auswählen]

atari_screen_stretch_x = 2
atari_screen_stretch_y = 2Nachdem ich den Wert von "2" auf "1" geändert habe ist die Ausgabe wieder normal.

- wenn ich MagicOnLinux starte und dann auf dem Desktop auf das Laufwerk C: klicke und dann über das Menü "File - Information" auswähle und dann versuche die erschienene Dialogbox mittels Cancel zu verlassen crasht MagicOnLinux wie im angehängten Screenshot zu sehen.

Wäre klasse wenn es in Zukunft auch ein App-Bundle für macOS gäbe damit man das Programm wie andere Applikationen vom Desktop aus starten kann.

[czietz]

- wenn ich MagicOnLinux starte und dann auf dem Desktop auf das Laufwerk C: klicke und dann über das Menü "File - Information" auswähle und dann versuche die erschienene Dialogbox mittels Cancel zu verlassen crasht MagicOnLinux wie im angehängten Screenshot zu sehen.

"Bytes/Sektor: 1048576" im angezeigten Dialogfeld sieht auch etwas dubios aus.

Bei macOS gilt es zu beachten, dass man "f_frsize" als Maßeinheit für Dateisystemblöcke nehmen muss. Unter Linux sind "f_bsize" und "f_frsize" typischerweise gleich, daher fällt das nicht auf. Ich verweise darauf, wie Hatari es letztlich gelöst hat: https://framagit.org/hatari/hatari/-/blob/main/src/gemdos.c#L1694

Leider ist das Hatari-Listen-Archiv down, sodass ich zur diesbezüglichen Diskussion nur auf eine Nachricht auf emutos-devel verweisen kann: https://sourceforge.net/p/emutos/mailman/message/59193055/

[Thorsten Otto]

"Bytes/Sektor: 1048576" im angezeigten Dialogfeld sieht auch etwas dubios aus.

Das sieht nicht nur dubios aus, sondern ist vermutlich auch der Grund für den Absturz. Das Text-Feld im Dialog dort ist 4 Zeichen lang, wenn der gelieferte Werte also >= 10000 ist, wird dort irgendwas anderes überschrieben. Sieht man auch am angehängten "ANDR": das ist der magische Wert, der intern von MagiC vor Speicherblöcke gesetzt wird.

Versuch mal bitte angehängte Version von MagxDesk, da sollte das abgefangen sein (gehört nach C:\GEMSYS\GEMDESK, aber aufpassen daß die Resource-Datei nicht beim ändern der Sprache wieder überschrieben wird).

PS.: solange MagicOnLinux unter macOS dort f_bsize liefert, kann es trotzdem sein daß die angezeigten Werte nicht stimmen; aber zumindest sollte es nicht mehr abstürzen).

[don_apple]

Versuch mal bitte angehängte Version von MagxDesk, da sollte das abgefangen sein (gehört nach C:\GEMSYS\GEMDESK, aber aufpassen daß die Resource-Datei nicht beim ändern der Sprache wieder überschrieben wird).

@Thorsten Otto Danke! Mit dieser Version von MagxDesk tritt der Crash nicht mehr auf.

[fichten]

Grüß' euch,
ich bin eher der Freund von europäischen Linux-Distributionen wie openSuse (kommt ja aus Nürnberg),
und daher habe ich versucht, MagicOnLinux auf Leap 16.0 zu installieren.
Dazu habe ich in install-all.sh apt durch zypper ersetzt (gcc und cmake usw. sind standardmäßig auch nicht installiert (ich bin ja lieber Python-Freak ):

Code: [Auswählen]

sudo zypper install cmake gcc gcc-c++ SDL2-devel SDL2_mixer-develDie Installation der Mime-Sachen hat mich bei den Ausgaben etwas "schockiert", hat aber anscheinend funktioniert. Und letztendlich läuft MagicOnLinux auch auf openSuse!
Ich habe MagicOnLinux über die Konsole gestartet, damit man auch alle Ausgaben auf stderr sieht, siehe Anhang...
Dabei ist mir folgendes aufgefallen:

• bei OpenSuse (KDE) gibt es kein gxmessage sondern nur ein xmessage, daher funktionieren die Ausgaben so auch nicht... muss ich mal mit einem symlink versuchen...
  
• und der shutdown funktioniert nicht, weil der Aufruf C:\GEMSYS\GEMDESK\shutdown.prg lautet... aber das Programm ist im GEMDESK-Ordner in Großbuchstaben (Fehlermeldungen siehe Anhang) oder ist da was anderes im Busch?
  

[fichten]

Und hier auch die aktuellen Warnings/Fehlermeldungen:

[AndreasKromke]

1. Die Vergrößerung des Atari-Fensters um den Faktor 2 ist für moderne Monitore gedacht. Bei 2,5k- oder 4k-Monitoren sieht man ansonsten den Atari-Bildschirm nur unter einer Lupe. Aber läßt sich ja leicht ändern.
2. Den Hinweis zum sdl2-mixer habe ich ergänzt. Das Paket kam erst später dazu.
3. Bitte versuche, den cp-Parameter "--update=none" zu ersetzen durch "--no-clobber". Wenn das auch nicht geht, dann bitte durch "-n". Dieser Parameter gilt als veraltet. Mein cp hat Version 9.4.
4. Bitte die soeben hochgeladene Version testen, ob der Überlauf in MAGXDESK auch damit behoben ist. Ich denke, eine Änderung der RSC-Datei sollte ausreichend sein. Ich habe es rudimentär getestet.

Und vielen Dank fürs Testen! Obwohl ich noch einen Vorkriegs-Mac stehen habe, bin ich doch leider weit weg von macOS, dafür habe ich derzeit keine Energie.

[AndreasKromke]

Vielen Dank fürs Testen! Die Log-Dateien sind mMn alle o.B..

Das virtuelle Laufwerk C: ist konfiguriert als 8+3 und "case insensitive", deshalb werden alle Zugriffe erstmal vom Atari-Zeichencode (wegen der anderen Umlaute etc.) in utf-8 und in Großbuchstaben (!) umgewandelt. Du könntest in "config.h" die Zeile "//#define _DEBUG_XFS" noch ent-kommentieren. Dann wirft das XFS massenweise Meldungen raus, die weiterhelfen könnten.

Du könntest mal MCMD starten (Strg-B) und schauen, ob SHUTDOWN.PRG zugreifbar ist.

Oder ob es eine Folge des fehlenden gxmessage ist? Das solltest Du Dir dringend (!) nachinstallieren. Ich habe auch erst mit xmessage experimentiert, weil das vorinstalliert war. Das ist erstens _winzigst, also der Text ist etwa drei Millimeter hoch (WTF), und außerdem ist es ziemlich ohnmächtig. Oder machtlos.

Vielleicht würde die ganze Installiererei auch mit etwas cmake-Magie distributionsunabhängig funktionieren, statt ein Shell-Script zu schreiben. Andererseits ist ein Script transparenter, man weiß also immer, was man tut .. oder tun will.

Hier zwei Schirmschüsse von xmessage und gxmessage zum Vergleich - beide unter einer starken Lupe.

[Thorsten Otto]

bei OpenSuse (KDE) gibt es kein gxmessage sondern nur ein xmessage,

Ja, is mir auch schon aufgestossen gxmessage gibt es auf https://trmusson.dreamhosters.com/programs.html#gxmessage, aber leider scheint es kein paket für openSUSE zu geben, auch nicht für TumbleWeed. Oder angehängte Version probieren, sollte sich recht einfach mit

Code: [Auswählen]

gcc -O2 `pkg-config --cflags --libs gtk+-2.0` -o gxmessage gxmessage.c
übersetzen lassen. gtk+3.0 sollte auch funktionieren. gtk4 allerdings nicht.

[goetz @ 3rz]

Ja, is mir auch schon aufgestossen gxmessage gibt es auf https://trmusson.dreamhosters.com/programs.html#gxmessage, aber leider scheint es kein paket für openSUSE zu geben, auch nicht für TumbleWeed.

Nur fürs Archiv: Auch Fedora Desktop hat kein gxmessage.

[fichten]

Ich habe jetzt was auf software.opensuse.org für Tumbleweed gefunden und auf mein Leap 16.0 installiert:

Code: [Auswählen]

zypper addrepo https://download.opensuse.org/repositories/home:jsegitz/openSUSE_Tumbleweed/home:jsegitz.repo
zypper refresh
zypper install gxmessage

damit hat es jetzt funktioniert: beim Beenden per Shutdown kommt jetzt eine Message, auf die ich aber auch gerne verzichten kann... denn MagiConLinuX funktioniert auch ohne gxmessage...