Hello, Guest the thread was viewed17k times and contains 340 replies

last post from Natas at the

Transwarp Release

  • Da verschiedene Spuren verschieden viele Sektoren haben, kann sich die Dateigröße in Blöcken ändern, je nachdem, welchen zusammenhängenden Bereich auf der Diskette die Datei einnimmt.

    Damit passt je nach Dateireihenfolge noch eine weitere auf die Disk oder nicht.


    In cc1541 fehlt noch ein Modus, um die Reihenfolge der Transwarp-Dateien solange zu permutieren, bis alle angegebenen raufpassen - oder letztendlich "irgendwann" mit Disk full abgebrochen wird, wenn es keine geeignete Reihenfolge gibt.

    Wow, dass ist ja ganz schön tricky. Aber eben auch schön schnell.


    cc1541 ist ein tolles Tool! Vielen Dank dafür.


    Ich befürchte jedoch, letztlich wird es erst eine nennenswerte Anzahl von Transwarp-Disketten geben, wenn es dazu eine GBO für WIN und Linux gibt, die ala NC oder TotalCMD arbeitet. Links die Quelldateien, rechts die Zieldateien - und der Rest geht dann automatisch.


    Bis dahin führt Transwarp - völlig zu Unrecht - das Nischendasein eines irre genialen Proof-of-Concepts :(


    Ich liebe es trotzdem, weil es für sovieles steht, was mich an die gute alte Zeit erinnert und in so vielen Details konsequent umgesetzt ist.

  • Gibt es da irgendwo eine deutsche Beschreibung, Anleitung?

    Ein deutsches Video würde vielleicht auch helfen.

    Ich habe da mal was gemacht, einfach das angehängte Zip herunterladen und entpacken.

    In das entpackte Verzeichnis, dann einfach die PRGs kopieren, die in Transwarp transformiert werden sollen, deren Namen sollten am Besten in Kleinschreibung sein und die Dateinamen nicht zu lang (max. 16 Zeichen).

    Dann einfach die "make.bat"-Datei doppelklicken und schon wird aus jedem PRG im Verzeichnis ein Transwarp.d64


    Ich habe auch ein Beispiel-Prg mit im Archiv, also reicht auch erstmal nur das Doppelklicken auf make.bat um zu sehen, wie aus der PRG eine superschnelle D64 wird.

  • Da handelsübliche IRQ-Loader während des Ladens dekomprimieren, bringen diese Optimierungen auch Geschwindigkeitsvorteile.

    Ja, genau sowas meine ich mit "lohnendes Ziel": Während beim herkömmlichen Lader die Floppy beschäftigt ist, könnte der C64 was sinnvolles tun, z.B. entpacken. Von Interleave 4 auf 3 zu wechseln bringt 25% Speed, bei 4 zu bleiben und zu entpacken bringt 60%. Wenn man dann auf so einem Level ist, dann wird das Protokoll wieder interessanter. Oder die GCR-Dekodierung, die Lft inzwischen in Nullzeit geschafft hat.


    Und ein IRQ-Loader erlaubt bequemer, Ladezeiten zu verstecken. Laden zu können, während Turrican aus dem Bild läuft spart derart viel Zeit, das holt der schnellste Lader nicht raus.

  • Oder die GCR-Dekodierung, die Lft inzwischen in Nullzeit geschafft hat.

    Das ist schon ein Weilchen her, und die Prüfsummierung hat er "vergessen". :)

    Das wurde dann von anderen dazuerfunden, also moderne Loader können on-the-fly GCR dekodieren UND prüfsummieren. =)


    Zum Entpacken fehlt dem Diskettenlaufwerk RAM. Zumindest für Packer, die ein bisschen mehr als RLE oder Huffman können.

    EDIT : Upd, Du meintest den C64, also so wie bisher üblich ...

    Im Laufwerk zu entpacken ergibt auch wenig Sinn, weil der serielle Bus ja der Flaschenhals ist. Da will man normalerweise nur die nötigsten Daten rüberschieben, also am besten in stark komprimierter Form.


    Bei Transwarp dagegen... will man das Programm möglichst unkomprimiert laden und übertragen, da das C-64-seitige Dekomprimieren (nach dem Laden) dann den Geschwindigkeitsvorteil sehr schnell wieder auffrisst.

  • Ich habe da mal was gemacht, einfach das angehängte Zip herunterladen und entpacken.

    In das entpackte Verzeichnis, dann einfach die PRGs kopieren, die in Transwarp transformiert werden sollen, deren Namen sollten am Besten in Kleinschreibung sein und die Dateinamen nicht zu lang (max. 16 Zeichen).

    Dann einfach die "make.bat"-Datei doppelklicken und schon wird aus jedem PRG im Verzeichnis ein Transwarp.d64


    Ich habe auch ein Beispiel-Prg mit im Archiv, also reicht auch erstmal nur das Doppelklicken auf make.bat um zu sehen, wie aus der PRG eine superschnelle D64 wird.


    Prima Sache. Eben ausprobiert, aber leider ist die enthaltene cc1541.exe von Claus, nicht zu meinem 32bit Windows System kompatibel und daran scheitert jetzt das Umwandeln hier. Hab mir vorhin mal die neueste Version von cc1541 von der CSDB heruntergeladen und auch da scheint nur eine exe für 64bit Systeme dabei zu sein.


    Claus , wäre eine 32bit kompatible Version von cc1541 V4.0 machbar? Die alten Versionen des Programms laufen noch bei mir, die neueren irgendwie nicht mehr, da kommt immer "nicht kompatibel zu meinem Windows".

  • Claus , wäre eine 32bit kompatible Version von cc1541 V4.0 machbar? Die alten Versionen des Programms laufen noch bei mir, die neueren irgendwie nicht mehr, da kommt immer "nicht kompatibel zu meinem Windows".

    Ja, leider erlaubt meine Bitbucket Pipeline keine Win32 Binaries mehr und ich habe es nach langen vergeblichen Versuchen aufgegeben, das irgendwie wieder hinzubasteln. Aber weil Du so nett fragst, bau ich Dir heute abend eine Version manuell und häng sie hier an :).

  • Im Laufwerk zu entpacken ergibt auch wenig Sinn, weil der serielle Bus ja der Flaschenhals ist. Da will man normalerweise nur die nötigsten Daten rüberschieben, also am besten in stark komprimierter Form.

    ...Wobei ich Anfang der 90er mal einen interessanten Loader gesehen habe. Die Floppy hat 320 Bytes ASAP geschickt, der 64er hat die während des Empfangs ungefähr in 5er-Pakete zerlegt und hat dann während der Wartezeit decodiert. Müsste Interleave 3 gewesen sein, was ja lange Jahre für Standard-Format nicht zu übertreffen war. Jedenfalls ein sehr origineller Ansatz, wo der Nachteil auf dem Bus mehr als aufgewogen wurde.

  • Im Laufwerk zu entpacken ergibt auch wenig Sinn, weil der serielle Bus ja der Flaschenhals ist. Da will man normalerweise nur die nötigsten Daten rüberschieben, also am besten in stark komprimierter Form.

    ...Wobei ich Anfang der 90er mal einen interessanten Loader gesehen habe. Die Floppy hat 320 Bytes ASAP geschickt, der 64er hat die während des Empfangs ungefähr in 5er-Pakete zerlegt und hat dann während der Wartezeit decodiert. Müsste Interleave 3 gewesen sein, was ja lange Jahre für Standard-Format nicht zu übertreffen war. Jedenfalls ein sehr origineller Ansatz, wo der Nachteil auf dem Bus mehr als aufgewogen wurde.

    Hmm, klingt aber nach genau so einem Fall, bei dem der Interleave eigentlich 2,1 ist und viel Zeit mit warten verbracht wird. :)

    Hat Action-Replay-Fastload (v5 und v6) nicht auch eine Geschwindigkeit von ungefähr 3 Umdrehungen pro Spur?


    Na mal sehen, wo mein Standard-Format-Fastloader (integriert mit Transwarp) dann rauskommen wird.

    Ich habe da noch ein paar Tricks auf Papier gekritzelt, die vielleicht was bringen. =)

  • Claus , wäre eine 32bit kompatible Version von cc1541 V4.0 machbar? Die alten Versionen des Programms laufen noch bei mir, die neueren irgendwie nicht mehr, da kommt immer "nicht kompatibel zu meinem Windows".

    Ja, leider erlaubt meine Bitbucket Pipeline keine Win32 Binaries mehr und ich habe es nach langen vergeblichen Versuchen aufgegeben, das irgendwie wieder hinzubasteln. Aber weil Du so nett fragst, bau ich Dir heute abend eine Version manuell und häng sie hier an :).

    Hier, mit Liebe gebaut :love:. Habs nicht wirklich getestet, aber ich wüsste nicht, warum es nicht gehen sollte...

  • Claus , wäre eine 32bit kompatible Version von cc1541 V4.0 machbar? Die alten Versionen des Programms laufen noch bei mir, die neueren irgendwie nicht mehr, da kommt immer "nicht kompatibel zu meinem Windows".

    Ja, leider erlaubt meine Bitbucket Pipeline keine Win32 Binaries mehr und ich habe es nach langen vergeblichen Versuchen aufgegeben, das irgendwie wieder hinzubasteln. Aber weil Du so nett fragst, bau ich Dir heute abend eine Version manuell und häng sie hier an :).

    Hier, mit Liebe gebaut :love:. Habs nicht wirklich getestet, aber ich wüsste nicht, warum es nicht gehen sollte...

    Ja, funktioniert. Und hier sofort im Bundle mit Transwarp, wie weiter vorne geschrieben, einfach ein paar PRGs in das Verzeichnis kopieren und make.bat doppelklicken:

  • Hier, mit Liebe gebaut :love:. Habs nicht wirklich getestet, aber ich wüsste nicht, warum es nicht gehen sollte...

    Coole Sache, danke für die 32-bit Version. Wie Cap schon schrieb, funktioniert sie auch einwandfrei zusammen mit seinem Schnell-Umwandler. :thumbup: Die 32bit-exe ist ja winzig, im Vergleich zur siebenmal so grossen 64-Bit Version. *lol*

    Die prg-Dateinamen dürfen kein Leerzeichen haben, bei Caps make.bat, fiel mir vorhin noch auf. Nachtrag: Kann man dann eigentlich auch mehrere der umgewandelten prg-Files dann wieder in einem d64 zusammenkopieren und einmal Transwarp hinzufügen und alle werden dann gewarpt, oder darf nur immer eines auf jedem Image sein?


    Und noch eine Frage an CapFuture1975 zu seinem Tool. Ich nehme immer den D64-Editor standardmäßig, wenn ich irgendetwas mit C64-Diskimages machen will und der meldet mir bei jedem dieser umgewandelten Files, im d64 dann immer einige crosslinked Blocks zwischen Transwarp und dem jeweils umgewandelten prg-File. Ist normal, oder?

  • Eigentlich darf man bei den Transwarp-Dateien kein Filecopy machen, wundert mich, dass die Sachen dann überhaupt noch funktionieren.


    Hast recht, geht auch nicht. Da kam ich wohl irgendwie bei den Files durcheinander, mit denen ich hier herumexperimentiert habe. Nochmal nachgestellt, dann merkte ich, dass das nicht funktioniert. Ich besserte es oben gerade noch aus, als ich das merkte, aber dann war schon deine Antwort da. Also muss man für jedes prg dann doch immer ein d64 nehmen.


    Und das mit den crosslinked Blocks ist normal, oder? Das wird wohl genau der Grund sein, warum man dann nicht mehrere Files zusammenkopieren kann, vermute ich, da eine Transwarp Version auf der Disk dann nur für ein prg-File zuständig sein kann.

  • Eigentlich darf man bei den Transwarp-Dateien kein Filecopy machen, wundert mich, dass die Sachen dann überhaupt noch funktionieren.

    Also wenn auf Blocks aus mehreren Dateien verlinkt ist, werden diese Blocks bei Filecopy bestimmt korrekt übernommen in die kopierten Files? Es entsteht dann vielleicht nur Redundanz, weil solche Blocks anschließend mehrmals existieren, nämlich für jede Datei einzeln.



    Edit:

    Hast recht, geht auch nicht. Da kam ich wohl irgendwie bei den Files durcheinander, mit denen ich hier herumexperimentiert habe. Nochmal nachgestellt, dann merkte ich, dass das nicht funktioniert.

    Gut, dann wohl doch nicht. :anonym

  • Gut, dann wohl doch nicht. :anonym

    Hab mir das nochmal genauer angesehen. Das scheitert im D64-Editor schon am Auslagern solch eines umgewandelten prg-Files auf eine andere Disk oder in den Memory, da das File dann auf einmal eine viel kleinere Größe hat



    Keine Ahnung was ich da vorhin gemacht hatte, als ich dachte, es hätte funktioniert?

    Wahrscheinlich von der falschen Disk dann geladen und gedacht, das wäre ein nachträglich umkopiertes File gewesen? *lol*