AtariX => MagicOnLinux

[AndreasKromke]

(Nur nebenbei: Ich habe den Emulator erfolgreich unter dem alten Ubuntu 22.04 installiert, das erfordert aber etwas Handarbeit.)

Weiß jemand, warum Ballerburg (BALLER.PRG) nicht funktioniert? Man muß es in 640x400 monochrom starten und als "single mode" (also über die Alt-Taste oder per "Anwendung anmelden"). Dann startet es nett und funktioniert auch scheinbar, aber tatsächlich ignoriert es alle Mausklicks auf den Bildschirm. Das Programm kommt mit Quelltext, aber auf den ersten zwei Blicken konnte ich nichts Verdächtiges sehen. Es gibt da ein evnt_multi() mit Mauspositionen und -klicks, und das Menü funktioniert, alles andere nicht. Natürlich müßte das Programm ein Fenster öffnen, statt einfach per AES und VDI auf dem Bildschirm herumzumalen, aber ist das ein Problem? Läuft das Programm unter Atari-MagiC?

[AndreasKromke]

Nachtrag: [https://de.wikipedia.org/wiki/Ballerburg] hat sogar einen Wikipedia-Artikel. Kraß!

[ragnar76]

Ich hab es geschafft, mit Hilfe der Apple Präprozessor-Direktiven, MoL unter FreeBSD zum laufen zu bringen. Annähernd. Ich bekomme jetzt eine Fehlermeldung, "no video driver". Irgendeine Idee?

[cyberish]

Ich würde das klasse Ding liebend gerne auf Mojave zum Laufen bringen.

[ragnar76]

Ich würde das klasse Ding liebend gerne auf Mojave zum Laufen bringen.

Wieso? Was klappt denn nicht?

[cyberish]

Komme bis hierhin unter Mojave:
** BUILD FAILED **


The following build commands failed:
   CompileC build/build/magic-on-linux.build/Release/Objects-normal/x86_64/Clipboard.o src/Clipboard.cpp normal x86_64 c++ com.apple.compilers.llvm.clang.1_0.compiler
   CompileC build/build/magic-on-linux.build/Release/Objects-normal/x86_64/HostHandles.o src/HostHandles.cpp normal x86_64 c++ com.apple.compilers.llvm.clang.1_0.compiler
(2 failures)


Oder beim Versuch mit XCODE zu kompilieren, spuckt's das aus, s.h. Foto

[ragnar76]

Komme bis hierhin unter Mojave:
** BUILD FAILED **


The following build commands failed:
   CompileC build/build/magic-on-linux.build/Release/Objects-normal/x86_64/Clipboard.o src/Clipboard.cpp normal x86_64 c++ com.apple.compilers.llvm.clang.1_0.compiler
   CompileC build/build/magic-on-linux.build/Release/Objects-normal/x86_64/HostHandles.o src/HostHandles.cpp normal x86_64 c++ com.apple.compilers.llvm.clang.1_0.compiler
(2 failures)

Die Zusammenfassung ist wenig hilfreich. Die eigentlichen Fehler stehen weiter oben. Du kannst ein log erstellen wenn du make wie folgt ausführst: "make 2>&1 build.log". Dann hast du eine Logdatei in der du nachsehen kannst

[nolina]

Hi Andreas,
MagicOnLinux lässt sich auch unter Mint Linux 22.1 bauen und läuft auch.
In der install-all.sh sieht die Änderung so aus:

case "$distribution" in
ubuntu | debian | linuxmint)

Gruss,
Bernd

[cyberish]

Komme bis hierhin unter Mojave:
** BUILD FAILED **


The following build commands failed:
   CompileC build/build/magic-on-linux.build/Release/Objects-normal/x86_64/Clipboard.o src/Clipboard.cpp normal x86_64 c++ com.apple.compilers.llvm.clang.1_0.compiler
   CompileC build/build/magic-on-linux.build/Release/Objects-normal/x86_64/HostHandles.o src/HostHandles.cpp normal x86_64 c++ com.apple.compilers.llvm.clang.1_0.compiler
(2 failures)

Die Zusammenfassung ist wenig hilfreich. Die eigentlichen Fehler stehen weiter oben. Du kannst ein log erstellen wenn du make wie folgt ausführst: "make 2>&1 build.log". Dann hast du eine Logdatei in der du nachsehen kannst

