Auf der Suche nach einer Alternative zum Atari800MacX, der eine sehr schöne Aqua-Oberfläche für den Atari800 bietet, habe ich mich über diverse wine-Versionen und Versionen von Altirra, Atari800Win und atari800 bis hin zum Quellcode von atari800 gewuselt, um nun endlich die neueste Version 5.0.0 von atari800 unter Mac OS X 10.8.5 zum Laufen zu bringen.
Warum das ganze?
Nun, Atari800MacX ist wirklich ein sehr schönes Stück Software.
Jedoch gibt es für meinen alten Mac keine aktuelle Version.
Für mein aktuelleres und mein gepatchtes MacBook Pro liegt zwar die neueste Version vor,
jedoch ist die Vollbild-Funktion nicht sehr optimal und verschlingt CPU-Zeit,
so dass keine 50 FPS mehr erreicht werden.
Auf dem gepatchten Gerät funktioniert das Vollbild gar nicht.
Die Performance der Windows-Versionen lässt unter Wine sehr zu wünschen übrig,
wenn es sich um einen Mac mit einer älteren Intel GMA950 oder X3100 Grafikkarte handelt
(namentlich MacBook1,1 bis MacBook4,1),
egal ob SDL, OpenGL, Altirra oder Atari800.
Dies betrifft nicht nur Macs, sondern auch wine unter Linux auf den gleichen Geräten oder herkömmlichen Laptops.
Von einem nativen SDL-Port für Mac OS X verspreche ich mir eine bessere Leistung als von einer wine-basierten Lösung.
Erstaunlicherweise gibt es im gesamten Internet keine Anleitung für das Bauen von Atari800 aus den Quellen,
zumal auch nirgends erwähnt wird, dass man sich nicht die Sources-Pakete,
sondern die .tar.gz ohne Angabe eines Zielsystems herunterladen muss.
Mac OS X bot jüngst an, die Xcode-Command-Line-Tools zu installieren, sobald man versuchte, einen Befehl wie make oder gcc im Terminal auszuführen. Ob und wie das (noch) klappt, weiß ich jetzt nicht genau, da meine OS X Installation hier vor mir bereits 12 Jahre alt ist.
./configure --enable-video-x11=no
make
sudo make install
bauen und installieren
./configure --with-video=sdl --with-sound=sdl
make
sudo make install
bauen und installieren
./configure --with-video=sdl --with-sound=sdl --with-readline=no
make
sudo make install
bauen und installieren
./configure --with-video=sdl --with-sound=sdl --with-readline=no --with-sdl-prefix=/usr/local
make
sudo make install
bauen und installieren
Ihr habt jetzt eine Command-Line-Version von atari800 vorliegen. Wie man das ganze jetzt in eine richtige OS X Anwendung packt, weiß ich (noch) nicht. Wichtig ist mir nur, endlich die aktuelle, native OS X Version von atari800 vorliegen zu haben, ohne auf fremde Paket-Manager wie brew oder macports angewiesen zu sein.
Getestet habe ich dieses Vorgehen unter
Snow Leopard (Intel 32 Bit),
Lion (Intel 64 Bit),
Leopard (PowerPC G4, siehe Hinweis),
Tiger (Intel 64 Bit, siehe Hinweis) und
El Capitan (Intel 64 Bit, siehe unten).
Unter Lion jedoch konnte ich den Emulator nur mit dem Altirra OS betreiben,
die originalen PC-Xformer-ROMs verursachen einen Segmentation fault: 11.
Warum dieser Auftritt,
während es unter den Vorgänger- und Nachfolgerbetriebssystemen funktioniert,
und ob es nur diesen einen Lion-Rechner betrifft,
muss ich noch herausfinden.
Unter Tiger scheint der Pfad nach /usr/local/bin nicht gesetzt zu sein,
was dazu führt, dass man einerseits den Prefix,
also den Installationsort von SDL angeben muss,
andererseits muss atari800 mit vollem Pfad gestartet werden,
also /usr/local/bin/atari800.
Beides lässt sich lösen bzw. vereinfachen,
in dem man der Datei ~/.bash_profile die Zeile
export PATH=$PATH:/usr/local/bin
hinzufügt.
Existiert die Datei nicht (Standard),
so legt man sie einfach an.
Mein Intel-Tiger-Rechner ist exakt der,
auf dem die originalen OS-ROMs unter Lion nicht funktioniert haben.
Unter Tiger funktioniert alles bisher tadellos.
Tadellos ist vielleicht ein kleines bisschen übertrieben, denn eines haben alle Builds gemein: die Maus-Emulation klappt nicht, der Maus-Zeiger ist in seiner Bewegung doch sehr eingeschränkt. Woran das liegt, kann ich nicht sagen, die SDL-Version von atari800 unter Linux und Windows zeigen dieses Verhalten nicht.
Unter Mac OS X 10.11.6 El Capitan scheiterte der Versuch,
SDL1 zu bauen,
immer wieder an dem Fehler
./src/video/quartz/SDL_QuartzVideo.h:94:5: error: unknown type name 'CGDirectPaletteRef'.
Das soll wohl alle Rechner ab Mac OS X 10.9 betreffen.
Internet-Recherchen brachten keine Lösung,
außer bereits gebaute SDL-Versionen aus brew oder anderen Projekten zu verwenden.
Hier verwendete ich einen verboten schlechten Hack:
ich kommentierte einfach die Zeile 94 der o.g. Quellcode-Datei aus, in der das Wort CGDirectPaletteRef vorkam.
Anschließen baute ich Atari800 und es läuft.
Bestenfalls läuft Atari800 problemlos.
Schlimmstenfalls stürzt Atari800 irgendwann ab oder andere SDL-Programme
(nicht SDL2)
funktionieren nicht mehr richtig.
Auch hier muss ich noch mehr forschen.
Bei meinem El Capitan Rechner handelt es sich allerdings um ein MacBook5,2 mit Nvidia 9400M Grafikkarte.
Auf dieser GPU sollten keine Leistungseinbußen zu erwarten sein,
wenn es um die Ausführung der Windows-Versionen von Atari800 und Altirra unter wine geht.
Außerdem läuft der 64-Bit-Build,
den ich unter Snow Leopard 64 Bit gebaut habe,
auch unter El Capitan,
so dass ich auf keinen eigenen El Capitan Build angewiesen bin.
An dieser Stelle höre ich verrückter Atari-Nerd,
der schon lange auf der Suche nach einer Alternative zu Atari800MacX war,
nicht auf und mache ein Mac-App-Bundle daraus,
das ich verteilen könnte.
Hierzu verwende ich das unter Tiger gebaute 32-Bit-Intel-Binary.
Verzeichnis für das App-Bundle erzeugen:
mkdir -p Atari800.app/Contents/MacOS
mkdir -p Atari800.app/Contents/Ressources/lib
(kann übersprungen werden, da ich das für Euch schon gemacht habe)
Überprüfen, welche Dateien noch in das App-Bundle gehören:
otool -L /usr/local/bin/atari800
Binärdateien hinein kopieren:
cp /usr/local/bin/atari800 Atari800.app/Contents/MacOS/
cp /usr/local/lib/libSDL-1.2.0.dylib Atari800.app/Contents/Ressources/lib/
Die ausführbare Binärdatei dahingehend abändern,
dass das im App-Bundle befindliche SDL verwendet wird,
und nicht das in /usr/local installierte:
install_name_tool -change "/usr/local/lib/libSDL-1.2.0.dylib" @executable_path/../Ressources/lib/libSDL-1.2.0.dylib Atari800.app/Contents/MacOS/atari800
Möchte ich -
bzw. ich werde -
auch noch Universal Binaries erzeugen,
so kann ich,
bevor ich das App-Bundle baue,
die Intel- und PowerPC-Binaries mit folgendem Befehl zusammenfassen:
lipo -create -output atari800 atari800.ppc atari800.x86
lipo -create -output libSDL-1.2.0.dylib libSDL-1.2.0.dylib.ppc libSDL-1.2.0.dylib.x86
Voraussetzung ist, dass die entsprechenden Dateien Power PC- bzw. Intel-Code enthalten.
Ich in meinem Fall müsste hierfür die auf PowerPC- und dem Intel-Rechner separat erzeugten Dateien unter den entsprechenden Namen
auf den Rechner kopieren,
auf dem ich die Universal Binary erzeuge.
Atari800 5.0.0 für alte Rechner und mit dem alten Kernel kompiliert kommt nicht an eine zufriedebstellende Leistung auf meinem iBook G3 mit 500 MHz heran.
Hier bevorzuge ich also den Atari800MacX 4.6.0.
Der ist so optimiert,
dass der emulierte Atari locker mit 100% läuft,
ohne Frames überspringen zu müssen.
Auf den Geräten ab PowerPC G4 und erst Recht auf den Intel-Macs lässt die Leistung des Emulators keine Wünsche offen.
Desweiteren sind alle Systeme,
auf denen SDL1 -
sprich mein Build von Atari800 5.0.0 -
läuft,
auch in der Lage,
Atari800MacX 4.6.0 laufen zu lassen,
also die Version,
die Dank SDL1 noch nicht auf die Vollbild-Variante der aktuellen Version 6.0.1 angewiesen sind,
die zumindest auf meinem gepatchten MacBook Pro 4,1 mit Monterey fehlerhaft läuft.
In Atari800MacX 4.6.0 funktioniert auch das Fangen und die Emulation der Maus besser als in atari800 5.0.0.
Auch einige Tastenkombinationen,
wie z.B. die Taste "Insert",
sind nur im Atari800MacX bis Version 4.6.0 zu finden (Shift + Ctrl + <).
In Atari800MacX >= 5 lässt sie sich genau wie in atari800 5.0.0 aber nicht aufrufen,
was das Programmieren in Turbo-BASIC erschwert.
Alles in allem war das Bauen von atari800 5.0.0 für Mac OS X in der Hauptsache eine Lernerfahrung.
Ob ich den Emulator gar nicht, selten oder immer nutzen werde,
weiß ich noch nicht.
Ein Traum wäre es ja,
mit Dr. Marc Grebe,
dem Autor von Atari800MacX,
direkt zusammen an dem Emulator zu arbeiten.
Die Resultate meiner Recherche sind im Download-Bereich meiner Web-Seite zu finden.