Hello, Guest the thread was called2.1k times and contains 54 replays

last post from Claus at the

cc1541 Batchdatei zum Masseneinfügen in D64-Images

  • 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*

  • 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.

    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.


    Konnte denn dieses Diskformat der "MicroLeague Baseball" Disketten identifiziert werden

    Ja, wobei das ein einfacher Fall ist weil wie Du schon sagst gar kein gültiges Directory drauf ist.

  • 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. :)

  • Ich glaube, meine Detektion ist mittlerweile ganz brauchbar. Zumindest scheint sie auf den ersten Blick sinnvolle Dinge zu tun, wenn ich meine Image-Sammlung darauf werfe (da weist sie etwa 50% der Images zurück, aber ich habe auch vor allem Demos und Spiele über mehrere Diskettenseiten bei denen das nicht anders zu erwarten ist). Leider ist es ja sehr mühselig, das im Detail zu prüfen, da man jedes einzelne Image im Emulator testen müsste. Ein Backup ist sicher sehr anzuraten 8) ! 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.

  • Hohum, lieber spät als nie... Es hat sich doch noch etwas gezogen, bis die offizielle neue cc1541-Version fertig war, aber nun ist es soweit. Mit dem beiliegenden Batchfile und dem cc1541 von hier: https://csdb.dk/release/?id=181090 kann man sicher Files einfügen, ohne nicht-DOS-Images zu beschädigen.

  • 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.

  • 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?

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

  • "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. ;)

  • 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.

  • atomcode hat natürlich Recht, ein Backup der Originalimages sollte in jedem Fall gemacht werden. Wer weiß, ob sich trotz Testen nicht doch noch irgendein Fehler in cc1541 versteckt ;)...

    (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.

    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.

    (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.

    In der ursprünglichen Version würder es mit der neuen Version überschrieben, mit der Änderung von 1-a wird es gelassen wie es ist.

    (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?

    Stimmt, das Tool schaut nicht den Inhalt von Dateien an.

    (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?

    Das Tool merkt dies und lässt das Diskimage unverändert. Das Image wird erst auf die Festplatte geschrieben, wenn es ohne Fehler im Speicher bearbeitet werden konnte.

  • Allerdings verstehe ich da auch noch nicht alles. Ob oder wie man bspw. ein File auf Disk renamen kann.

    Ja, das Tool ist mittlerweile ziemlich mächtig und die Features sind durchaus nicht einfach in einem kurzen Satz zu beschreiben. Hm, renamen war eigentlich gar nicht als Feature vorgesehen, geht aber tatsächlich mit einem leicht umständlichen Weg:

    Code
    1. cc1541.exe -f altername -T DEL -O -w program.prg -f neuername -w program.prg image.d64

    Das "schreibt" das alte File nochmals, aber mit dem Filetype DEL und dem Open-Flag gesetzt, was in CBM DOS der Markierung für ein komplett gelöschtes File entspricht und schreibt es dann unter neuem Namen nochmals. Setzt allerdings voraus, dass man das zu renamende File als prg vorliegen hat.

  • 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.

  • 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.

    Das ist eine wesentliche Änderung in der neuen cc1541-Version 3.0! Nun werden Kleinbuchstaben in der Kommandozeile in ungeshiftete Zeichen auf dem Diskimage umgesetzt und Großbuchstaben als geshiftete. So ist es dann doch intuitiver (auch wenn die Änderung des Verhaltens sicher für Verwirrung sorgen wird, aber daher heißt die neue Version 3.0 und nicht 2.1).

  • 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.


    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. :P 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. :thumbup:


    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).

  • 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. :emojiSmiley-106: