STEmulator 2: Preview auf den Edel-Emulator

Lange war es doch ruhig geworden um den STEmulator 2, so dass manche langjährige Anwender wohl schon gedacht haben, dass er wie manch anderes Atari-Programm nicht mehr weiterentwickelt wird. Dies ist aber nicht so. Die Entwicklung geht langsam, aber stetig weiter und nähert sich jetzt merklich dem Ende. Wir hatten jetzt die Möglichkeit uns die aktuelle Entwicklungsversion einmal anzusehen und zeigen hier einmal den aktuellen Stand auf.

Einstellungssache

Gegenüber seinem Vorgänger hat der STEmulator 2 einige Veränderungen erfahren und neue Fähigkeiten hinzugewonnen. Beim Starten fällt sofort der neue Einstellungsdialog auf, dieser ist deutlich moderner gestaltet und gruppiert die Einstellungsmöglichkeiten nicht mehr in Reitern, sondern im bekannten Outlook-Style.

Beim Sichten der Möglichkeiten fallen dem Anwender dann schnell die neuen Fähigkeiten ins Auge: Verschiedene CPU- und TOS-Versionen stehen zur Auswahl, die Liste der möglichen Bildschirmmodi wurde erweitert, für die neu hinzugekommen Module ist ein eigener Verwaltungsdialog hinzugekommen und der Laufwerksdialog wird jetzt mit der rechten Maustaste über ein Popupmenü bedient.

Dieses Popupmenu ist kontextabhängig und bietet je nach geladenen Modulen zur Laufwerksverwaltung mehr oder weniger Funktionen an. Neben den normalen Windowslaufwerken stehen hier zum Beispiel jetzt auch Laufwerkscontainer wie unter MagiC PC zur Verfügung. In einem immer sichtbaren Bereich des Dialoges erscheinen Erklärungen zu dem Dialogelement, über dem der Mauszeiger steht.

Nach dem Start der Emulation fällt dem Anwender sofort auf, dass jetzt das letzte offizielle TOS von Atari, die Version 4.04, benutzt wird. Dadurch wird in den Programmen der 3D-Look benutzt, und es stehen Farbicons und natürlich auch die anderen AES-Erweiterungen, die an dieser TOS Version vorgenommen wurden, bereit.

Da das TOS 4.04 nur in einer 680030-Version erschienen ist, wird hiermit auch klar, was für eine CPU jetzt emuliert wird, nämlich ein 68040-Prozessor. Durch diese benutzte CPU-Emulation werden jetzt auch die Programme nutzbar, die mindestens eine, 030-Prozessor voraussetzen. Zurzeit wird allerdings nur die 68LC040-CPU emuliert. In dieser Version des 68040-Prozessors ist keine FPU enthalten. Dies bringt allerdings keine wirklichen Einschränkungen, da nur die wenigsten Programme eine FPU voraussetzen. Und falls doch, dann liegen sie auch meist in einer nicht für die FPU optimierten Version vor. Die von 68LC060-Nutzer berichteten Probleme mit NVDI auf dem Milan treten hier übrigens nicht auf. Eine Nachrüstung mit einem FPU-Modul ist allerdings möglich und soll über Kurz oder Lang auch erscheinen - darüber weiter unten mehr. Die MMU des 68LC040 wird übrigens nur soweit emuliert, wie nötig. Ein Speicherschutz oder virtuelle Adressen sind hiermit nicht möglich.

Die Geschwindigkeit der Emulation hat sich nicht geändert. Im Grafikbereich steht jetzt auch endlich die echte 32-Bit-TrueColor-Farbtiefe zur Verfügung. Damit ist die volle Farbtiefe der installierten PC-Grafikkarte nutzbar. Die Atari-kompatiblen Auflösungen wurden um den 256-Farben-Modus des Falcon erweitert. Diese Grafikmodi sind jetzt auch in beliebigen Auflösungen möglich, und eine Unterstützung durch optimierte Intel-Grafikroutinen erfolgt jetzt auch in den Atari-Farbauflösungen. Durch das vorhandene Blittermodul wird die Zeichengeschwindigkeit zusätzlich unterstützt.

Modularität

Von den Modulen wurde jetzt schon oft gesprochen, doch um was handelt es sich den jetzt dabei? Der große Unterschied des STEmulators 2 zu seinen Vorgängern ist seine Modularität. Das ganze Programm besteht aus etlichen Modulen, die zusammen die Funktionalität des STEmulators bilden. Alle sinnvoll zu trennenden Funktionsgruppen des Programms wurden in Modulen zusammengefasst. Dies sind unter anderen die CPU, das TOS und die TOS-Teilbereiche VDI, GEMDOS, BIOS sowie AES, aber auch Hardwareteile wie der Shifter, Blitter, DMA-Sound oder MFP und die Schnittstellen. Daneben sind aber auch Dinge wie die Clipboard-Unterstützung oder der Einstellungsdialog in Module gefasst worden. Ihre Funktionalität üben diese Module mit Hilfe von Nachrichten aus, die Ihnen von anderen Modulen oder dem Kernel gesandt werden.

