Hey, keinen Druck ausüben.
"später" ist doch relativ
Aber cool dass du es herausgefunden hast. ![]()
Es gibt 30 Antworten in diesem Thema, welches 7.295 mal aufgerufen wurde. Der letzte Beitrag (
Hey, keinen Druck ausüben.
"später" ist doch relativ
Aber cool dass du es herausgefunden hast. ![]()
Cool Danke!, ist das irgendwie zu patchen?
Cool Danke!, ist das irgendwie zu patchen?
Leider nicht mit vertretbarem Aufwand. Das Problem ist wie folgt:
1.) Meine Vermutung geht dahin, daß der falsch geladene Datensektor die Anfänge der Ladeabschnitte enthält, die den Originaldateien entsprechen, welche zu einer großen Datei zusammengefaßt worden sind. Dieser Sektor ist essentiell für den Scannvorgang. Die Frage ist daher: Wie bekommt man ihn sicher in den Laufwerkspuffer bei $400?
2.) Dazu gibt es zwei Möglichkeiten: a) Man lädt mittels Block-Read diesen Sektor direkt in den Puffer. b) Man überträgt diesen Sektor zusammen mit dem Scanner vom Programm aus ins Laufwerk. (Das hätte eigentlich die erste Wahl sein müssen. Warum das nicht gemacht wurde? Keine Ahnung.)
3.) Sofern man dem Diskettenverzeichnis vertrauen kann, ist die Diskette bereits überbelegt (666 Sektoren), d. h. es wurden schon Sektoren der Verzeichnisspur (Track 18) herangezogen. Trotzdem sollte sich dort noch ein freier Sektor vorfinden, in dem man die Daten für einen B-R (U1) ablegen kann. Das würde jedoch mit dem von Nostalgia gewählten Prinzip brechen, daß die Dateien an sich auf jedem Laufwerk abspielbar sein sollen und der Datenträger folglich keine versteckten Sektoren aufweisen darf. Ansonsten könnte man genauso gut auf das ganze Dateigerümpel verzichten und gleich einen vernünftigen Schnelllader einbauen. Dann bräuchte man auch keinen Scanner mehr. (Wäre meine persönliche Wahl gewesen.)
4.) Bliebe dann nur die zweite Möglichkeit: Das Ladeprogramm muß so gepatcht werden, daß es am Ende neu hinzugefügt den Sektor beinhaltet, der dann mit dem Scanner ins Laufwerk geladen wird. Auch hierfür müßte ein (noch hoffentlich freier) Sektor im Verzeichnistrack herangezogen werden, diesmal jedoch eingebunden in einer Datei und damit übertragbar.
Das wäre vielleicht machbar, aber der Aufwand ist recht hoch.
Hmh schade, scheint n Trackloader zu sein und ausgerechnet einer der wenigen N0S-Releases, bei denen man nicht die Option KERNAL Load hat.
Das liegt daran, daß Kernal-Lader nun einmal keine IRQs erlauben, also keine Musik, Splitscreens etc. (Nebenbei: Der Unterschied zwischen einem Trackloader und einem Sektorloader besteht darin, daß bei einem Trackloader nicht nur ein einzelner Sektor übertragen wird, sondern gleich der ganze Track. Dieses Verfahren gibt es hardwarebedingt standardmäßig auf dem Amiga. Auf dem C64 findet man es nur sehr selten, da hierfür ein entsprechend großer freier Platz (21 Sektoren = $1500 Bytes) zur Aufnahme des Tracks im Arbeitsspeicher des C64 bereitgestellt werden muß. "Most Access" von Oliver Stiller ist solch ein Fall.)
Naja, der Vorteil an diesem "Dateigerümpel" ist ja u.a., dass es keine nur teilweise genutzen Sektoren mehr gibt, sonst hätte das vmtl. nicht auf eine Seite gepasst. Man könnte aufn 40-Track Image ausweichen, was aber auch der Filecopybarkeit nicht unbedingt zugute kommt.
Edit: ich seh grad 57 Blocks allein für die Anleitung, wie man das spielt dürfte eigentlich jeder wissen, also Platz ist Prinzip genug da. ![]()
InsertDisk2: Hast du zufällig irgendwas Easyflashartiges am C64 angeschlossen? Dann könntest du alternativ die Bitte melde dich an, um diesen Link zu sehen. zum Spielen nehmen.
Naja, der Vorteil an diesem "Dateigerümpel" ist ja u.a., dass es keine nur teilweise genutzen Sektoren mehr gibt, sonst hätte das vmtl. nicht auf eine Seite gepasst.
Äh.. Sorry.. Das habe ich nicht ganz verstanden.
Läßt man das Dateisystem weg. ändert man ja an der inneren Dateistruktur nichts.
Im Gegenteil werden durch Weglassen der Sektorenlink-Bytes sogar ganze 577 * 2 = 1154 Bytes, also mehr als ein ganzes KB eingespart. (Wow!
) Und paßt man den Sektor-Interleave an die Ladergeschwindigkeit an, erhält man auch recht brauchbare Diskettenzugriffszeiten.
also Platz ist Prinzip genug da.
![]()
Na denn, Freiwillige vor.
Hast du zufällig irgendwas Easyflashartiges am C64 angeschlossen?
Das wäre dann wohl die bessere Lösung. ![]()
Äh.. Sorry.. Das habe ich nicht ganz verstanden.
Läßt man das Dateisystem weg. ändert man ja an der inneren Dateistruktur nichts.
Im Gegenteil werden durch Weglassen der Sektorenlink-Bytes sogar ganze 577 * 2 = 1154 Bytes, also mehr als ein ganzes KB eingespart.
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.
Und es ist mit nem Filecopier kopierbar1elf
Naja, der Vorteil an diesem "Dateigerümpel" ist ja u.a., dass es keine nur teilweise genutzen Sektoren mehr gibt, sonst hätte das vmtl. nicht auf eine Seite gepasst. Man könnte aufn 40-Track Image ausweichen, was aber auch der Filecopybarkeit nicht unbedingt zugute kommt.
[...]
InsertDisk2: Hast du zufällig irgendwas Easyflashartiges am C64 angeschlossen? Dann könntest du alternativ die Bitte melde dich an, um diesen Link zu sehen. zum Spielen nehmen.
An dem 40 Tracks "Problem" sitze ich auch gerade..
Hintergrund der ganzen Aktion ist meine Idee dies hier zu realisieren:
Bitte melde dich an, um diesen Link zu sehen.
Alle Games sollen, um den max speed zu erhalten, (s)-jiffy gesaved sein. In der Tat passt bei Filecopy das Game nicht komplett auf die Disk, wenn man Track 18 unangetastet lässt.
Mit 40 Tracks würde es funktionieren, jedoch was machen die Leute die kein Betriebssystem mit 40 Tracks haben, in dem Fall kein s-jiffy?
Das nächste Problem ist, wie bekomme ich die Sachen dann auf ne .d64 um das ganze, mit 40 Tracks, in die Wolke zu laden.
Ich habe nur die 1541UII, ist die Easyfslash kompatibel? Ich glaube nicht, oder?
ist das irgendwie zu patchen
Das kann man kaum noch Patch nennen, das ist schon ziemlich aufwändiges Re-Cracking
Leider nicht mit vertretbarem Aufwand.
Sehe ich auch so, wer will sich das antun, nur weil 3 User mit ihren Spooky Settings Wünschen das wollen?
Platz ist Prinzip genug da
Platz ist in der kleinsten Hütte
Na denn, Freiwillige vor.
*tritt 10 Schritte zurück und rennt "CLAUDE!!!" rufend davon*
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. ![]()
Öhm. nein. Mit einem normalen Filekopierer ist die Diskette auch schon nicht mehr kopierbar, weil der Verzeichnistrack angeknabbert wurde.
Ja ok, in diesem Fall nicht, aber "im Prinzip"[tm] ist das die Absicht.
Oder man kopiert es auf eine 1581, manche Leute wollen sowas ja immer unbedingt, warum auch immer. ![]()
im notfall muss der sauhund hier mal wieder ranhalten! - aber der ist ja falsch abgebogen ![]()