TT-Tuning: Speed without the price

Sie besitzen einen Atari TT? Na fein. Eines der Modelle mit schnellem TT-RAM? Noch besser. Sie haben 512K Speicherplatz übrig? Wunderbar. Dann opfern Sie diesen Speicher, um Ihren Rechner um 10-20% zu beschleunigen.

Von der Speicherorganisation des Atari TT war in den letzten Monaten häufig die Rede. Rekapitulieren wir: Im TT existieren zwei Sorten RAM, das ST-kompatible ST-RAM und das schnellere TT-RAM.

Auf das ST-RAM können alle Peripheriebausteine zugreifen, die ursprünglich nur für den ST gedacht waren, also z.B. die Laserdrucker und Festplatten für die ST-Serie. Auch dem Videochip (genauer gesagt dem Video-Shifter) des TT steht nur das ST-RAM zur Verfügung. Aus diesem Grund darf der Bildschirmspeicher des TT nicht im TT-RAM liegen. Da sich Shifter und 68030-Prozessor bei Zugriffen auf das ST-RAM den Bus teilen, muß der Prozessor beim Zugriff auf dieses RAM des öfteren Wartezyklen einlegen, bis der Shifter den Bus freigibt.

Das schnelle TT-RAM (Fast-RAM) steht dagegen in erster Linie dem Prozessor zur Verfügung. Zwar können SCSI-Geräte, zu denen auch die interne Festplatte des TT zählt, auf dieses RAM zugreifen, aber dies geschieht nur während des Ladens und Speicherns von Daten. Eine ständige Busbelastung, wie sie der Buszugriff des Video-Shifters für das ST-RAM darstellt, ist für das TT-RAM nicht vorhanden. Zugriffe auf das Fast-RAM erfolgen somit schneller als beim ST-RAM.

Auch die sogenannte Busbreite unterscheidet sich bei beiden RAM-Typen. So besitzt das ST-RAM eine Busbreite von 16 Bits. Dies heißt, daß für einen Zugriff auf ein 16-Bit-Wort nur ein einziger Buszugriff notwendig ist. Soll auf ein Langwort (32 Bits) zugegriffen werden, sind jedoch zwei Buszyklen nötig, da das Langwort in zwei Schritten (zweimal 16 Bits) aus dem Speicher geholt werden muß.

Im Gegensatz zum ST-RAM ist das TT-RAM in einer Breite von 32 Bit organisiert. Hier genügt ein einziger Buszugriff, um ein Langwort zum Prozessor zu übertragen. Darüber hinaus unterstützt das TT-RAM eine besonders effektive Art des Zugriffs, nämlich den sogenannten „burst mode“ des 68030. Dieser Modus erlaubt es, bei einem Buszugriff auf einen Schlag gleich vier Langworte in den Cache des 68030 zu übertragen, so daß für die folgenden Befehle weniger Buszugriffe notwendig sind, da ein Teil von ihnen ja bereits gelesen wurde.

Vom RAM zum ROM

Das ROM des TT hat eine Busbreite von 16 Bits. ROM-Zugriffe dauern demnach genauso lange wie Zugriffe aufs ST-RAM. Wäre das ROM wie das schnelle TT-RAM organisiert, würden ROM-Routinen mit erhöhter Geschwindigkeit ablaufen. Diese Situation wäre vergleichbar mit der Geschwindigkeitssteigerung, die ein Programm erfährt, das statt im ST-RAM im TT-RAM abläuft.

Nun läßt sich die Organisation des ROMs natürlich nicht ändern, und damit scheint es keine Möglichkeit zu geben, mit einer Wortbreite von 32 Bits auf das ROM zuzugreifen. Aber wie heißt es so schön: Der Schein trügt. Ein Trick wirkt hier Wunder.

ROM - O + A = RAM

Im Klartext: Das ROM des ST wird ins RAM kopiert, genauer gesagt ins schnelle TT-RAM.

Nun kann dies noch nicht der Weisheit letzter Schluß sein. Schließlich müßten ja alle absoluten Adressen, die sich im ROM befinden, angepaßt werden, damit man eine lauffähige ROM-Kopie im RAM erhält. Wer in dieser Richtung weiterdenkt, stößt auf ein zusätzliches Problem: Diverse Systemvektoren, die in das ROM zeigen, müßten ebenfalls allesamt geändert werden. Ist der Weg, eine ROM-Kopie im RAM abzulegen und dem Prozessor diese Kopie als ROM unterzujubeln, also überhaupt gangbar?

Wäre der TT mit einem 68000-Prozessor, wie man ihn im ST findet, ausgerüstet, so gäbe es in der Tat keine Möglichkeit, diesen Plan zu verwirklichen. Nun befindet sich im TT jedoch der 68030, und in diesen ist eine sogenannte PMMU (Paged Memory Management Unit) integriert, mit deren Hilfe die verrücktesten Speichermanipulationen möglich sind.

Lückenbüßer

Zunächst jedoch eine grundsätzliche Frage: Wie ist der Speicher bei ST und TT eigentlich aufgeteilt?

Bei beiden Rechnern kann der Prozessor mehr Speicher adressieren, als in der Regel vorhanden ist. So ist der ST standardmäßig nur mit maximal 4 MB RAM erhältlich. (Inzwischen gibt es jedoch auch eine Erweiterungsmöglichkeit auf 12 MB RAM.) Selbst wenn man die 192 kB ROM und den für die Hardware reservierten Speicherbereich hinzunimmt, erreicht man bei weitem nicht die 16 MB Hauptspeicher, die vom 68000-Prozessor angesprochen werden können. Im Adreßraum des ST befindet sich also eine Lücke von fast 12 MB. Hier befinden sich weder RAM oder ROM noch irgendwelche Hardware-Adressen.

