PAK-68 - Hansdampf in allen Gassen? 68020-Power im ST!

Wer heute einen Rechner kauft, muß damit rechnen, daß übermorgen eine Super-duper-hyper-maschine auf den Markt kommt, die den eigenen Computer als lahme Ente erscheinen läßt. Vor wenigen Jahren galt der 68000 als das Non-plus-ultra, mit dem man Workstations ausstattete. Heute ist er ein Massenprodukt, das allgemein zu einem günstigen Preis erhältlich ist (unter 20 DM). Am nahen Horizont zeichnet sich die Einführung der Transputer für den Massenmarkt ab, man denke nur an den ABAQ von ATARI. Der Einsatz des 68030 ist auch schon fest geplant. Vor diesem Hintergrund fragt sich der geplagte Anwender, ob er sich schon wieder einen neuen Rechner zulegen muß, oder ob es Erweiterungsmöglichkeiten gibt, mit denen sein neuer, alter Rechner noch eine Weile mithalten kann.

Für den AMIGA schon gang und gäbe, ist es nun möglich, auch den ATARI ST mit einer CPU-Austauschkarte auszurüsten, die einen 68020 und optional den Arithmetikchip 68881 enthält. Was bringt eine solche Erweiterung nun im alltäglichen ST-Betrieb? Dieser Test gibt eine Antwort:

Zunächst einmal vorweg: Die von mir hier getestete Karte ist von der Firma esd in Hannover entwickelt worden und wird auch von ihr als Fertigkarte professionell vertrieben. In der c’t 8/87 ist diese Karte als c’t-Projekt vorgestellt worden. Es besteht also die Möglichkeit, die Platine einzeln zu beziehen und die Karte selber aufzubauen - so habe ich es gemacht. Mittlerweile werden von verschiedenen Firmen auch schon Bausätze angeboten -allerdings ohne 68020 und 68881. Wer sich also den Selbstbau zutraut, der sollte den Kleinanzeigenteil der Computerzeitschriften nach günstigen Angeboten durchforsten. Auf diese Weise habe ich von einem Privatmann beide Chips (68020 und 68881) für 500 DM bekommen - in der 16-MHz-Ausführung! Das war im Februar dieses Jahres ein sehr guter Preis. Inzwischen dürften die Preise für Prozessoren noch etwas gefallen sein.

Für die PAK-68-Karte gibt es außerdem noch zwei Erweiterungen: Die PUK-Umschaltplatine, mit der man zwischen 68000 und 68020 umschalten kann, und eine PAK-68-MEM-Karte, die die 32-Bit-CPU erst so richtig aufleben läßt. Die PUK-Umschaltplatine ist besonders sinnvoll, denn nicht alle Programme laufen mit dem flotten 20er.

Aufbau

Zunächst einmal zu den technischen Details: Die PAK-68 ist quadratisch, praktisch , gut und hat eine Kantenlänge von 10 cm. Auf ihr sind 13 ICs, 11 Kondensatoren, verschiedene Stift- und Pfostenleisten, 2 Widerstandsnetzwerke und ein Quarzoszillator verteilt. Alles in allem sind es mehr als 500 Lötstellen, die auf 100 cm2 untergebracht werden wollen. Für mich war die PAK-68 die erste größere Platine, die ich eigenhändig bestückt und verlötet habe. Das Teil ist auf Anhieb gelaufen, also nur Mut (was ich allerdings - so ganz ohne Oszilloskop und entsprechendes Fachwissen - gemacht hätte, wenn etwas schiefgelaufen wäre, weiß ich nicht - und will es auch nicht wissen!).

Der Quarzoszillator auf der Platine verdient eine genauere Betrachtung. Da hat man vielleicht - wie in meinem Fall - die 16- oder gar 20-MHz- Ausführung des Prozessorgespannes erworben. In diesem Fall möchte man natürlich auch die Leistungsreserven voll ausnutzen und setzt munter den 16-MHz Oszillator ein - und nichts geht mehr. Leider ist im ATARI der Buszugriff der CPU mit dem Rest (z.B. Shifter) so verzahnt, daß für eine Takterhöhung kein Spielraum mehr bleibt. Den AMIGA kann man dagegen fast problemlos mit 10-13 MHz takten [1]. Allerdings besteht die Möglichkeit, den Coprozessor mit einem anderen Takt als die CPU zu versorgen. Auf der PAK-68 tragen Jumper dieser Tatsache Rechnung. Im ATARI wählt man also für die CPU den Systemtakt von 8 MHz und für den Coprozessor den bordeigenen, höheren Takt (z.B. 12.5, 16 oder 20 MHz).

