Hallo Besucher, der Thread wurde 4,7k mal aufgerufen und enthält 21 Antworten

letzter Beitrag von LogicDeLuxe am

[suche] Tracksaver 1541

    Hallo,
    es gibt ja diverses an Trackloadern für die 1541, darunter auch richtig geniale und schnelle Teile wie zum Beispiel Mafiosinos Trackloader.
    Gibt es denn was vergleichbares auch für´s speichern? Also eine kleine Routine die ins Ram der Floppy eine beschleunigte Speicheroutine einbindet?
    Ich interessiere mich für reine Softwarelösungen, die das Speichern maximal beschleunigen. Leider verlief meine bisherige Suche recht erfolglos - klar, schnell laden war wesentlich beliebter als speichern, aber vielleicht kenn ja jemand eine passende Routine die (idealerweise) den Kernalsave kräftig boostet?

    Natürlich kann man auch schneller schreiben, d. h. den Transport der Daten zum Laufwerk hin beschleunigen. Wie schnell soll es denn sein? Eigentlich ist jeder eigene Lader, der die Standardroutinen umgeht, bereits ein Beschleuniger. Nun kann man aber, wie üblich, unterteilen in Übertragung mit Handshake pro 1 Bit bzw. 2 Bit oder 8 Bit. Die meisten auch schreibenden Lader, die ich kenne, verwenden lediglich die 1 Bit-Handshake-Übertragung. Eine Ausnahme ist z. B. der Lader von TestdriveII. Hier findet sich folgender Code für die Übertragung von 8 Bit gleichzeitig (analog zum Verfahren fürs Laden):

    Das Verfahren hat den Vorteil, daß es einerseits recht schnell ist, aber trotzdem den Bildschirm angeschaltet läßt.

    Danke schon mal für eure Antworten, ich werde damit mal ein bissel experimentieren.
    Es gibt keinen akuten Anlass, es ist mehr akademisches Interesse. Die Speedloader sind ja weit verbreitet, es war mir nur aufgefallen dass kaum jemand versucht hat ein wirklich schnelles save zu implementieren, und da stellte sich mir die Frage ob es da Limitierungen gibt die bei einem Fastloader nicht existieren. Grade der o.g. Mafiosinolader ist ja einfach schweineschnell, und wenn man das mit einem Tracksave ähnlicher Güte kombinieren könnte hätte man eine interessante Möglichkeit on the fly größere Datenmengen zu bearbeiten. Da braucht es halt beides in schnell, laden wie speichern.

    Zitat von BladeRunner

    es war mir nur aufgefallen dass kaum jemand versucht hat ein wirklich schnelles save zu implementieren, und da stellte sich mir die Frage ob es da Limitierungen gibt die bei einem Fastloader nicht existieren

    Ja, solche Limitierungen gibt es tatsächlich. Bei einem Schnellader kann man z. B. das Laden eines Tracks aufspalten, indem man in einem Durchgang zunächst nur die erste Hälfte eines Sektors lädt und im nächsten Durchgang dann die zweite. Beim Schreiben muß jedoch immer der ganze Sektor geschrieben werden.
    Desweiteren arbeiten moderne Schnellader so, daß während des Lesens der GCR-Daten von Diskette bereits eine Vordekodierung (also Umwandeln von GCR-Code in normale Bytes) vorgenommen wird. Mir ist zur Zeit kein Verfahren bekannt, daß analog dazu während des eigentlichen Schreibens die letzte Kodierung in GCR-Bytes vorgenommen wird.
    Die neuen Ladeverfahren benötigen außerdem wesentlich mehr Platz im Speicher als früher, einerseits für das längere Dekodierungsprogramm, andererseits für die größeren Lesepuffer. (Ältere Schnellader kümmern sich nur um die Übertragung, verwenden aber zum Lesen und Schreiben die Standardroutinen im Laufwerk.) Gleichzeitig Routinen für schnelles Dekodieren (Lesen) und Kodieren (Schreiben) von Daten in den kleinen Speicher der Floppy reinzupacken, halte ich für schwierig.
    Zuletzt gibt es noch das Problem mit dem Interleave. Man kann eine Diskette so formatieren bzw. die Sektoren per Hand so verteilen, daß der Interleave dafür sorgt, daß das Laden zügig vonstatten geht, aber da Schreiben und Lesen unterschiedlich lange dauern, kann es sein, daß als Folge beim Schreiben die Geschwindigkeit komplett zusammenbricht, da bei Scheibstart der Folgesektor gerade vorbeirotiert ist.

    Zitat von M. J.

    Desweiteren arbeiten moderne Schnellader so, daß während des Lesens der GCR-Daten von Diskette bereits eine Vordekodierung (also Umwandeln von GCR-Code in normale Bytes) vorgenommen wird. Mir ist zur Zeit kein Verfahren bekannt, daß analog dazu während des eigentlichen Schreibens die letzte Kodierung in GCR-Bytes vorgenommen wird.

    Zitat von M. J.

    Gleichzeitig Routinen für schnelles Dekodieren (Lesen) und Kodieren (Schreiben) von Daten in den kleinen Speicher der Floppy reinzupacken, halte ich für schwierig.

    Hm - und wenn man den Sektor jeweils schon im C64 auf GCR umrechnet und erst dann sendet, das sollte doch einiges bringen, oder?
    Die Idee die mir da vorschwebt darf im Speicher des C64 durchaus ein paar KB belegen, da es ja um Nutzdaten ginge, nicht darum ein komplettes Speicherabbild zu sichern.


    Und es sollte doch theoretisch auch nicht so viel Overhead sein vor der benötigten Operation (r/W) den passenden code für diesen Zweck in die Floppy zu laden, oder?


    Bliebe noch die Sache mit dem Interleave, da ist sicher nicht viel zu machen. Und der Speicher der 1541 ist da auch ein Problem. Wenn aber die Daten ja als steter vorcodierter Stream ankämen sollte auch das wieder zu vernachlässigen sein, oder?


    Ein kompletter Track mit 21 Sektoren hätte GCR-Codiert 6720 Byte (21sec*256byte*10bit)/8bit, das würde zB unter das Kernal passen. Ich weiss jetzt nicht wie die Floppy die Daten Zwischen den Sektoren einpflegt, ob das automatisiert geschieht oder auch in Software, aber dann könnte man diese Nutzdaten nötigenfalls auch ncoh mit in den Speicher packen und direkt senden. Ich bin leider technisch nicht sehr versiert und habe keine Ahnung ob ich da was übersehe, aber so sollte doch zumindest der Floppyinterne Flaschenhals (GCR-Kodierung) umgangen werden können. Und wenn man dann noch wie weiter oben angeführt einen anderen Handshake für die Übermittlung nimmt müsste man doch theoretisch am Stück übertragen können bis der komplette Track geschrieben ist, oder habe ich da einen Denkfehler?

    Zitat von BladeRunner

    Hm - und wenn man den Sektor jeweils schon im C64 auf GCR umrechnet und erst dann sendet, das sollte doch einiges bringen, oder?

    Ist das denn so zeitaufwändig? Das ist doch nur ein wenig Bitschieberei. Und viel Speicher kostet das auch nicht (16 Byte Lookup-Tabelle)

    Naja, wenn die Floppy mit 300 rpm dreht bedeutet dass dass der komplette Track 5 mal pro Sekunde am Schreibkopf ist. macht bei einer angenommenen Nutzlast von um die 8kb inklusive aller Header etc. 40kb/s die da durchflutschen. Ein einzelnes bit hat also 1/(8*40*1024) = ca. 3 ms zeit geschrieben zu werden, sprich 3 Zyklen der Floppy. So viel zeit ist das nicht um da nebenbei was anderes zu erledigen, oder?

    Wie macht das denn das Standard-DOS? Hat die Floppy ein GCR-ROM, wie die alten CBM-Floppies?

    Zitat von BladeRunner

    wenn man den Sektor jeweils schon im C64 auf GCR umrechnet und erst dann sendet, das sollte doch einiges bringen, oder?

    Dabei muß man mitbedenken, daß die Übertragung der zusätzlichen Daten (Der Faktor zwischen Originaldaten und GCR-Daten liegt bei ca. 5/4) zusätzlich Zeit kostet. Hier ist genaues Abwägen nötig, was nun langsamer ist: Kodieren der Daten in der Floppy oder Übertragen von zusätzlichen Bytes. Ich vermute mal, daß die schnellste Methode wäre, die Bytes als Nibbles zu schicken, diese dann in der Floppy aber nicht mehr zu Bytes zusammenzusetzen, sondern gleich daraus den GCR-Code zu ermitteln, sozusagen als Kodierungsvorstufe.

    Zitat von BladeRunner

    es sollte doch theoretisch auch nicht so viel Overhead sein vor der benötigten Operation (r/W) den passenden code für diesen Zweck in die Floppy zu laden

    Das käme darauf an, wie Du den Code in das Laufwerk übertragen möchtest. Standardmäßig wird dies über die langsamen Kernalroutinen abgewickelt. Alternativ kann man es so handhaben wie Ultraload: Man schickt zuerst eine kurze Assemblerroutine ans Laufwerk, welche dann den eigentlichen Code beschleunigt lädt. Wie man an Ultraload erkennen kann, dauert jedoch auch dies bei Programmstart immer noch spürbar lang.

    Zitat von BladeRunner

    Ein kompletter Track mit 21 Sektoren hätte GCR-Codiert 6720 Byte (21sec*256byte*10bit)/8bit, das würde zB unter das Kernal passen.

    Lader wie "Most Access" benutzen den umgekehrten Weg, um einen Track schnell zu laden. Es werden die reinen GCR-Bytes zum C64 übertragen. Während die Floppy den nächsten Sektor einliest, dekodiert der C64 die Bytes zu Sektoren, die dann unter das Kernal-Rom geschoben werden.

    Zitat von BladeRunner

    ch weiss jetzt nicht wie die Floppy die Daten Zwischen den Sektoren einpflegt

    Ich bin nicht sicher, was Du damit meinst. Der Sektorheader wird nur beim Formatieren einmalig geschrieben. Beim Schreiben von Sektoren wird allein der Datenbereich überschrieben. (Deswegen gibt es zwischen dem Sektorheader und dem Datenbereich noch eine Syncmarkierung.)

    Zitat von BladeRunner

    müsste man doch theoretisch am Stück übertragen können bis der komplette Track geschrieben ist

    Zwischen dem Schreiben von zwei GCR-Bytes auf Diskette hat das Programm ca. 20 Taktzyklen Zeit (den genauen Wert müßte ich nachschlagen). Diese Zeit reicht nicht aus, um gleichzeitig ein neues Byte über den seriellen Bus in Empfang zu nehmen. Wenn ich mich recht erinnere, kann daher die Zoomfloppy nur mit einer 1571 einen Track in einem Rutsch lesen, da dort ein anderes Übertragungsprotokoll zum Einsatz kommt. Geh davon aus, daß die zu schreibenden Daten vor dem Schreiben komplett ins Laufwerk übertragen werden müssen. Da der Speicher dort aber nicht ausreicht, um die 6720 Bytes aufzunehmen, kann man mit der 1541 eine Spur nur sektorweise beschreiben.

    Zitat von BladeRunner

    dann wäre meine Frage wann sie das erledigt? Zwischen den Sektoren?

    Die Dekodierung passiert nicht zwischen den Sektoren, da der zeitliche Abstand zwischen Sektoren viel zu kurz ist. Tatsächlich braucht es recht lange, bis das Rom die Daten zu GCR-Daten konvertiert hat. In der Zeit sind schon weitere Sektoren am Lesekopf vorbeigerauscht. Aus diesem Grunde werden die Sektoren nicht direkt nacheinander gelesen bzw. geschrieben, sondern in Abständen, dem sogenannten Interleave. Wie ich oben schon schrieb, orientiert sich der Interleave normalerweise am Lesen, da dies öfters vorkommt als das Schreiben. Kommt es nun zu Unterschieden zwischen dem Interleave fürs Lesen und fürs Schreiben, wobei voraussichtlich das Lesen schneller abgewickelt wird als das Schreiben, so führt das dazu, daß beim Schreiben fast eine ganze Rotation gewartet werden muß, bis der passende Sektor wieder am Lesekopf vorbeirotiert.

    ist es möglich, die save-routine vom 15-sekunden parallel-backup


    an den seriellen port anzupassen. die wir zwar nicht so schnell


    auf disk schreiben, wie mit parallel-kabel ,aber vielleicht kann


    man da was draus machen.



    ich hatte mir die laderroutine mal ausgebaut, um eine disk,


    auf der ein an die reu angepasstes spiel war, in die reu zu laden.


    die 530 blocks wahren innerhalb von einigen sekunden geladen.


    und dann konnte mal spielen.



    stephan

    Zitat von M. J.

    Zuletzt gibt es noch das Problem mit dem Interleave. Man kann eine Diskette so formatieren bzw. die Sektoren per Hand so verteilen, daß der Interleave dafür sorgt, daß das Laden zügig vonstatten geht, aber da Schreiben und Lesen unterschiedlich lange dauern, kann es sein, daß als Folge beim Schreiben die Geschwindigkeit komplett zusammenbricht, da bei Scheibstart der Folgesektor gerade vorbeirotiert ist.

    Das Interleave-Problem ist wohl der eigentliche Grund, daß Trackloader überhaupt existieren. Denn bei Trackloadern spielt Interleave keine Rolle mehr. Es wird immer der ganze Track geladen, und die gewünschten Sektoren werden erst anschließend rausgesucht. Beim Save sollte es dann doch auch nicht anders sein, nur umgekehrt.


    Die 1581 und der Amiga haben doch bereits Trackloader im ROM. Wie sieht es da eigentlich mit Save aus? Wird da auch immer der ganze Track am Stück gespeichert? Das würde dann ja bedeuten, daß ein teilbelegter Track zunächst mal geladen werden muß, um die vorhandenen Sektoren nicht zu verlieren. Das wäre sicher schon ein Grund, warum ein Tracksave nie so schnell sein kann, wie ein Trackload. Lediglich ein kompletter Diskkopierer hätte diese Einschränkung natürlich nicht.

    Zitat von M. J.

    Ich bin nicht sicher, was Du damit meinst. Der Sektorheader wird nur beim Formatieren einmalig geschrieben. Beim Schreiben von Sektoren wird allein der Datenbereich überschrieben.

    Das trifft beim sektorweisen Schreiben zu. Beim Tracksaver müsste das ja nicht zwangsläufig auch so sein.

    Zitat von LogicDeLuxe

    Wird da auch immer der ganze Track am Stück gespeichert? Das würde dann ja bedeuten, daß ein teilbelegter Track zunächst mal geladen werden muß, um die vorhandenen Sektoren nicht zu verlieren. Das wäre sicher schon ein Grund, warum ein Tracksave nie so schnell sein kann, wie ein Trackload.

    Beim Amiga wird auch beim Speichern eines Sektors stets die ganze Spur geschrieben. Die Geschwindigkeitseinbußen sind aber relativ gering und verschmerzbar, weil der Trackload irgendwo mitten im Track starten kann. Es wird also nicht zunächst auf Sektor 0 gewartet. Dies ist möglich, da die Syncmarkierung, die der Controller braucht, um den Anfang der Daten bzw. des Headers zu finden, vor jedem Sektor stehen und das Laufwerks-Signal "Anfang einer Spur" keine Rolle spielt. Für weitere Beschleunigung sorgt der ohnehin benötigte Spurcache. Hierbei werden die Daten zunächst im Speicher gesammelt und erst dann geschrieben, wenn auf eine andere Spur gewechselt werden soll oder eine bestimmte Zeit vergangen ist.

    Zitat von LogicDeLuxe

    Es wird immer der ganze Track geladen, und die gewünschten Sektoren werden erst anschließend rausgesucht. Beim Save sollte es dann doch auch nicht anders sein, nur umgekehrt.

    Ohne zusätzliche Hardware gibt es bei der 1541 keine echten Trackloader oder Tracksaver, wobei ich mich allerdings vage daran erinnere, daß es mal jemanden gab, der es tatsächlich geschafft hat, eine Spur in einer Rotation zu lesen und zum C64 zu schicken. (Muß ich mal nachschlagen.) Für das Speichern halte ich dies aber für ausgeschlossen. Ein Tracksaver ist auf einer 1541 nicht möglich, denn dabei müßten alle GCR-Daten im Speicher der 1541 vorhanden sein. Der Speicher der 1541 ist dafür jedoch viel zu klein. Dieses Manko war folglich die Basis für mehrere Kopierschutzverfahren.

    Zitat von LogicDeLuxe

    Das Interleave-Problem ist wohl der eigentliche Grund, daß Trackloader überhaupt existieren.

    Schön wär's. Wenn ich mich recht erinnere, sieht das in etwa folgendermaßen aus:

    Das Senden der vollständigen GCR-Daten an den C64 benötigt die Zeit, in der 2 weitere Sektoren am Lesekopf vorbeirotieren, und dies ist auch nur durch den Einsatz von extrem aufwendigen und zeitkritischen Busroutinen möglich, die den Handshake extrem einschränken, was zur Folge hat, daß sie auf NTSC etc in der Regel nicht mehr funktionieren.
    Desweiteren wird beim Lesen zumeist nicht einfach der nächste Sektor genommen, sondern auf einen bestimmten Sektor gewartet. So ist der Interleave von 3 in Most Access fest eingebaut. Als Nachteil entsteht dadurch auch, daß nach einem Spurwechsel stets auf Sektor 0 gewartet werden muß, was recht lange dauern kann. Adaptive Tracklader, d. h. solche, bei denen die Reihenfolge der Sektoren auf der Diskette keine Rolle spielt, weil der Lader selbst guckt, ob er den gefundenen Sektor gebrauchen kann oder nicht, sind selten, da sie nur in Situationen verwendet werden, in denen der C64 irgendwie aufgehalten werden kann z. B. durch Interrupts. Spontan fällt mir daher auch nur mein eigener Tracklader ein, der - wie oben bereits genannt - mit eingeschaltetem Bild und IRQ auf einen Interleave von 5 kommt, wobei die Laderoutinen zusätzlich noch nicht nur auf PAL laufen, sondern auch für NTSC geeignet sind.

    Zitat von M. J.

    Most Access hat damit einen Interleave von 3.

    Mir ist schon klar, daß Softwarespeeder nicht die ganze Spur in einer Umdrehung schaffen. Der Softinterleave (Anordnung der Datei) ist aber dennoch irrelevant, da letztendlich doch die ganze Spur davon unabhängig gelesen wird.

    Zitat von M. J.

    Als Nachteil entsteht dadurch auch, daß nach einem Spurwechsel stets auf Sektor 0 gewartet werden muß

    Gut, da ist sicher Optimierungspotential vorhanden.

    Zitat von BladeRunner

    vielleicht kenn ja jemand eine passende Routine die (idealerweise) den Kernalsave kräftig boostet?

    Das 64'er Hypra-Load wurde ja später mit einer schnellen Save-Routine zum Hypra-System erweitert:


    https://csdb.dk/release/?id=98951


    Das VC-20-Äquivalent dazu hatte ich vor Jahren mal zwischen: die Floppy-Routinen werden zweistufig geladen - erst eine kleine Routine für den schnellen Byte-Transfer und dann die Sektor-Schreib-Logik. Dann wird ein Dummy-Directory-Eintrag angelegt (leere Datei), dann die Datei geschrieben (mit auf schnelleres Laden optimiertem Interleave), die BAM aktualisiert und zum Schluß auch der Directory-Eintrag (Track/Sektor erster Block, Anzahl Blocks).


    Ist doch etwas mehr Aufwand dabei als beim Lesen. Auf dem VC ist bei größeren Dateien Load 6x, und Save 3x schneller.

    Zitat von LogicDeLuxe

    Der Softinterleave (Anordnung der Datei)

    Ach so, Du meintest die Dateistreuung. Sorry, hatte ich mißverstanden. Bei der gibt es allerdings auch das kleine Problem, daß Tracklader nur dann wirklich erfolgreich sind, wenn die Sektoren der Datei regelmäßig nacheinander in die Sektoren einer Spur geschrieben wurden. Das Worst-Case-Szenario ist, wenn sich der jeweils nächste Sektor in einer anderen Spur befindet, da dann der Tracklader für jeden Sektor eine ganze Spur laden würde, also viel zu viel Overhead. Bekämpfen könnte man dies, wenn man vorher alle Sektorenlinks der Diskette scannt und dann vor dem Laden ermittelt, wieviele Sektoren der Datei sich in der Spur befinden, um daraus dann die Datei Stück für Stück zusammenzusetzen. Eine andere Möglichkeit wäre es, die Diskette zu defragmentieren, wobei ich allerdings nicht weiß, ob es solch ein Programm für die 1541 überhaupt gibt (direkt auf dem C64 oder für den PC). Allerdings... Wenn es darum geht, einen Schnellader in einem eigenen Programm einzusetzen, kann man das Dateisystem ohnehin einfach ignorieren. Das ist dann der einfachste und schnellste Weg, Daten von Diskette zu laden.

    Zitat von LogicDeLuxe

    Gut, da ist sicher Optimierungspotential vorhanden.

    Wie ich schon schrieb: Der Lader darf nicht auf einen bestimmten Sektor warten, sondern muß beim Lesen des Sektorheaders feststellen, welchen Sektor er gerade vor sich hat. Ist es einer, der noch nicht gelesen wurde, wird er gelesen und rübergeschickt, ansonsten übersprungen. Beim Rüberschicken muß dann halt nur die Information, um welchen Sektor es sich handelt, mitgesendet werden.


    Leider funktionieren diese Verfahren (bis auf das Ignorieren des Dateisystems) nicht bei einem Tracksaver, da der darauf angewiesen ist, daß die Daten nacheinander geschrieben werden und nicht irgendwie wild durcheinander.

    Zitat von Mike

    ann wird ein Dummy-Directory-Eintrag angelegt (leere Datei)

    Was ist der Zweck des Dummy-Eintrags?

    Zitat von Mike

    Sektor-Schreib-Logik

    Wie weit verwendest Du für das Schreiben (GCR-Kodierung, Ansteuern des Lese-/Schreibkopfes, Suchen des Sektors, Schreiben der GCR-Daten) eigene Routinen oder Routinen aus dem ROM?