cc1541 Batchdatei zum Masseneinfügen in D64-Images

Zitat von Claus

Genau aus dem Grund wollte ich es eigentlich nicht prüfen, denn wenn es nur als Schreibschutz missbraucht würde, könnte man es ja ignorieren. Oder meinst Du, dass es aus gutem Grund als Schreibschutz verwendet wurde (eben weil es ein nicht-DOS-Format ist)?

Ich würde selbst bei einer zu 100% DOS-konformen Disk annehmen, dass, wer auch immer den Schreibschutz aufgebracht hat, dafür einen Grund hatte.
Diesen Schutz zu ignorieren, kann man ja wiederum per CLI-Switch ermöglichen, aber Default sollte das nicht sein, IMHO.

Meine Meinung ist, dass man bei allen irgendwie zweifelhaften Diskformaten die sich identifizieren lassen, also etwa die ganzen genannten, dann diese d64-Files so belassen sollte und dort besser nichts hineinkopiert. Ich verstehe hier allerdings die Problematik, dass das Tool hierbei vielleicht nicht alle solchen Fälle einwandfrei identifizieren kann. Deshalb wenn auch nur der geringste Zweifel besteht, das File so belassen. Wenn keine Identifikation möglich, dann ist es natürlich problematisch.

Aber in meiner konkreten Anwendung wofür ich dieses Batch-Skript bräuchte, sieht es sowieso bei über 95% der Diskimages so aus, dass deren Directories normal gelistet werden können, sie also wahrscheinlich normale DOS-Directorys sind, denn es sind ja in meinem Fall hier, alles getestete Diskimages die am SD2IEC laufen. Denn ich will den SD2BRWSE Filebrowser auf jede Disk der SD-Karte kopieren, da mein SD2IEC beim Reset nicht in die Root-Directory geht und ich immer sofort den Browser griffbereit haben will, wenn möglich.

Nun ist der Filebrowser von mir schon in alle Unterordner hineinkopiert worden, die auf der SD-Karte existieren (was schonmal hunderte sind) und auch in die wichtigsten Diskimages hab ich ihn schon vor einiger Zeit reinkopiert per Hand. Da ich nun aber noch jede Menge neue Files von "CommFor's" Disk-Archiv mit auf die SD-Karte kopiert habe, wollte ich mir das händische Hineinkopieren hier sparen und daher die Frage noch solch einem Tool was dies automatisiert erledigen kann.

Also da es ja, wie schon erwähnt, alles getestete Diskfiles für's SD2IEC sind, heisst dies schonmal, daß seltsame Fastloader-Formate oder auch viele Sonderformate auf diesen Diskimages eh schonmal ausgeschlossen sind, da solche Files sowieso erst gar nicht am SD2IEC laufen würden. Ich hab mal einen Blick in einige der Files geworfen, die grosse Mehrheit sind definitiv DOS-Directorys, die auch voll listbar sind. Nur ein paar wenige Ausnahmen sind darunter, wie eben scheinbar diese Leveldisks des Spiels "MicroLeague Baseball", bei denen der D64-Editor eben diese "Error-Info" meldet, solange sie unverändert sind und danach dann nicht mehr.

Konnte denn dieses Diskformat der "MicroLeague Baseball" Disketten identifiziert werden, ist es ein Sonderformat, beziehungsweise muss dort dieser Error auf den Disks, den der D64-Editor meldet, zwangsläufig vorhanden sein, damit diese Leveldisk dann im Spiel funktioniert? Wird man ohne es zu testen wahrscheinlich nicht sagen können, nehme ich an? Und dieses Spiel kenne ich so gut wie kaum, da kann ich es auch nicht richtig testen, ohne erstmal das Game richtig lernen zu müssen, was schonmal mit den Baseball Regeln losgeht, bei denen ich mich nicht richtig auskenne, weil sie mich nie interessiert haben. *lol*

Zitat von Claus

