cc1541 Batchdatei zum Masseneinfügen in D64-Images

Zitat von Claus

Fall es hilft, könnte ich Dir ein Script zusammenschustern, das dies mit cc1541 tut. Sag einfach bescheid (auch für welches OS).

Das wäre natürlich toll, wenn das möglich wäre. Ich würde das Tool dann auf meinem Windows-PC nutzen wollen, wenn das ginge. Ob nun in DOS (über die Eingabeaufforderung) oder in einer Win-GUI wäre nicht so wichtig.

Falls das Tool merkt, dass auf einem der d64 Files nicht mehr genügend Platz ist, um das hineinzukopierende File dort unterzubringen, dann soll das Tool solch ein d64 File unbehelligt lassen und am besten erst gar nicht anfangen, es dort reinkopieren zu wollen. Solch ein d64 sollte dann so belassen werden wie es ist und das Tool soll automatisch mit dem nächsten d64 weitermachen, in welches das File reinkopiert werden soll. Also falls das so möglich ist?

Denn wenn das ginge, dann bräuchte man vorher nicht alle d64-Files dahingehend manuell abzuchecken, ob überall genügend freie Blocks vorhanden sind, sondern man könnte dann auch einfach in tausende Diskimages ein File automatisiert reinkopieren lassen. Das wäre geil, wenn das ginge. Nicht so gut wäre hier, wenn das Tool dann trotzdem auch bei solchen d64-Files anfängt, das File dort hineinzukopieren und den Vorgang dann mit "Disk voll" abbricht und sich dann Reste des Files auf dem d64 befinden und "0 Blocks frei" dann dazu angezeigt wird. Falls das irgendwie verhindert werden kann, wäre das toll. Wenn das nicht geht, dann müssen die Files eben vorher manuell gecheckt werden.

Zitat von Claus

Ich habe da mal was vorbereitet und attached . Du musst cc1541.exe im Pfad haben (oder im selben Verzeichnis wie das Batchfile). Die Syntax für den Aufruf des Batchfiles ist

Code

1. d64_add_prg.bat file filename

wobei "file" das PRG-File ist, das Du hinzufügen willst, und "filename" der Name, wie er im Directory auftauchen soll. Also z.B. "d64_add_prg.bat sd2brwse.prg SB".

Besten Dank. Gerade runtergeladen. Werde ich heute im Verlauf des Abends mal ausprobieren und morgen Rückmeldung geben.

Eines noch - was passiert, wenn schon ein File gleichen Namens auf einer der d64-Images drauf ist? Wird es überschrieben, auch wenn es ein anderes File ist, was nur den gleichen Namen hat als das hinzuzufügende, oder wird dann in solch einem Fall auch nicht daraufkopiert (was die bessere Alternative wäre).

Naja, ich sehe das ja dann eh, wenn ichs ausprobiere. Kann ja mal ein d64 hinzufügen, welches bereits ein File gleichen Namens enthält.

Zitat von Claus

Ein File gleichen Namens würde mit der neuen Version überschrieben. Ich sammele gerade Ideen für die nächste cc1541 Version, eine Option die das Überschreiben verhindert wäre vielleicht eine gute Idee.

Ja, vor allem wenn das sich vorher schon auf der Disk befindliche File gleichen Namens EIN ANDERES FILE ist, als das, was durch das Skript auf die Disk kopiert werden soll.

Wäre es das gleiche File, dann wäre das ja nicht schlimm, dann würde einfach das File wieder durch genau das gleiche File ersetzt werden, aber das Programm auf der Disk läuft dann immernoch normal. Aber wenn ich beispielsweise (und das habe ich so vor) den SD2BRWSE Filebrowser mit dem Namen "00" auf alle Disketten kopieren will, sich aber nun zufällig bei einem der d64-Files eine andere Datei mit demselben Namen dort befindet (etwa eine zu einem Spiel dazugehörige Datei namens 00), dann würde das überschreiben dann dieses Spiel ruinieren.

Daher am besten so vorgehen wie bei "zu vollen d64 Images", sprich, dann vorher erkennen dass solch ein File drauf ist und dann gar nicht kopieren in solch ein d64. Aber am besten solch ein d64-File dann ebenfalls namentlich nennen (so wie bei den zu vollen Diskimages) am Schluss des ganzen Vorgangs, dann kann man später manuell in solchen Einzelfällen gut nacharbeiten, indem man dann den Browser für solche Disks vorher per Hand irgendwie umbenennt und dort dann manuell reinkopiert. Denke das macht Sinn, oder was meinst Du?