Beim TT stellt sich die Situation noch krasser dar. Der 68030-Prozessor kann bis zu 4 GB (Gigabyte) Speicher adressieren. Dieser Adreßraum ist 256mal so groß wie der des ST. Maximal 18 MB können auf der Mutterplatine mit RAM bestückt werden. Darüber hinaus ermöglicht der VME-Bus den Zugriff auf weitere 8 MB RAM. Auch hier wird also nur ein kleiner Teil der theoretisch möglichen Speicherkapazität genutzt. Einen Rechner mit größerer RAM-Kapazität auszustatten, ist zwar prinzipiell möglich, aus Kostengründen kommt dies jedoch nur in seltenen Fällen in Frage.

Die maximal 4 MB ST-RAM des TT befinden sich im unteren Bereich des Adreßraums ab Adresse $00000000. (Die ersten 8 Bytes lassen sich übrigens nicht verändern, da es sich hierbei um gespiegelte ROM-Adressen handelt, deren Inhalte zur Initialisierung des Prozessors nach einem Reset benötigt werden.) Das TT-RAM beginnt ab $01000000. Zwischen ST-RAM und TT-RAM sowie oberhalb des TT-RAMs weist der Speicher also Lücken auf, in denen sich ähnlich wie beim ST weder RAM noch ROM befinden. Die soeben beschriebene Speicheraufteilung kann beim TT durch die MMU des 68030 beeinflußt werden.

Was leistet eine MMU?

Wie der Name schon andeutet, hat eine MMU etwas mit Speicherverwaltung zu tun. Ein wichtiges Leistungsmerkmal einer MMU besteht darin, daß der zur Verfügung stehende Speicher durch geeignete Programmierung dieses Bausteins an nahezu beliebigen Adressen bereitgestellt werden kann.

Hierzu ein Beispiel: Bei einem TT mit 4 MB TT-RAM befindet sich das TT-RAM im Speicherbereich von $01000000 bis $013FFFFF. Hierbei handelt es sich um sogenannte physikalische Adressen. Eine physikalische Adresse gibt an, an welcher Adresse sich das RAM tatsächlich befindet (diese Adresse ist durch die Hardware festgelegt). Mit Hilfe der MMU läßt sich diese Zuordnung so ändern, daß dieses RAM aus Sicht des Programms an einer völlig anderen Adresse, der logischen Adresse, angesprochen werden kann. Man kann sogar so weit gehen, die 4 MB TT-RAM in mehrere Bereiche aufzuteilen, so daß ein Teil beispielsweise ab der logischen Adresse $02000000 und ein weiterer Bereich ab $03000000 angesprochen werden kann.

Eine wichtige Aufgabe der MMU ist es also, logische Adressen in physikalische zu übersetzen. Der kleinste Speicherbereich, auf den eine solche Adreßumrechnung angewendet werden kann, nennt sich Speicherseite (Page). Beim 68030 ist die Größe einer solchen Seite variabel, sie kann zwischen 256 Bytes und 32 kB liegen. Der letztgenannte Wert wird auch beim Atari TT verwendet, da er den geringsten Verwaltungsaufwand und die größte Geschwindigkeit mit sich bringt.

Bild 1: CPU Root-Pointer-Register und Deskriptor-Aufbau

Der tiefere Sinn

Für das Betriebssystem der Atari-Computer ist die Fähigkeit einer MMU zur Adreßübersetzung eigentlich nur von geringer Bedeutung. Das TOS kann das RAM nämlich nur dann korrekt nutzen, wenn sich keine Lücken innerhalb des RAM-Speichers befinden. Eine Neuorganisation des Speichers ist deshalb im Normalfall nicht sinnvoll. Äußerst wichtig ist eine MMU jedoch für Systeme, die mit einer virtuellen Speicherverwaltung arbeiten. Hierzu zählt beispielsweise UNIX, das laut Atari demnächst auch für den TT zur Verfügung stehen soll.

Das Prinzip des virtuellen Speichers besteht darin, daß die Speicherkapazität externer Medien, bei denen es sich normalerweise um Festplatten handelt, zum eigentlichen Hauptspeicher quasi addiert wird. Stark vereinfacht bedeutet dies: Besitzt man einen Rechner mit einem RAM-Ausbau von 4 MB und eine Festplatte, die 60 MB zur Verfügung stellt, so stehen einem Programm scheinbar 64 MB Hauptspeicher zur Verfügung. Das Betriebssystem sorgt in einem solchen Fall dafür, daß Speicherbereiche (eben die soeben angesprochenen Pages), die momentan nicht benötigt werden, auf der Platte gesichert und andere RAM-Bereiche von der Platte in den Hauptspeicher übertragen werden. Hinter diesem System steckt ein recht komplizierter Mechanismus, mit dem wir uns an dieser Stelle nicht näher beschäftigen wollen. Erst durch eine MMU ist es jedoch möglich, dieses Konzept sinnvoll zu verwirklichen.

Zurück zum TT