Ganz so einfach ist es leider nicht. Generell gibt es zwei Möglichkeiten, auf Disketten zuzugreifen: mit den DOS-Routinen (also letztlich mit LOAD, INPUT# etc.), oder indem man direkt Sektoren auf der Diskette anspricht. Letzteres ist zunächst mal unabhängig von Fastloadern und wird auch vom sd2iec vollumfänglich unterstützt.
Eine Software, die per direktem Sektonzugriff arbeitet, hat aber typischerweise trotzdem mindestens ein File im DOS-Format, damit man sie überhaupt mit LOAD starten kann. In dem Fall hat man eine Mischung aus einem korrekten Directory (das auch normal gelistet werden kann) und zusätzlichen Daten, die irgendwie auf der Diskette stehen. Und genau dieser Fall ist schwierig sicher zu identifizieren.

Okay, dann verhält sich das doch komplexer als ich zunächst dachte. Dann sollte man zumindest all diejenigen Files ausschließen, welche sich identifizieren lassen. Wenn dann, wie du sagst, einige wenige Formate, die sicher auch nur selten vorkommen, dabei sind bei denen das nicht geht, dann ist das eben so. Man sollte ja eh immer eine Sicherheitskopie der d64-Images vorher machen und stellt man dann irgendwann später fest, dass eine Diskette auf die das File kopiert wurde nun nicht mehr richtig läuft, dann kann man ja diese eine Diskette wieder mit der von der Sicherheitskopie ersetzen. Wenn so etwas dann bei, aus der Luft gegriffen, 20 Disketten von 1000 der Fall ist, dann ist das durchaus verkraftbar. Immernoch besser, als per Hand in 1000 Disketten das File manuell einfügen zu müssen.

Zitat von Claus

Ich bastele gerade noch an den finalen Features für die neue Version (Unterstützung für andere Dateitypen als PRG), dann veröffentliche ich sie.

Cool. Bin schon gespannt darauf, das dann auszuprobieren.

Tolle Sache. Gerade runtergeladen. Dann muss man nun keine Angst mehr haben, dass bestimmte d64-Formate denen das Hinzufügen einer weiteren neuen Datei schaden würde, ruiniert werden können?

Werde ich ausprobieren in den nächsten Tagen. Da kommt dann der SD2BRWSE Filebrowser auf hunderte d64 Images mit drauf, für die bequeme Nutzung mit meinem SD2IEC samt FC3 Modul. Mein SD2IEC geht nach einem Reset nicht in die ROOT Directory zurück sondern bleibt immer im vorher geöffneten Image. Ja ich weiß, könnte man hardwaremäßig ändern, aber ich will da jetzt nicht nochmal ran, bzw das Ding auch gar nicht mehr aufmachen, da verklebt. Nur im absoluten Notfall mach ich das.

Zitat von Claus

Exakt! Der Check ist relativ paranoid, also wenn ein Image den Check besteht, kann m.E. wirklich beim besten Willen nichts schiefgehen.

Super! Werde ich testen irgendwann die nächsten Tage.

"CLAUS", ein paar Fragen noch zur Sicherheit, bevor ich den Prozess mit dem automatisiertem Hineinkopieren in Hunderte Disks hier starte:

(1) wenn sich auf den Disketten bereits ein File befindet, welches den gleichen Namen hat wie das, was ich dort automatisiert hineinkopieren will, dann wird nicht in solch ein d64-File hineinkopiert, richtig? Denn sonst würde man ja Programme ruinieren die das File gleichen Namens welches schon auf der Disk war, irgendwann mal zum nachladen brauchen.

(1-b) dabei spielt es dann auch keine Rolle, ob das File gleichen Namens, welches sich bereits auf dem d64 befand, vom Inhalt her anders ist als das hineinzukopierende (und nur der Name gleich ist) oder ob es auch vom Inhalt her genau das gleiche File ist. Könnte ja auch sein, dass genau dieses File (also in meinem Fall der Filebrowser) schon auf einer der Disketten drauf ist. Also ganz genau das gleiche File samt gleichen Namens. Hier wäre es dann zwar nicht so schlimm, wenn das gleiche File nochmals drüberkopiert wird, aber ich nehme an, auch hier wird dann nicht hineinkopiert, weil es ja auch keinen Sinn machen würde? Ausserdem checkt das Tool ja auch den Inhalt eines Files gar nicht ab, sondern nur dessen Namen, stimmt's?

(1-c) ist auf einem d64 bereits das gleiche File drauf, als das welches ich nun hineinkopieren will, aber hat es dort am Image einen ANDEREN NAMEN, dann bemerkt dein Tool dies natürlich nicht und kopiert das neue File auch noch mit hinein, richtig? Das Tool checkt ja nicht jedesmal den Inhalt aller sich auf der Disk schon befindlichen Files ab und merkt somit dann nicht, dass genau dieser Filebrowser schonmal drauf ist wenn er einen ANDEREN Namen hat. Richtig?

(2) was genau passiert nun, wenn nicht mehr genug Platz in einem der d64 frei ist, um das nun hineinzukopierende File komplett aufzunehmen? Wird dann gar nicht erst versucht, das File dort hineinzukopieren (was ja eigentlich das Beste wäre), oder versucht es das Programm dann trotzdem und bricht erst dann ab, wenn das d64 voll ist und 0 Blocks dort frei sind? Was nicht so toll wäre, denn dann würden sich ja Teile des hineinzukopierenden Files nun auf dieser Disk befinden und es wären dann unter Umständen bei d64-Files bei denen vorher beispielsweise 4 Blocks frei waren, jetzt dann nur noch 0 Blocks frei. Dies könnte eventuell, wenn es blöd kommt, dann auch bei einigen d64-Files ein Problem verursachen. Aber ich gehe mal davon aus, das Tool versucht dann erst gar nicht, in ein d64 reinzukopieren, wenn es vorher abgecheckt hat, dass dessen freier Platz eh nicht ausreicht um das hineinzukopierende File komplett aufnehmen zu können. Korrekt?

Die Sätze klingen bisschen verwirrend, aber wie soll man das sonst ausdrücken? *lol* Das meiste davon wurde zwar im Threadverlauf schonmal besprochen, aber ich frage doch lieber vorher nochmal nach zur Sicherheit, bevor hier der automatisierte Massen-Hineinkopier-Prozess gestartet wird.

Zitat von AW182

ein paar Fragen noch zur Sicherheit, bevor ich den Prozess mit dem automatisiertem Hineinkopieren in Hunderte Disks hier starte

[...]

aber ich frage doch lieber vorher nochmal nach zur Sicherheit, bevor hier der automatisierte Massen-Hineinkopier-Prozess gestartet wird

Mach halt ein Backup vorher, oder besser zwei und eines außerhalb des Systems ablegen.

Ich befasse mich jetzt auch mal damit, weil ich es im Zusammenhang mit dem C64-Studio benutzen möchte.

Wenn man nur cc1541 eingibt, bekommt man die Erklärung der Schalter. Allerdings verstehe ich da auch noch nicht alles. Ob oder wie man bspw. ein File auf Disk renamen kann.

Ich mache das dann immer so, dass ich mit einer Testdisk herumfummele und die Schalter ausprobiere, nach dem Prinzip Try-and-Errror, bis ich das wichtigste hab und es das macht, was ich brauche.

Danke. Das reicht so völlig aus. Beim MediaManger vom Studio musste ich das File auch löschen und mit "-renameto" neu importieren.

Das eigentliche Problem damit war aber, dass man die vorgegebenen Variablen des Studios, wie z.B. $(Filename), nicht benutzen kann, wenn deren Zeichenketten Kleinbuchstaben enthalten, denn die werden dann als Grafikzeichen (bzw. als Großbuchstaben im anderen Zeichensatz) eingetragen, und nur Großbuchstaben werden normal eingetragen, also für meinen Geschmack falsch herum. Ich gehe jetzt mal davon aus, dass cc1541 eine Datei namens "programm.prg" als "PROGRAMM" für den Groß/Grafik-Zeichensatz bzw. als "programm" für den Klein/Groß-Zeichensatz speichert.

Zitat von atomcode

Mach halt ein Backup vorher, oder besser zwei und eines außerhalb des Systems ablegen.

Sowieso. Das mache ich sowieso und ist schon alles zweimal kopiert. Ich hab eh immer alles doppelt und dreifach gesichert und nochmal auf DVD's gebrannt undsoweiter. Dennoch interessierten mich die Antworten von CLAUS noch, bevor ich das Ganze starte. Heute abend gehts dann los, drüben auf meinem zweiten PC.

Zitat von Claus

Im Moment würde ein File gleichen Namens überschrieben. Das lässt sich aber ändern, indem man im Batchfile die Zeile

Code

1. %cc1541% -V -t -f "%name%" -w "%prg%" "%%i" > NUL

ändert in:

Code

1. %cc1541% -V -o -t -f "%name%" -w "%prg%" "%%i" > NUL

Der -o Switch verhindert das Überschreiben existierender Files. Ist halt Geschmackssache, ob man lieber überall die neueste Version des Programms draufkopieren will, oder eher Sorge hat, dass es andere Files mit gleichem Namen gibt.

Das ist gut zu wissen, denn das hineinzukopierende File, sprich der Filebrowser heisst auf der gesamten SD2IEC SD-Karte immer "00" und da ist die Gefahr natürlich recht gross, dass sich schon Files mit solch einem Namen auf einigen der d64 Images befinden, etwa als Teile von Nachlade-Spielen. Also ändere ich diese Zeile im Batchfile mit "Ultra-Edit" nachher so ab, wie du geschrieben hast.

So "CLAUS", bin fertig. Das Ganze lief durch und dein Tool scheint wirklich sehr vorsichtig zu sein. Das hineinzukopierende File, also der Filebrowser, wurde 'nur' in 58,31% der Disketten kopiert, genauer gesagt in 1456 von 2497 d64-Images. Liegt aber wohl auch mit daran, dass ich bei einigen der d64-Files schon vorher wusste, dass der Filebrowser mit dem Namen "00" dort früher schonmal manuell reinkopiert wurde. Schätze mal, dies war bestimmt bei circa 300 bis 400 Files so schon der Fall.

Siehe hier, der Screenshot:

Es wurden jetzt soviele Disks gemeldet, in die das File nicht hineinkopiert wird, dass man die gar nicht mehr alle durchlisten kann im DOS-Fenster. Logfile legt das Programm keines an, oder? Zumindest sehe ich nirgends eines im Ordner. Wäre aber vielleicht keine schlechte Idee sowas, oder was meinst du? Dann hätte man das einmal auf einem Dokument und nicht nur im DOS-Fenster, wo es nach dem Schließen ja dann weg ist.

Aber auch wenn jetzt nur in knapp über die Hälfte der Files das Tool hineinkopiert wurde, ist es ja gut, dass dein Tool so vorsichtig ist und in alle, auch nur im Ansatz zweifelhafte d64-Images, gar nicht erst hineinkopiert. Dieser automatisierte Kopierprozess lohnt sich aber auf jeden Fall, vor allem natürlich bei der grossen Menge an Files wie jetzt hier in dem Fall. Man stelle sich vor, dies mit der Hand manuell machen zu müssen. Da hockt man ewig, während dein Tool nichtmal eine Minute dafür gebraucht hat.

Okay, Sicherheitskopien aller Files habe ich ja eh, ich werde jetzt nachher mal zufällig einen Blick in einige der d64 Images werfen, beziehungsweise sie ja sowieso zukünftig wieder benutzen mit dem SD2IEC. Sollte ich dabei irgendwann mal auf ein 'nun defektes' D64-Image stossen welches vorher funktioniert hat, werde ich dir das mitteilen. Dann kannst du das Tool nochmal anpassen.

Auf jeden Fall ist das ein cooles Tool, definitiv.

Und gleichmal noch eine Nachfrage rein interessehalber und zwar sieht man ja bei den letzten d64 Images noch die Meldungen, warum dort nicht hineinkopiert wurde. Was bedeutet beispielsweise diese Meldung beim d64 von "Zombie Brain" wo es heisst:

"Hash of filename "00" [$9863] is not unique"

Das heisst doch quasi, ein File gleichen Namens war in der Adresse 9863 auf dieser Diskette schon vorhanden, richtig? Und warum kam diese Meldung zweimal in dem Fall? (es stimmte übrigens auch, es war schon ein File mit solch einem Namen auf der Disk vorhanden vorher, hab gerade reingeschaut auf das d64).

Wie es der Zufall so will, gleich mal ein d64 gefunden, welches ruiniert wurde dadurch. Ich hab es mal hier angehängt.

zork1.d64

Da hätte nicht hineinkopiert werden dürfen. Das löschen des hineinkopierten "00" Files rettet das Image auch nicht wieder, hab das gerade mal ausprobiert.

AW182 War das eine mehr oder weniger originale Game-Disk? Diese tragen nicht immer alles richtig in die Directory ein. Sobald das eine Disk ist, die nachträglich irgendwie getweakt wurde, wo nicht alle Dateien ordnungsgemäß eingetragen oder nicht alle Sektoren ordentlich verlinkt sind, wird das wohl Probleme geben. Aber dann auch, wenn man das von Hand machen würde.

Claus cc1541 -f "$(BuildTargetFilenameWithoutExtension)" -w "$(BuildTargetFilename)" output.d64 macht genau das, was ich wollte.