In der Testphase befindet sich eine dynamische Taktumschaltung, die bei Zugriffen des 68020 auf den Cache-Speicher und auf das optionale 32-Bit-Ram diesen auf bordeigenen Takt schaltet. Wenn es dann noch möglich ist, das 32-Bit-Ram in die TOS-Verwaltung zu integrieren (auch in dieser Hinsicht haben es AMIGA-User leichter), dann hat man eine kleine Workstation, die nur noch bei Ein-/Ausgabeprozessen langsamer ist als eine ‘echte’ 2Oer-Maschine. Doch nun genug geträumt, begnügen wir uns zunächst mit dem, was da ist.

Einbautips

Wie kriege ich den 20er nun in meinen ST? Bekanntlich führen mehrere Wege nach Rom, in unserem Falle zwei: Wer mit deutscher Gründlichkeit Vorgehen möchte, der lötet seinen treuen 68000er aus, eine 64polige Fassung ein und steckt schließlich die PAK-Karte zusammen mit der PUK-Umschaltplatine ein. Die Sache hat nur einen Haken: Das Entlötwerkzeug - ein 64poliges IC ist teuer - zu teuer für eine einmalige Aktion. Profis benutzen regelbare Heißluftgeräte. Ich habe ganz einfach radikal alle Pins der CPU abgekniffen und dann jeden einzelnen ausgelötet. Die dermaßen bearbeitete CPU läßt sich natürlich nicht weiter verwenden, man muß sich vorher eine neue 68000er-CPU besorgen.

Die zweite Methode läßt den alten 68000er leben, erfordert jedoch denselben Lötaufwand. Die PUK-Umschaltplatine wird halbiert und auf den 68000er direkt aufgelötet. Vorher sind allerdings die Pins 11,12,13 und 20 zu durchtrennen, damit sie mit der Umschaltplatine verschaltet werden können.

Ich habe mich für die erste Methode entschieden, da mir einerseits das Gefummel am ‘lebenden’ Objekt zu risikoreich war und andererseits eine zukünftige Erweiterung leichter ist, wenn alles gesockelt ist (das Märchen vom nachrüstbaren Blitter ist ja nun doch noch war geworden, ich bin gerade am Löten...). Hinzu kommt, daß -sollte bei der zweiten Methode etwas schiefgehen - man eventuell doch noch dazu gezwungen ist, den alten 68000er gegen einen neuen auszutauschen. Dann steht man allerdings mit einer halben PUK-Platine da, und bekanntlich ist abschneiden einfacher als ankleben.

Beim Aufbau ist zu beachten, daß die Platine von der CPU aus nach ‘hinten’ in Richtung Floppy-Stecker verläuft und mit diesem kollidiert. Man muß also die Stecksockel der PAK und PUK so dimensionieren, daß die PAK-Karte den Floppy-Stecker ein klein wenig überragt. Ist ja nicht schwer, habe ich mir gedacht, und großzügig noch ein paar Sockel (gedrehte versteht sich) spendiert. Doch damit hat die Betriebssicherheit drastisch abgenommen, der Rechner lief nur noch 15 Minuten am Stück. Das könnte damit Zusammenhängen, daß im ST der Systembus nicht gepuffert ist (soweit mir bekannt ist), und die CPU ihre Bits also eigenhändig durch den Bus jagen muß. Also habe ich den benötigten Abstand genau ausgemessen und dann die Sockel danach ausgesucht. Das empfiehlt sich sowieso, wenn man seinen ST nicht in ein PC-Gehäuse eingebaut hat oder einen MEGA besitzt. Der Platz ist ziemlich knapp. An dieser Stelle noch ein Tip: Man sollte die ICs und Fassungen so wenig wie möglich mit den Fingern begrabbeln. Dies nicht so sehr wegen der möglichen Gefahr einer statischen Aufladung, sondern schlicht wegen des Drecks, der einem an den Fingern klebt. Vor dem Einsetzen sollte man außerdem alle Steckkontakte großzügig mit einem guten Videospray einsprühen (z.B. Kontakt 90). Für diesen Tip muß ich mich bei Uli Eickmann bedanken, der meinen Rechner durch schlichtes Einsprühen wieder flott gekriegt hat.

