Nimm mal an du hast 20 Files, die im jeweils letzten Sektor nur 1 Byte belegen, dann hast du 20*253 = 5060 Bytes verschwendet, wenn du die auf herkömmliche Art speicherst. Diese IFFL-Dinger quetschen das üblicherweise so in ein File zusammen, dass bis auf den letzten Sektor alles voll ausgenutzt wird. Ok, n paar Byte gehen dann wieder dafür drauf, wo in welchem Sektor man was von welchem File findet, aber u.U. macht das schon Sinn.
Schon klar.
"Die drei Musketiere" funktioniert auch nach diesem Prinzip, sonst hätten die Daten nicht auf drei Disketten gepaßt. Im konkreten Fall liegt aber bereits eine große 577 Sektoren lange Datei vor. Es ging mir darum, zwecks schnellem Zugriff und ohne Scanner diese direkt ohne Dateisystem in Diskettensektoren abzulegen. Wozu IFFL, wenn man es viel einfacher haben kann? Das Dateisystem ist eh nicht das beste, besonders das sequentielle Lesen drückt die Geschwindigkeit. Bei einem direkten Sektorenlesen könnte man zumindest einen partiellen Trackloader verwenden. Dabei wird ein gefundener Sektor überprüft, ob er zur Datei gehört, und falls ja übertragen. Dadurch erhält man gleich drei große Vorteile: 1.) Das Lesen wird massiv beschleunigt. 2.) Man benötigt kein spezielles Interleave mehr. 3.) Der Lader paßt sich dynamisch an die Ladegeschwindigkeit des C64 an. Werden dort z. B. umfangreiche Aktionen im IRQ abgewickelt, wird die Ladegeschwindigkeit nur minimal verzögert und bricht nicht gleich komplett ein.
Und es ist mit nem Filecopier kopierbar1elf
Öhm. nein.
Mit einem normalen Filekopierer ist die Diskette auch schon nicht mehr kopierbar, weil der Verzeichnistrack angeknabbert wurde.
Hintergrund der ganzen Aktion ist meine Idee dies hier zu realisieren:
IFFL und Jiffy schließen sich (soweit ich weiß) aus. IFFL benötigt beschleunigten Zugriff auf einzelne Sektoren der Diskette. Die LOAD-Routine von Jiffy kommt hierbei nicht zum Einsatz. Wenn überhaupt, müßte in Jiffy ebenfalls eine beschleunigte Version von Block-Read eingebaut sein, das wäre dann aber nicht mehr kompatibel zu anderen Systemen. Kurz gesagt: Geht nicht.
Alle Games sollen, um den max speed zu erhalten, (s)-jiffy gesaved sein.
Und hier hätten wir das nächste Problem. Ich gehe mal davon aus, daß S-Jiffy zur Beschleunigung des Ladevorgangs einen speziell angepaßten Interleave einsetzt. Da aber die Version von "Defender of the Crown" nicht auf S-Jiffy zurückgreift, sondern einen eigenen Lader verwendet zusammen mit Musikroutinen im IRQ, könnte dies dazu führen, daß der Sektorenabstand zu kurz ist für den Lader und die Sektoren nicht mehr wie gewollt direkt nacheinander gefunden werden. Stattdessen müßte die Leseroutine eine ganze Rotation warten, um den nächsten Sektor aufzuspüren, was drastische Einbußen bei der Ladegeschwindigkeit zur Folge hätte.
Das gleiche passiert übrigens auch, wenn die Sektorenaufteilung einer IFFL-Diskette an den eingebauten Lader angepaßt wurde, aber dann bei einem simplen Filekopierer dieses Interleave nicht mitkopiert wird. Auch dann geht die Ladegeschwindigkeit ruckzuck flöten. Auf realer Hardware reicht es eben nicht aus, nur die Daten an sich zu kopieren, sondern auch das Aufzeichnungssystem muß mit übernommen werden, und das gelingt nur mit einem Diskettenkopierer. Filekopieren lohnt sich eigentlich nur bei moderner(er) Hardware, aber nicht bei der 1541.
Zusammengefaßt: Wie man es dreht und wendet, steht man beim C64 am Ende immer vor dem gleichen Dilemma:
Entweder
a) entwickelt man Programme so, daß sie mit Kernal-Load laden und dadurch mit gewisser moderner Hardware kompatibel sind. aber verzichtet dabei während des Ladens auf IRQs etc
oder
b) man verwendet schnelle Lader, die kompatibel sind mit der Originalhardware und gleichzeitig IRQs erlauben etc, aber dafür mit gewisser moderner Hardware nicht zusammenspielen.
Leider ist dieser Konflikt nicht einfach bzw. billig zu lösen. Wofür man sich letztendlich entscheidet, ist Geschmackssache. Mich erstaunt in dieser Hinsicht allerdings schon, daß große Teile der Retroszene wiederholt für die Verwendung dieser gewissen modernen Hardware plädieren, aber in anderen Hardwarefragen (bzgl. CPU, RAM, SID...) immer gerne davon sprechen, daß dies dann nicht mehr C64-like sei. ![]()