Habe ich eben behauptet, die Adreßumsetzung sei für TOS nicht allzu wichtig? Nun, für das TOS des TT stimmt das nicht so ganz. Die ST-Kompatibilität dieses Rechners basiert zum Teil darauf, daß der TT-Adreßraum von 4 GB durch die MMU so zurechtgebogen wird, daß die Verhältnisse denen beim ST gleichkommen. Man kann also von einer Art ST-Emulation sprechen. Die MMU sorgt dafür, daß sich das ROM und alle Hardware-Adressen innerhalb der ersten 16 MB des Adreßraums (dies ist der ST-Adreßraum) wiederfinden. Die gleichen Hardware-Adressen sind jedoch auch in den letzten 32 kB des TT-Adreßraums zu finden. Für den Betrieb unter UNIX sollte die ST-Kompatibilität des TT also keinerlei Nachteile mit sich bringen. Hier fällt die ST-Emulation einfach unter den Tisch, und man hat einen Rechner mit ganz anderen Eigenschaften vor sich, der nur noch einen Teil der Hardware mit einem ST gemeinsam hat.

Aufbau der PMMU

Zwar ist die im 68030 integrierte PMMU mit einem ganzen Satz an Steuerregistern ausgestattet, doch wollen wir uns hier nur mit den für unser Vorhaben wichtigen Registern und Datenstrukturen beschäftigen. Bild 1 zeigt eine Übersicht über alle für uns relevanten Angaben. Ausführliche Beschreibungen der MMU finden sich in [1]. [2] und [3]. In [2] wird in erster Linie die PMMU 68851 beschrieben, die gegenüber der PMMU des 68030 einige zusätzliche Fähigkeiten besitzt.

Das CPU Root-Pointer-Register (CRP)

Voraussetzung für eine Adreßumrechnung per MMU ist die Aufteilung des Adreßraums in Abschnitte, für die jeweils ein eigener Umrechungsmodus eingerichtet werden kann. Diese Speicherabschnitte werden durch spezielle Datenstrukturen beschrieben, die man Deskriptor-Tabellen nennt. Eine solche Tabelle enthält wichtige Angaben darüber, wie die MMU den logischen Adreßraum auf den physikalisch vorhandenen Speicher abbilden soll. Das CRP stellt in erster Linie einen Pointer auf die erste dieser Deskriptor-Tabellen (Tabelle der Ebene 1) dar. Jede Tabelle muß auf einer durch 16 teilbaren Adresse beginnen. Somit genügen 28 Bits im CRP, um die Startadresse der ersten Tabelle zu definieren. Die Limit-Bits des CRP beschränken den Index in diese Tabelle nach oben (L/U=0) oder unten (L/U=1). Der Deskriptor-Typ (DT) gibt schließlich die Art der Deskriptor-Tabelle an. auf die das CRP zeigt.

Einen Teil der Deskriptor-Tabellen kann die MMU übrigens in einem besonderem Cache, dem ATC (Address Translation Cache) unterbringen, so daß zur Adreßumrechnung nicht ständig auf den Hauptspeicher zugegriffen werden muß.

Deskriptor-Tabellen

Eine Deskriptor-Tabelle kann zwei Arten von Einträgen enthalten: Tabellen-Deskriptoren (Table Descriptor) und Seiten-Deskriptoren (Page Deskriptor).

Die Unterscheidung zwischen diesen Deskriptoren geschieht in deren niederwertigen beiden Bits. Handelt es sich um einen Tabellen-Deskriptor, haben diese Bits den Wert %10. Neben einigen Flags, die wir gleich kennenlernen werden, enthalten die oberen 24 Deskriptor-Bits in diesem Fall die Adresse einer weiteren Deskriptor-Tabelle.

Bei Seiten-Deskriptoren finden wir in den niederwertigen Bits die Bit-Kombination %01. Seiten-Deskriptoren enthalten Angaben darüber, wie die Adreßumsetzung vom logischen auf den physikalischen Speicher durchzuführen ist. Der Aufbau dieser Deskriptoren ähnelt dem der Tabellen-Deskriptoren. Die höchstwertigen 24 Bits enthalten jedoch keinen Pointer auf einen weiteren Deskriptor, sondern die Adresse des physikalischen Speichers, der von der MMU im Rahmen der Adreßumsetzung einer logischen Speicherseite zugeordnet werden soll. Bei der Besprechung der Deskriptoren des TT werden wir hierzu konkrete Beispiele kennenlernen.

Flagge bekennen

Neben den 24 höchstwertigen Adreß-Bits enthält jeder Deskriptor einige weitere Bits, hinter denen sich wichtige Flags verbergen. Bei den Seiten-Deskriptoren kommt diesen Flags die folgende Bedeutung zu:

WP (Write Protect bit): Ist dieses Bit gesetzt, kann die vom Deskriptor beschriebenen Speicherseite nicht beschrieben werden. Schreibzugriffe führen zu einem Busfehler.

U (Used bit): Dieses Bit wird von der MMU gesetzt, sobald der zugehörige Deskriptor für eine Adreßübersetzung benötigt wird. Durch Testen dieses Bits kann man also feststellen, ob zwischenzeitlich auf einen bestimmten Speicherbereich zugegriffen wurde. Das Used bit wird übrigens niemals von der MMU zurückgesetzt. Hierfür muß man also bei Bedarf selber sorgen.

M (Modified bit): Ist dieses Bit gesetzt, hat ein Schreibzugriff auf die entsprechende Speicherseite stattgefunden, es wurden also Speicherinhalte verändert. Besonders bei der Verwaltung von virtuellem Speicher ist dieses Bit von Bedeutung. Wurde eine Speicherseite nicht verändert, ist es nicht notwendig, diese vor dem Überschreiben auf einem externen Datenspeicher zu sichern. Auch dieses Bit kann zwar von der MMU gesetzt, jedoch nicht zurückgesetzt werden.

