Transwarp Release

Quote from AW182

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.

"Crosslinked" ist normal, aber man kann via cc1541 natürlich auch mehrere Transwarp-Dateien auf einer Disk haben, bis sie voll ist, mit genau einem Transwarp-Loader.

Dabei zeigen die "normalen" T/S-Links in den Directory-Einträgen der Transwarp-Dateien alle auf diesen Booter ("crosslinked"), aber der findet dann beim Laden via ,8,1 schon raus, welche Datei man "eigentlich" laden wollte, und lädt die dann (Transwarp-Dateien haben noch ein paar Metadaten-Bytes mehr in der Directory).

Theoretisch ist es natürlich möglich, einen Transwarp-Filecopier zu erfinden, aber praktisch eigentlich auch nicht notwendig in Zeiten von Crossdev.

(Transwarp-Dateien selbst haben keine T/S-Blocklinks von einem Dateiblock zum nächsten, da verschlucken sich dann DOS-konforme Dateikopierer dran.)

Okay, dann ist das klar soweit. Cooler Loader auf jedenfall. Schon erstaunlich, wenn man sich das alles vorstellt. Ganz früher wartete man zweieinhalb Minuten, bis mal ein wirklich grosser Onefiler von Disk geladen war. Dann kamen so Sachen wie Fastdisk oder Hypraload und es ging schonmal mindestens fünfmal so schnell. Dann Module wie FC3 oder AR6 und es ging schon 10 bis 15 mal so schnell. Jetzt hat man ProfDOS, DolphinDOS, Mafiosino, Transwarp usw und man ist mit maximal 5 Sekunden Ladezeit dabei, bei einem 200 Block grossen Onefiler auf einem Diskimage.

Was sich da getan hat, ist schon unglaublich. Das ist fast schon Instant-Loading, wie von Modul und das Witzige ist, wenn ich im Denise, bei einem Disk-Nachladespiel welches eh schon einen game-internen Fastloader besitzt, auch noch einen AutoWarp für's Nachladen aktiviere, dann lädt diese Diskversion schneller als deren Cartridge-Versionen. Hab ich neulich erst mit "Puzzle Bobble" und "Knights & Slimes" ausprobiert und deren Modul- mit den Disk-Versionen samt AutoWarp verglichen, was Ladezeiten angeht. "Transwarp + AutoWarp" multipliziert sich ja dann und ist quasi so etwas wie 500fach Ladespeed dann, auf meinem schon älteren PC. Auf aktuellen PC's dann noch mehr, weil die noch höheren Warp-Speed schaffen. *lol* Aber klar, in Sekunden sind die Unterschiede dann natürlich nicht mehr wirklich gross, weil die Ladezeiten jetzt dann eh schon sehr kurz sind. Interessant ist es aber dennoch.

Quote from AW182

Die 32bit-exe ist ja winzig, im Vergleich zur siebenmal so grossen 64-Bit Version. *lol*

Das liegt aber vor allem an Visual Studio, das viel kleinere Binaries erzeugt als der gcc, den ich in meiner Bitbucket-Pipeline habe und normalerweise für cc1541 verwende.

Quote from Claus

Quote from AW182

Die 32bit-exe ist ja winzig, im Vergleich zur siebenmal so grossen 64-Bit Version. *lol*

Das liegt aber vor allem an Visual Studio, das viel kleinere Binaries erzeugt als der gcc, den ich in meiner Bitbucket-Pipeline habe und normalerweise für cc1541 verwende.

Es gibt auch ältere Versionen von Visual Studio zum kostenlosen Download, von denen bestimmt eines auf dem antiken Windows von AW182 läuft.

Quote from Claus

Das liegt aber vor allem an Visual Studio, das viel kleinere Binaries erzeugt als der gcc, den ich in meiner Bitbucket-Pipeline habe und normalerweise für cc1541 verwende.

Das liegt aber vor allem daran, dass du das mingw-Binary mit Debug-Symbolen auslieferst und das von Visual Studio erzeugte vermutlich nicht. Eine Behandlung mit strip lässt die cc1541.exe aus Release 4.0 von 582.400 auf 141.824 Byte schrumpfen.

Quote from Unseen

Das liegt aber vor allem daran, dass du das mingw-Binary mit Debug-Symbolen auslieferst und das von Visual Studio erzeugte vermutlich nicht. Eine Behandlung mit strip lässt die cc1541.exe aus Release 4.0 von 582.400 auf 141.824 Byte schrumpfen.