Hat man seinem Rechner nun glücklich eine gespaltene Persönlichkeit verpaßt, so juckt es einen natürlich in den Fingern, alles auszuprobieren. Vorsichtig beginnt man dabei zunächst im 68000er-Modus. Hier müßte alles wie gehabt funktionieren - wenn es funktioniert. Ist diese Hürde überwunden, so probiert man mutig die zweite Schalterstellung - und damit die PAK - aus. Der Rechner fängt an zu booten, um nach kurzer Zeit sang- und klanglos abzustürzen und von vom anzufangen. Dieses Spielchen wiederholt sich nun endlos, bis der bestürzte Computer-Besitzer den Netzstecker zieht. Woran liegt das? Nun, im TOS liegen mehrere Fallstricke für das 68020/68881 Gespann bereit:

• MOVE SR, ist beim 68020 ein privilegierter Befehl, der nur im Supervisor-Modus benutzt werden darf. Der 68000 erlaubt diesen Befehl auch im User-Modus.
• Der 68020 legt bei einer Exception 8 Bytes auf den Stack, der 68000 jedoch nur 6.
• Im TOS werden die Line-F-Routinen für eigene Zwecke benutzt, obwohl diese von MOTOROLA für die Kommunikation mit dem Arithmetik-Chip 68881 reserviert sind.
• Selbstmodifizierender Code ist unverträglich mit dem Cache des 68020.

Diese Fußangeln im Betriebssystem sind der Grund dafür, daß zwischen der ersten Vorstellung der PAK-68 im August-Heft letzten Jahres der Zeitschrift c’t und diesem Artikel eine größere Zeitspanne liegt. Denn unter TOS konnte man die Karte bisher nicht nutzen, und damit ist sie für die Vielzahl der ST-Anwender nicht interessant gewesen. Unter RTOS lief sie dagegen fast auf Anhieb - seit dem letzten Update wird auch der Coprozessor unterstützt. Doch zurück zum TOS: Umfangreiche Patches waren nötig, um die PAK unter TOS lauffähig zu machen. Daraus ergeben sich - wie nicht anders zu erwarten - einige Einschränkungen: Programme, die reservierte Line-F-Opcodes benutzen, laufen nicht mehr, desgleichen solche, die extensiv Line-A-Opcodes benutzen oder nur noch eigene Line-A-Routinen ansprechen. Das hängt damit zusammen, wie oben genannte Fußangeln entschärft wurden. Wer sich genauer für die einzelnen Schritte beim Patchen interessiert, kann dies in [2] nachlesen. Fertig gebrannte Eproms - übrigens werden 150 ns-Eproms gebraucht - können bei der eMedia GmbH, Hannover oder bei esd bezogen werden. Für den Self-Made-Mann besteht die Möglichkeit, das fertig gepatchte Betriebssystem auch auf Diskette zu bekommen.

In der Praxis treten oben angeführte Probleme mit Anwenderprogrammen zum Glück selten auf. Alle wichtigen Programme laufen - zumindest wenn ich auf 68000er umschaltete, hatte ich noch keine Probleme mit dem gepatchten TOS.

Auf die Plätze...

