Hilfestellung Teil II: Noch mehr Festplattenutilities

Utilities (engl, jutülities), (die), Computerprogramme, die Probleme lösen, die man ohne Computer gar nicht hätte.

Massenspeicher, (der), Speichermedium für Computer, das seinen Namen aus seiner hervorstechendsten Eigenschaft ableitet, nämlich der, daß es massenhaft Probleme schafft.

Festplatte, (die), Teilerchen mit Futterage für ausgepumpte Hacker. Jede andere Erklärung für dieses Wort entspringt Hirngespinsten verwirrter Computermenschen, die schon zu lange nichts mehr Ordentliches gegessen haben (zum Beispiel von einer F.) und daher schon weiße ATARI-Mäuse sehen.

(.Auszug aus Brods Konfusionslexikon, Band 7: bis zum 1.1.1988 zum einmaligen Subskriptionspreis von DM 49 pro Band erhältlich beim Winz-Verlag in 8999 Niedertracht)

In der letzten Ausgabe der ST-Computer hatte ich bereits einige Programme in der Mangel, die sich mit der sorgsamen Pflege der Massenspeicher-Peripherie des ST befassen; diesen Monat erwischt es zwei Nachzügler: Harddisk Help & extension sowie 1st Speeder.

Doch zuvor noch eine kleine Preiskorrektur zur letzten Ausgabe: der Hard Disk Accelerator von Computerware kostet nicht wie fälschlich böse Redakteure behaupten DM 179,-, sondern ist schon für DM 98,- zu haben.

Harddisk Help & extension stammt von den '“Application Service”-Programmierern (nicht zu verwechseln mit Application Systems Heidelberg) Lüning und Kraft; ihr - nicht kopiergeschütztes - Backup-Programm ist bei GDATA im Vertrieb, kostet 129 DM und hat ein oder zwei besprechenswerte Besonderheiten. Zwar wurde es schon einmal kurz in der ST5/87 unter die Lupe genommen, doch habe ich jetzt eine neue Version vor mir. Bevor ich aber mit der üblichen Testerei loslege, möchte ich Sie noch für die Problematik von Backup-Programmen sensibilisieren (schönes Wort, gelle?).

Grundsätzliches über Bäkk-Apps

Fangen wir mit einer Entschuldigung an die vielen Freizeitlektoren an: Natürlich ist es unschön, das englische “Backup” zu verwenden; vielleicht sollte ich lieber schön deutsch “Sicherungskopierer” - STOP PRESS, “kopieren” ist ja auch so fremdsprachig - besser: “Sicherungsdurch-pauser” sagen... ist ja gut, ich bleibe freiwillig bei “Backup”. Klingt ja auch so schön professionell. Es ist halt ein Jammer: Das Deutsche scheint der Computerrevolution (schon wieder zwei Fremdworte in einem) nicht gewachsen zu sein.

Aber wir sind uns immerhin einig, über was wir reden: Von Zeit zu Zeit sollte man sich eine Kopie des gesamten Inhalts der Festplatte anlegen, damit man vor unwirschen Verhaltensstörungen der Platte sicher ist. Dazu kann man natürlich das Desktop verwenden, sicher noch ist besser aber ein Programm, das die dabei anfallenden Arbeiten automatisiert - eben ein Backup-Programm (die umgekehrte Richtung, die Kopie von der Diskette zurück zur Platte bezeichnet man neudeutsch als “Restore”-Vorgang).

Dabei gibt es grundsätzlich zwei Taktiken:

  1. Dateiweises Kopieren, das heißt, der gesamte Dateibaum auf der Platte wird durchsucht (endlich eine Anwendung für die Rekursion), jede Datei wird für sich kopiert. Die Vorteile:
  1. Physikalisches Kopieren. Jeder Sektor einer Partition wird auf Diskette geschrieben, ohne Rücksicht auf den Dateibaum. Vorteile:

Harddisk Help & extension ist ein Vertreter der zweiten Gattung (es gibt auch Programme, die beide Spielarten beherrschen). An Service bietet es folgende vier Hauptfunktionen: Backup, Restore, Ausgabe eines Dateibaums, Kopieren von überlangen Dateien von Platte auf Diskette und umgekehrt; alles mit übersichtlicher GEM-Unterstützung, aber ohne Menüleiste und damit ohne Accessories. Harddisk Help liegt mir in der Version 2.5 vor, die laut Anleitung in Details verbessert sein soll; leider kenne ich die alte Version nicht, kann dazu also nichts sagen. Gehen wir drum einfach alle Optionen chronologisch durch.

Einen Backup kann man von jeder einzelnen Partition ziehen oder von allen zusammen; beliebige Kombinationen sind nicht möglich. Es werden auch grundsätzlich immer ganze Partitionen auf ein-oder zweiseitige Disketten kopiert. Die werden vor dem Backup programmkonform formatiert, wenn sie’s nicht schon sind. Die Anleitung spricht von einem Spezialformat, das angeblich verwendet wird, allerdings kann ich an einer doppelseitigen Diskette, auf 80 Spuren mit je 9 Sektoren formatiert, nun wirklich nichts erregend Spezielles finden; nicht einmal einen zusätzlichen Sektorvorspann haben die Programmierer spendiert, um auf Systemen ohne eingebautem FASTLOAD das Laden und Speichern etwas aufzupeppen. “Spezial” ist allenfalls die unangenehme Eigenart der Disketten, daß sie nicht unter GEMDOS lesbar sind (“0 Bytes in 0 Dateien”), und daß man vor allem nach dem Einlesen eines solchen Verzeichnisses im Desktop überhaupt keiner Diskette mehr eine vernünftige Inhaltsangabe entlocken kann. So muß man sich also mit entsetzlich üppigen (mehr entsetzlich als üppig) 720 Kilobyte pro Diskette begnügen.

Alles weitere, was sich ereignet, wenn man diese Option ausgewählt hat, ist weder dazu geeignet, meinen Unmut erneut zu wecken noch mich staunen zu lassen. Die 5-MB-Beispielpartition, mit etwa 1.3 Megabyte gefüllt, war in 2:13 Minuten kopiert (alle Diskettenzeiten in diesem Test sind ein bißchen dadurch geschönt, daß ich FASTLOAD verwende). Dabei kopiert das Programm aber nur alle in der Blockbelegungstabelle als besetzt gekennzeichneten Sektoren (was die Programmautoren als “Kompression” bezeichnen).

Diese Zeit ist nicht unbedingt erstaunlich -trotz eigener DMA-Routinen, die allerdings so hartnäckig im Rechner kleben bleiben, daß die Anleitung empfiehlt, nach dem Backup neu zu booten, um den Festplattentreiber nicht zu verwirren. Das in der letzten ST-Computer besprochene Konkurrenzprodukt Harddisk Utility (diesmal wirklich von Application Systems) schaffte die gleiche Datenmenge in 1:30 Minuten; damit war es über eine Dreiviertelminute schneller, obwohl es den beschwerlicheren Weg über den Dateibaum geht (Methode 1), dabei aber einige Tricks anwendet, die zu dieser beachtlichen Geschwindigkeit führen. Bei beiden Zeiten wurden die Pausen, die durch Diskettenwechsel anfielen, schon abgezogen. Harddisk Help brauchte drei Zieldisketten ä 720 KB (Harddisk Utility dagegen nur deren zweie zu je 820 KB ).

Nächster Tagesordnungspunkt: Die RE-STORE-Funktion. Man legt dazu eine der erzeugten Disketten ein (egal welche!) und fängt mit ihr an; die Reihenfolge, wie man die Disketten ins Laufwerk schiebt, ist dem Programm gleich, Hauptsache, daß keine doppelt vorkommt (was das Programm bemerkt und moniert). Doch, wirklich, das muß mir Beschriftungsmuffel gefallen.

Nicht zugesagt hat mir, daß die Restore-Funktion rücksichtslos den Dienst verweigert, sobald sie auf einer Diskette auch nur einen einzigen Lesefehler entdeckt hat; ein bißchen mehr Nachsicht bitte, meine Herren Programmierer - man kann doch wegen eines winzigen Sektors keine ganze Partition wegwerfen!