Eine andere wichtige Möglichkeit der Steuerung sind die so genannten Callbacks. Ein Callback ist eine definierte Schnittstelle, an den sich ein Modul hängen kann, um bestimmte Ereignisse mitgeteilt zu bekommen oder um Funktionen zu übernehmen. Beispiele hierfür sind Timer, Mausbewegungen, Zugriffe auf lO-Adressen oder auch Sprünge aus der 68k-Umgebung in die Module. Es können Traps, Exceptions, Interrupts, Bildschirmzugriffe und alles mögliche andere von den Modulen abgefangen werden. Gebündelt wird das ganze vom Kernel, der auch für die Verwaltung der Module selbst zuständig ist. Der Kernel ist die eigentliche STEMULATOR.EXE, es lädt alle nötigen Module nach, initialisiert diese und startet schließlich das CPU-Modul.

Was bringt das ganze für Vorteile - schließlich ging es auch vorher ohne Module? Nun, erst einmal können mit Hilfe der Module die Leistungsmerkmale des Emulators geändert werden. Es gibt zum Beispiel ein Modul mit dem TOS 4.04 und eins mit TOS 2.06, außerdem liegt die CPU als ein 68000- und ein 68040-Modul vor. So wird die Kompatibilität auch zu kritischen Programmen gewahrt. Des Weiteren ist es so sehr einfach möglich, Fehler und Probleme schnell zu beheben. Der Entwickler legt einfach ein verbessertes Modul auf die Homepage, der Anwender kopiert dieses in seinen Modul-Ordner und der STEmulator benutzt jetzt dieses Modul.

Ein wichtiger weiterer Vorteil ist aber die nachträgliche Erweiterung des Emulators. Da alle Schnittstellen offen gelegt werden, kann zum Beispiel eine andere CPU oder eine FPU eingebunden werden, ein anderer Treiber für die serielle Schnittstelle oder ein beliebiger Hardwarechip, der dann innerhalb des IO-Adressen Bereiches der Emulation auftaucht. Damit jetzt aber nicht das DLL-Chaos ausbricht, wird der STEmulator immer noch als eine Datei STEMULATOR.EXE geliefert. Die einzelnen Module sind alle in diese Datei eingebunden. Erst, wenn ein weiteres Modul in den Modul-Ordner kopiert wird, für das ein Pendant in der EXE-Datei existiert, wird dieses benutzt und ersetzt das interne Modul.

Native Routinen

Eng verbunden mit den Modulen ist die Möglichkeit, aus Atari Programmen heraus Native Intel-Routinen in selbst geschriebenen Modulen aufzurufen. Oft krankt die Geschwindigkeit eines schon seit Jahren gepflegten Programms nur an wenigen Routinen. Das ganze Programm nach Windows zu portieren ist viel zu kompliziert oder aufwändig. Mit dem STEmulator 2 bekommt der Entwickler jetzt ein Werkzeug an die Hand mit dem es möglich ist, gezielt Funktionen in schnelle Intel Routinen zu legen und diese innerhalb seines Programms aufzurufen. Dabei ist es egal, ob das Programm in C, Assembler, GFA oder Omikron-Basic geschrieben ist. Nur die Möglichkeit eine beliebige GEMDOS-Funktion aufzurufen muss gegeben sein. Anschluss an eine SQL Datenbank, eine schnelle Fast Fourier Transformation, eine eigene Floating Point Library und vieles andere lässt sich realisieren.

Die Schnittstelle ist bewusst komfortabel und einfach zu bedienen konzipiert worden. Keine Illegal Opcodes und Memory-Offsets müssen beachtet und keine Assembler Work-Arounds konstruiert werden. Die externen Intel-Routinen können fast wie normale Betriebssystemfunktionen aufgerufen werden. Übergebende Parameter und Strings werden so konvertiert, dass sie für die nativen Routinen direkt nutzbar sind. Die Aufrufe der Routinen laufen übrigens nicht über den GEMDOS-Dispatcher, sondern werden schon innerhalb der CPU abgefangen. So geht keine Performance verloren, aber die Aufrufsyntax ist sehr einfach und in allen Sprachen möglich.

Erstes Fazit

Wir sind gespannt, was noch alles im fertigen Produkt stecken wird, da an vielen interessanten Modulen, die hier noch gar nicht erwähnt wurden, noch gearbeitet wird, stc

http:/www.stemulator.net/