Nun wird es spannend: Was bringt die Karte an Speed in einem System, bei dem die Software von einem 68000 ausgeht? Leider wird ein eingesetzter Coprozessor vom TOS nicht angesprochen, und so geht die Geschwindigkeitserhöhung allein auf das Konto des 68020 mit seinem Cache-Speicher. Über den Daumen gepeilt kann man sagen, daß Integerarithmetik ungefähr doppelt so schnell abgearbeitet wird wie auf einem 68000. Bei Fließkommazahlen und trigonometrischen Funktionenen fällt der Geschwindigkeitszuwachs spürbar geringer aus. Unter RTOS/PEARL wird dagegen auch der 68881 unterstützt. Hier geht dann natürlich die Post so richtig ab. Für PRO PASCAL und PRO FORTRAN gibt es aber seit neuestem eine 68881-20 plus Library, die die PAK-68 unterstützt. Damit kann man die Leistungsfähigkeit der Karte nun auch unter TOS nutzen. Bleibt zu hoffen, daß noch mehr Softwareanbieter auf die Idee kommen, ihre Programme anzupassen. Besonders rechenintensive Programme wie CAD oder Desktop-Publishing würden von einer solchen Anpassung profitieren.

Vor den nackten Zahlen noch ein subjektives Wort meinerseits: Ich finde, daß die Geschwindigkeitserhöhung im täglichen Betrieb durchaus spürbar ist. Die Fenster, das Scrolling - alles geht einen Hauch schneller. Man merkt es vor allem, wenn man - aus irgendeinem Grund - wieder ohne PAK arbeitet (ähnlich wie bei der Einführung des Blitter-TOS). Allerdings bringt ein Blitter doch noch ein Stück mehr an Geschwindigkeit beim Umgang mit dem Desktop oder Programmen, die sauber programmiert sind und ihn somit nutzen. Natürlich nur im Grafikbereich, wo es auf schnelles Verschieben von Speicherbereichen ankommt. Kann man als Programmierer aber die volle Geschwindigkeit des 68020/68881 nutzen, dann bringt die PAK-68 bei rechenintensiven Programmen natürlich enorm viel. Ich programmiere in PEARL unter RTOS und war restlos begeistert, als ich bei einer Demo gesehen habe, wie schnell ein cos oderein sin berechnet werden kann, wenn man das die Hardware machen läßt. Neuerdings gibt es von ATARI für den MEGA-ST ja auch den Coprozessor 68881 zum Nachrüsten. Einige Sprachen unterstützen das Teil auch schon (GFA-B ASIC 68881, spezielle Bibliotheken für verschiedene PASCAL- und C-Compiler). Diese Lösung ist zwar preiswerter al s die PAK-68, aber auch nicht so effektiv. Die Kommunikation zwischen 68000 und 68881 ist ziemlich aufwendig, der Prozessor muß mit move-Befehlen die Werte in die Register des 68881 schreiben und sie von dort auch wieder abholen. Es kann also durchaus passieren, daß der Datentransfer mehr Zeit kostet, als die eigentliche Berechnung dauert. Trotzdem ist das Programm natürlich mit Coprozessor schneller als ohne!

Die Kopplung zwischen 68020 und 68881 ist dagegen wesentlich eleganter. Ist der Coprozessor im System eingebaut, so erscheint das Gespann nach außen hin nicht wie zwei Prozessoren, sondern wie ein einziger. Dadurch ist die Kommunikation zwischen beiden natürlich viel schneller. Der Programmierer sieht die Register des 68881 einfach als Ergänzung zu denen des 68020.

So, nun aber endlich ein paar Zahlen:

Als Anwenderprogramm habe ich 1st-Word genommen, weil das wohl die meisten kennen. Ich habe einen ca. 50 kByte großen Text zeilenweise durchscrollen lassen und die Zeit dafür gestoppt (s.Tabelle 1).

Wie man sieht, bringt die PAK-68 zwar etwas, jedoch wird sie hier vom Blitter eindeutig geschlagen. Um ihr Ansehen zu heben, gebe ich gleich die Benchmark-Zeiten unter RTOS/PEARL mit und ohne Coprozessor an (s.Tabelle 2).