Für die Wiederherstellung der obengenannten Partition brauchte Harddisk Help 2:10 Minuten, war also ebenso schnell wie beim Backup. Zum Vergleich: Das Harddisk Utility brauchte dafür 10:46 Minuten -es ist eben dateiorientiert und muß beim Restore-Vorgang den gesamten Dateibaum erst wieder erzeugen. Hier zeigt sich also der größte Vorteil von Harddisk Help. Allerdings benutzt man in der Praxis die Backup-Funktion öfter als die Restore-Funktion, so daß sich der Vorteil gleich wieder relativiert.

Die dritte Option schließlich tut ihren Dienst, wie man es erwartet: Der gesamte Dateibaum einer Partition (leider nicht von einer Diskette, warum eigentlich nicht?) kann auf Bildschirm, Drucker oder Datei ausgegeben werden; dabei kann man Dateien mit einer bestimmten Extension auswählen (zum Beispiel alle .DOC-Da-teien) oder auch alle Dateien, die zwischen zwei einzugebenden Tagen erzeugt wurden. Das erzeugte Verzeichnis ist brauchbar, aber nicht besonders übersichtlich; leider bietet Harddisk Help uns hier auch nur den Dateinamen und keine sonstigen nützlichen Angaben wie etwa Dateigröße, Erstellungsdatum und Attribut. FILECOPY nennt sich der letzte Versuch von Harddisk Help, mich von sich zu überzeugen. Damit kann man Dateien, die größer als 720 KB sind, segmentiert auf mehrere Disketten schreiben und auch wieder zurückkopieren (hier kann man die Disketten leider nicht mehr nach Belieben in irgendeiner Reihenfolge einlegen, schade drum).

Aber schon muß ich wieder meckern. Die Zieldisketten müssen nämlich schon vorformatiert sein, FILECOPY an sich merkt nur, daß eine Diskette dem Programm nicht gefällt; formatieren kann man dabei nicht. Zu allem Überfluß wird aber nicht etwa das Format verlangt, das beim Backup erzeugt wird, sondern ein normales Diskettenformat. Also zuerst raus aus dem Programm (grrr), neue Disketten formatieren (gähn), wieder rein ins Programm (mein Doppelklickfinger schmerzt höllisch) und loskopieren (endlich). Immerhin kann man auf diese Art und Weise auch höher formatierte Disketten (etwa HYPERFORMAT mit 900 KB) nutzen. Den Namen der Maxi-Datei sollte man sich tunlichst merken, weil Harddisk Help die Fragmente der Datei im Verzeichnis der Zieldisketten phantasielos SAVE0.DAT, SAVE1.DAT usw. nennt, anstatt den Dateinamen beizubehalten und nur in der Extension die Segmentnummer mitzuführen, etwa: BIGF1LE.000, BIG-FILE.001 und so fort.

Es ist wirklich kein Genuß gewesen, die Anleitung zum Programm zu studieren. Nicht, daß ich mich noch groß über Fehler in Rächtschraippung, Syntax oder ,;- Zeichensetzung !?. aufrege (von denen sich viel, viel mehr als genug finden, mir tränen noch die wunden Hackeraugen); auch fühlt man sich nicht unbedingt mangelhaft informiert, alle Möglichkeiten des Programms werden erwähnt und ausreichend klar beschrieben. Dennoch: Man spürt am trockenen Stil, daß die Anleitung nicht gerade aus purer Schrei-berlust entstanden ist. Und ein bißchen mehr Hintergrundinformation hätte sicher auch nicht geschadet. Zudem gab es zum Testexemplar gar keine richtige Anleitung, sondern nur zwei Textdateien auf Diskette (IstWord- und ASCII-Format). Im Handbuch früherer Versionen sollen einige Hardcopies enthalten gewesen sein, die auf der Diskette nicht zu finden sind. Die Autoren sprechen aber ausdrücklich von einer Übergangslösung für die neueste Version; mittlerweile müßte jedem Exemplar beim Kauf auch ein vollständiges Handbuch beiliegen.

Jetzt wollen Sie sicher ein Testfazit von mir haben. Versuchen wir es so: Harddisk Help ist ein kleines, durchaus brauchbares Programm, das seine Arbeit ohne große Sensationen, aber im wesentlichen auch ohne schwerwiegende Fehler erledigt. Woran ich mich stoße: Am mickrigen 720/360-Kilo-byte-Format, an der Zickigkeit, mit der das Programm beim Restore-Vorgang auf Lesefehler reagiert, am einschläfernden Handbuch. Ansonsten will ich mich nicht beschweren, immerhin funktioniert das Programm, und das ist mehr, als man von anderen behaupten kann. Positiv fällt natürlich die bisher einzigartige Möglichkeit auf, überlange Dateien in Einzelteilen auf Diskette kopieren zu können (wenn diese Funktion nicht übermäßig gut realisiert ist). Die Restore-Geschwindigkeit ist ebenfalls sehr erträglich. Aber alles in allem: Muß ich auch zu einem Preis von 129 DM nicht haben.

1st Speeder: Pufferlösung

Zum nächsten Testobjekt, dem 1st Speeder, einem Cache-Programm. Zwei Vertreter dieser Gattung sind ja schon in der ST1/ 88 vorgestellt worden (M-Cache und Harddisk Accerator). Mit dem Testsieger M-Cache mußte sich der Speeder messen. Ein Cache-Programm, soviel nur zur Erinnerung, ist ein Programm, das häufig benutzte Sektoren eines Massenspeichers im RAM des Rechners puffert; da im RAM alle Zugriffszeiten entfallen, verspricht man sich davon zu Recht eine rasantere Dateibehandlung. Anders als bei einer RAM-Disk entscheidet hier das Programm, welche Dateien (oder Dateiteile) im Puffer gehalten werden; bei einer RAM-Disk ist der Anwender selbst dafür zuständig, wenn der Platz in der RAM-Disk eng wird. Der Algorithmus, welche Sektoren ein- und ausgelagert werden, ist darum auch mit entscheidend für die Effizienz eines Pufferspeichers.

1st Speeder ist ein kleines Bröckchen von 3.5 KB (es hätte damit sogar noch in meinen guten alten VC20 gepaßt), das man in den Autoordner kopiert. Beim Booten stellt es allerlei lästige Fragen (nein, nicht über Ihr Privatleben), um sich zu konfigurieren. Der Konkurrent M-Cache verfügt über ein kleines, separates Konfigurationsprogramm. das man einmal durchlaufen muß; danach fährt sich M-Cache ohne nervige Nachfragerei von selbst aus dem Autoordner hoch. Vielleicht denkt man bei Tom-mySoftware ja noch einmal über eine solche Vorgehensweise nach.

Der Speeder meldet, wieviel Speicher frei ist, und fragt, wieviel davon (zwischen 5 und 700 KB) man für den Puffer verwenden möchte. Danach wählt man noch die Laufwerke aus, die gepuffert werden sollen - auch die Floppylaufwerke A und B, was gegenüber M-Cache ein echtes Novum ist. Und gerade bei Floppylaufwerken ist die Pufferung besonders interessant, weil hier die Zugriffszeiten viel schwerer ins Gewicht fallen als bei der Platte. So verspricht TommySoftware denn auch eine Beschleunigung um einen Faktor zwei bei der Platte und um Faktor zehn bei der Diskette. Das schrie natürlich nach gründlichen Benchmarks.

Verglichen habe ich daraufhin die Zeiten auf einer Platte ohne sowie mit Cache-Speicher (M-Cache und 1st Speeder). Dazu habe ich ein selbstgestricktes Programm verwendet, das mir schon in der ST1/88 als Maßstab diente. Vier verschiedene Puffergrößen (8, 16, 32 und 100 Kilobyte) wurden ausprobiert.

