C64 Image Tester gesucht

  • Hidiho,


    meine Skripte zum Sichern von Floppies via Kryoflux nehmen langsam gestalt an (wenn man blos etwas mehr Zeit haette...)


    Anbei 3 Archive mit Images, die ich mit Kryoflux erstellt habe. Da ich selbst keinen 64er mehr habe, kann ich die nicht testen (und einen Emulator hab' ich auch noch nicht installiert). Die Namen der Archive leiten sich von dem Label der Diskette ab (insofern vorhanden und lesbar).


    Wenn ein Commodore-Enthusiast mal etwas Zeit hat: Bitte die Archive mal angucken und beurteilen, inwiefern die Images brauchbar sind.


    Da ich keine Ahnung habe, welche Archivformate unter CBM-Juengern geschaetzt werden, hab' ich meine Skripte erstmal alle erzeugen lassen. Fuer Hinweise wie "CBM_DOS und CBM_GCR reicht" waere ich dankbar, da das natuerlich Speicherplatz spart.


    -- Klaus


  • DOTC sieht schon mal perfekt aus ... alle Inhaltsverzeichnisse da ... starten einwandfrei ... GCR sind auch OK ... checke jetzt nochmal die Integrität der .d64 ... Frage: Warum sind das so viele .img ... 12 x .d64 und 2 x g64 ?... soll das Zurückschreiben auf Diskette auch getestet werden?


    Gruß,


    Erik

  • DOTC:


    ... die .d64 sind OK (Integrität geprüft; lediglich BAM verändert ... 0 Blocks free ... unauffällig & normal).


    ... bei den beiden GCR-Images (.g64) wären wir dann schon tief in der KRYOFLUX etc. pp.-Thematik ... ;-)


    ... siehe Anhang!


    ... ich freue mich schon auf weitere Beiträge in diesem Thread ... ;-)

  • Fertig_3 ... Images ... so, weiter geht es ... im Prinzip das, was ich schon vorher geschrieben habe.


    ... .d64 alle OK (slapshot, 1 Block, ist wohl ein übriggebliebenes File)


    ... GCR ... siehe Anhang ... auch da tauchen vereinzelt "Fehlerhinweise" auf, wie


    GCR decode error in data block


    Unknown ID found ($Hexwert)


    ERROR 20, 22, 27 ... etc.

  • DOTC ... .g64 ... Vergleichsimage ... V-MAX gekryofluxed ... ohne


    GCR decode error in data block

    ?


    Nicht böse sein, aber ganze Sätze wären jetzt irgendwie hilfreicher ;)


    Zur Info: Kryoflux meldet mir bei den C64 Disketten bei fast jeder Spur "Data is hidden in unused parts of the block header."


    Die Block header werden ja in den "normalen" Images, die nur die "normalen" Daten beinhalten nicht mitgespeichert, daherkommen da wahrscheinlich keine Fehlermeldungen. Aber schonmal gut zu wissen, dass die Images bei Dir offenbar gut funktionieren, also die Daten korrekt sind.


    Die GCR Images enthalten hingegen den kompletten GCR Code aller Spuren, inclusive den Spurbeginn-Marker, sowie auch aller Blockheader, so wie sie von der Spur gelesen wurden. Wenn dann irgendwo Datenbits in Datenbereichen gefunden wurden, die normalerweise unbenutzt sind, so stehen die natürlich auch drin.


    Die Frage ist jetzt, was "unused parts" heisst: Sind es Bereiche, die Aufgrund des Verhaltens der C64 Disk Drives normalerweise Übersprungen werden (sowohl beim Lesen, als auch beim Schreiben), dann findet sich in dem Bereich zufälliger Müll, der getrost ignoriert werden kann.


    Heisst "unused parts" aber, dass in dem Bereich normalerweise ein bestimmtes Bitmuster stehen sollte, aber ein anderes gefunden wurde, dann stellt sich die Frage, warum die da stehen.


    Wenn alle Datenblöcke von Kryoflux korrekt gelesen wurden, gehe ich mal davon aus, dass er auch die Bits der Header korrekt liest.


    Es kann sich z.B. um absichtlich plazierte Datenbits eines Kopierschutzes handeln. Möglich ist auch, dass es einfach nur Müll von früheren Verwendungen der Floppy ist. Deswegen wollte ich ja auch gerne, dass sich ein 64er/CBM Spezi die Images mal anguckt und bewertet (und uns vielleicht noch etwas Interessantes zu den CBM Eigenheiten erzählen kann).


    -- Klaus

  • Es kann sich z.B. um absichtlich plazierte Datenbits eines Kopierschutzes handeln.

    Damit meinst du aber sicher keine sector-gap bytes ... oder? Die gab es meines Wissens auf der C64-Schiene nicht (als copy protection scheme) ... lasse mich gerne belehren.

  • Da in der 1541 Programmcode geladen und ausgeführt werden kann, und dieser beliebigen Zugriff auf alle I/O Ports hat, ist damit prinzipiell alles machbar, was physikalisch geht.
    Selbst die GCR-Kodierung und Dekodoerung wird in der 1541 in Software ausgeführt.
    Es gibt beliebigen Zugriff auf so grundlegende Dinge wie die Schreib/Lese-Logik, die Schrittmotorsteuerung, usw.
    Da sind der Phantasie kaum Grenzen gesetzt.