Stefan Schreiber Kesselweg 14 8650 Kulmbach Speeder+ ( Verdopplung der Schreib- und Lesegeschwindigkeit des Atari ST ) Mehr als drei Jahre sind nun seit Erscheinen der Speeder- Urversion vergangen, die immer noch sehr weit verbreitet ist. Zwei in der Zwischenzeit erschienene Updates sind leider nicht ganz so weit in Umlauf gekommen, sie hatten aber auch mit den beiden neuesten TOS-Versionen noch Schwierigkeiten. Ich hoffe, daž diese berf„llige und hoffentlich endgltige Version meine und Ihre Erwartungen erfllen wird! Es existieren derzeit vier offizielle TOS-Versionen fr den Atari ST, n„mlich TOS 1.0 ( das "alte" TOS vom 6.2.86 ), TOS 1.2 ( das "Blitter-TOS" ), TOS 1.4 ( "Rainbow-TOS" ) und schliežlich TOS 1.6 ( STE-TOS ). Verkompliziert wird alles noch dadurch, daž einige TOS-Versionen, aber nicht alle, auch als TOS.IMG-File vorliegen und damit z.B. von Festplatte gebootet werden k”nnen. Diese Speeder-Version sollte nun endlich mit jedem TOS funktionieren, auch wenn sich dieses im RAM befinden sollte. Hier eine kurze Entwicklungsgeschichte des Speeders ( ok, das interessiert zwar nur mich, aber diese Anleitung soll halt alles enthalten, auch was Sie garantiert nicht brauchen k”nnen! ): Bekanntlich lief die alte Speeder-Version 1.4 nur auf TOS V1.0, nicht jedoch auf neueren Betriebssystemsversionen. Eine Zwischenversion ( 2.0 ), die sich allerdings niemals allzuweit verbreitet hat, lief zwar mit Blitter-TOS, aufgrund eines minimalen, aber dennoch schwer zu entdeckenden Programmier- fehlers wurde aber bei TOS 1.4 und 1.6 kein Beschleunigungseffekt erreicht. Diese Version landete aber immerhin mit leichten Modifizierungen auf Claus Brods "Kleisterscheibe". Update Nr. 3.0 behob diesen Fehler zwar, funktionierte allerdings ab TOS V1.2 nicht, wenn es beim Booten aus dem AUTO-Ordner heraus gestartet wurde. Und warum nicht? Weil bei neueren TOS-Versionen die Systemvariable $4f2 (sysbase) noch nicht initialisiert ist, wenn Programme im AUTO-Orner aufgerufen werden, praktisch alle anderen Systemvariablen aber bereits verwendet werden drfen. Bei TOS 1.0 trat jedenfalls diese Inkonsequenz noch nicht auf. Is' ja auch logisch, oder?! Tja, und da muž ich auch einige ST-Anwender kritisieren, die mich immer ganz entrstet anriefen und Ihre Meinung zum Ausdruck brachten, was fr ein Schrott der Speeder+ doch sei. Diese Leute erz„hlten mir, daž der Speeder+ nicht funktionierte, und ich hatte ihn natrlich auf allen TOS-Versionen getestet, allerdings nur per Doppelklick vom Desktop aus. Und da lief eben alles. Auf jeden Fall hat mir nie jemand genau sagen k”nnen, was eigentlich nicht klappte, und mit ein bižchen Mhe h„tte es m”glich sein mssen, festzustellen, daž besagtes Problem nur mit AUTO-Ordner auftrat. Na gut, also Schwamm drber! Diese Speeder+-Version darf frei kopiert werden, sollte aber niemals ohne diese Anleitung weitergegeben werden! Weichen Sie nach M”glichkeit nur in begrndeten Ausnahmef„llen von dieser Bitte ab. Z.B. h„tte ich nichts dagegen, wenn Speeder+ als Schnellader bei Spieledisketten eingesetzt wrde. In solchen F„llen wird natrlich kein Platz fr die Anleitung vorhanden sein. Sie sollten folgende Files auf dieser PD-Diskette vorfinden: 1. Speeder4.prg : Speeder+-Programm 2. Speeder4.q : Quelltext des Programms 3. Speeder4.doc : wenn dieses File nicht vorhanden ist, k”nnen Sie diesen Text nicht lesen / geniežen / in den Desktop- Papierkorb werfen. 4. Speeder4.s: das gleiche im ASCII-Format ( ohne Schriftarten ) II. Theoretische Grundlagen von Fastload-Utilities Mažgebend fr die Geschwindigkeit eines Computers ist nicht nur seine Prozessorleistung, sondern vor allem auch die Leistungsf„higkeit seiner Peripherie wie Diskettenlaufwerke, Festplatte und Drucker. Bezglich der Diskettenlaufwerke hat der ATARI ST beim Arbeiten mit l„ngeren Files eine durchschnittliche Lesegeschwindigkeit von 8 KByte/sec., bzw. ungef„hr 4 KByte/sec. beim Schreiben. Diese Werte k”nnen durch das Ausschalten eines Verifys verdoppelt werden. Noch dazu hat diese Mažnahme praktisch keinen gravierenden Nachteil zur Folge, jedenfalls hat mich noch kein Skeptiker vom Gegenteil berzeugen k”nnen. Dieser Text ist noch immer eine der wenigen detaillierten und korrekten Beschreibungen dafr, was passiert, wenn das Track- Verify beim Spurwechsel ausgeschaltet wird ( das Prinzip aller Fastload-Utilities ). Eine Warnung im voraus: Es handelt sich hierbei um keine leichte Materie. Ich habe mich jedoch bemht, diese Anleitung m”glichst leichtverst„ndlich zu verfassen. Wenn Sie schon im voraus gen- gend Vertrauen zu meinem Programm haben sollten, brauchen Sie sich mit programmtechnischen Details natrlich nicht zu belasten. Was bewirkt das Programm "Speeder4.prg" nun konkret und ist bei der Sache nicht doch ein Haken? Um evtl. Žngste der Skeptiker und Sicherheitsfanatiker zu zerstreuen, m”chte ich einen kurzen Ausflug in die Theorie des Floppy Disc Controllers ( FDC ) des Atari ST unternehmen. Der FDC bietet unterschiedliche Vorkehrungen, die Datensicherheit zu erh”hen. Es existieren haupts„chlich drei Arten eines Verifys: 1. Lesen eines Sektors: Der FDC arbeitet bereits hardwarem„žig mit Prfsummen. Wenn ein Sektor auf die Diskette geschrieben wird, fgt der FDC automatisch eine 16-Bit Prfsumme an. Diese Prfsumme wird auch als "Cyclic Redudancy Check" oder kurz CRC bezeichnet. Beim Lesen berechnet der FDC aus den eingelesenen Daten die CRC-Prfsumme erneut und vergleicht diese mit der auf der Diskette bereits abgespeicherten. Bei einem Lesefehler tritt zwischen diesen beiden Werten mit an Sicherheit grenzen- der Wahrscheinlichkeit eine Diskrepanz auf. 2. Schreiben eines Sektors: Hier ist das Verifizieren nicht ganz so einfach. Der FDC kann jedenfalls nicht unmittelbar herausfinden, ob die Daten auf der Diskette richtig angekommen sind. Die Verify-Routine des TOS verwendet hier einen kleinen Trick: Alle geschriebenen Sektoren werden nach dem Schreiben in einen eigenen 1024 Byte-Puffer eingelesen ( 512 Bytes w„ren mindestens erforderlich ). Wenn beim Schreiben ein Fehler aufgetreten ist, kann dies ber die CRC-Logik festgestellt werden, da logischerweise nun auch ein CRC-Fehler auftreten muž. Es ist so immerhin nicht notwendig, daž alle geschrie- benen Daten mit den im Speicher vorhandenen Byte fr Byte verglichen werden mssen. Durch diese Methode halbiert sich im allgemeinen die Schreib- gegenber der Lesegeschwindigkeit, da jeder geschriebene Sektor noch einmal zum Verifizieren gelesen werden muž. Dieses Verify kann ber das Betriebssystem ausgeschaltet werden, indem die Systemvariable $444 auf einen Wert ungleich 0 gesetzt wird. Dies ist aber aus Grnden der Datensicherheit wirklich riskant. 3. Track-Verify nach Positionierung des Schreib/Lesekopfes: Nach einer Positionierung des Schreib/Lesekopfes durch einen SEEK-, RESTORE oder STEP-Befehl des FDC besteht die M”glich- keit, zu berprfen, ob der logische Track mit dem physikal. Track auf der Diskette bereinstimmt. Es kann n„mlich vorkommen, daž der Schrittmotor des Diskettenlaufwerks den Befehlsimpulsen zur Positionierung nicht folgen kann und sich dann auf einem falschen Track befindet. Zum Verifizieren liest der FDC das ID-Feld des n„chsten Sektors, in dem Seite, Track, Sektornummer und Gr”že als Informationen ber den betreffenden Sektor abgelegt sind. Die BIOS-Routine 4 ( "rwabs" ), ber die fast alle Disketten- zugriffe laufen, macht von diesem Verify beim Positionieren Gebrauch. Die entsprechende Stelle liegt bei jeder Betriebs- systemversion natrlich woanders. Bei der TOS-Version 1.0 liegt sie z.B. an der Addresse $FC1B8A: $FC1B8A: moveq.l #$14,d6 ; SEEK mit Verify $FC1B90: bsr $FC1BB6 ; an FDC schicken Im "Atari ST INTERN" von Data Becker wird die Routine, in der diese Sequenz enthalten ist, als "go2track" bezeichnet, aller- dings ist dieser Name nicht "offiziell". Sie dient dazu, wie bereits der Name sagt, einen bestimmten Track anzusteuern. Speeder+ schaltet dieses Verify aus, indem der FDC-Befehl $14 durch $10 ( SEEK ohne Verify ) ersetzt wird. Dies hat bei l„ngeren Files eine Verdopplung der Schreib- und Lesegeschwin- digkeit zur Folge. Der Grund liegt in nutzloser Wartezeit des FDC: Nehmen wir einmal an, daž 50KByte oder 100 Sektoren, die hintereinanderliegen, gelesen werden sollen. Nach 9 Sektoren ( bzw. 10 Sektoren bei einer FATDISK, 11 Sektoren bei 'hyperformatierten' Disketten ) muž der Schreib/Lesekopf auf den n„chsten Track positioniert werden. Bei eingeschaltetem Verify holt der FDC die physik. Tracknummer aus dem n„chsten ID-Feld, das zu Sektor 1 des n„chsten Tracks geh”rt. Sektor 1 ist aber gleichzeitig derjenige Sektor, der als n„chster gelesen werden muž. Da dessen ID-Feld soeben am Lesekopf vorbeigerauscht ist, muž eine ganze Umdrehung abgewartet werden, bis er das n„chste Mal gefunden wird. Fr das Lesen eines Tracks werden also statt einer Umdrehung jeweils zwei ben”tigt. Die m”gliche šbertragungsrate wird dadurch halbiert! Welche Nebenwirkungen treten bei der Ausschaltung dieses Verifys auf? šberhaupt keine! Ein Track-Verify findet n„mlich auch bei jedem Schreib/Lesevorgang auf Diskette statt. Der FDC prft bei einem READ-SECTOR-Befehl ( bzw. WRITE-SECTOR ), ob die vorhandene Tracknummer im ID-Feld mit der gewnschten Nummer im Track- Register des FDC bereinstimmt. Ein Fehler wird ber ein Status- bit erkannt ( "Record not found" ) und auch vom Betriebssystem registriert. Wenn wirklich einmal ein falscher Track angesteuert ist, sucht das Betriebssystem die betreffende Spur noch einmal ( ein "RESEEK"-Vorgang ). Technisch gelingt dies ber ein RESTORE ( Positionierung des Lesekopfes auf Track 0 ) und einem anschlie- ženden SEEK-Befehl an den FDC. Damit wird die gewnschte Spur auch bei einem Positionierungsfehler mit an Sicherheit grenzender Wahrscheinlichkeit gefunden. Keine Geschwindigkeitsvorteile bieten Fastload-Utilities brigens bei "Schnelladedisketten", die auf folgende Art formatiert worden sind: Track 0 beginnt mit Sektor 1 ( wie immer ). Bei jedem folgenden Track rutscht der logische Sektor 1 um eine Position nach hinten, d.h. Track 1 beginnt mit Sektor 9 ( bzw. Sektor 10 bei einer Fatdisk! ) und erst anschliežend folgt Sektor 1. Auf Track 2 steht Sektor 1 schliežlich erst an 3. Position, usw. Durch diese Methode wird auch bei eingeschaltetem Track-Verify fast eine Verdopplung der Schreib- und Lesegeschwindigkeit erzielt, leider bieten aber nach wie vor die wenigsten Formatierprogramme eine Option an, nach der Disketten mit dieser Methode formatiert werden k”nnen. III. M”gliche Probleme mit Fastload-Utilities Mit dem Laufwerkstyp NEC-1037 traten in Einzelf„llen Probleme beim Lesen von Daten auf. Ab und zu werden korrekt geschriebene Sektoren als defekt deklariert. Bei weiteren Leseversuchen werden sie dennoch richtig eingelesen. Ich vermute, daž es sich hierbei um ein rein mechanisches Problem dieses ansonsten sehr guten Laufwerks handelt. Bei ausgeschal- tetem Track-Verify wird nach einem Spurwechsel der zu lesende Sektor in der Regel viel schneller erreicht als mit Verify ( wo meistens bis zum Lesen der Daten ein ganzer Diskettenumlauf gewartet werden muž! ). Wenn der Schreib/Lesekopf nach dem Spurwechsel noch etwas schwingt, werden die Daten evtl. nicht korrekt eingelesen, obwohl sie natrlich richtig aufgezeichnet worden sind. Sofern meine Theorie stimmt, k”nnten durch die leichte und flache Bauweise des NEC-1037 Laufwerks solche Pro- bleme unter Umst„nden auftreten. Allerdings muž ich zugeben, daž diese Erkl„rung eine reine Hypothese darstellt, die nicht un- bedingt zutrifft. Falls bei Ihnen dieses Problem auftauchen sollte, empfehle ich, eine Systemvariable im Betriebssystem zu ver„ndern. Es handelt sich um die Variable in $440 ( seekrate, Word-Format ). Wenn diese Variable auf '0' statt auf '3' gesetzt wird, erh”ht sich die Wartezeit, die der FDC nach einem Step-Impuls einlegt, von 3 auf 6 ms. Auf die Addresse $440 kann brigens nur im Supervisor- Modus des 68000ers zugegriffen werden. Ich m”chte noch einmal ausdrcklich darauf hinweisen, daž dieser bisher nur im Zusammenhang mit Laufwerken des Typs NEC 1037 aufgetretene "Fehler" im Grunde nichts mit mangelnder Daten- sicherheit des Speeder+ oder anderer Fastload-Programme zu tun hat. Die Daten werden zumindest immer korrekt aufgezeichnet, im schlimmsten Falle k„me man an sie nach einem neuen Bootvorgang ohne Fastload-Programm heran, normalerweise aber bereits bei einem weiteren Leseversuch. Natrlich tritt das eben erw„hnte Problem nicht auf allen NEC- 1037 Laufwerken auf, und selbst auf betroffenen Laufwerken nur h”chst sporadisch. Mit anderen Laufwerkstypen hat es bisher keine Schwierig- keiten gegeben, auch nicht mit 5.25"-Laufwerken. Eine weiteres h„ufiges Problem wird Fastload-Programmen v”llig zu unrecht zugeschrieben: Disketten k”nnen zwar mit dem eigenen Laufwerk korrekt gelesen werden, nicht jedoch auf einem anderen. Derartige Schwierigkeiten k”nnen nie durch den Speeder+ verursacht worden sein. Ursache fr solche Probleme sind vielmehr z.B. unterschiedliche Drehzahlen der Laufwerke ( 300 UpM ist die Solldrehzahl, die tats„chliche Drehzahl eines Laufwerks kann aber durchaus bis zu 2% von diesem Wert abweichen! ), oder auch ein verstaubter Schreib/Lesekopf bei einem der beiden "inkompatiblen" Laufwerke etc. Derartige Fehler h„ngen natrlich nicht mit dem Ausschalten eines Verifys zusammen, da physikalische Intoleranzen zwischen Laufwerken nichts damit zu tun haben, ob Daten mit oder ohne Track-Verify aufgezeichnet worden sind. Die Erfahrungen in Zusammenhang mit Fastload-Programmen zeigen, daž beim weitaus gr”žten Teil der ST-Anwender, die entsprechende Utilities verwenden, niemals irgendwie geartete Probleme aufge- treten sind. Und schliežlich verwende ich selbst seit Jahren TOS-Versionen im EPROM, in denen ich das Track-Verify ausgeschaltet habe. Natrlich fhle ich mich trotz eines Verifys weniger in meinem Rechner keineswegs bedroht ( eher schon von der Fileverwaltung des GEMDOS! ). Auch wenn in ( seltenen ) Einzelf„llen Probleme mit Fastload-Utilities beim Lesen auftreten k”nnen, ist der wichtigsten Forderung bezglich der Datensicherheit immer Rechnung getragen: Fehlerhaftes Aufzeichnen oder šberschreiben von Daten aufgrund ausgeschaltetem Track-Verify ist unm”glich. Sie sollten sich also nicht davon abhalten lassen, Ihren Diskettenlaufwerken auf die Sprnge zu helfen! III. Algorithmus von "Speeder4.prg" Nach diesen theoretischen Vorbemerkungen k”nnen wir endlich den 'Speeder+' unter die Lupe nehmen. Fast alle Zugriffe auf die Diskettenlaufwerke laufen, wie weiter oben schon gesagt, ber die Funktion 4 des BIOS, in der nur ein einziges Byte ge„ndert werden muž. Im ROM ist es allerdings unm”glich, diese Stelle zu manipulieren ( was natrlich „rgerlich ist ). Zum Glck wird diese Routine ber einen Vektor angesprungen ( Systemvariable $476 ), der auf eine eigene Routine umgebogen werden kann. Von dieser Tatsache machen z.B. auch Ramdisks und Festplatten-Treiber Gebrauch. Das Prinzip jedes Fastload-Programms besteht darin, daž es als residentes Programm installiert wird. Wenn es nicht bereits selbst von der alten rwabs-Routine abgeleitet ist, wie mein alter "Speeder", muž es diese aus dem Betriebssystem kopieren. Leider ist die originale rwabs-Routine eine der l„ngsten Routinen im Betriebssystem, zu ihr geh”ren beispielsweise Unterprogramme zur DMA-Kontrolle, Fehlerbehandlung etc. Zudem stehen diese Subroutinen nicht ordentlich hintereinander, sondern sind recht verstreut. Beim Kopieren der originalen rwabs-Routine ins RAM bestehen deutliche Unterschiede zwischen 'Fastload' und meinem Speeder+. Fastload-Versionen kopieren ab Beginn des Betriebssystems 8 KByte Daten aus dem ROM in einen programminternen Puffer, das reicht bei allen bisherigen TOS-Versionen aus, um die rwabs-Routine komplett ins RAM abzubilden. Anschliežend werden von "Fastload" noch einige Sprungaddressen reloziert, wobei je nach TOS-Version auf eine eigene Tabelle zugegriffen wird. Speeder+ verh„lt sich wesentlich intelligenter. Zun„chst wird mit Hilfe von Suchstrings nach dem im Speicher am weitesten vorne stehenden Unterprogramm gesucht, das noch von der rwabs-Routine aufgerufen wird. Bei allen bisherigen TOS-Versionen war dies bis- her entweder die BIOS-Mediach-Routine oder die XBIOS-Flopread- Funktion. Speeder+ vergleicht die Startaddressen beider Routinen und ko- piert ab der niedrigeren Addresse 4 KByte aus dem Rom ins RAM, damit wird im Vergleich zu "Fastload" ca. 4 KByte weniger Speicher belegt. Die Relozierroutine kommt ebenfalls ohne Tabellen aus. Es mssen lediglich die Sprungaddressen einiger jsr-Aufrufe angepažt werden. Jsr-Befehle ( absolute Addressierung ) k”nnen leicht aufgefunden werden, indem nach dem Wort $4EB9 gesucht wird. Zwei Sprunaddressen, n„mlich in den 'Critical Error Handler' und in die Sektorkopierroutine 'fastcopy', zeigen weiterhin in den ROM-Bereich. Durch diesen Trick, wirklich nur die Routinen zu kopieren, die fr die doppelte Schreib/Lesegeschwindigkeit relevant sind, ist der Speeder+ fast so kompakt wie m”glich geworden. Lediglich der Vorl„ufer 'Speeder.prg' V1.4 reserviert noch weniger Speicher ( ca. 2.5 KByte ), l„uft dafr aber nur mit TOS 1.0. Anschliežend wird im Ram-Puffer noch nach der Routine 'go2track' gesucht und der FDC-Befehl 'Seek mit Verify' ($14) in 'Seek ohne Verify' ($10) umge„ndert. Zuletzt wird der Vektor $476 auf eine Speeder+-Routine umgebogen, die bei rwabs-Aufrufen erkennt, ob Laufwerk A oder B angesprochen wird. Falls dies nicht der Fall ist, wird die Kontrolle an den entsprechenden Ramdisk-, Festplattentreiber etc. abgegeben. Da Speeder+ im Gegensatz zu 'Fastload' keine Reloziertabellen verwendet, sondern ausschliežlich mit Suchstrings arbeitet, drfte es sogar auf zuknftigen TOS-Versionen funktionieren, wenn fr den ST das TOS berhaupt noch weiterentwickelt werden sollte. Die Funktionsf„higkeit des Speeder+ ist zwar ( bisher ) auf allen TOS-Versionen des Atari ST gew„hrleistet. Wahrscheinlich wird er jedoch nicht auf dem bereits lieferbaren 'Atari TT' funktionieren. Ich weiž ehrlich gesagt noch nicht einmal, ob das TT-Tos ein Track-Verify vorsieht oder nicht. Eine Anpassung des Speeder+ an den 'Atari TT' wrde ich auch auf keinen Fall als meine Aufgabe betrachten. Aber schliežlich gebe ich dafr ja auch den Quelltext meines Programms mit heraus, so daž bei Bedarf jemand ohne zu grožen Aufwand diese Anpassung erledigen k”nnte. Kulmbach, den 18.10. 90 Stefan Schreiber P.S.: "Speeder+" ist ein „užerst ntzliches Utility und steigert die Leistungsf„higkeit Ihres Computersystems evtl. ganz erheblich. Falls Sie dieses Programm h„ufig benutzen, wrde ich es fr fair halten, wenn Sie mir als Anerkennung dafr einen Betrag zuschicken, den Sie fr angemessen halten. In diesem Falle vielen Dank bereits im voraus!