CI (Cache Inhibit bit): Beim Zugriff auf Speicherseiten, in deren Deskriptoren dieses Bit gesetzt ist, wird der interne Cache des 68030 nicht verwendet. Auf solchen Speicherseiten können sich z.B. Hardware-Adressen befinden, deren Inhalt sich ohne Wissen des Prozessors verändern kann.

So weit die Beschreibung der Deskriptor-Flags für Seiten-Deskriptoren. Die Bedeutung dieser Flags kann in analoger Weise auf Tabellen-Deskriptoren übertragen werden. Ist beispielsweise bei einem Tabellen-Deskriptor das Write Protect Bit gesetzt, sind alle von diesem Deskriptor abhängigen (also die über diesen Deskriptor mit Hilfe weiterer Deskriptoren definierten) Speicherseiten gegen Überschreiben geschützt.

Ich möchte nicht verschweigen, daß neben dem hier beschriebenen kurzen Deskriptor-Format noch ein langes Format existiert, das jedoch für unseren Fall keine Bedeutung hat. In diesem erweiterten Format benötigt jeder Deskriptor-Eintrag 8 Bytes. Das lange Deskriptor-Format ermöglicht es in erster Linie, einzelne Speicherseiten gegen Zugriffe aus dem User-Modus des 68030 zu schützen. Dies erinnert an die Systemvariablen des TT, die nur im Supervisor-Modus angesprochen werden können. Hier geschieht der Schutz jedoch nicht über die MMU, sondern ist hardwaremäßig realisiert.

TT-Deskriptoren der Ebene 1

Wie sind nun die Deskriptor-Tabellen des TT organisiert?

Die Tabellen- und Seiten-Deskriptoren des 68030 liegen beim TT laut CRP ab Adresse $700, also oberhalb der Systemvariablen im nur aus dem Supervisor-Modus zugänglichen Speicherbereich. Alle Deskriptoren sind zusammen mit ihren Adressen im Speicher des TT in Bild 2 dargestellt. Bei der Analyse dieser Langworte muß man die Aufteilung der 32 Bits umfassenden Deskriptoren in einen Pointer auf einen weiteren Deskriptor bzw. auf eine Speicherseite (Bits 31 bis 4) und in die Flags (Bits 3 bis 0) beachten.

Der erste Deskriptor macht Aussagen über die Adreßumsetzung für den logischen Speicherbereich von $00000000 bis $0FFFFFFF mit einer Größe von 256 MB. Es handelt sich um einen Tabellen-Deskriptor, wie an beiden niederwertigen Bits, die ja den Deskriptor-Typ beschreiben, unschwer zu erkennen ist. Bit 3 ist in diesem Deskriptor gesetzt. Hierbei handelt es sich um das U-Bit, was besagt, daß dieser Deskriptor bereits von der MMU verwendet worden ist. Seit dem Einschalten des Rechners erfolgte also mindestens ein Zugriff auf die ersten 256 MB des Hauptspeichers. Genauere Angaben über die Zuordnung dieses Speicherbereichs macht die Deskriptor-Tabelle ab $740, deren Adresse dieser Deskriptor enthält.

Die nächsten 14 Deskriptoren stellen Seiten-Deskriptoren dar. Es erfolgt für jeweils 256 MB eine direkte Umsetzung der logischen in die physikalischen Adressen. Anzumerken ist lediglich, daß in den Deskriptoren für den Adreßraum von $80000000 bis $EFFFFFFF das CI-Flag gesetzt ist. In diesen Speicherbereichen wird der Prozessor-Cache des 68030 also nicht verwendet.

Beim letzten Deskriptor der Ebene 1 handelt es sich wieder um einen Tabellen-Deskriptor, der auf eine weitere Deskriptor-Tabelle zeigt, die ab Adresse $780 zu finden ist. Diese Tabelle macht Angaben über die Aufteilung der oberen 256 MB des Hauptspeichers.

Bild 2: Die Deskriptortabellen beim TT

Die nächste Ebene

Die erste Deskriptor-Tabelle der Ebene 2 beginnt ab $0740 und beschreibt die Einteilung der ersten 256 MB des Adreßraums. Auch diese Tabelle enthält 16 Einträge, von denen jeder für einen Speicherbereich von 16 MB zuständig ist. Beim ersten Langwort handelt es sich um einen Tabellen-Deskriptor, alle anderen sind Seiten-Deskriptoren, die keinen besonderen Effekt für die Speicherzuteilung besitzen. Der logische Speicher wird hier direkt auf den physikalischen abgebildet.

Die zweite Tabelle enthält Aussagen über die letzten 256 MB des Adreßraums. Bis auf den letzten Deskriptor finden sich in dieser Deskriptor-Tabelle ausschließlich Seiten-Deskriptoren mit gesetztem CI-Flag, die lediglich für gleiche logische und physikalische Adressen sorgen. Nur für die oberen 16 MB des Speichers ist ein Tabellen-Deskriptor vorhanden, da hier eine spezielle Aufteilung notwendig ist.

Vergleicht man die beiden Tabellen-Deskriptoren für die ersten und die letzten 16 MB des Adreßraums, fällt auf, daß beide auf die gleiche Adresse, also auf die gleiche Deskriptor-Tabelle zeigen.