Huch, das ist nicht beabsichtigt. Seufz, ich werde wohl die Build Pipeline doch noch einmal anschauen

Quote from Claus

Quote from Unseen

Das liegt aber vor allem daran, dass du das mingw-Binary mit Debug-Symbolen auslieferst und das von Visual Studio erzeugte vermutlich nicht. Eine Behandlung mit strip lässt die cc1541.exe aus Release 4.0 von 582.400 auf 141.824 Byte schrumpfen.

Huch, das ist nicht beabsichtigt. Seufz, ich werde wohl die Build Pipeline doch noch einmal anschauen

Immer noch ganz schön weit weg von 35 kB. Wird mit "-Os" o.ä. für Size-Optimierung gebaut? Und die Runtime dynamisch gelinkt? (Alles eine rein akademische Übung, natürlich, der Unterschied tut ja nicht weh.)

Quote from Krill

Und die Runtime dynamisch gelinkt? (Alles eine rein akademische Übung, natürlich, der Unterschied tut ja nicht weh.)

Das ist genau die Sache - die Visual C++ Runtimes haben viele sowieso installiert, die MingW-Runtimes tendentiell seltener. Da dynamisch zu linken, klappt das wirklich in der Praxis so gut?

Quote from Krill

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?

Ist anzunehmen. Mit erst Sektor lesen, dann übertragen sind die 3 Umdrehungen wohl nicht zu knacken. Irgendwie Schade, dass Parallelkabel nie Standard geworden sind.

Mal ein abwegiger Gedanke:
Die 1541 war ja für SD-Disketten. Könnte sie bei DD-Disketten mit 150 Umdrehungen laufen?
Und ließe sich die Drehzahl mit PWM steuern?

Quote from Hoogo

Die 1541 war ja für SD-Disketten. Könnte sie bei DD-Disketten mit 150 Umdrehungen laufen?

Sind überhaupt SD und DD von der reinen Fluxrate auf der Diskette verschieden?

Soweit ich weiß, erreicht DD die höhere Rate eigentlich durch Verwendung von MFM statt von FM. Und nicht dadurch, dass die Fluxabstände kürzer wären.

Quote from Hoogo

Mit erst Sektor lesen, dann übertragen sind die 3 Umdrehungen wohl nicht zu knacken. Irgendwie Schade, dass Parallelkabel nie Standard geworden sind.

Ja, dieser Ansatz ist vermutlich schon längst ausgereizt.

Mir schwebt was mit On-the-fly-Übertragung vor, in 2 Umdrehungen, mit On-the-fly-Dekodierung und -Prüfsummierung während der Übertragung.

Recht ähnlich zum Ansatz von Mafiosino, aber in vielen Details anders.

Die Hoffnung ist, dass es am Ende deutlich weniger Zeit beim "Housekeeping" während des Spurwechsels braucht und vielleicht irgendwo bei 30x rauskommt.

Quote from Hoogo

Mal ein abwegiger Gedanke:
Die 1541 war ja für SD-Disketten. Könnte sie bei DD-Disketten mit 150 Umdrehungen laufen?
Und ließe sich die Drehzahl mit PWM steuern?

Unklar. Ich würde massiven Wobble erwarten, bei dem, abhängig vom Laufwerksexemplar und Mondstand, schlechtes bis sehr schlechtes Signal am Lesekopf ankommt.

Quote from markusC64

Soweit ich weiß, erreicht DD die höhere Rate eigentlich durch Verwendung von MFM statt von FM. Und nicht dadurch, dass die Fluxabstände kürzer wären.

Ist das nicht dasselbe? MFM hat eine viel höhere Fluxrate und im Prinzip ein Füllbit pro Nutzbit. Wenn dann am Ende eine höhere Kapazität rauskommt, müssen die Bitcells zwangsläufig viel kleiner sein.

Quote from Krill

MFM hat eine viel höhere Fluxrate

Ne, eben nicht. Gegenüber von FM spart man ein Clockbit zweischen zwei Einsen, die an Nutzdaten geschri werden, ein. Bie Fluxrate sinkt also bei gleicher Datenrate.

Um das, was das Medium hergibt, auszunutzen, erhöhe man die Datenrate. So dass man bei gleicher Fluxrate landet.

