MagicMacX Symbol

Konzept von MagicMacX





Der Emulatorkern

MagicMacX ist eine Kombination von Emulator und Atari-Betriebssystem, welche Ihnen ermöglicht, die meisten neueren Atari-Programme komfortabel und schnell auf Ihrem Macintosh unter MacOS X auszuführen. Ein Teil von MagicMac arbeitet „native", d.h. wird direkt vom MacOS mit maximaler Geschwindigkeit ausgeführt. Dazu gehören Teile der Bildschirmausgabe sowie alle Dateioperationen. Die restlichen Programmteile, die dem Atari-Programm seine gewohnte Umgebung bieten, laufen als 68 Code in einem Emulator.

Der Emulator selbst emuliert eine Motorola 68020 CPU ohne mathematischen Koprozessor (68882) und ohne PMMU (68851), er ist in PowerPC Assembler geschrieben. Entwickelt wurde der Emulatorkern von Aaron Giles für das MacMame-Projekt, er wurde für die Atari-Emulation erweitert, es wurden diverse Fehler behoben (und die Korrekturen an das MacMame-Projekt zurückgegeben), und die Geschwindigkeit wurde deutlich erhöht. Der Emulator arbeitet interpretierend, d.h. er dekodiert immer einen 68k-Assemblerbefehl und führt ihn dann aus, dann dekodiert er den nächsten usw.. Durch die fortgeschrittene Optimierung ist der 68k-Emulator von MagicMacX vermutlich der schnellste rein interpretierende; schneller sind nur noch compilierende oder teilcompilierende Emulatoren, wie sie z.B. von kommerziellen PC-Emulatoren oder auch von QEmu verwendet werden.

Für eine optimale Ausnutzung der Prozessorleistung, auch von mehreren CPUs, läuft der emulierte Atari in einem eigenen Thread.

Die Bildschirmausgabe

MagicMacX aktualisiert den Hintergrund-Bildpuffer von OS X synchron (gleichzeitig) mit dem Vordergrundpuffer. Der Bildschirminhalt ist daher stets konsistent. Einige Mac-Programme legen sich aber über das Emulator-Fenster, ohne daß dieses das mitbekommt. Das ist ein zugegebener Fehler im MacOS, der aber vermutlich nicht so schnell behoben wird. In diesem Fall wird das überlappende Element leider vom Emulator überschrieben (falls dieser im Vordergrund liegt). Das läßt sich leider nicht verhindern. In der Paxis kommt das aber eher selten vor. Störenfriede sind das Dock sowie alle Menüs, die rechts in der Menüleiste liegen, z.B. für die Lautstärke und die Uhr.

Unterschiede zu MagicMacX

MagicMacX arbeitet ähnlich wie sein Pendant für MacOS 8 und 9, MagicMac; es ergeben sich aber einige wichtige Unterschiede.

Leider konnte das bewährte Konzept von MagicMac aufgrund der völlig anderen Systemarchitektur von MacOS X nicht beibehalten oder angepaßt werden, selbst die Lauffähigkeit unter Classic war nicht möglich (wegen der Nicht-Umblendbarkeit des unteren 68k-Adreßraums). Aus diesem Grund ist das vorliegende Programmeine vollständige Neuentwicklung und enthält keinen Code von MagicMac.

