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)