cc1541 Batchdatei zum Masseneinfügen in D64-Images


  • Claus
  • 383 Views 25 replies

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

  • cc1541 Batchdatei zum Masseneinfügen in D64-Images

    AW182 wrote:

    Und zwar suche ich schon länger ein Tool, welches mir ein prg-File automatisch in hunderte von d64-Files reinkopieren kann, ohne dass ich dies per Hand für jedes File einzeln machen muss. Genauer gesagt, will ich den" SD2BRWSE" Filebrowser in 249 d64-Files reinkopieren und zwar immer ganz unten ans Ende im jeweiligen d64. Platz ist noch genug auf den Disks für die 5 Blocks die der Browser hat.
    Gibts da ein Tool für, weiß jemand was?
    Fall es hilft, könnte ich Dir ein Script zusammenschustern, das dies mit cc1541 tut. Sag einfach bescheid (auch für welches OS).

    EDIT by FXXS: Threadsplit: Popstings stammten urspünglich aus: Programme zum Erstellen und Nachbearbeiten von C64-Diskettenabbildern
    ────────────────────────────────────────────────────────────
    Time of Silence - Time of Silence 2 Development Blog
    ────────────────────────────────────────────────────────────

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

  • Claus wrote:

    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.

    The post was edited 2 times, last by AW182 ().

  • 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

    Source 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".

    Das Batchscript geht durch das aktuelle Verzeichnis und alle Unterverzeichnisse und sucht nach *.d64 oder *.D64 Files und fügt das PRG hinzu. Wenn es aus irgendeinem Grund nicht geht (meist wohl weil es nicht draufpasst), wird der betreffende Filename des Imagefiles ausgegeben und das File selber unverändert gelassen.

    Einen Warnhinweis habe ich aber: ich bin nicht ganz sicher was passieren kann, wenn das D64 kein DOS-Format hat (also z.B. bei GEOS-Disks oder so). Es ist sicher anzuraten, ein Backup Deiner Images zu machen, bevor Du das Skript drauf loslässt ^^ !

    Feedback ist natürlich gerne gesehen, insbesondere wenn es irgendwelche Probleme gibt!
    Files
    • d64_add_prg.zip

      (776 Byte, downloaded 11 times, last: )
    ────────────────────────────────────────────────────────────
    Time of Silence - Time of Silence 2 Development Blog
    ────────────────────────────────────────────────────────────
  • Claus wrote:

    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

    Source 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.
  • 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.
    ────────────────────────────────────────────────────────────
    Time of Silence - Time of Silence 2 Development Blog
    ────────────────────────────────────────────────────────────
  • Claus wrote:

    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?

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

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


    Source Code

    1. CC1541.exe funktioniert nicht mehr.
    2. Problemsignatur:
    3. Problemereignisname: BEX
    4. Anwendungsname: cc1541.exe
    5. Anwendungsversion: 0.0.0.0
    6. Anwendungszeitstempel: 5c39fb27
    7. Fehlermodulname: ucrtbase.DLL
    8. Fehlermodulversion: 10.0.14393.2630
    9. Fehlermodulzeitstempel: 5bbec6e6
    10. Ausnahmeoffset: 00087fd4
    11. Ausnahmecode: c0000417
    12. Ausnahmedaten: 00000000
    13. Betriebsystemversion: 6.1.7601.2.1.0.256.1
    14. Gebietsschema-ID: 1031
    15. Zusatzinformation 1: 05c8
    16. Zusatzinformation 2: 05c86dde23a12b058608e0979a92188b
    17. Zusatzinformation 3: a8c8
    18. Zusatzinformation 4: a8c813537c3d2e25e0bf7aa58308ab67
    Display All

    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?
  • 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?
    ────────────────────────────────────────────────────────────
    Time of Silence - Time of Silence 2 Development Blog
    ────────────────────────────────────────────────────────────
  • Claus wrote:

    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.

    The post was edited 5 times, last by AW182 ().

  • Ooooh Mann X/ , 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. :)
  • New

    AW182 wrote:

    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.
    Ah, das sollte natürlich nicht sein, dass cc1541 in diesem Fall abstürzt. Ich konnte das Verhalten auch reproduzieren und werde es fixen.
    ────────────────────────────────────────────────────────────
    Time of Silence - Time of Silence 2 Development Blog
    ────────────────────────────────────────────────────────────
  • New

    Kleines Update zwischendurch: ich arbeite an einer neuen cc1541-Version. Der Crash bei schreibgeschützten Outputdateien ist behoben. 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 (Demos mit Trackloadern, kopiergeschützte Spiele, GEOS, etc.). Leider ist mein Test wohl sehr (zu?) gründlich und ich habe in dem Zusammenhang festgestellt, dass cc1541 keine korrekte BAM zu schreiben scheint. Das möchte ich noch korrigieren, bevor es eine Version 2.1 gibt :/ . Also bitte noch ein paar Tage Geduld :sleeping: :saint: .
    ────────────────────────────────────────────────────────────
    Time of Silence - Time of Silence 2 Development Blog
    ────────────────────────────────────────────────────────────
  • New

    Claus wrote:

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

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

    Claus wrote:

    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! :thumbup: Bin gespannt auf diese neue Version.

    atomcode wrote:

    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.

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

  • New

    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:

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

    AW182 wrote:

    Deshalb vielleicht vorsichtshalber, um hier nichts zu riskieren, lieber bei solchen Disks das File nicht mit reinkopieren, oder?
    Genau für diese Fälle baue ich den Check nach einem gültigen CBM DOS Format ein (und der mäkelt im Moment auch und weigert sich, die unveränderte Leveldisk zu patchen).
    ────────────────────────────────────────────────────────────
    Time of Silence - Time of Silence 2 Development Blog
    ────────────────────────────────────────────────────────────
  • New

    AW182 wrote:

    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.
    Yes, I'm the guy responsible for the ACME cross assembler
  • New

    Mein Check sieht im Moment so aus:

    • enthält das DIR ungültige Filetypen?
    • sind Starttrack oder -sektor eines Files illegal?
    • wird der Startblock von einem anderen File verwendet (und zwar als nicht-Startblock)?
    • enthält die Sector-Chain eines Files illegale Tracks oder Sektoren?
    • enthält die Sector-Chain eines Files einen Block, der auch von einem anderen File verwendet wird?
    • ist der Sektor am Ende des Directories ungleich 255?
    Danach ist hoffentlich einigermaßen sicher, dass es sich um ein DOS-Directory handelt. Der wichtigste Check ist wohl dann der letzte:
    • Sind BAM und die Blöcke die durch die Files und das Directory belegt werden verschieden?
    Meine Hoffnung ist, dass bei einem Trackloader oder eigenem Dateisystem die belegten Sektoren dennoch in der BAM markiert sind. In dem Fall würde der Check fehlschlagen. Wenn das nicht der Fall ist, hat man in der Tat keine Chance, so ein Image zu erkennen.
    ────────────────────────────────────────────────────────────
    Time of Silence - Time of Silence 2 Development Blog
    ────────────────────────────────────────────────────────────

    The post was edited 4 times, last by Claus ().

  • New

    Claus wrote:

    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?
    Yes, I'm the guy responsible for the ACME cross assembler
  • New

    Mac Bacon wrote:

    Ich meine mich dunkel zu erinnern, dass es Disk/Dir-Editoren gibt, die dort leider einen falschen Wert eintragen.
    Ja, hatte ich auch schon überlegt.

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

    Mac Bacon wrote:

    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?
    Tja, wobei ich mich frage, ob das nicht zu viel des guten ist. Ich werde mal schauen, ob das in meinem D64-Gruselkabinett mal vorkommt (ohne dass die anderen Kriterien ohnehin zum tragen kommen).
    ────────────────────────────────────────────────────────────
    Time of Silence - Time of Silence 2 Development Blog
    ────────────────────────────────────────────────────────────
  • Users Online 1

    1 Guest