Zunächst war ich ziemlich erschreckt: Mit dem 1st Speeder wurde die Platte um bis zu 80 Prozent langsamer - zumindest bei Puffergrößen bis einschließlich 32 Kilobyte; in diesem Bereich zeigte M-Cache bereits spürbaren Effekt (und zwar positiven). Nicht, daß ich hier irgendjemanden kritisieren will (was läge in einem Softwaretest denn auch ferner...), aber das ist nicht der Sinn eines Speeders - oder? Sprinterqualitäten zeigte 1st Speeder erst ab 100 Kilobyte Puffergröße. Hier zog er M-Cache weit davon - zuweilen war er doppelt so schnell. Ich interpretiere diese Eigentümlichkeit etwa so, daß der Speeder einen recht guten Algorithmus verwendet, um den Speicher daraufhin zu durchsuchen, ob ein bestimmter Sektor schon gepuffert ist. M-Cache wurde dagegen bei manchen Anwendungen sogar einen Hauch langsamer, wenn man den Pufferspeicher vergrößerte. Wahrscheinlich lagert der Speeder eine Liste von Sektomummern in einem kleinen Speicherblock, der schnell durchsucht ist, während M-Cache auf der Suche erst durch den ganzen Speicher hüpfen muß. Warum ist 1st Speeder dann bei kleinen Puffergrößen so langsam? Ich tippe unter anderem auf einen ungeschickten Algorithmus beim Entfernen von Sektoren aus einem vollen Puffer, kann es aber nicht beschwören. Um meinen anderen Verdacht zu erläutern, hole ich weit aus:

Bei M-Cache konnte ich das disassemblierte Programmlisting noch leicht von Hand analysieren; beim 1st Speeder hat man es schon nicht mehr so einfach, offensichtlich sind größere Programmteile in C geschrieben (oder in sehr ungeschicktem Assembler). Ein kleines Programmierschmankerl aber habe ich gefunden. Ganz wichtig für die Leistung eines Pufferspeichers ist die Routine, die einen Sektor aus dem Puffer- in den Anwenderspeicher kopiert. So etwas programmiert man normalerweise etwa so:

		Taktzyklen
loop:
	move.l (a0)+, (a1) +	20
	dbf d1,loop	10
	(bzw. 14 Taktzyklen beim letzten 
	Durchlauf der Loop-Schleife)

Immer vorausgesetzt, daß in den Registern A0 und Al die Adressen von Quell- und Zielbereich stehen. D1 enthält vor Durchlauf der Routine die Anzahl der zu kopierenden Langworte (minus eins, wegen des DBF-Befehls). Um 128 Langworte (also 512 Bytes = ein Sektor) zu kopieren, braucht diese Routine etwa 3800 Taktzyklen (=0.48 Millisekunden, das entspricht einer Übertragungsrate von 8.1 Megabits pro Sekunde).

Geschickter wäre folgende Schleife:

					TaktZyklen
loop:
	move.l	(a0)+,(a1)+	20
	move.l	(a0)+,(a1)+	20
	move.l	(a0)+,(a1)+	20
	move.l	(a0)+,(a1)+	20
	dbf d1,loop	10/14

Hier enthält Dl vor dem Durchlauf die Anzahl der Langworte geteilt durch 4 (minus eins, wieder wegen DBF). Um den Sektor zu kopieren, sind jetzt nur noch etwa 2900 Taktzyklen nötig (=0.36 Millisekunden, entspricht etwa 10 Megabits pro Sekunde). Natürlich könnte man auch eine einzige große Liste von 128 move-Befehlen hinschreiben, für die der Rechner dann knapp 2600 Taktzyklen (=0.32 Mikrosekunden, 12 Megabits/Sekunde) bräuchte. Die Programmierer des Speeders waren aber noch cleverer. Da gibt es nämlich noch den allzu oft verkannten movem-Befehl des 68000, der ein wahrer Wunderschaufler ist.

Taktzyklen

movem.l (a0)+,d0-d7/a1-a2/a4-a6 12+8n 
movem.l d0-d7/a1-a2/a4-a6, (a3)	8+8n
adda.w #$34,a3	12
(n=Anzahl der Register, hier 13)