Was hei0t: Die Disketten dürften AFAIK da keinen Unterschied haben. Wegen der Vorformatiierung, die üblich würde, machte es dennoch Sinn, das DD anzugeben.

Quote from markusC64

Gegenüber von FM spart man ein Clockbit zweischen zwei Einsen, die an Nutzdaten geschri werden, ein. Bie Fluxrate sinkt also bei gleicher Datenrate.

Ich meinte gegenüber GCR, nicht FM.

Jedenfalls gibt es viele Behauptungen, dass herkömmliche SD-(bzw. eher DD)-Disketten (also die, die wir in der 1541 nutzen) auch zuverlässig mit der SFD-1001 benutzt werden konnten, und das sind ja ca. 500 KB pro Seite.

Quote from Krill

bei dem, abhängig vom Laufwerksexemplar und Mondstand, schlechtes bis sehr schlechtes Signal am Lesekopf ankommt

Wäre das Signal nicht schon wegen der geringeren Drehzahl schlechter weil der Flusswechsel langsamer am Kopf vorbeizieht und damit die induzierte Spannung kleiner ist?

Quote from Krill

Ich meinte gegenüber GCR, nicht FM.

Jedenfalls gibt es viele Behauptungen, dass herkömmliche SD-(bzw. eher DD)-Disketten (also die, die wir in der 1541 nutzen) auch zuverlässig mit der SFD-1001 benutzt werden konnten, und das sind ja ca. 500 KB pro Seite.

Hm, GCR hat alle 3,25 bis 4µs einen Flux bei einer 1541, je nach Speedzone (beim Sync, wenn Nullen hinzukommen, ist der Abstand natürlich größer). Wenn man sicher sein will, dass der Datenträger das mitmacht, muss man jedoch nach den minimalen Abstand fragen, und der ist bei GCR beim Sync, auch wenn er woanders auch angenommen wird.,

MFM hat bei DD eine Bitcellsize von 2µs, da aber garantiert ist, dass keine zwei Einsen aufeinanderfolgen, ist der minimale Fluxabstand 4µs. [Edit: 6µs und 8µs sind weitere vorkommende Werte]

Daher schreibt GCR die Daten sogar mit kürzeren Fluxabstand auf die Diskette.

Prinzipiell kann die Diskette aber noch mehr, eine SFD-1001 hat Fluxabstände 8/3, 5/2, 7/3, 13/6 bei ansonsten gleichen Aufzeichnungsverfahren. Dadurch passen natürlich mehr Sektoren auf die Tracks.

Quote from 1Byte

Lassen sich diese Transwarp-D64 Files auch wieder auf Disk zurück spielen und zwar so das sie den Transwarp-Speed beibehalten oder muß ich Disk vorher vorbereiten ?

Keinerlei Spezialbehandlung notwendig.

Das sind ganz normale D64-Images. Man kann sie mit allen üblichen Disktransfer- und Kopierlösungen auf echte Disketten spielen oder von echten Disketten Images erstellen, ohne irgendeine Beeinträchtigung der Transwarp-Funktionalität.

(Volle D64-Kompatibilität war eines der wichtigsten Designkriterien. Niemand will G64 und Co. auf echte Diskette zurückschreiben.)

Edit: Das Format könnte eine kleine Rolle spielen. Bei Standard-Slowformat vor dem Schreiben sind im Allgemeinen weniger Beeinträchtigungen zu erwarten als bei Fastformattern, welche häufig kein sehr schönes Blocklayout produzieren.

Grundsätzlich aber dürfte Transwarp mit krummen Fastformat-Spuren klarkommen, aber womöglich mehr Retrys und Slowdowns vermelden.

Quote from markusC64

Hm, GCR hat alle 3,25 bis 4µs einen Flux bei einer 1541

[...]

MFM hat bei DD eine Bitcellsize von 2µs, da aber garantiert ist, dass keine zwei Einsen aufeinanderfolgen, ist der minimale Fluxabstand 4µs. [Edit: 6µs und 8µs sind weitere vorkommende Werte]

Daher schreibt GCR die Daten sogar mit kürzeren Fluxabstand auf die Diskette.

Okay, dann wundert mich das hier noch mehr, als es vorher schon tat.

Warum geht auf dem Amiga GCR nur mit halber Kraft?