So, ich konnte doch nicht abwarten und musste es gleich mal ausprobieren.

- deine cc1541.exe V2.0 aus der CSDB runtergeladen und in's gleiche Verzeichnis kopiert wie dein Batch-File
- 160 verschiedene d64-Images (wahllos aus meinem Archiv zusammenkopiert) mit dazu
- das reinzukopierende File namens "00.prg" noch mit rein ins Verzeichnis

Auf meinem Windows-7 PC die MS-DOS Eingabeaufforderung gestartet und dann ging es los mit dem von dir beschriebenen Befehl.

Der Vorgang läuft durch und es sieht gut aus. Am Ende meldete dein Programm "Succesfully patched 150 of 160 Diskimages." und zeigte mir namentlich diejenigen 10 Disketten an, auf die er das File nicht kopiert hat. Ich sah mir diese dann mal mit dem d64-Editor an und wie erwartet, sind diese auch alle zu voll gewesen, um das File noch mit beinhalten zu können. Diese Disks wurden auch, wenn ich mir die Datei-Daten ansehe, nicht geändert, während bei allen anderen (den 150 Stück) nun ein einheitliches Änderungsdatum stand. Soweit hat also alles sehr gut geklappt.

Zwei Sachen aber noch. Nachdem das File den Vorgang beendet hatte und mir diese "Succesfully ..." Meldung gebracht hatte, stürzte es ab mit dieser Fehlermeldung im Windows:

Das hat den Vorgang an sich jetzt nicht beeinflusst, aber mich doch etwas gewundert. Ich musste das Programm dann schließen. Soll ich das Script mal im Kompatibilitätsmodus zu älteren Windows-Varianten laufenlassen, oder woran kann das liegen?

Und eine letzte Sache. Ich hatte spasseshalber auch mal eine d64 Datei unter die 160 Stück gemischt, in der ich ein bereits auf der Disk vorhandenes File vorher in "00" umbenannt hatte. Das war ein Teil eines Nachladespiels und vorher 77 Blocks gross. Und genau wie du vorher schon erwähnt hast, überschreibt dein Skript dieses File nun mit dem neuen. Solch ein Spiel, welches bereits ein File namens 00 vorher enthalten hat, wäre damit dann kaputt. Diesen Punkt sollte man also ändern. Solch eine Disk sollte unbehelligt gelassen werden und namentlich dann mit erwähnt.

Ansonsten hat alles gut geklappt und schnell ging es auch noch die ganze automatische Reinkopiererei.

Eines war noch etwas merkwürdig. Ich startete den Vorgang um 20:42, aber bei all den bearbeiteten d64-Images stand dann einheitlich 20:33 als Änderungszeit (das Datum passte). Übernimmt die DOS-Eingabeaufforderung nicht den Zeitwert der Windows-Uhr? Merkwürdig diese 9 Minuten Abweichung, oder?

Zitat von Claus

Erstaunlich, denn nach der Ausgabe "Successfully..." wird cc1541 gar nicht mehr aufgerufen. Wenn es ein D64-Image gäbe bei dem cc1541 abstürzt, wäre das natürlich sehr interessant zu wissen.

Evtl. sollten wir entweder auf Konversation umschalten, oder einen separaten Thread beginnen?

Ja, gute Idee. Am besten wäre es wahrscheinlich, wenn ein Mod das abspalten würde ab meinem Eintrag 37. Ich melde das mal einem Mod, damit er das machen kann. Wenn dieses kleine Tool fertig ist, dann kann es ja am Schluss wieder hier verlinkt werden. Ist doch ein cooles kleines Programm und automatisiert ein File in tausende Diskimages kopieren zu können, ist auch eine feine Sache.