Eine Aneinanderreihung mehrerer solcher Programmstücke braucht für einen Sektor nur mehr etwa 2300 Taktzyklen (=0.29 Millisekunden, 13 Megabits/Sekunde). Obwohl diese Routine die denkbar optimalste sein dürfte, weist der Speeder bei kleinen Puffergrößen, wie schon gesagt, recht miese Zeiten auf. Wahrscheinlich liegt das mit daran, daß auch Lese- und Schreibzugriffe auf mehrere aufeinanderfolgende Sektoren gepuffert werden, was wenig effektiv ist. Bei einem solchen Zugriff nämlich entfallen die Zugriffszeiten zwischen den einzelnen Sektoren; der DMA-Bus läuft auf Hochtouren (maximal 10 Megabits pro Sekunde). Damit lohnen sich auch schnelle Verschieberoutinen kaum noch; der kleine Zeitvorteil, den man durch sie gewinnt, wird durch den Verwaltungsaufwand mehr als wettgemacht. Man sollte also die Speeder-Taktik noch einmal überdenken, damit auch bei kleinen Puffergrößen die Programmierschmankerl im Speeder (effiziente Suche im Puffer, schnelle Verschieberoutinen) zur Geltung kommen; nicht jeder hat gerade mal eben 100 Kilobyte zu verschenken.

Natürlich könnte man dafür seine RAM-Disk opfern, aber ich denke, nur Werbetexter haben das bisher in Erwägung gezogen (unter anderem auch in dem dürftigen Faltblättchen, das beim Speeder als Anleitung dient).

Nur wenige Cache-Programme können auch Sektoren von Diskettenlaufwerken puffern; 1st Speeder gehört dazu. Dazu habe ich wieder die Puffergrößen 8, 16, 32 und 100 Kilobyte installiert, diesmal für die Laufwerke A und B. Schon bei 16 Kilobyte Puffergröße liefen bestimmte Verzeichnisoperationen (Durchsuchen nach einem Dateinamen) ganz schön fix ab; zuweilen ergab sich eine Steigerung um das Zehnfache. Ab 32 Kilobyte schließlich griff das Cache-Programm auch bei anderen Benchmark-Teilen, die bis zu einhundert-mal schneller abliefen als ohne Puffer. Hoffentlich verwendet der Hersteller nicht ausgerechnet den letzten Satz, um für sein Produkt zu werben; man muß nämlich ergänzend und berichtigend dazu sagen, daß diese letzteren Benchmarks wie geschaffen für Cache-Programme waren. Insgesamt kann man realistischerweise von einer Steigerung um das fünf- bis zehnfache ausgehen; es kam allerdings auch wieder wie bei der Festplatte vor, daß das System bei zu kleinem Pufferspeicher mitnichten schneller, sondern zuweilen sogar langsamer wurde als vor der Installation von 1st Speeder.

Ein kitzliges Thema muß ich noch ansprechen: Die Sicherheit. Im Festplattenbetrieb lief alles problemlos. Schwierig ist aber die Floppypufferung, denn im Unterschied zur Platte kann man eine Diskette wechseln. Bei diesem Wechsel müssen nun im Cache-Speicher alle gepufferten Sektoren des betreffenden Laufwerkes freigegeben werden, um Platz zu schaffen und Verwirrung zu vermeiden. Ich glaube, mir Situationen vorstellen zu können, wo sonst Daten auf der Diskette vernichtet werden könnten. Um festzustellen, ob eine Diskette gewechselt wurde, benutzt der 1st Speeder die BIOS-Funktion mediach, die sich nicht gerade durch besondere Zuverlässigkeit auszeichnet. Wenn man den Schreibschutz der Disketten aktiviert, kommt es ab und zu vor, daß das BIOS einen Wechsel nicht erkennt!

Nehmen wir an, mediach benimmt sich nicht ordnungsgemäß. Dann sind verheerende Fehler denkbar: Von der alten Diskette wurden einige Sektoren beispielsweise FAT- und Directorysektoren - gelesen und gepuffert. Der Wechsel wird nicht erkannt, die Puffer werden nicht freigegeben. Bei einem erneuten Zugriff auf diese Sektoren liefert der Speeder den fälschlich immer noch gepufferten Sektor und nicht den von der neu eingelegten Diskette; das Programm modifiziert diesen Sektor und schreibt ihn zurück - diesmal werden so-wohl Puffer als auch physikalischer Sektor auf der Diskette aktualisiert, und schon haben wir auf der neuen Diskette die FAT der alten; Ihre Dateien auf dieser Diskette können Sie jetzt mit dem Diskmonitor mühsam wieder zusammenklauben (mein Doppelklickfinger glüht beim bloßen Gedanken daran warnend und angstvoll auf).

