nibconv: Fehlerkorrekturen

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

  • Hi Markus - I have integrated the GCR and G64 patches. I left the GEOS patching D64 to G64 since that really should be a special forked tool you manage if that is OK.

    That's ok.

    The 2nd patch leaves one bug (no new bug): If the following conditions all are met, then parsing that sector fails:

    • Sync length is shorter than usual, just 10 - 16 bits.
    • Header sync is starting at end of track in image with 8 bits or less.
    • Header sync is therefore continued at start of track, again with 8 bits or less.

    Therefore the sync is not recognised neither at the end of the track nor at its start.

    Well, these conditions are very unlikely to occur, but there is a possible problem. That's the "FIXME"-Comment in the source code (with a typo in the german text after it).

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

  • Hey @Pete, that's great news. Sorry if this is taking place primarily in German. Not that we want to keep you out of the loop. :) Over the course of our exchange on this matter, Markus and I did in fact pretty much find ourselves in agreement there as well, i.e. that things like recreating or patching protections is beyond the scope of a converter tool (or nibscan or nibrepair, for that matter) and not quite within the spirit of "original data/software preservation" anyway, and thus best left to a fork or other tool.

    Von den Ausgaben gibt es in der Wolke auch gepatchte Versionen, denen die Kopierschutzabfrage fehlt. Solange ich nicht ausschließen kann, dass Du jene Version benutzt hast, ziehe ich diese Möglichkeit in Betracht.

    Getestet mit verschiedenen D64 aus verschiedenen Quellen, inklusive denen die sicher in die Wolke gelangt sind (ohne es jetzt geprüft zu haben - dazu zählen Forenmitglieder und weitere umtriebige Szeneleute, zweifelsohne ist das auch mal hochgeladen worden). Getestet vor allem auch mit meinen eigenen Dumps meiner selbstgekauften Originaldisketten von damals, von denen ich also genau weiss dass sie unmodifiziert sind.

    Was ich schon bemerkt habe ist dass Timex anscheinend JiffyDos überhaupt nicht mag, zumindest nicht im Emulator. Ohne JiffyDos startet es, mit JiffyDos nicht. Noch testen muss ich verschiedene Emulatoren und Versionen. Dass die Emulationsqualität von CCS64 sozusagen so simpel sein könnte, dass es "versehentlich" läuft ähnlich wie der Warpmodus-Trick in Vice, könnte plausibel sein. Trotzdem sollte das offensichtlich nicht so sein. Sehr schräg.

    Gibt's eigentlich einen Weg, aus dem Perl-Skript ein Executable zu machen, ohne Perl installiert zu haben (Perl2exe setzt das anscheinend voraus)?

  • Leider nicht, und ich habe jetzt sehr wenig Zeit - in 3 Minuten geht der Job los. Aber ich kann Dir eine exe machen, g64conv ist gerade einigermaßen stabil.
    Nur werde ich sicher im Forum nicht bei jeder Neuerung eine exe veröffentlichen.

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

  • Bitte sehr, eine exe von g64conv: Bitte melde dich an, um diesen Link zu sehen. (leider zu groß für das Forum),.

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

  • Na fein, besten Dank. :)

    Bisschen weiter getestet. MD Ausgabe 04/90 weigert sich beim Start von einem D64 (so wie man's erwarten würde...). MD 05/90 funktioniert trotz Timex, egal in welchem Emulator (ausser mit JiffyDos, dann geht nichts). Mal in den Loader schauen, ob da vielleicht von einem Monat auf den nächsten irgendwas runtergeschraubt oder deaktiviert wurde weil's beim Kunden wieder nur Probleme mit dem scheiss Kopierschutz gab...

  • Wie im Post 34 geschrieben habe ich auch mit jener Ausgabe getestet. Selbe Ergebnis. Nur mit aufgebrachten Kopierschutz gehts.
    Übrigens auch auf echter Hardware.

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

  • Ja, aber dass die 05 so geht... finden wir gerade raus, dass nur 09/89 und 04/90 überhaupt wirklich "geschützt" sind?


    Übrigens kriege ich 04/90 nicht per Template-Methode zum Laufen. In Vice (egal welches) geht er in den Schutz, fährt den Kopf zurück zu Track 18, und da wo dann vermutlich das weitere normale Laden stattfinden sollte, rödelt er endlos zwischen 18 und 20/21 hin und her. In Micro64 annähernd das gleiche, endet aber im typischen "protection invalid"-Screen (mit den hellgrauen Halbstreifen). In CCS64 ungefähr das gleiche. In Hoxs64 schafft er (mit Standard-Kernal) nichtmal das Laden vom G64, er bleibt bei "searching for boot" hängen (riecht nach Bug in Hoxs).

    Nachtrag:
    Mit deinem Text-Patch aus Post 36 geht's dagegen erfolgreich.

  • Thanks everyone, again, for the bug fixes. I have not spent much time on the code in recent times, and yes I am an "amateur" programmer. :)

    My very old track cycle search code tries to move the start of track to the firstfull byte of sync at the gap , Which what for easier writing purposes- but we are not limited by that. The code looking for "FF" bytes is not the best as you know Because We Can make sync it will miss Easily like 01111111 11111110 as happens in KF images.

    I will look into more parts of the code that depend on this and fix it possibly this summer if nobody else does before. :)

    --

    Peter Rittwage

    C64 Preservation Project

    Bitte melde dich an, um diesen Link zu sehen.

    NIBTools

    Bitte melde dich an, um diesen Link zu sehen.


  • Übrigens kriege ich 04/90 nicht per Template-Methode zum Laufen.
    [...]


    Nachtrag:
    Mit deinem Text-Patch aus Post 36 geht's dagegen erfolgreich.

    Danke. Ich werde beide Images vergleichen, dann wird sich der Fehler finden.

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

  • Scheint am Template zu liegen. Wenn ich den Track 18-Textpatch anstelle des dortigen Track 18 Sector 18 ins Template setze, dann funktioniert's.

    Erfolgsberichte:
    MagicDisk 09/98, GameOn 09 und 10/89 (jeweils beide Seiten), Timex V1. MagicDisk 04/90, GameOn 04 und 05/90 (jeweils erste Seite), Timex V2.
    Alle anderen Ausgaben scheinen (wie auch immer) ungeschützt zu sein. GoldenDisk-Ausgaben, noch nicht geprüft.

    (Cyanloader-Patch und dergleichen funktioniert ansonsten auch. Good job. :) )

  • Scheint am Template zu liegen. Wenn ich den Track 18-Textpatch anstelle des dortigen Track 18 Sector 18 ins Template setze, dann funktioniert's.

    Habe ich unabhängig auch bemerkt. Ist korrigiert.



    Alle anderen Ausgaben scheinen (wie auch immer) ungeschützt zu sein. GoldenDisk-Ausgaben, noch nicht geprüft.

    In diesem Lichte erscheint die Tatsache, dass vice jene Ausgaben im Turbomode starten kann im ganz anderen Licht - doch keine Ungenauigkeit im Vice?!

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

  • In diesem Lichte erscheint die Tatsache, dass vice jene Ausgaben im Turbomode starten kann im ganz anderen Licht - doch keine Ungenauigkeit im Vice?!

    Wenn ich das wüsste. Ein grosser Kopfkratzer.
    Ich hatte das vor einigen Jahren mal ausführlich durchgetestet. In keinem Emulator ging's ausser in Vice, und da nur im Release. Es war auch nachvollziehbar, dass er bei normaler Geschwindigkeit im Schutz hängenblieb, und mit Warp ins Menü durchsprang. Ich hatte sogar mal einen Haufen G64 aus den betroffenen D64 gebaut, allein als Marker um später noch nachvollziehen zu können welche Ausgaben betroffen sind. Sollte meine Erinnerung mich etwa dermassen trügen? So alt bin ich doch noch ganicht... und die D64 werden sich ja wohl kaum zwischenzeitlich selbst entschützt haben... ?(

  • Emulator hin, Emulator her - hier kann nur ein echter C64 und eine echte 1541 verraten, welches Verhalten richtig ist.

    Ich habe noch ein anderes Problem: Beigefügte (extra zum Testen hergestellte) g64 lässt sich weder mit nibconv noch mit 64copy in ein d64 umwandeln. Im Emulator funktioniert jene aber einwandfrei.

    Ist das Problem, dass der Soll-Inhalt von Track 1 auf Track 2 gelandet ist, der von Track 2 auf Track 3 usw.
    Eine echte 1541 stellt fest: Kopfposition eine Spur zu niedrig, korrigiert das und alles funktioniert, wie es soll. Im Emulator das gleiche.
    Gibt es einen g64 nach d64 Konverter, der das hinbekommt?

    Riecht jedenfalls wieder mal nach einem TODO für den nibconv...

    Dateien

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

    2 Mal editiert, zuletzt von markusC64 (5. März 2016 um 14:45)

  • Interessant. nibscan blanko sagt haufenweise "unformatted".
    DirMaster gibt garbage aus (wenig überraschend). micro64disktool produziert daraus ein komplett leeres 40Track-D64.
    Emulatoren (Vice, CCS64, Micro64, Hoxs64) können allesamt das Directory nicht lesen wenn man es im UI-Dialog anhängen will. Aber wenn es erstmal anhängt, können sie alle ganz normal das Directory und sonstwas laden... ist ja famos...

  • GoldenDisk-Ausgaben, noch nicht geprüft.

    Ausgaben 07, 08, 09/90 sind vertimexed, sieht (logischerweise) nach V2 aus. Da gibt's leider viel modifiziertes und gepatchtes, muss ich erst aussortieren bis ich verifizierbar originale Images identifiziert habe.

    Nicht dass es nötig wäre, aber Flimbo's Quest-D64 ist übrigens nicht mit dem TimexV2-Template erfolgreich behandelbar. Könnte das Timex "V3" sein?

  • Könnte sein. Track 18 sieht jedenfalls ganz anders aus. Ein großer Anteil der Sektoren ist mit 0 Bytes (echte 0, keine 00 gcr encodiert) gefüllt - inkl. Prüfsumme (auch "echte" 0).

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

  • Gibt es einen g64 nach d64 Konverter, der das hinbekommt?

    Das gute (13 Jahre) alte g2d.exe aus dem mnib-Paket kann es. Ergebnis ist ein korrektes D64 komplett identisch mit der Ausgangs-Testdiskette.

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

  • Danke. Den muss ich doch auch mal testen...

    Derweil habe ich in nibconv eine Heuristik eingebaut: Beim Lesen von Track 18 Sektor 0, was ganz am Anfang gemacht wird) wird im Fehlerfall der Track des gefundenen Sektors 0 genommen und daraus die Trackdistanz berechnet. Der Rest des Programms (inkl. des erneuten Versuches, Track 18 Sektor 0 zu lesen) wird mit jener Trackdistanz verschoben durchgeführt.

    Dateien

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

  • Hello MarkusC64, et al,

    Thank you for prompting me to look a little further at the parsing of the KF-type G64's (non-sync aligned). I ended up rewriting the handling of those so they are re-synced and then reprocessed completely through the alignment code as if they were NIB data, which helped further. KF G64's are all aligned to the index signal, which for many disks is just in the middle of data. This is a problem for most of my tools which expect it to be on sync boundary and aligned to the track gap or sector 0 (or other custom alignment).

    Anyway, give it a test if you want. It is better now, probably far from perfect. Parsing KF G64's results in less errors now than the code you submitted into extract_*. Please send me examples of bad parses so it can be further improved.

    --

    Peter Rittwage

    C64 Preservation Project

    Bitte melde dich an, um diesen Link zu sehen.

    NIBTools

    Bitte melde dich an, um diesen Link zu sehen.

  • Could you please tae a look at the foo.g64 of posting 53?

    I'll translate you our results shortly:

    Test case was: Convert foo.g64 to a d64 image.

    nibconv cannot read direcory sector. nibscan says "unformated".
    DirMaster outputs garbage.
    micro64disktool creates an empty 40 track d64.
    Emulators (Vice, CCS64, Micro64, Hoxs64) cannot display directory content in GUI Dialog for attaching image. When the image is attached, all of these can read the drectory and everything else.

    These results are surprising, aren't they?

    Before you question: That image has been made just for testing. The content which should be on track 1 is actually on track 2, the content that should be on track 2 is actually on track 3 and so on.

    A real 1541 can handle this situation without any problems: The DOS 2.6 finds that the head is initially one track below the desired track and corects it. Then all goes on just as if the disk has been formatted normally.


    Addition: One more thing. I have reports that the GEOS 128 version 2.0r Kryoflux Image (the one from above) cannot be written back to a 1571 using a ZoomFloppy and nibwrite (unknown version). Can you check that?

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

    Einmal editiert, zuletzt von markusC64 (8. März 2016 um 19:59)