nibconv: Fehlerkorrekturen

Es gibt 105 Antworten in diesem Thema, welches 24.061 mal aufgerufen wurde. Der letzte Beitrag (2. März 2018 um 15:59) ist von r.cade.

  • Bitte melde dich an, um diesen Link zu sehen.:
    Idee, anknüpfend an das Aufbringen von Kopierschutzmerkmalen mittels nibconv oder g64conv durch "upconverting" D64->G64...

    Könnte man auch einen wählbaren Block als "weak bits"/unformatierter Sektor einbauen?

    Der Gedanke kam mir, weil Stephan (Klaus Scheuer) in sein Archiv mit Originalen mein Kopie-D64 von Clever & Smart gepackt hat, wo ich den Schutz rausgepatcht habe (weak bits auf T18S18), was ja nur so dreiviertelideal ist. Prinzipiell sollte es doch machbar sein, daraus ein G64 zu bauen, das diesen Sektor unformatiert gemacht bekommen hat und so die Schutzabfrage zufriedenstellt. Ein Original von dieser Disk aufzutreiben ist ansonsten anscheinend leider schwierig (von anderen Versionen in Compilations abgesehen), aus irgendwelchen Gründen scheint das Spiel eher selten zu sein.(*)


    (*) Dürfte sich nicht gut verkauft haben, das Spiel an sich ist ziemlich Mist...

  • Geht auch so schon. Man nehme eine Kopie der templates/stddisk.txt bzw stddisk2.txt und ändere den Sektor passend ab mit einen beliebigen Texteditorr. Suche nach "Trk 18 Sec 18" führt Dich ganz nahe an der richtigen Stelle.

    ---
    Meine Github-Projekte: Bitte melde dich an, um diesen Link zu sehen. Vice 3.2 Improved: Bitte melde dich an, um diesen Link zu sehen.
    1541 Ultimate II / Ultimate 64 Firmware Releases: Bitte melde dich an, um diesen Link zu sehen.
    1541 Ultimate II Update instructions: Bitte melde dich an, um diesen Link zu sehen.

  • Kriege ich nicht hin. Wenn ich einen solchen Sektor von woanders rüberkopiere, beschwert sich g64conv erstmal über die Tracklänge (klar), wenn ich die Länge in Bytes und Bits anpasse bis es ein multiple of 8 ist, hat das nicht den gewünschten Effekt. Lösche ich den Sektor ganz aus dem Textfile raus, macht g64conv daraus einen korrekten CBMDOS-formatierten leeren Block. (wtf?)

    Ich muss sagen, ich bin dadurch eher verwirrter als vorher. Wahrscheinlich verstehe ich irgendwas am G64-Format falsch, aber Immers und Neufeld helfen trotz wiederholter Lektüre leider auch nicht weiter. Ich kapiere ehrlich gesagt auch nicht wirklich, wie das in einem G64 abgebildet werden soll: egal was dort für diesen Sektor im G64 steht, ein abfragender Emulator wird doch immer die selben Bits/Bytes herauslesen, richtig? Oder gibt es einen Definitionszustand für Sektoren in einem G64 namens "nicht definiert"?

    Der Drivecode-Check auf weak bits/unformatierter Sektor in Clever & Smart liest T18S18 zweimal ein und vergleicht beide Lesedurchläufe. Sind sie gleich, ist das check fail (=Sektor ist formatiert, wie das bei Kopiern auf formatierte Disketten halt so ist...). Sind beide Durchläufe unterschiedlich, ist das check pass (=Sektor ist ab Werk unformatiert und gibt deswegen "Zufallsrauschen" zurück). Wie will man sowas in einem G64 abbilden? Übersehe ich hier was?

  • In a G64, the GCR bytes should be 0x00 in the weak areas. The drive emulation (and a real drive) will return semi-random bytes when these are read.

    --

    Peter Rittwage

    C64 Preservation Project

    Bitte melde dich an, um diesen Link zu sehen.

    NIBTools

    Bitte melde dich an, um diesen Link zu sehen.

  • In a G64, the GCR bytes should be 0x00 in the weak areas. The drive emulation (and a real drive) will return semi-random bytes when these are read.

    Ah, the thick plottens. :)
    0x00 where exactly, data block only, data and header including IDs and all, or...?

  • Anywhere you want. Raw GCR does not care. It need to be where the protection checks for it.

    --

    Peter Rittwage

    C64 Preservation Project

    Bitte melde dich an, um diesen Link zu sehen.

    NIBTools

    Bitte melde dich an, um diesen Link zu sehen.