Ich denke, die Zeiten sprechen für sich. Als Benchmark habe ich die HL-Bench-marks genommen, die ich auch schon für den MIRAGE-Test in der August/Sep-tember-Ausgabe verwendet und vorgestellt habe. Die leicht unterschiedlichen Zeiten z.B. bei Intmath zwischen 68020 und 68020/68881 ergeben sich daraus, daß in einem Multitasking-Betriebssystem der Verwaltungsaufwand mit Coprozessor etwas erhöht ist. Wie man an den Zeiten sieht, lohnt sich der Coprozessor besonders bei Fließkommazahlen und trigonometrischen Funktionen. Kann man bei diesen beiden Anwendungsfällen nur einen 68020 rechnen lassen, dann ist das Programm etwa 15-20% schneller als ein 68000. Bei Ganzzahl-Operationen ergibt sich durch den Einsatz eines Coprozessors natürlich keine weitere Steigerung. Hier rechnet ja in jedem Fall der 68020.

So, und nun dieselben Benchmarks, aber diesmal für GFA-Basic, das wohl zu den am meisten benutzten Programmiersprachen auf dem ATARI ST zählt (s.Tabelle 3). Ich habe sowohl die neueste Version 3.0 als auch die ältere 2.02 ausprobiert. Anzumerken ist, daß der Interpreter erst ab Version 3.0 zusammen mit der PAK-68 läuft. Der Compiler funktioniert dagegen einigermaßen.

Es gab bisher nur Probleme mit größeren Programmen, die etwas nachladen (SED und TED von der Kleisterscheibe). Ob dies nun dem Compiler oder aber den Programmen anzulasten ist, habe ich -auch nach Rücksprache mit Claus Brod -nicht sicher feststellen können. Ich tippe aber eher auf den Compiler. Nun ja, c’est la vie, zur Not kann man ja immer noch auf 68000 umschalten. Tröstlich ist da nur, wenn man eine resetfeste RAM-Disk hat.

Außerdem hatte ich noch ST-PASCALPLUS 2.0 zum Testen.

Die Geschwindigkeitssteigerung liegt beim GFA-Compiler zwischen 6 und 15%. Beim Interpreter 3.0 kehren sich dagegen kurioserweise die Verhältnisse zum Teil um. Bei Intmath und Realmath ist der 68000 schneller als der 68020. Nur die Götter und Herr Ostrowski wissen, warum das so ist. Bei meiner Meßmethode dürfte kein Fehler liegen, denn schließlich habe ich nur auf 68000 umgeschaltet und dasselbe Benchmarkprogramm in genau derselben Weise ablaufen lassen. Zur Sicherheit - und weil ich selber der Sache nicht so recht traute, habe ich noch mal alle Zeiten für den 68020 nach gemessen, aber leider hat sich nichts geändert.

ST-PASCAL PLUS 2.0 hat sich wenigstens den Erwartungen entsprechend verhalten. Die Zeiten waren mit 68020 in jedem Fall besser als ohne. Besonders groß war der Gewinn bei Integer-Berechnungen mit mehr als 70%. Bei Fließkommazahlen waren es zwar immerhin auch über 20%, doch ist ST-PASCAL anscheinend etwas schwach auf der Brust, wenn es um die fließenden Zahlen geht, so daß die Zeiten hier im Vergleich zu GFA-BASIC deutlich schlechter sind.

Leider konnte ich Pro-Pascal mit den neuen Bibliotheken nicht testen. Ich nehme aber an, daß es wesentlich besser abschneidet und vielleicht sogar an RTOS/PEARL herankommt - zumindest bei Triglog, denn hier ist besonders der Coprozessor beschäftigt.

ohne PAK-68 und ohne Blitter	2 min 25 sec	Zeiten für 1st Word und
mit PAK-68:	1 min 41 sec	ca. 50 kByte großen Text bei zeilenweisem Scrolling
mit Blitter:	1 min 22 sec	mit den Cursor-Tasten
mit PAK-68 und Blitter:	1 min 12 sec

Tabelle 1: Scrollen unter 1st Word

--	68020/68881 8 MHz/16 MHz	68020 8 MHz	68000 8 MHz	Faktor 68000 - 68020/68881
Intmath:	0.236 sec	0.232 sec	0.441 sec	1.87
Realmath:	0.525 sec	2.574 sec	3.064 sec	5.84
Triglog:	0.161 sec	3.930 sec	4.544 sec	28.22
Textscrn:	31.221 sec	31.217 sec	31.213 sec	lohnt nicht
Grafscrn:	0.349 sec	0.328 sec	0.505 sec	1.45
Store:	6.745 sec	6.745 sec	6.348 sec	lohnt nicht