Dies sind die wesentlichen Vorteile im Vergleich zu MagicMac:

  1. Da der 68k-Interpreter vollständig in MagicMacX integriert ist, konnte eine höhere Kompatibilität zum Atari realisiert werden. So funktioniert z.B. das Trace-Bit richtig, wodurch, im Gegensatz zu MagicMac, Debugging problemlos möglich ist(PureDebugger, BUG.TTP usw.).
  2. Der 68k-Emulator emuliert auch in gewissen Grenzen Atari-Hardware, zumindest werden teilweise Zugriffe ignoriert (z.B. auf die Bildschirm-Register), andererseits jedoch Busfehler erzeugt (Zugriff auf nicht vorhandene FPU). So ist einFPUPATCH nicht mehr notwendig.
  3. Statt der Atari-Bomben gibt es einen Mac-Dialog, der eine genaue Fehlerbeschreibung liefert. Für genauere Informationen kann der Dialog aufgeklapptwerden. 
  4. MagicMacX verwendet, im Gegensatz zu MagicMac, nur sogenannte "Highlevel"-Schnittstellen zum MacOS. Dadurch ergeben sich viel weniger Probleme beim Einsatz unterschiedlicher Mac-Hardware wie Tastaturen/Mäusen usw. Probleme wiez.B. beim Umstieg von MacOS 9 auf 9.1 sollten mit MagicMacX nicht auftreten.
  5. MagicMacX ünterstützt jede Mehrtastenmaus, die vom Betriebssystem unterstützt wird.

  6. Das Programm arbeitet im Prinzip wesentlich stabiler als MagicMac. So ist es für ein Atari-Programm unmöglich, dem Betriebssystem irgendwelche Schäden zuzufügen. Auch die Wahrscheinlichkeit, daß MagicMacX selbst durch ein amoklaufendes Atari-Programm instabil wird, sind wesentlich geringer.
  7. MagicMacX erlaubt, die Mac-Menüleiste eingeschaltet zu lassen, während der Atari emuliert wird.
  8. MagiCMacX hat einen Pseudo-Fenstermodus. Der emulierte Atari schreibt zwar immer noch direkt in den Mac-Bildschirm, jedoch auch optional innerhalb eines Fensterrahmens. Das Fenster läßt sich sogar minimieren und ins Dock legen. Unabhängig vom Fenster kann der Emulator mit Cmd-R angehalten und wieder gestartet werden, falls er z.B. im Dock keine Rechenzeit verbrauchen soll. Das "Icon" im Dock wird sogar regelmäßig aktualisiert.
  9. Im Gegensatz zu MagicMac reagiert MagicMacX auf die Nachricht, daß das Emulatorfenster in den Hintergrund tritt, mit einer Zeichenmodus-Änderung: Im Hintergrund (d.h. auch dann, wenn ein Mac-Menü heruntergeklappt wurde) schreibt der emulierte Atari "sauber", d.h. betriebssystemkonform, in den Hintergrundspeicher des Fensters, und dieser wird zyklisch unter Berücksichtigung aller Verdeckungen in das Fenster kopiert (wie unter MagiC-PC, jedoch
    ist der Hintergrundspeicher Bestandteil von MacOS X, nicht jedoch von Windows). Vorder- und Hintergrundmodus sind am Fenstertitel erkennbar. Die Aktualisierungsfrequenz ist konfigurierbar.
  10. Auf dem Atari ist Laufwerk M: das gesamte Mac-Dateisystem, wie es von Carbon-Programmen gesehen wird. Als freier Platz auf M: werden dem Atari immer 2GiByte vorgespiegelt.
  11. Das Atari-Multitasking ist stets prä-emptiv und braucht nicht gesondert abgeschaltet zu werden, außer ggf. wie beim Atari in der Konfigurationsdatei MAGX.INF.
  12. Diverse Hsmodem-Fcntl-Kommandos werden für die serielle Schnittstelle unterstützt. Es empfiehlt sich, den Gerätetreiber DEV_SER auf dem simulierten Atari zu installieren, um eine optimale Geschwindigkeit zu erhalten (dabei wird das Atari-BIOS umgangen). Dieser installiert die Gerätedatei "U:\DEV\SERIAL". Gerätetreiber *.dev gehören nach "C:\GEMSYS\MAGIC\XTENSION".
  13. Die Tastaturtabellen im Atari-Kernel können mit "dead keys" konfiguriert werden. Beispieldateien für UK und CZ liegen anbei. Die alten Tastaturtabellen von MagiC funktionieren jetzt nicht mehr, weil mindestens zwei Nullbytes für eine leere "dead key table" enthalten sein müssen.
  14. Die Emulator-Erweiterungen (XCMDs) können in den Ordner "Preload-XCMDs" gelegt werden, wenn sie direkt bei Programmstart geladen werden sollen.


Durch den neuen, vom MacOS unanbängigen Emulatorkern ergeben sich systembedingt auch einige Einschränkungen gegenüber MagicMac:

  1. Aufgrund des interpretierenden 68k-Emulators ergibt sich eine geringere Ausführungs-Geschwindigkeit für Atari-Programme (MacOS verwendet einen compilierenden Emulator).
  2. Der direkte Zugriff auf Disketten oder Festplatten unter Verwendung des MagiC-eigenen VFAT-Dateisystems ist unter OS X nicht mehr möglich. Theoretisch wäre es denkbar, Laufwerk-Container wie in MagiCPC zu verwenden, diese sind jedoch z.Zt. noch nicht implementiert.
  3. Aufgrund des völlig anderen Konzepts sind alle Programme für MagicMac, die auf die MacOS-Seite zugreifen, nicht mehr kompatibel. Grund dafür ist, daß es in Carbon keine MacOS-68k-Seite mehr gibt. Dennoch können Atari-Programme über "shared libraries" direkt auf MacOS-Funktionen zugreifen (siehe beigefügte Programmier-Dokumentation).
  4. Die Bildschirmtreiber von NVDI5 funktionieren aus dem genannten Grund nicht. Sie greifen direkt auf Quickdraw zu und müßten angepaßt werden. Jedoch kann (und es sollte!) NVDI als GDOS verwendet werden
  5. Der MACPRN-Druckertreiber von NVDI funktioniert ebenfalls nicht. Nur diejenigen Drucker können angesprochen werden, für die Atari-Druckertreiber existieren. Für den Zugriff auf Mac-Drucker müßte MACPRN an MagicMacX angepaßt werden.
  6. Es gibt offenbar einen Fehler ab MacOS X 10.2 im "File Manager", der dazu führt, daß das Durchsuchen eines Verzeichnisses in umgekehrter Reihenfolge (Standard bei MagiCMac) nicht richtig funktioniert. Der Fehler wird sichtbar, wenn man in MagxDesk einen neuen Ordner erstellt, dann noch einen usw. Irgendwie kommt das MacOS nicht mit, und man sieht den neu erstellten Ordner nicht, sondern erst bei Druck auf [Esc].
    Es sieht so aus, als wenn zunächst die Größe des Verzeichnisses höher gesetzt wird (Anzahl++) und erst dann die
    Datei/der Ordner tatsächlich eingetragen wird. Dazwischen ruft MagiC aber die Anzahl ab und findet ein Objekt weniger, als angegeben wurde. Daher ist für die aktuelle Version die umgekehrte Reihenfolge abgeschaltet für alle Laufwerke außer C: und M:. Damit gibt es natürlich Probleme beim rekursiven Löschen von Dateien.
    Der Fehler ist leider MacOS X-immanent und kann daher durch MagicMacX nicht behoben werden. Der Fehler ist an Apple gemeldet, ist also Apple bekannt, jedoch nicht behoben worden.
  7. Achtung: Wenn MagicMacX mit einer alten MAGX.INF gestartet wird, kann das AES abstürzen. Der Gerätetreiber #_DEV muß immer "1 0" sein.