Klasse, danke. Werde ich machen und wechsle dann rüber in den "Mojave-Thread" . 

[ragnar76]

Da ich kein Coder bin hab ich Google Gemini um Hilfe gebeten. Der Grund war ein hart codiertes Verzeichnis von Linux ("/proc/self/fd/") in der Datei HostXFS.cpp.

Gemini hat da was FreeBSD taugliches gebastelt aber ich kann nicht beurteilen wie gut oder schlecht die Umsetzung ist. Jedenfalls findet ihr den Code hier: https://gitlab.com/annaundarthur94/magiclinux

[AndreasKromke]

Ich wollte eigentlich nur mal "kurz" nachschauen, warum Ballerburg nicht funktioniert. Schließlich sind die Quellen frei verfügbar, aber -- ach! -- abgesehen davon, daß die Quellen ohne .PRJ kommen und sich auch mit neuem .PRJ nicht übersetzen lassen, sind die nicht einmal in ANSI-C (stattdessen K&R), sparsam mit Datentypen, keine Deklarationen, doppelt definierte Symbole ... oh Graus!

Wenn jemand noch mit FreeBSD basteln möchte, dann bitte versuchen, ob nicht sowas geht wie "wenn macOS oder ein anderes BSD, dann nimm dieses, und wenn nicht, dann ist es Linux, und dann nimm jenes. Zuviele bedingte Compilierungen machen den Kram unnötig kompliziert.

[goetz @ 3rz]

Ich wollte eigentlich nur mal "kurz" nachschauen, warum Ballerburg nicht funktioniert. Schließlich sind die Quellen frei verfügbar, aber -- ach! -- abgesehen davon, daß die Quellen ohne .PRJ kommen und sich auch mit neuem .PRJ nicht übersetzen lassen, sind die nicht einmal in ANSI-C (stattdessen K&R), sparsam mit Datentypen, keine Deklarationen, doppelt definierte Symbole ... oh Graus!

Nun, die allererste Ballerburg-Version ist ~2 Jahre älter als ANSI C, insofern kein großes Wunder, dass es K&R ist, und Deklarationen waren damals nicht überall Stilempfehlung.

[goetz @ 3rz]

Maxon Pascal 1.5 / Highspeed Pascal 1.5 crashen unter MoL (aber nicht unter Hatari mit EmuTOS) beim compilieren einer (sehr simplen) Pascal-Datei. Ich kann bei Bedarf Maxon Pascal zur Verfügung stellen.

Code: [Auswählen]

Atari crash

    exc = bus error (2)
    exception address = 0x06760001 (Reserved)
    access mode = read word
    pc = 0x003798fa
         code = 0x3011 [0xd040] 0xd07b
    sr = 0x0018 (EXTNEG INT=0)
    usp = 0x0039219e
     d0 = 0x0000ffff
     d1 = 0x0000ffff
     d2 = 0x00000000
     d3 = 0x00000000
     d4 = 0x01e6ffff
     d5 = 0x00010000
     d6 = 0x00000000
     d7 = 0x00000007
     a0 = 0x007be3d0
     a1 = 0x06760001
     a2 = 0x007be370
     a3 = 0x007be3d0
     a4 = 0x007be3be
     a5 = 0x0037cf8a
     a6

[AndreasKromke]

Gern. Aber derzeit ärgere ich mit noch mit Ballerburg herum. Das ist nicht nur K&R. sondern auch für LatticeC geschrieben, womit die Datentypenbreiten nicht zu PureC passen (int hat wohl 32 Bit, und short hat 16). Einige Bibliotheksfunktionen hat PureC nicht, und außerdem hat der Autor keine Strukturen verwendet, sondern die gesamte Zeigerarithmetik selber gemacht, auf der Basis von "int", auch für die AES-Objekte. Er hat keine Leerzeichen verwendet und -zig Anweisungen auf dieselbe Zeile geschrieben, Ausdrücke nicht geklammert (PureC verweigert ambigöse Operationen) und so weiter. Einen Fehler habe ich schon gefunden, da fehlt einfach mal ein Parameter beim Funktionsaufruf. Ich kriege das Programm jetzt endlich gebaut, aber es reißt den gesamten Emulator in den Abgrund.