cc1541 Batchdatei zum Masseneinfügen in D64-Images


  • Claus
  • 441 Views 25 replies

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • Claus wrote:


    Mac Bacon wrote:

    Dann würde ich auf jeden Fall noch das Formatbyte (Offset 2 auf T18S0) testen, das wurde ja gern auch mal als Schreibschutz missbraucht.
    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.
    Yes, I'm the guy responsible for the ACME cross assembler
  • 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*
  • AW182 wrote:

    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.

    AW182 wrote:

    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.
    ────────────────────────────────────────────────────────────
    Time of Silence - Time of Silence 2 Development Blog
    ────────────────────────────────────────────────────────────

    The post was edited 1 time, last by Claus ().

  • Claus wrote:

    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.
    ────────────────────────────────────────────────────────────
    Time of Silence - Time of Silence 2 Development Blog
    ────────────────────────────────────────────────────────────