Dies heißt im Klartext: Ob die unteren 16 MB (hier befindet sich in erster Linie das ST-RAM) oder die oberen 16 MB (dort liegen die Hardware-Adressen) des TT-Adreßraums angesprochen werden, macht keinen Unterschied. Beide Speicherbereiche werden gleich behandelt. Diese Situation ist an die Speicheraufteilung des ST angelehnt. Bei diesem Rechner werden nur die ersten 16 MB genutzt. Innerhalb dieses Bereichs können sowohl das RAM als auch die Hardware-Adressen und das ROM angesprochen werden. Eben diese Speicheraufteilung wird durch die MMU des TT nachgebildet. Beim Zugriff auf das obere Megabyte, in dem sich die Adressen der Hardware befinden, wird der Cache laut Seiten-Deskriptor übrigens nicht benutzt.

So, damit haben wir alle Deskriptor-Tabellen und somit die normale Speicheraufteilung des TT im ST-kompatiblen Modus abgehakt. Es bleibt anzumerken, daß die obigen Erläuterungen zur MMU lediglich die Aufteilung des TT-Speichers betreffen. Die MMU erlaubt viel komplexere Einteilungen des Adreßraums, als wir sie beim TT finden. Hier sei auf die angegebene Literatur verwiesen.

Aus ROM wird RAM

Für unser Unterfangen, alle ROM-Zugriffe per MMU ins RAM umzulenken, ist nur einer der besprochenen Deskriptoren von Bedeutung. Es handelt sich um den Deskriptor ab Adresse $7F8, der den Wert $00E00009 besitzt. Dieser Seiten-Deskriptor gibt an, daß alle Zugriffe auf die logischen Adressen ab $00E00000 (hier befindet sich das ROM!) quasi ohne Umrechnung auf die entsprechenden physikalischen Adressen erfolgen. Wird hier ein Pointer auf einen Speicherbereich im RAM eingerichtet, werden alle Zugriffe, die eigentlich im ROM landen würden, aus dem RAM bedient. Ein Wert von $01000009 als Seiten-Deskriptor sorgt beispielsweise dafür, daß beim Zugriff auf $0E000004 in Wirklichkeit auf $01000004 zugegriffen wird. Programme merken von der geänderten Situation gar nichts, egal ob sie sich bereits im Speicher befinden oder zu einem späteren Zeitpunkt gestartet werden.

Nun steht uns unser Ziel vor Augen: Das ROM wird ins RAM kopiert und der Seiten-Deskriptor für die logische ROM-Adresse auf diesen RAM-Bereich umgebogen. Eigentlich ganz einfach, oder?

In der Kürze liegt die Würze

Denn die eigentlichen Routinen zur Verschiebung des ROMs ins RAM und zur MMU-Programmierung umfassen nur wenige Programmzeilen.

Wichtig ist, daß die RAM-Kopie an einer Page-Grenze beginnt. Da eine Speicherseite beim TT-TOS 32 kB groß ist, wird durch eine passende AND-Operation die korrekte Startadresse erzeugt. Nachdem das ROM an diese Adresse kopiert wurde, kann nun der Page-Deskriptor angepaßt werden. TOS legt den Deskriptor für den Speicherbereich ab $00E00000 an Adresse $7F8 ab. Zwar ist es nicht gerade sauber, diese nicht offiziell dokumentierte Adresse zu ändern, aber andererseits wäre es auch nicht besser, eine völlig neue Deskriptor-Tabelle anzulegen. Hierzu müßten nämlich undokumentierte Eigenschaften der TT-Speicherorganisation verwendet werden.

Der neue Page-Deskriptor besagt, daß alle Zugriffe auf die ROM-Adressen nun von der MMU ins TT-RAM umgelenkt werden. Der Deskriptor selbst setzt sich aus den oberen 24 Adreß-Bits der physikalischen Adresse des neu belegten Speicherblocks sowie aus den bereits angesprochenen Flags zusammen. Wird Bit 2 des Deskriptors gesetzt, kann auf die Adressen ab $00E00000 kein Schreibzugriff erfolgen. Es ist zu beachten, daß es dennoch möglich ist, auf die Adressen der ROM-Kopie im TT-RAM schreibend zuzugreifen. Zwar könnte auch das RAM durch einen erhöhten Programmieraufwand mit Hilfe der MMU gegen Überschreiben geschützt werden, aber hierfür wäre eine größere Deskriptor-Tabelle erforderlich, was zu Zeitverlusten bei der Adreßübersetzung führen würde. Der ATC des 68030 faßt nämlich maximal 22 Deskriptor-Einträge. Bei großen Deskriptor-Tabellen müssen deshalb des öfteren Einträge aus dem RAM gelesen werden, was einen gewissen Geschwindigkeitsverlust zur Folge hat.

Der MMU-Befehl PFLUSHA sorgt abschließend dafür, daß alle Einträge im ATC der MMU invalidiert werden. Der geänderte Seiten-Deskriptor wird somit beim nächsten Zugriff auf die Adressen des ehemaligen ROM-Bereichs neu in die MMU übertragen, und damit werden alle Zugriffe auf ROM-Adressen nun im RAM abgewickelt.

Auf das RAM kommt es an

ROMSPEED läuft nur auf dem Atari TT und gibt beim Start auf dem ST eine entsprechende Meldung aus. Auf welchem Rechner das Programm gestartet wurde, erkennt es anhand des entsprechenden Eintrags im cookie jar [4].

