Computer Club Elmshorn Atari PD

home *** CD-ROM | disk | FTP | other *** search

/ Computer Club Elmshorn Atari PD / CCE_PD.iso / pc / 0600 / CCE_0686.ZIP / CCE_0686 / SPEEDER_.U77 / ANLEITUN.G / SPEEDER4.S < prev

Wrap

Text File | 1990-04-08 | 21KB | 386 lines

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 endgültige Version meine und Ihre Erwartungen erfüllen wird! Es existieren derzeit vier offizielle TOS-Versionen für 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 dürfen. 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 entrüstet anriefen und Ihre Meinung zum Ausdruck brachten, was für ein Schrott der Speeder+ doch sei. Diese Leute erzählten mir, daß der Speeder+ nicht funktionierte, und ich hatte ihn natürlich 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 Mühe hätte es möglich sein müssen, festzustellen, daß besagtes Problem nur mit AUTO-Ordner auftrat. Na gut, also Schwamm drüber! Diese Speeder+-Version darf frei kopiert werden, sollte aber niemals ohne diese Anleitung weitergegeben werden! Weichen Sie nach Möglichkeit nur in begründeten Ausnahmefällen von dieser Bitte ab. Z.B. hätte ich nichts dagegen, wenn Speeder+ als Schnellader bei Spieledisketten eingesetzt würde. In solchen Fällen wird natürlich kein Platz für 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 für die Geschwindigkeit eines Computers ist nicht nur seine Prozessorleistung, sondern vor allem auch die Leistungsfähigkeit seiner Peripherie wie Diskettenlaufwerke, Festplatte und Drucker. Bezüglich 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 dafür, 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 bemüht, 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 natürlich 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 Prüfsummen. Wenn ein Sektor auf die Diskette geschrieben wird, fügt der FDC automatisch eine 16-Bit Prüfsumme an. Diese Prüfsumme wird auch als "Cyclic Redudancy Check" oder kurz CRC bezeichnet. Beim Lesen berechnet der FDC aus den eingelesenen Daten die CRC-Prüfsumme 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 für Byte verglichen werden müssen. Durch diese Methode halbiert sich im allgemeinen die Schreib- gegenüber 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 Gründen 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 überprüfen, 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 natürlich 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. Für 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 prüft bei einem READ-SECTOR-Befehl ( bzw. WRITE-SECTOR ), ob die vorhandene Tracknummer im ID-Feld mit der gewünschten 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 gewünschte 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 natürlich 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 ausdrücklich 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. Natürlich 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 für 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 natürlich 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. Natürlich fühle 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 bezüglich 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 Sprünge 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 natürlich ärgerlich ist ). Zum Glück 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 müssen 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 für 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 dafür 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, dürfte es sogar auf zukünftigen TOS-Versionen funktionieren, wenn für 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' würde ich auch auf keinen Fall als meine Aufgabe betrachten. Aber schließlich gebe ich dafür 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 nützliches Utility und steigert die Leistungsfähigkeit Ihres Computersystems evtl. ganz erheblich. Falls Sie dieses Programm häufig benutzen, würde ich es für fair halten, wenn Sie mir als Anerkennung dafür einen Betrag zuschicken, den Sie für angemessen halten. In diesem Falle vielen Dank bereits im voraus!