
Neue Funktionen von MagicMacX
Änderungen in der Version 1.2.1
Diese Version wurde unter Tiger compiliert, jedoch mit SDK 10.2.8 (die letzte Version von „Jaguar“). MagicMacX verwendet zwar Systemfunktionen zur Auflösungswechsel-Erkennung, die erst unter 10.3 „Panther“ vorhanden sind, diese fehlenden Funktionen werden jedoch erst zur Laufzeit eingebunden. Damit läuft MagicMacX (theoretisch) notfalls auch mit „Jaguar“.
Ein Absturz im Laufwerkauswahl-Dialog (Registerkarte im Einstellungen-Dialog) wurde behoben.
Das Eingabefeld für Atari-Speicher im Einstellungen-Dialog wurde verbreitert.
Die RAM-Speichergröße für den emulierten Atari wird jetzt auf 2 GiByte limitiert. Das Eingabefeld im Einstellungsdialog wird restriktiv überwacht, d.h. man kann auch keine größere Zahl eingeben.
Diverse Fnctl() und Dcntl()- Aufrufe wurden repariert.
Im Einstellungen-Dialog kann man für das virtuelle Laufwerk M: (tatsächlich das Macintosh-Dateisystem) den Sortiermodus und das 8+3-Format nicht mehr auswählen. Dies war in den vorherigen Programmversionen von MagicMacX zwar möglich, wurde aber ignoriert.
Ein Fehler im VDI führte bei Fenstergrößen ab 2034
Pixel horizontal für das Atari-Fenster und 32 Bit Farbtiefe zu
Fehlern beim Bildschirmaufbau. Da ich den Quelltext fürs VDI nicht
habe, wird die fehlerhaft berechnete LineA-Variable BYTES_LIN jetzt
nach der Initialisierung des VDI von „außen” auf den
richtigen Wert gesetzt. In der Debug-Version von MagicMacX wird eine
entsprechende Warn-Meldung in die Log-Datei geschrieben.
Änderungen in der Version 1.2 (20. Dezember 2004)
Erweiterte Einstellungen
Im Einstellungs-Dialog, Unterdialog „Allgemeines“ kann man die Emulation der rechten Maustaste konfigurieren.
Application Package
MagicMacX ist jetzt ein Application Package.
Da die Entwicklung ursprünglich mit MacOS 8.6 anfing, war
MagicMacX bis zur Version 1.1 ein „CFM/PEF“-Programm. PEF
steht
für „Preferred Executable File“ und ist ein
Dateiformat für
ausführbare Dateien (wie ELF in Linux und COFF in Windows). CFM
bezieht sich auf den von Apple mit den Power Macs eingeführten
„Code Fragment Manager“. Dieser ermöglicht,
Maschinencode für
PowerPC und Motorola 68k beliebig zu mischen, nämlich in
„Fragmenten“.
CFM/PEF-Applikationen haben folgende Eigenheiten:
- Sie verwenden eine "resource fork", d.h. das Programm kann nicht einfach auf andere Systeme kopiert oder per Mail verschickt werden.
- Die Applikation besteht aus nur einer Datei.
- Eine Lokalisierung mit mehreren landessprachlichen Ressourcen ist nicht ganz einfach.
- Das Prozessor-Register gpr2 ist ein "rtoc"-Zeiger und zeigt auf globale Daten, die mit einem 16-Bit-Offset adressiert werden.
- Die Applikation kann nicht direkt von MacOS X gestartet werden, hierfür wird "LauchCfmApp" benötigt. Dies wird vom Finder transparent erledigt, jedoch nicht von der Kommandozeile.
- Diverse moderne Systemfunktionen, insbesondere neuere Carbon- und alle Nicht-Carbon-Aufrufe, müssen mühsam zur Laufzeit über "frameworks" manuell aufgerufen werden. Dazu muß man die entsprechenden "Bundles" laden und die Zeiger auf die Systemaufrufe über ihre Namen ermitteln.
Also gibt es einige Nachteile dieser „veralteten“ Technik, außerdem wird die Unterstützung von PEF/CFM vielleicht irgendwann einmal von Apple aufgegeben.
MachO steht für Mach-Object, Mach ist der „microkernel“ von MacOS X. Applikationen im MachO-Paketformat haben folgende Eigenheiten:
- Das Programm ist eigentlich ein Ordner "<Programmname>.app" (der Finder unterschlägt das ".app"). Der Ordner enthält beliebige Programme und Daten, die man im Finder unter "Paketinhalt anzeigen" einsehen kann.
- Es gibt keine "resource forks". Die Ressourcen liegen in der "data fork" von eigenen Dateien. Daher kann die Applikation problemlos gepackt oder z.B. auf Windows-Systeme kopiert werden.
- Die Lokalisierung ist einfach und wird sogar im Kontextmenü des Finders unterstützt. Für jede Lokalisierung existieren Unterordner mit entsprechenden Ressourcen, mit denen die Default-Ressourcen überlagert werden können.
- Statt Prozessor-Register gpr2 wird das Register RPIC verwendet, und zwar mit einem 32-Bit-Offset. Anscheinend ist RPIC aber gpr0, und dann verwendet der PowerPC absolute Adressen. Das wäre wegen der PMMU-Verwendung auch nicht verwunderlich (PIC = Position Independent Code).
- Die Applikation kann direkt von MacOS X gestartet werden, auch von der Kommandozeile.
- Die Applikation kann nicht von "Classic MacOS" gestartet werden.
- Die Zuordnung zu Dateitypen (*.TOS, *.PRG usw.) ist auch ohne die klassische Type/Creator-Methode möglich, d.h. wie bei Windows anhand der Datei-Endung.
- Die Icons liegen als einfach editierbare ".icns"-Dateien vor.
Die Vorteile des MachO-Paketformats (es gibt auch Mischformen, etwa “CFM application packages“, die in MacOS 9 eingeführt wurden) überwiegen, und die Nachteile lassen sich leicht in Kauf nehmen. Für MagicMacX ergeben sich damit insbesondere noch folgende Neuerungen:
- Es gibt jetzt keine drei „MagicMacX“-Programme für Deutsch, Englisch und Französisch mehr, sondern nur noch eine, die automatisch je nach Systempräferenzliste die richtigen Ressourcen lädt. Der MagiC-Kernel ist auch lokalisiert. D.h. es liegen drei Versionen im Bundle, die je nach Spracheinstellung geladen werden. Achtung: Fehlt die Datei im Bundle, wird sie wie bisher vom Verzeichnis geladen, in dem das Bundle liegt. Es fehlen aber noch die Ressource-Dateien der Atari-Applikationen, z.B. MAGXDESK.RSC, diese sind nicht lokalisiert.
- Es gibt eine eigene Icon-Datei für TOS-Programme,
außerdem ist auch ein spezielles Icon für den Dateityp
".CDK" vorgesehen, aber es gibt noch keine zugehörige
".icns"-Datei.
Neue Plugins (XCMDs)
Wegen des MachO-Formats von MagicMacX gibt es ein ganz neues
Plugin-Konzept, das sich an den Apple-Vorgaben (CFPlugIn) orientiert.
Das Beispielprojekt ist für XCode ausgelegt.
Von der Atari-Seite aus können außer den PEF/CFM
Bibliotheken jetzt auch die neuen CFPlugIn-Bibliotheken im MachO-Format
eingebunden werden. Dazu gibt man den ganzen Namen inklusive Endung
(z.B. ".bundle") als Bibliotheknamen an. Gesucht wird dann in
~/Library/MagicMacX/PlugIns
sowie in
/System/Library/MagicMacX/PlugIns.
Für nähere Informationen siehe das mitgelieferte Beispiel-Plugin.
Alte XCMDs
Die bisherigen XCMDs (Plugins) werden noch (eingeschränkt) unterstützt. Das eine Problem dabei besteht darin, daß die Bibliotheken im PEF-Format sind und vom CFM (Code Fragment Manager) verwaltet werden, das Programm selbst aber inzwischen ein MachO (mach object) Programm ist. Dafür muß sogenannter glue-Code eingebunden werden ("call CFM from MachO"), der zur Laufzeit einen Code-Schnipsel generiert, welcher die CFM-Funktion aufruft. Die Callbacks müssen natürlich andersrum ver-glue-t werden („call MachO from CFM“). Beim Entladen der Bibliotheken werden alle Schnipsel wieder freigegeben (nein, nicht „frei gegeben“, das wäre mehr wie "freiwillig gegeben", außerdem ist die Neue Rechtsschreibung blödsinnig). Das zweite Problem ist die Carbon-Funktion GetSharedLibrary(), die offenbar überhaupt nicht mehr funktioniert, d.h. die Bibliotheken nicht finden kann.
Um das zweite Problem, das Nicht-Finden der Bibliotheken, zu umgehen, mußte statt GetSharedLibrary() die Funktion LoadDiskFragment() verwendet werden, die aber einen Dateinamen (eigentlich einen FSSpec) und nicht einen Bibiotheknamen benötigt. Wenn ein Atari-Programm den Bibiotheknamen angibt, so muß der Dateiname „geraten“ werden, indem, wenn er keine Endung hat, ".lib" oder ".shlib" angehängt wird.
Zur Zeit sucht MagicMacX die PlugIns ausschließlich innerhalb des Paketes („application packet“), und zwar dort, wo die ausführbare Datei liegt, also in "MagicMacX.app/Contents/MacOS". Eine spätere Version könnte aber einen Plugin-Ordner im Paket unterstützen.
Folglich müssen alle XCMDs, auch die von Calamus, in das Paket kopiert/verschoben werden. Der Ordner "Preload-XCMDs" sollte nicht mehr verwendet werden.
Beim Laden eines PlugIns (initiiert von der Atari-Seite aus) wird, wenn ein Pfad angegeben ist, nur eine CFM/PEF-Bibliothek geladen. Andernfalls, d.h. es wurde ein Name angegeben, wird zunächst ein CFPlugIn (MachO-Bundle) von „~/Library/MagicMacX/PlugIns“ geladen, und, wenn es dort nicht gefunden wird, in in „/SystemLibrary/MagicMacX/PlugIns“ und schließlich, wenn es dort auch nicht gefunden wird, wird eine CFM/PEF-Bibliothek gesucht.
68k-Emulator
Diverse Optimierungen im 68k-Emulator haben die Ausführungsgeschwindigkeit der Atari-Programme etwas erhöht. Es gibt ja bekanntlich keinen objektiven „benchmark“, aber der Gewinn dürfte so bei 10 bis 20% liegen.
Eine neue Version von MagicMac.OS signalisiert dem Emulator, wenn sich MagiC in der "idle loop" befindet. Der Emulator-Thread legt sich dann schlafen, bis ein simulierter Interrupt auftritt. Damit braucht MagicMacX nur noch wenig Rechenzeit auf dem Mac, wenn gerade kein Atari-Programm läuft (d.h. Berechnungen o.ä. durchführt).
Emulatorfenster
Der Fall "MagicMacX ausblenden" bzw., wenn ein anderes Programm gerade aktiv ist, "Andere ausblenden" wird jetzt berücksichtigt. Dabei wird dieser Fall wie ein manuelles Schließen behandelt. Beim Wiederöffnen wird der Inhalt des Atari-Emulatorfensters wieder automatisch neu aufgebaut.
Die Erkennung, wenn die Bildschirmeinstellungen geändert wurden (Größe, Farben), mußte geändert werden und benötigt jetzt mindestens OS X 10.3 „Panther“ (CGDisplayRegisterReconfigurationCallback() statt DisplayManager). Damit sollte MagicMacX bei Änderung der Bildschirmeinstellungen nicht mehr abstürzen, außerdem ignoriert MagicMacX Änderungen, die an anderen Bildschirmen als dem verwendeten vorgenommen werden.
Klick auf Icons im Finder
Das "Apple-Event" odoc wird ausgewertet, d.h. man kann jetzt den Emulator durch Doppelklick auf eine TOS-Datei starten oder eine Datei auf das Icon des laufenden Programms ziehen. Dazu braucht man aber den "MagicMacX Daemon" MMXDAEMN.PRG. Dieses Hilfsprogramm, das die Kommunikation zwischen dem Emulator MagicMacX auf der MacOS-Seite mit dem emulierten Atari bereitstellt, installiert man am besten durch Kopieren nach „/gemsys/magic/start“.
Beenden des Emulators
Beim Beenden von MagicMacX wird versucht, das emulierte MagiC „sauber“ herunterzufahren. Dazu muß, wie beim Starten von Programmen über AppleEvents, auf der Atari-Seite der MMXDAEMN laufen. Funktioniert das manuelle Herunterfahren (über den Menüpunkt in MagicMacX) nicht, so kann ein zweiter Versuch unternommen werden; nach Bestätigung eines Dialogs kann MagicMacX dann beendet werden, ohne den Emulator korrekt herunterzufahren.
Im Fall eines AppleEvents ('quit'), ausgelöst über das Dock, durch Abmelden oder Herunterfahren des Rechners, hat das emulierte MagiC zehn Sekunden Zeit, sich zu beenden. Anschließend wird MagicMacX nach Rückfrage beendet.
Diverses
Die Druckdateien werden beim Beenden von MagicMacX automatisch gelöscht.
Das XCMD-Beispielprogramm, das eine Dateiauswahl zeigt, stürzt nicht mehr ab, wenn man den Dialog mit "Abbruch" beendet. Das war offenbar doch kein Fehler in MagicMacX, sondern ein Systemfehler, den Apple mit 10.3 beseitigt hat.
Der Beenden-Dialog ("Alert") "MagicMacX sofort beenden? Nichtgesicherte Daten laufender Atari-Anwendungen gehen verloren" behandelt jetzt die Esc-Taste wie einen Klick auf den "Abbruch"-Knopf. Dafür mußte die Objekt-Numerierung geändert werden (2 = Abbruch, 3 = OK). Desgleichen in den englischen und französischen Dialogen. Die Return-Taste wird offenbar nicht unterstützt, so daß man hier wohl keine Eingriffmöglichkeit hat.
Dpathconf(-1) arbeitet jetzt korrekt. Leider war die Abfrage falsch gewesen: Auf 0xffffffff statt 0xffff (auf dem Mac ist ein "int" 32 Bit breit, nicht 16 wie bei den meisten Compilern auf dem Atari).
Dcntl() überprüft den übergebenen Zeiger und wird daher von Calamus nicht mehr zum Absturz gebracht.
Eine tschechische Lokalisierung (mit englischem MagiC-Kernel) wurde hinzugefügt.
Verbleibende bekannte Fehler
Mitunter tritt das Phänomen auf, daß bei installiertem NVDI und "log="-Eintrag im "[boot]"-Abschnitt von MAGX.INF die BIOS-Textausgabe völlig im Eimer ist. Man merkt das z.B., wenn man Ctrl-Alt-Esc drückt und nicht viel sieht. Oder wenn man den VT52.PRG umbenennt, so daß ihn das System nicht finden kann, und dann ein TOS-Programm startet. Läßt man NVDI weg oder löscht die "log="-Zeile aus MAGX.INF, ist wieder alles in Ordnung.
Die Tastenkombination Ctrl-F1 scheint nicht richtig beim Atari anzukommen. Offenbar ist sie von MacOS X reserviert. Um sie wieder zu ermöglichen, muß man das Kontrollfeld "Tastatur und Maus" öffnen und die Registerkarte "Tastatur-Kurzbefehle". Hier muß man die Aktion, die der Taste Ctrl-F1 zugewiesen ist, abschalten. Irgendwie ist das Kontrollfeld kaputt. Die Funktion "Fenster drehen" (gemeint ist: zyklisch wechseln) hat den Kurzbefehl Cmd-^, den kann man aber nicht von Hand aktivieren, wenn der Taste versehentlich etwas anderes zugewiesen ist. Man muß alles auf "Standard" setzen, dann stimmt es wieder.
Änderungen in der Version 1.1 (23. Juli 2003)
Diverse Fehlerkorrekturen und bessere Kompatibilität zu Atari-Programmen.
„Preload-XCMDs“- Ordner eingeführt.
Bildschirmausgabe für „true colour“ (16 Millionen Farben) ist jetzt in etwa so schnell wie bei „high colour“ (32768 Farben).
Synchrone Bildschirmausgabe in den Hintergrundpuffer, d.h. Vorder- und Hintergrundpuffer werden nach Möglichkeit immer identisch gehalten (im Vordergrundbetrieb).
Findet MagicMacX in seinem Programmverzeichnis eine „Preferences“-Datei, so wird diese verwendet und nicht diejenige im „Preferences“-Ordner des Benutzers.
Achtung: Wenn MagicMacX mit einer alten MAGX.INF gestartet wird, kann das AES abstürzen. Der Gerätetreiber #_DEV muß immer „1 0“ sein.
Fensterbedienung für Emulatorfenster eingeführt, inkl. Minimieren.
Ältere Versionen
Die erste Alpha-Version von MagicMacX stammt vom 17.12.2000. Sie wurde noch unter OS 9 und der „Public Beta“ von MacOS X entwickelt.
Version 1.0 ist vom 26. August 2002 und wurde für MacOS 10.1 „Puma“ entwickelt, da die Vorversion von MacOS X (10.0 alias „Cheetah“) völlig unbrauchbar war. Erst die zweite Systemaktualisierung - 10.1.2 - war soweit brauchbar, daß MagicMacX ausgeliefert werden konnte.
Version 1.0.1 ist vom 2. Dezember 2002 und enthält einige Fehlerkorrekturen.