Damit die Systemroutinen auch wirklich schneller werden, muß unbedingt dafür gesorgt werden, daß das ROMSPEED-Programm im TT-RAM läuft. Hierzu muß man das entsprechende Bit im Programm-Header setzen. Andernfalls ist kein Geschwindigkeitszuwachs zu beobachten, da ein Zugriff aufs ST-RAM mit der gleichen Geschwindigkeit abläuft wie ein normaler ROM-Zugriff. Aber auch dann, wenn man nicht über einen TT mit Fast-RAM verfügt, kann ROMSPEED durchaus nützliche Dienste leisten. Hierzu gleich mehr.

Noch ein Hinweis zum Assemblieren: ROMSPEED enthält 68030-Code und sollte deshalb mit einem Assembler assembliert werden, der diesen Code erzeugen kann. Besonders empfehlenswert ist der MAS, der zum Lieferumfang des TURBO C 2.0 Professional gehört. Sind Sie nicht im Besitz eines geeigneten Programms, kann anstatt des PFLUSHA-Befehls auch der entsprechende Opcode direkt eingetragen werden. Der Opcode von PFLUSHA ist aus dem Assembler-Quelltext (Listing 1) ersichtlich. Die Programmlänge von ROMSPEED nach dem Assemblieren sollte 337 Bytes betragen.

Werkeinen Assembler besitzt, kann sich mit einem kleinen Programm in GFA-BASIC behelfen (Listing 2). Dieses Programm erzeugt eine lauffähige Version von ROMSPEED, in der bereits alle Flags des Programm-Headers korrekt gesetzt sind.

BIOS text BIOS String BIOS scroll GEM draw  
211% 207% 225% 180% ohne ROMSPEED
242% 252% 228% 233% mit ROMSPEED

Tabelle 1: Benchmarks (Quickindex V1.8, TOS 1.6 als Referenz)

Was bringt's?

Diese Frage steht natürlich bei jeder Methode, die Geschwindigkeit eines Rechners zu erhöhen, im Mittelpunkt. Tabelle 1 stellt Vergleichsdaten zur Verfügung. Gemessen wurden die Zeiten für die Bildschirmausgabe in der hohen ST-Auflösung mit und ohne ROMSPEED unter Verwendung des Programms Quickindex V1.8. Alle Zeiten beziehen sich auf einen Atari 1040STE mit TOS 1.6 als Referenz.

Ganz allgemein läßt sich sagen, daß ein Programm durch ROMSPEED umso stärker beschleunigt wird, je mehr ROM-Routinen von diesem Programm aufgerufen werden. Besonders deutlich wird der Geschwindigkeitszuwachs bei Programmen, die das GEM intensiv nutzen, da hier besonders viele Systemroutinen durchlaufen werden. Dementsprechend ist der Gewinn an Geschwindigkeit beim Zeichnen von Dialogboxen am größten. Hierfür spricht auch der von Quickindex gelieferte Wert für das Darstellen von Dialogboxen. Einige GEM-Funktionen erfahren durch ROMSPEED um bis zu 30% Beschleunigung.

Selbst wenn man bereits Programme wie Belas NVDI installiert hat, die neue, schnellere GEM-Routinen im TT-RAM zur Verfügung stellen, läßt sich bei Ausgaben, die über das GEM getätigt werden, noch ein Geschwindigkeitsgewinn feststellen.

Kompatibilität ist Trumpf

Viele Leser dürften sich inzwischen fragen, ob denn Manipulationen, wie sie von ROMSPEED vorgenommen werden, zu Kompatibilitätsproblemen führen können. Diese Frage kann man im Prinzip mit „Nein“ beantworten. Selbst Programme, die so unsauber programmiert sind, daß sie undokumentierte Systemvariablen verwenden oder gar ROM-Routinen direkt anspringen (auch so etwas soll es geben), haben mit ROMSPEED keinerlei Probleme. Dies ist auch kein Wunder, da ein Programm, das sich nicht selber der MMU bedient, überhaupt nichts von den vorgenommenen Speichermanipulationen bemerkt. Vorsicht geboten ist lediglich bei Programmen, die eigene Manipulationen an der MMU vornehmen. Hier kann es passieren, daß ROMSPEED nicht einsatzfähig ist.

Tja, noch sind wir nicht am Ende angelangt. Vielleicht ist dem einen oder anderen Leser ja schon in den Sinn gekommen, daß neben der höheren Geschwindigkeit der Systemroutinen noch eine weitere Besonderheit aus der durchgeführten Speichermanipulation resultiert: Die ROM-Kopie, die im RAM liegt, kann ohne jegliche Hardware-Bastelei gepatcht oder mit etwas größerem Aufwand durch ein anderes TT-Betriebssystem ersetzt werden. (Dies ist in erster Linie dann interessant, wenn in Zukunft neue TOS-Versionen für den TT erscheinen sollten.) Auch für TT-Anwender, deren Rechner nicht über TT-RAM verfügen, kann ROMSPEED also durchaus interessant sein. Zwar bringt das Programm in diesem Fall keinen Geschwindigkeitsgewinn, aber immerhin kann das ROM quasi ins RAM verlegt werden.