Zugegeben, auch im normalen Betrieb ohne Cache-Programm sind theoretisch solche Fehler möglich, vor allem wenn man an den im GEMDOS integrierten Cache-Manager gerät: bei gewöhnlichen BIOS-Aufrufen ist es aber ohne zwischengeschalteten Cache-Speicher wesentlich schwieriger, so etwas zuwegezubringen.

Die Anleitung des Speeders warnt deshalb auch davor, den Schreibschutz der Disketten zu aktivieren; man erhält den Rat, seine Dateien doch besser per Dateiattribut vor dem Schreibzugriff zu schützen (im Desktop per ‘Zeige Info’) - stellen Sie sich aber mal bildhaft vor, was das für ein Aufwand wäre, alle Dateien auf Ihren Arbeitsdisketten so zu modifizieren (raten Sie mal, wie mein Doppelklickfinger sich gerade anfühlt)!

Zusätzlich zu dieser Kalamität fielen mir im Testbetrieb noch ein oder zwei Merkwürdigkeiten auf: Normalerweise habe ich im DESKTOP.INF alle *.BAS-Dateien als GFA-BASIC-Anwendungen angemeldet, das heißt, beim Anklicken (ist ja gut, lieber Finger, reden wir nicht mehr davon) einer *.BAS-Datei wird zuerst GFA-BASIC geladen und danach das eigentliche Basic-Programm. Bei installiertem Speeder kam es vor, daß GFA-BASIC auf einmal nicht mehr gefunden wurde; irgendein Zugriffspfad war irgendwie irgendwo irgendwann verlorengegangen.

Während man das noch leicht verkraften kann, habe ich mich ziemlich über eine andere Macke geärgert. Installierte man den Speeder mit 8 Kilobyte Puffer, die man den Laufwerken A und B zuweist, wurde mein (durch und durch harmloses) Benchmarkprogramm auf einmal mitten im Testlauf ausgebombt - zumindest solange noch der ATARI-Festplattentreiber im System sein Unwesen trieb. Zuweilen kam es gar vor, daß der Speeder eine Weile lang lief und sich und das System erst ab einem bestimmten Punkt (wahrscheinlich dann, wenn der Puffer vollgeschrieben war) an einer sauberen Warteschleife aufhängte. Vielleicht ist ja der Speeder gar nicht mal direkt schuld daran; trotzdem ist er ja wohl darauf ausgelegt, daß er mit der Festplatte arbeitet, drum muß man sich wohl auch darum kümmern, daß Festplatte und Cache-Programm sich vertragen. Oder nicht?

Insgesamt hinterläßt 1st Speeder, für 89 Märker zu haben, bei mir höchst zwiespältige Gefühle. Einerseits war ich während des Tests immer wieder begeistert von den phänomenalen Zeiten, die er zuwege brachte. Andererseits mußte man gerade für diese Zeiten sehr viel Pufferspeicher (etwa 100 Kilobyte) opfern; bei kleineren Puffern schlug die Wirkung des Speeders nicht selten ins Negative um. Zudem war mir bei den Testläufen mit gepuffertem Diskettenlaufwerk immer recht unwohl, weil die Sicherheit hier - wie beschrieben - nicht hundertprozentig ist. Wer das Risiko eingeht, wird allerdings auch mit irren Beschleunigungswerten belohnt - solange der Puffer groß genug gewählt wird.

Klappe zu, klickklick - aua!

Der Autor dieses Berichts wurde Opfer eines Racheanschlags seines rechten Zeigefingers. Spenden für die Familie bitte an...

CB


Aus: ST-Computer 02 / 1988, Seite 150
Links
Copyright-Bestimmungen: siehe Über diese Seite