Und zum Programm nochmal. Also diese Meldungen kommen alle fast zeitgleich. Es steht dann die "succesfully ..." Meldung im DOS-Fenster da und zugleich kommt ein Windows-Fenster mit dieser "CC1541.exe funktioniert nicht mehr" Fehlermeldung. Ich meine, eigentlich kann man es auch so belassen, Hauptsache das Programm erledigt seine Aufgabe und das tut es ja. Ich probiere mal noch etwas mit dem Kompatibilitäsmodus rum, mal sehen, ob man diese Fehlermeldung irgendwie wegbringt. Es war, zumindest in meinem getesteten Fall hier mit den 160 Files, höchstwahrscheinlich kein d64-File selbst, welches das Programm zum Absturz brachte, vermute ich. Denn sonst hätte das Programm den Vorgang wohl irgendwo in der Mitte der Diskimages abgebrochen und nicht die ganzen 160 Disks abgearbeitet. Zumindest vermute ich das.

Gut wäre dann noch diese schon angesprochene Änderung zum Umgang mit "Files gleichen Namens auf dem Diskimage", wenn die den Weg noch in das Skript finden könnte. Ansonsten klappt das schon so wie gewünscht. Mit einem Diskimage im Sonderformat, wie etwa dem angesprochenen GEOS, hab ich es jetzt noch nicht ausprobiert, das muss ich noch testen.

Ooooh Mann , ich hab den Grund gefunden für den Absturz des Programms. Und zwar fiel mir auf, dass dein Tool den Kopiervorgang immer komplett fertig macht, aber dann, wenn er die Files namentlich auflistet, auf die das File nicht mehr draufpasst, diese Windows-Fehlermeldung kommt. Klicke ich die dann weg mit Programm schließen, dann schließt er erst ab und dann kommt erst (und da hatte ich mich vorhin getäuscht) diese "succesfully patched ..." Meldung im DOS-Fenster. Somit vermutete ich nun, dass es vielleicht mit einem dieser 10 Files zu tun haben könnte, die da am Schluss namentlich gelistet werden und so war es auch.

Und zwar habe ich mir die Datei-Eigenschaften der Files dann nochmal angesehen und es war ein einziges File unter den ganzen 160 Files dabei, welches "read only" war, also schreibgeschützt. Und das war natürlich ausgerechnet auch noch genau eines von den 10 Files die zu voll waren, um dort das 00.prg noch mit hineinzukopieren. Dummer Fehler von mir, da hätte ich natürlich vorher mal schauen sollen bei den ganzen Files, ob der Schreibschutz draussen ist.

Auf jedenfall hat der Schreibschutz dieses einen d64-Files dann diese Fehlermeldung verursacht und das, obwohl ja auf dieses File gar nicht erst geschrieben wird (da zu wenig Platz frei). Das wäre mir eher aufgefallen dass es daran liegt, wenn eines der 150 anderen d64-Files schreibgeschützt wäre, denn dann hätte das Tool wahrscheinlich exakt bei dieser Disk angehalten und den Vorgang nicht zu ENde gebracht, aber NEIN, das schreibgeschützte musste natürlich genau eines der 10 vollen d64-Images sein *lol*.

Naja, zumindest ist der Grund nun identifiziert, also das Tool stürzt jetzt nicht mehr ab.

Eine Ausnahmebehandlung könnte Claus vermutlich leicht nachbasteln, entweder per Batch oder auch direkt im cc1541 2.0.
Tipp: Wenn man Tablacus, Q-Dir oder andere Explorer-Displacements nutzt, kann man die Dateinamen anhand der Attribute einfärben.

Zitat von Claus

Das möchte ich noch korrigieren, bevor es eine Version 2.1 gibt . Also bitte noch ein paar Tage Geduld .

Keinerlei Eile von Nöten, ist ja gut, daß das überhaupt jemand realisiert.

Zitat von Claus

Es gibt schon eine Kommandzeilenoption, die das überschreiben von Dateien mit gleichem Namen im Diskimage verhindert. Außerdem habe ich eine Option eingebaut, die checken soll, ob ein Diskimage überhaupt gültiges CBM-DOS-Format hat, so dass man nicht versehentlich Images zerschießt, die ein eigenes Dateisystem haben

Top! Bin gespannt auf diese neue Version.

Zitat von atomcode

Wenn man Tablacus, Q-Dir oder andere Explorer-Displacements nutzt, kann man die Dateinamen anhand der Attribute einfärben.

Keine schlechte Funktion mit den verschiedenen Farben. So kann man schnell und einfach diejenigen Files finden, die schreibgeschützt sind. Wobei man jetzt aber für diese automatisierte Hineinkopier-Arbeit die das Batch-Skript hier erledigt, diese Files gar nicht unbedingt einzeln identifizieren muss.