Ist es beim ST noch unumgänglich, ROM-Patches zur abschließenden Überprüfung in Eproms zu brennen, braucht man sich beim TT um solche Feinheiten nicht mehr zu kümmern. Um das direkte Patchen des ursprünglichen ROM-Bereichs zu ermöglichen, genügt es, das Schreibschutz-Bit im neu angelegten Page-Deskriptor nicht zu setzen. Dies ist im Assembler-Listing angedeutet. Gepatcht werden darf anschließend nach Herzenslust. Im Falle eines Falles genügt ein Reset, um sich eines fehlgeschlagenen Patch-Versuches zu entledigen. Die Devise heißt also: Patch As Patch Can!

Gesagt, getan

Wenn nun schon das Patchen beim TT so leicht fällt, so soll ein vom ST bekannter Standard-Patch an dieser Stelle nicht fehlen. Da der TT mit dem gleichen Floppy-Controller (WD1772) wie der ST arbeitet, ist es auch beim TT möglich, höhere Geschwindigkeiten beim Laden und Speichern dadurch zu erreichen, daß das Verify, das der Controller nach jedem Spurwechsel durchführt, abgeschaltet wird.

Der Befehl, der das entsprechende Bit beim TT setzt, befindet sich an Adresse $00E01F44 (Diese Angabe gilt nur für Version 3.01 des TT-TOS!) Um das Verify abzuschalten, muß das Wort $7C14, das sich an dieser Stelle befindet, durch $700 ersetzt werden. Dies bereitet uns keinerlei Probleme, liegen doch alle ursprünglichen ROM-Routinen nun im RAM. Aber nicht vergessen: Das Schreibschutz-Bit des Seiten-Deskriptors für den Bereich ab $00E00000 darf nicht gesetzt sein, sonst kann der Speicher nicht verändert werden!

Ausblick

Man kann davon ausgehen, daß in nächster Zeit weitere Programme von der im 68030 integrierten MMU Gebrauch machen werden. Besonders interessant dürfte die MMU beispielsweise für die Entwickler von Macintosh-Emulatoren sein, kann man doch jetzt die ROM-Routinen dieses Rechners an ihren eigentlichen Adressen belassen. Damit unterscheidet sich eine Macintosh-Emulation auf dem TT nur noch in den hardware-abhängigen Punkten von der standardmäßigen ST-Emulation.

Mindestens ein Programm, das sich die Möglichkeiten der MMU zunutze macht, existiert übrigens schon seit dem Herbst letzten Jahres. Hierbei handelt es sich um das Programm 24BIT.PRG, das von Atari USA kommt. Dieses Programm sorgt dafür, daß Programme, die die oberen 8 Adreß-Bits der 32-Bit-Adressen des 68030 für eigene Zwecke mißbrauchen, dennoch im ST-RAM des TT ablaufen können. (Beim 68000 werden diese Adreß-Bits ignoriert.) Das von mir in [5] angesprochene Problem hat sich somit erledigt. Prominentes Beispiel für ein Programm, das nur mit Hilfe von 24BIT.PRG auf dem TT lauffähig ist, ist die Textverarbeitung TEMPUS WORD. Auch compilierte GFA-BASIC-Programme sind betroffen. Sollte Ihr Lieblingsprogramm nicht auf dem TT laufen, kann 24BIT.PRG durchaus die Lösung darstellen. Leider ergab eine Anfrage bei Atari Deutschland die Antwort, daß die Verbreitung toleriert wird, aber es nicht über Atari bezogen werden kann.

US

[1] „MC68030 32-Bit Microprozessor User's Manual, Motorola Inc.

[2] „MC6885I Paged Memory Management Unit User’s Manual“, Motorola Inc.

[3] Steve Williams, „68030 Assembly Language Reference“, Addison-Wesley Publishing Company Inc.

[4] Rolf Kotzian, „Das Cookie-Jar-Prinzip“, ST-Computer 12/90

[5] „Wie ST-kompatibel ist der TT?“, ST-Computer 10/90


OPEN "O",#1,"ROMSPEED.PRG"
FOR i=1 TO 337 
    READ byte
    PRINT #1,CHR$(byte);
NEXT i 
CLOSE #1

DATA &60,&1a,&00,&00,&01,&28,&00,&00,&00,&00,&00,&08,&a0,&06,&00,&00 
DATA &00,&00,&00,&00,&00,&00,&00,&00,&00,&07,&00,&00,&48,&7a,&00,&5e 
DATA &3f,&3c,&00,&26,&4e,&4e,&5c,&8f,&4a,&39,&00,&08,&81,&2d,&66,&3c 
DATA &48,&7a,&00,&b6,&3f,&3c,&00,&09,&4e,&41,&5c,&8f,&4a,&39,&00,&08 
DATA &81,&2c,&66,&34,&22,&79,&00,&08,&81,&28,&93,&fc,&00,&00,&01,&28 
DATA &d3,&fc,&00,&08,&00,&00,&20,&6f,&00,&04,&d3,&e8,&00,&0c,&43,&e9 
DATA &01,&00,&42,&67,&48,&51,&3f,&3c,&00,&31,&4e,&41,&48,&7a,&00,&ae 
DATA &3f,&3c,&00,&09,&4e,&41,&5c,&8f,&42,&67,&4e,&41,&20,&38,&05,&a0
DATA &57,&f9,&00,&08,&81,&2d,&67,&5e,&20,&40,&4c,&d8,&00,&03,&4a,&80 
DATA &67,&54,&b0,&bc,&5f,&4d,&43,&48,&66,&f0,&b2,&bc,&00,&02,&00,&00
DATA &56,&f9,&00,&08,&81,&2d,&66,&3e,&0c,&78,&00,&e0,&07,&£8,&56,&f9
DATA &00,&08,&81,&2c,&66,&30,&22,&3c,&00,&00,&81,&28,&c2,&7c,&80,&00
DATA &23,&c1,&00,&08,&81,&28,&20,&41,&43,&£9,&00,&e0,&00,&00,&20,&3c 
DATA &00,&02,&00,&00,&20,&d9,&53,&80,&66,&fa,&82,&7c,&00,&05,&21,&c1 
DATA &07,&£8,&£0,&00,&24,&00,&4e,&75,&0d,&0a,&52,&4f,&4d,&53,&50,&45
DATA &45,&44,&20,&56,&31,&2e,&30,&20,&69,&6e,&73,&74,&61,&6c,&6c,&69
DATA &65,&72,&74,&0d,&0a,&bd,&20,&31,&39,&39,&31,&20,&62,&79,&20,&55 
DATA &77,&65,&20,&53,&65,&69,&6d,&65,&74,&0d,&0a,&00,&0d,&0a,&52,&4f
DATA &4d,&53,&50,&45,&45,&44,&20,&6c,&84,&75,&66,&74,&20,&6e,&75,&72
DATA &20,&61,&75,&66,&20,&64,&65,&6d,&20,&41,&74,&61,&72,&69,&20,&54
DATA &54,&0d,&0a,&00,&00,&00,&00,&0e,&14,&08,&06,&36,&20,&0e,&08,&0a
DATA &00,&0c