Tabelle 2: Benchmark-Zeiten unter RTOS/PEARL

--	Intmath	Realmath	Triglog	Textscrn Grafscm	Store
GFA 3.0 Interpreter mit PAK	7.385 s	6.69 s	4.8 s	28.46 s	13.09
ohne PAK	7.37 s	6.155 s	5.71 s	32.73 s —	13.1
GFA 2.2 Compiler mit PAK	4.675 s	3.445 s	3.205 s	27.54 s —	13.09
ohne PAK	5.305 s	3.72 s	3.86 s	31.96 s	13.1
GFA 2.2 Interpreter mit PAK	läuft nicht	mit der PAK-68!
ohne PAK	9.33 s	7.55 s	4.45 s	32.53 s —	13.1
ST-PASCAL PLUS 2.0 mit PAK	0.272 s	8.354 s	16.997 s	47.095 s	—
ohne PAK	0.483 s	10.319 s	17.087 s	50.335 s —	—
Steigerung	77%	23%	0.5%	6%

Tabelle 3: Benchmark-Zeiten von GFA-BASIC und ST Pascal Plus

---	PAK-68 68020 + 68881 (12 MHZ)	68020+ 68881 (Lischka 16 MHz)	68020
Intmath:	0.52 sec	0.415 sec	0.495 sec
Realmath:	0.97 sec	1.4 sec	3.865 sec
Triglog:	0.195 sec	0.185 sec	6.05 sec

Tabelle 4: Benchmark-Zeiten für ProPascal

--	Intmath	Realmath	Triglog	Textscm	Store
MIRAGE Pascal 68020+68881	0.5 sec	2.78 sec	0.42 sec	31.38 sec	30.8 sec

Tabelle 5: Benchmark-Zeilen für MIRAGE

Und wenn Sie nicht gestorben sind...

Für wen ist diese Zusatzkarte nun interessant? Der relativ hohe Preis für die fertige Karte ist wohl das Haupthindernis, das einer größeren Verbreitung im Weg steht. Für den normalen TOS-Alltag empfehle ich die Karte nicht, da bringt ein Blitter mehr.

Wer jedoch rechenintensive Programme auf dem ST laufen lassen möchte und auch einem Betriebssystemwechsel (RTOS/MIRAGE) aufgeschlossen gegenübersteht, dem kann man die PAK -sofern er über das nötige Kleingeld oder Bastlergeschick verfügt - wärmstens empfehlen. Um unter TOS die PAK-68 ausnutzen zu können, sollte man sich PRO-PASCAL ansehen, welches zurZeit leider die einzige Sprache ist, die entsprechende Bibliotheken zur Verfügung stellt.

Ich bereue den Kauf bzw. den Bau der PAK-68 nicht.

Auf den letzten Drücker:

Auf der ATARI-Messe in Düsseldorf (2.-4. September 1988) hatte ich Gelegenheit, Pro Pascal laufen zu sehen. Der Rechner war mit einer PAK-68 (68020 und 68881 12 MHz) und einem Coprozessor (16 MHz) von Lischka ausgestattet. Wahlweise konnte man nun die verschiedenen Benchmarks mit PAK-68 oder mit Lisch-ka-Coprozessor laufen lassen. Die Ergebnisse der einzelnen Durchläufe kann man Tabelle 4 entnehmen.

Zu dem Programm, mit dem diese Zeiten gemessen wurden, kann ich leider nichts sagen. Zu beachten ist jedoch, daß der Coprozessor auf der PAK nur mit 12 MHz getaktet war. Wie es zu den unterschiedlichen Zeiten bei Intmath kommt, kann ich nicht erklären. Außerdem kommt einem bei dem Vergleich der Zeiten von PEARL und ST-PASCAL+ der Verdacht, daß die integer-Routinen nicht für den 68020 optimiert worden sind. Bei Realmath ist der langsamere 68881 auf der PAK deshalb schneller, weil hier die Zeiten für die Datenübergabe stark ins Gewicht fallen (habe ich weiter oben genauer erklärt). Bei Triglog hat der 16MHz-Coprozessor von Lischka die PAK überholen können, weil hier weniger Daten übergeben werden, und der Coprozessor mehr alleine rechnen muß. Übrigens sind die Coprozessorerweiterungen von Lischka, Weide und ATARI zueinander softwarekompatibel.

Brandneu ist auch die aktuelle MIRAGE-Version, die jetzt endlich mit der PAK-68 lauffähig ist. Genauer habe ich mir diese Version noch nicht angesehen, ich habe nur das 68881-Bolton geladen und mein Benchmark-Programm aus dem ST-Magazin 8/9 1988 laufen lassen. Hier nun die Zeiten:

Wer die Zeiten von dem MIRAGE-Test [3] noch im Gedächtnis hat, wird merken, daß schon eine beträchtliche Steigerung vorhanden ist (außer Store, hier ist MIRAGE plötzlich 10 sec. langsamer geworden). Allerdings werden die Zeiten dem Coprozessor eigentlich nicht gerecht, denn der könnte schneller, wie man bei RTOS/PEARL sieht. Möglicherweise hängt das damit zusammen, daß MIRAGE intern wirklich auf 96 Bit genau rechnet, dies aber selbst dem Coprozessor auf einmal zuviel ist, und er mehrmals aufgerufen werden muß. Aber dafür braucht man bei MIRAGE wirklich nur sin anderes - im Lieferumfang enthaltenes - Bolton zu laden, um dem Geschwindigkeitsrausch zu verfallen. Es ist nicht zwingend nötig, das Programm neu zu compilieren. Das ist ein Riesenvorteil für den Anwender, der Software gekauft hat, denn im allgemeinen muß man noch einen saftigen Aufpreis für die Coprozessor- oder PAK-Unterstützung bezahlen (GFA 68881, Pro Pascal). Aufgefallen ist mir noch, daß MIRAGE nach wie vor mit 200ns Eproms geliefert wird, die PAK aber mit 150ns Eproms spezifiziert ist. Bei mir hat es - trotz ROM-Port-Buffer+Erweiterung - funktioniert. Es ist aber mehrmals vorgekommen, daß MIRAGE plötzlich Fehlermeldungen gebracht hat und zuweilen auch abgestürzt ist. Das läßt darauf schließen, daß die Eproms sporadisch einfach schlapp machen. Für den professionellen Einsatz empfehle ich also doch 150ns Eproms, um auf Nummer Sicher zu gehen.

C.D.Ziegler

[1] Kickstart 4/88
[2] c’t 3/88
[3] ST-Magazin 8/9 1988

ENDE

Bezugsnachweis

Die PAK-68 mit Zubehör ist von

ESD

Vahrenwalder Straße 7 3000 Hannover 1

entwickelt worden. Die Firma vertreibt die PAK als Fertigplatine in verschiedenen Ausbaustufen sowie die einzelnen Platinen. Aus eigener Erfahrung weiß ich, daß die Jungs ganz nett sind und bei Problemen auch weiterhelfen.

Da die PAK ein Hardware-Projekt der Zeitschrift c’t ist, kann man die Platinen auch über den Platinen- & Software-Service beziehen:

eMedia GmbH Bissendorfer Straße 8 3000 Hannover 61

Außerdem gibt es noch andere Firmen, die Bausätze oder Fertiggeräte von c’t-Projekten anbieten. Die angegebenen Preise für fertigaufgebaute Platinen sind Preise von ESD, die für reine Platinen und Software sind von eMedia.

fertig aufgebaut	Platine	c’t
PAK-68 mit CPU und FPU (12 MHz)	1098.-	49.-
PUK-Umschaltplatine	69.-	16.-
PAK-MEM mit 128 kByte	178.-	49.-
PAK-MEM mit 256 kByte	336.-	49.-
gepachtes TOS:	auf 6 150ns Eproms	auf Diskette
Blitter-TOS	197.-	30.-
ROM-TOS (Feb. 1986)	197.-	30.-

Man sieht also, es ist kein billiges Vergnügen.

---

---