Man kann ja im Win-Explorer vorher auch einfach mal nachsehen in demjenigen File-Verzeichnis in dem sich die Diskimages alle befinden, ob dort auch wirklich bei allen Files der Schreibschutz draussen ist und falls nicht, dann einfach im Explorer bei ALLEN Files diesen dann ausschalten in einem Schritt (am besten gleich mit Subfolder-Option an wenn es Unterverzeichnisse gibt). Ich hatte das nur vergessen und gar nicht damit gerechnet, daß deswegen gleich CC1541 abstürzt. Aber "CLAUS" hat das ja jetzt eh schon behoben in der neuen Version.

Jetzt bin ich beim weiteren durchforsten der 150 Stück d64-Images, auf die das File kopiert wurde, noch auf ein eventuelles Problem gestossen.

Und zwar waren in den Diskimages auch zwei Leveldisks des Spiels "MicroLeague Baseball" mit dabei:

http://www.gb64.com/game.php?id=4798

Das Game hat mehr als 10 Disketten und bei allen Disks kann man die Directory nicht richtig auflisten. Es heisst zwar dann "21 Blocks free" oder "15 Blocks free" wenn man sich die einzelnen Disks ansieht, aber man sieht nur einen kleinen Teil der Programme in der Auflistung der Directory, die anderen nicht.

Hier hat das Batch-Skript das File nun auch überall mit hineinkopiert und ich bin mir nicht sicher, ob es dadurch nicht irgendwas auf diesen Leveldisks kaputtmacht. Ich hänge dir mal zwei solcher Leveldisks des Spiels hier an, einmal in der ursprünglichen Form und einmal nachdem das File hineinkopiert wurde, dann kannst du dir das mal ansehen. Vielleicht sollte man solche "nicht komplett auflistbaren" Diskimages auch irgendwie anders behandeln, beziehungsweise auch beim Kopiervorgang mit übergehen und so belassen? Ich befürchte nämlich, dass hier ein hinzufügen irgendeiner neuen Datei auf der Disk, irgendwas kaputtmachen könnte.

Der D64-Editor meldet bei diesen Leveldisks wenn man sie öffnet auch immer "35 Track D64 File + Error Info". Kopiert man dann in solch eine Leveldisk irgendein neues File hinein, dann meldet der D64-Editor anstatt der obigen Meldung "35 Track D64 File (Standard)". Nun ist die Frage - läuft dann solch eine Disk noch normal, wenn das Spiel sie im Verlauf des Gameplays verlangt? Deshalb vielleicht vorsichtshalber, um hier nichts zu riskieren, lieber bei solchen Disks das File nicht mit reinkopieren, oder?

Zitat von AW182

Vielleicht sollte man solche "nicht komplett auflistbaren" Diskimages auch irgendwie anders behandeln, beziehungsweise auch beim Kopiervorgang mit übergehen und so belassen? Ich befürchte nämlich, dass hier ein hinzufügen irgendeiner neuen Datei auf der Disk, irgendwas kaputtmachen könnte.

Das ist aber ein grundsätzliches Problem. Es sind ja auch Spieledisks denkbar, bei denen 664 freie Blocks angezeigt werden, und der "Schreibschutz" besteht nur aus der Warnung: "MeinTollesSpiel, Leveldisk, NichtsSelberAbspeichern!" im Directory (das Spiel macht dann Direktzugriffe auf Blocks).

Soll heißen: Egal wieviel Intelligenz man in das Tool packt - es kann dann immer noch Fälle geben, in denen es den Disk-Inhalt zerstört.

Zitat von Claus

Mein Check sieht im Moment so aus:
[...]
ist der Sektor am Ende des Directories ungleich 255?

Ich meine mich dunkel zu erinnern, dass es Disk/Dir-Editoren gibt, die dort leider einen falschen Wert eintragen. Daher hätte ich dieses Merkmal jetzt nicht als Ausschlusskriterium genommen. Eine Warnung für solche Fälle wäre natürlich sinnvoll, oder ein CLI-Switch, der diesen Test separat (de-)aktiviert.

Dann würde ich auf jeden Fall noch das Formatbyte (Offset 2 auf T18S0) testen, das wurde ja gern auch mal als Schreibschutz missbraucht.

Und was man noch testen könnte: Passt in der BAM in jeder Spur die Zahl der freien Blöcke zum Inhalt der drei Bitmap-Bytes?