Listing 1: ROMSPEED.LST (GFA-BASIC)

*********************************
*                               *
* ROMSPEED.PRG                  *
* verlegt ROM ins TT-RAM        *
* (c) MAXON Computer GmbH       *
*                               *
* Januar 1991 by Uwe Seimet     *
*                               *
*********************************


GEMDOS  = 1 
CCONWS  = 9 
PTERMRES= 49


XBIOS   = 14 
SUPEXEC = 38

_p_cookies = $5a0           ;Pointer auf cookie-jar


        text

        pea super(pc) 
        move #SUPEXEC,-(sp) 
        trap #XBIOS 
        addq.l #6,sp
        tst.b stflg         ;Atari ST?
        bne.b quitst        ;je-
        pea message(pc)
        move #CCONWS,-(sp)  ;Meldung
        trap #GEMDOS        ;ausgeben
        addq.l #6,sp
        tst.b ramflg        ;bereits installiert? 
        bne.b quit          ;ja-
        move.l rompnt,a1    ;neue ROM-Startadresse
        sub.l #mem,a1
        add.l #524288,a1    ;512K Speicher reservieren 
        move.l 4(sp),a0     ;Basepage-Adresse
        add.l 12(a0),a1     ;TEXT-Segment
        lea $100 (a1),a1    ;Basepage-Länge
        clr -(sp) 
        pea (a1)
        move #PTERMRES,-(sp);residentes 
        trap #GEMDOS        ;Programm
quitst: pea ttonly(pc)
        move #CCONWS,-(sp) 
        trap #GEMDOS 
        addq.l #6,sp 
quit:   clr -(sp)
        trap #GEMDOS

super:
        move.l _p_cookies,d0 ;cookie jar vorhanden?
        seq stflg
        beq.b exit          ;nein-
        move.l d0,a0 
loop:   movem.l (a0)+,d0-d1 ;Ende der
        tst.l d0            ;Liste?
        beq.b exit          ;ja-
        cmp.l #"_MCH",d0    ;cookie für Computertyp? 
        bne loop            ;nein-
        cmp.l #$00020000,d1 ;TT? 
        sne stflg
        bne.b exit          ;nein-
        cmp #$00e0,$7f8     ;ROMSPEED schon installiert?
        sne ramflg
        bne.b exit          ;ja-

*Die folgenden Befehle sind die entscheidenden

        move.l #mem+32768,d1 
        and #$8000,d1       ;neue ROM-Adresse 
                            ;auf Pagegrenze ausrichten
        move.l d1,rompnt    ;und merken
        move.l d1,a0
        lea $00e00000,a1    ;ROM-Adresse
        move.l #131072,d0   ;512K ROM ins
copy:   move.l (a1)+,(a0)+  ;RAM kopieren
        subq.l #1,d0 
        bne copy
        or #5,d1            ;Page-Deskriptor markieren und 
                            ;schreibschützen (nicht geschützt 
                            ;bei or #1,d1) 
        move.l d1,$7f8      ;in Deskriptor-Tabelle eintragen 
        pflusha             ;ATC löschen (identisch mit dc.l $F0002400) 
exit:   rts                 ;das war alles

message:dc.b $0d,$0a
        dc.b "ROMSPEED V1.0 installiert" 
        dC.b $0d,$0a
        dc.b "  1991 by Uwe Seimet"
        dC.b $0d,$0a,$00

ttonly: dc.b $0d,$0a
        dc.b "ROMSPEED läuft nur " 
        dc.b "auf dem Atari TT" 
        dc.b $0d,$0a,$00


        bss

Mem:    ds.b 557056     ;512K + 32K

rompnt: ds.l 1          ;Pointer auf ROM-Kopie 

ramflg: ds.b 1          ;Flag für Zweitinstallation

stflg:  ds.b 1          ;Flag für Atari ST

Listing 2: ROMSPEED.S (Assembler)


Uwe Seimet
Aus: ST-Computer 03 / 1991, Seite 145

Links

Copyright-Bestimmungen: siehe Über diese Seite