Zur Zeit bestehen folgende weiteren Einschränkungen gegenüber MagicMac:

  1. 68k-Bus- und -Adreßfehler sind in dem verwendeten 68k-Emulator nicht vollständig implementiert. So lesen einige Zugriffe von einem ungültigen Speicherbereich zur Zeit einfach Nullen, Schreibzugriffe werden teilweise ignoriert.
    Außer zum Debuggen von Atari-Programmen oder sehr spezielle Atari-Anwendungen birgt dieses Verhalten aber keinerlei Nachteile.
  2. Der Atari-Adreßraum ist stets zusammenhängend, d.h. TT-RAM wird nicht unterstützt.
    Auch diese Einschränkungen dürfte für alle voll korrekt programmierten Atari-Programme bedeutungslos sein.
  3. Die rechte Shift-Taste kann mit Apples Carbon-Programmierschnittstelle (sogenannte API) leider nicht gesondert abgefragt werden. Ein klares Fehl-Design von Apple.
  4. Es wird stets möglichst viel Zeit an die anderen Mac-Applikationen abgegeben; d.h. MagicMacX benötigt einen Prozessor nur dann, wenn ein Atari-Programm etwas zu rechnen hat.
    Für die Rechenzeit-Verteilung sorgt das Betriebssystem, sie kann nicht beeinflußt werden. Möglicherweise lassen sich mit UNIX-Kommandos ("nice") aber Prioritäten festlegen. In den allermeisten Fällen dürfte dies aber nicht nötig sein.
  5. Die Dateioperationen sind zur Zeit ausschließlich synchron. Angesichts der Transfergeschwindigkeit heutiger Festplatten ist diese Einschränkung wahrscheinlich ohne irgendeinen merklichen Einfluß auf die Emulation.
  6. Eine "unmittelbare Dateisicherung" ist unter OS X obsolet.
  7. Gestartet wird stets von Laufwerk C:. Laufwerk C: ist immer der Ordner MAGIC_C im selben Verzeichnis wie die MagicMacX-Applikation.
  8. Eine Konfiguration von Dateitypen wird nicht unterstützt. Lediglich die Dateitypen PRG, TOS und TTP (d.h alle Atari-Programme) erhalten ein MagicMacX-Type/Creator und damit ein entsprechendes Icon. Alle anderen Dateitypen erhalten einen leeren Type/Creator, d.h. es wird dem Finder überlassen, welches Mac-Programm der Dateiendung zugeordnet ist. Damit erhalten Dateien vom Typ *.TXT automatisch das TextEdit-Icon usw.
  9. OS X fängt offenbar einige Tastenkombinationen ab, zumindest auf meinem alten G3. Von der Standard-Einstellung abweichende Tasten-Zuweisungen sind z.Zt. nicht möglich. Jedoch werden unterstützt:

        Cmd-U für Undo (Taste "Pause")
        Cmd-L für Help (Taste "Druck")
        Cmd-D für Delete (Taste "Entf")
        Cmd-E für Insert (Taste "Einfg")
        Cmd-M für Clr/Home (Taste "Pos1")

  10. Bisher ist kein Kompatibilitätsmodus für die Atari-Grafik (z.B. 640*400*2) implementiert. MagicMacX verwendet nur die Auflösungen, die MacOS X unterstützt.
  11. Bisher hat MagicMacX nicht die Fähigkeit, die Bildschirmauflösung oder Farbtiefe umzuschalten. MagiC läuft daher immer in der Farbe und Auflösung, die unter OS X eingestellt wurden.
  12. Ist die Mac-Menüleiste sichtbar, funktioniert (im Gegensatz zu OS 9.x) die Vollbild-Anzeige in OS X nicht. Apple bezeichnet das als "beabsichtigt", und es führt dazu, daß das Dock immer noch im Vordergrund liegt und MagicMacX stört. Notfalls kann man das Dock abschalten (Prozeß "Dock" über Terminal-Fenster abschießen. Dazu z.B."kill -STOP <pid>" und später "kill -CONT <pid>").

Die letztgenannten Einschränkungen können möglicherweise in späteren Versionen einmal beseitigt werden.

Weitere Informationen finden Sie hier:

Übersicht über MagicMacX

Versionsgeschichte