Disketten vergleichen?

Es gibt 65 Antworten in diesem Thema, welches 14.273 mal aufgerufen wurde. Der letzte Beitrag (17. Juli 2021 um 19:09) ist von Fraggle.

  • Wenn aber nun im Emulator mit D64 ein Kopierschutz z.b. von Track 22 Sektor 15 die Header ID abfrägt was passiert dann?


    Der Emulator verwendet dann üblicherweise die im Directory eingetragene ID.

    Zitat

    Und wäre dann nicht ein idealer Kopierschutz wenn auf Track 10 eine andere ID stehen müsste wie z.b. Track 20 ?


    Nein, sowas lässt sich trivial kopieren.

    10 x=rnd(-1963):fori=1to81:y=rnd(1):next
    20 forj=1to5:printchr$(rnd(1)*16+70);:next
    30 printint(rnd(1)*328)-217

    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

  • Wenn es trivial ist, dann müsste der TE doch nur ein solches Kopierprogramm nutzen um das D64 auf das echte Floppy zu kopieren?


    Klar, wenn man das D64 in eine 1541U oder ein Chameleon "einlegt" und einen Nibbler auftreibt, der mit zwei Laufwerken umgehen kann könnte das funktionieren. Wenn das D64 dagegen nur in einen Emulator "eingelegt" werden kann bringen einen die existierenden C64-Kopierprogramme auch nicht weiter.

    10 x=rnd(-1963):fori=1to81:y=rnd(1):next
    20 forj=1to5:printchr$(rnd(1)*16+70);:next
    30 printint(rnd(1)*328)-217

    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

  • Interessant, dass mit den IDs in den Headern UND in der BAM. Kann man denn die Header-IDs irgendwie einfach (möglichst ohne eigenen Code im Laufwerk) auslesen? Reicht ein M-R $16/$17 nach einem U1? Kann man sie irgendwie einfach (über-)schreiben, abgesehen von Formatieren?

    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

  • Wenn es trivial ist, dann müsste der TE doch nur ein solches Kopierprogramm nutzen um das D64 auf das echte Floppy zu kopieren?


    Habe ich ja auch gemacht, nur hat sich der Thread verselbständigt. Bei mir war das Problem nicht die ID oder sonst eine ungleiche Kopie. Bei mir war es einfach nur eine zweite Floppy am Bus.
    Und das funktioniert halt mit einigen Games/Demos nicht, die wollen eine single Floppy!

    - WiC64 - The Commodore 64 Wireless Interface -> Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen.
    - WiC64 - Radio -> Bitte melde dich an, um diesen Link zu sehen.
    - WiC64 - GameBox -> Bitte melde dich an, um diesen Link zu sehen. :thumbsup:
    - WiC64 - DemoBox -> Bitte melde dich an, um diesen Link zu sehen.

  • Kann man denn die Header-IDs irgendwie einfach (möglichst ohne eigenen Code im Laufwerk) auslesen? Reicht ein M-R $16/$17 nach einem U1? Kann man sie irgendwie einfach (über-)schreiben, abgesehen von Formatieren?

    An die ID eines einzelnen Sektors kommst Du nicht so einfach ran. Beim ersten Zugriff bzw. Initialize wird diese im RAM gespeichert (aus dem erstbesten Sektorheader der vorbeikommt, denke ich). Wenn bei einem Leseversuch eine andere ID im Header steht -> disk id mismatch error.

    Sektorheader werden einmalig beim Formatieren geschrieben, dann nie wieder. Also ist die ID nicht "einfach" zu ändern.

    Code: Floppy Fehlerkanal abfragen - Ausserdem kann ich bei "drive not ready" den I: und N: Befehl verwenden und notfalls den Kopf manuell zurückschieben. Und Finger weg vom Stepper!
    10 open1,8,15                   : rem 8 ist die Geräteadresse und das kann man bei Bedarf natürlich anpassen
    20 get#1,a$:?a$;:ifst<>64goto20 : rem Das CLOSE 1 am Ende kann man sich sparen, weil beim RUN automatisch ein CLOSE ALL ausgeführt wird.
    RUN
  • Herrlich alt dieser "Fred", aber ich glaube es gibt immer noch kein Programm, um Disketten und/oder Sektoren miteinander vergleichen zu können!

    So wundert es nicht, dass der "Sauhaufen" an unterschiedlichen Programmversionen/Disketten niemals besser wird.

    So habe ich mir selbst ein Tool geschrieben, und die erste Andwendung findet sich hier: Bitte melde dich an, um diesen Link zu sehen.

    Wie gesagt, man kann damit:

    * Kopien verifizieren

    * Disk/Programm-Unterschiede genau ermitteln

    * rudimentär (aufwändig, unpräzise, aber ohne spezielle Kenntnisse) hacken

    Warum die Welt bislang ohne solche Tools ausgekommen ist? Vermutlich weil sich noch nie jemand um Datensicherheit jemals Gedanken gemacht hat.

  • Sehr gut! :smile: Danke! :smile:

    Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen. :böse Bitte melde dich an, um diesen Link zu sehen. Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen.

    „Vor dem Himmel kommt das Leben auf Erden, und da gilt es, eine soziale Gesellschaft aufzubauen.“ – Heinz Nixdorf (1986)

    Bitte melde dich an, um diesen Link zu sehen. :beer:Bitte melde dich an, um diesen Link zu sehen. Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen.

  • Jetzt mal nachgefragt, ohne den ganzen Thread vorher durchgelesen zu haben. Wie ist das eigentlich, wenn man ein Checksum-Tool am PC verwenden würde, etwa WinMD5free? Könnte man damit eine C64 Kopie verifizieren oder nicht?

  • Das ginge schon, nur möchte man ja nicht nur wissen, ob das Image gleich ist, sondern wo es sich unterscheidet und sich das dann auch noch anzeigen lassen, so wie ich das verstanden habe.

    Bitte melde dich an, um diesen Anhang zu sehen.

    So, und jetzt noch am C64...

  • "Disketten vergleichen" kann man halt unterschiedlich auffassen:

    • auf Datei Ebene
    • auf Sektor Daten Ebene
    • auf Disketten-Format Ebene

    In den meisten Fällen wird die Datei Ebene reichen und auch die beste Wahl sein.

    Aber manchmal werden halt Daten direkt in Blöcke gespeichert.

    Ich glaub zb. das Spiel "Loderunner" macht das so.

    Da können alle Dateien gleich sein und doch läuft das Spiel nicht oder eben anders.

    Man muss halt wissen was man will und wie man es am besten tut.

    Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen.

  • Das ginge schon, nur möchte man ja nicht nur wissen, ob das Image gleich ist, sondern wo es sich unterscheidet und sich das dann auch noch anzeigen lassen, so wie ich das verstanden habe.

    Ich mache von Quelle und Ziel Disk jeweils ein D64/D81 und nutze dann unter Linux vbindiff, das zeigt dann die unterschiedlichen Bytes in roter Farbe an. Mit mc kann man das Image im HEX-Modus auch bearbeiten.

    Mittels MD5SUM kann ich vorher testen ob beide Images identisch sind...

    Das direkt am C64 zu vergleichen würde man hinbekommen, aber effektiv nur mit zwei Laufwerken und sehr langsam. Mit nur einem Laufwerk würde das glaube ich ziemlich aufwändig.

  • Also wenn es nur um .D64 Images geht, dann kann man das am PC mit Beyond Compare oder mit dem Total Commander per Byte-Vergleich machen, da werden dann auch gleich die unterschiedlichen Bytes in rot hervorgehoben.

    Auf Sektor-Ebene klappt das so natürlich nicht, aber das liegt ja am .D64 Image - was nicht im Image enthalten ist, kann auch nicht verglichen werden.

    Das könnnte man dann nur mit .G64 Images lösen. wobei ich mir aber nicht sicher bin welche Daten in .G64 Images genau enthalten sind, und ob es evtl. sein könnte, daß sich 2 .G64 Images von ein und der selben Disks untereinander unterscheiden, je nachdem auf welche Art und Weise sie erstellt wurden? (z.b. mit Kryoflux, Greaseweasel, MNIB, oder irgendwelchen Methoden direkt am C64, usw.?!)

    was ich noch so suche:
    Amiga 1020 Laufwerk

    Einmal editiert, zuletzt von Overdoc (6. Juli 2021 um 11:22)

  • Selbst wenn Du dieselbe Diskette zweimal mit Kryoflux/Greaseweazle etc. ausliest, kommt nicht exakt das gleiche Image raus.

    Das liegt daran, dass an bestimmten Stellen der Diskette die Flussänderungen nicht genau definiert/geschrieben wurden.

    Typischerweise ist der Track Trail und die Write Splice Location so eine Stelle. Da hängt es dann davon ab, ob die Diskette z.B. vorher entmagnetisiert wurde, oder ob bis zur Write Splice Position noch definierte Bit Patterns geschrieben wurden (z.B. $55).

    Angenommen du hast einen RAW Stream mit demselben Dekoder zu einem G64 konvertiert, dann kannst du mit G64Conv das G64 zu einer Textrepräsentation konvertieren. Diese lässt sich dann mit Text Compare Tools vergleichen.

    Alternativ kannst du die Timings der Flusswechsel auch mit G64Conv als Textrepräsentation extrahieren. Aber aufgrund der begrenzten Genauigkeit der Datenaufnahme sind die Zeitwerte schon bei verschiedenen Rotationen nicht exakt identisch. Da müsste man also noch shiften und Toleranzen zulassen, damit es überhaupt vergleichbar wird.

    Bei NibTools hast Du das Problem, dass die absolute Spurlage beim einlesen einer 1541 nicht erfasst wird (Mangels Indexlochpulse). Somit muss man die Spuren zur Vergleichbarkeit erst einmal bei den zu vergleichenden Images ausrichten. Bei normalen CBM DOS Format findet man das noch recht einfach, bei Custom Formaten ist das aber auch schon ein Problem.

  • Alles klar, vielen Dank für die technische Erklärung.

    D.h .ein Vergleich von .G64 Images gegeneinander über Binärvergleich ist im Gegensatz zu .D64 Vergleichen sinnlos.

    Aber ein Vergleich von .D64 Images macht ja auch nur begrenzt Sinn. Genügt ja ein anderer Header, schon sind zwei .D64 Images unterschiedlich, auch wenn sie sonst die selben Daten enthalten.

    Sehr brauchbar für den Vergleich von .D64 Images wäre ein Tool, welches die darin enthaltenen Dateien (.PRG, .SEQ, usw.) von zwei .D64 Images gegeneinander vergleicht!

    Es gibt da z.b. ein .D64 Plugin für den Total Commander, allerdings fehlt dem leider die 'Direcotry's Synchronisieren/Vergleichen' Funktion :(

  • Aber ein Vergleich von .D64 Images macht ja auch nur begrenzt Sinn. Genügt ja ein anderer Header, schon sind zwei .D64 Images unterschiedlich, auch wenn sie sonst die selben Daten enthalten.

    Es kommt drauf an, was du brauchst. Wenn du sicher sein willst, dass die Disketten gleich sind, musst du das machen. Wenn du wissen willst, ob die Dateien auf der Diskette gleich sind, musst du die vergleichen.

    Sehr brauchbar für den Vergleich von .D64 Images wäre ein Tool, welches die darin enthaltenen Dateien (.PRG, .SEQ, usw.) von zwei .D64 Images gegeneinander vergleicht!

    Es gibt da z.b. ein .D64 Plugin für den Total Commander, allerdings fehlt dem leider die 'Direcotry's Synchronisieren/Vergleichen' Funktion

    Wieso ein spezielles Programm um D64 miteinander zu vergleichen?

    Es reichen:

    1. Ein Tool, um Dateien aus einem D64 zu extrahieren (c1541 aus dem VICE-Paket ist eine, aber nicht die einzige Option hierzu)
    2. Zum Feststellen, ob die Dateien identisch sind: Ein Vergleichstool (fc unter Windows, diff unter Unixoiden), alternativ auch ein Programm, welches eine Prüfsumme bildet (md5sum, sha256sum, ...) - wobei die Prüfsumme die (vermutlich vernachlässigbare) Gefahr enthält, dass trotz Unterschieden trotzdem die gleiche Prüfsumme rauskommt.
    3. Zum Feststellen, wo sich die Dateien unterscheiden: Ein Tool, um Binärdateien in Hex-Darstellung zu wandeln (ich nutze hier gerne xxd), sowie ein Vergleichstool (diff wäre wieder möglich, oder, bei größeren Komfort, wdiff)
    4. Je nachdem, wie groß die Unterschiede sind, ein Texteditor und/oder Viewer. Ich nutze hier gerne vim, andere gehen aber genauso.

    Wenn ich ganze Images vergleichen will lasse ich Nr. 1 weg und arbeite am Image. Zum Vergleich "identisch/nicht identisch" nutze ich diff, ansonsten ein dem diff vorgeschaltetes xxd.

    Jedes Tool kann eine Aufgabe, die aber dann richtig. Da brauche ich keine super-duper zusammengestellten Tools für eine Speziallösung. Die Kette geht mir auch schon so von der Hand, da muss ich gar nicht mehr drüber nachdenken.

    Der Vorteil: Wenn ich mal andere Dateien habe funktioniert die ganze Toolkette, mit leichten Anpassungen, immer noch. Das ist bei spezialisierten Tools meistens nicht der Fall.

    Die Kette kann ich auch rückwärts machen: Eine Hex-Darstellung, die mit xxd gewonnen wurde, kann mit "xxd -R" auch wieder zurück in eine Binärdatei umgewandelt werden. So kann ich also recht einfach editieren.

    Klingt das kompliziert? Das ist es nur auf den ersten Blick, dafür sehr flexibel handhabbar.

  • Selbst wenn Du dieselbe Diskette zweimal mit Kryoflux/Greaseweazle etc. ausliest, kommt nicht exakt das gleiche Image raus.

    Das liegt daran, dass an bestimmten Stellen der Diskette die Flussänderungen nicht genau definiert/geschrieben wurden.

    Das ist interessant. Aber würde hier dann ein normales Checksum-Vergleichs-Tool am PC diese beiden Images als gleich anzeigen oder nicht?

  • Aber würde hier dann ein normales Checksum-Vergleichs-Tool am PC diese beiden Images als gleich anzeigen oder nicht?

    Ich Vergleichs-Tool, welches nur die Binärdaten anschaut (und nicht die Inhalte interpretiert), würde das immer als verschieden anzeigen.

    Um es gleich anzuzeigen muss es in die Daten reinschauen und sie "interpretieren", um festzustellen, dass zum Beispiel kleinere zeitliche Abweichungen keinen Einfluß auf den Nutzdateninhalt haben. Hierzu bräuchte es eines sehr spezialisierten Tools.

  • Selbst wenn Du dieselbe Diskette zweimal mit Kryoflux/Greaseweazle etc. ausliest, kommt nicht exakt das gleiche Image raus.

    Das liegt daran, dass an bestimmten Stellen der Diskette die Flussänderungen nicht genau definiert/geschrieben wurden.

    Das ist interessant. Aber würde hier dann ein normales Checksum-Vergleichs-Tool am PC diese beiden Images als gleich anzeigen oder nicht?

    Hier mal ein Beispiel:

    Das ist ein Teil eines G64 als Textrepräsentation. Man sieht den Anfang von Spur 1 mit einem Sektorheader und Sektordaten. Ich habe die Trail Bytes von Header und Sektordaten rot markiert. Die Werte der Bytes sind nicht für das korrekte Lesen der Spur relevant, aber können sich im Vergleich unterscheiden. Man sieht, dass nach den Daten von Sektor 0 auch der write-splice ist und dort ein Byte 4A ist.

    Das gleiche gilt auch für den Track-Trail Bereich.

    Realistisch gibt es also mehrere Stufen von "gleich", die man haben möchte:

    - gleiche Zeiten bei Flussänderungen auf dem Medium

    - gleiche dekodierte Bytes (wie sie in den VIA der 1541 geshiftet werden)

    - gleiche Diskdaten (Sektorheader, Sektordaten)

    - gleiche Nutzdaten (Sektordaten)

    Für übliche Einleseroutinen sind "gleiche Diskdaten" ununterscheidbar, so dass für die meisten Fälle ein Vergleich auf dieser Stufe ausreicht.

    Für Disketten mit Kopierschutzsignaturen benötigt man gleiche dekodierte Bytes.

    Um eine Aussage zu treffen, ob dieselbe Diskette mehrfach eingelesen wurde benötigt man gleiche Zeiten bei Flussänderungen.

    z.B. gut gemasterte Originaldisketten sind gleich bei den dekodierten Bytes.