nibconv: Fehlerkorrekturen

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

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

    Which probably should be the reason why the image works just fine in any emulator once it is attached. The emulators all "run" the CBM DOS in the emulated drive, so if this is a regular DOS function, the DOS takes care of the situation. The UI dialogs don't parse the image using an emulated DOS, they simply expect the image to look properly.

  • I have run into this before, and had no intention of supporting images written (or read with) with a misaligned drive intentionally or not! :)

    A real or emulated drive will step ahead and back looking for the data, but image tools should not have to do this.

    --

    Peter Rittwage

    C64 Preservation Project

    Bitte melde dich an, um diesen Link zu sehen.

    NIBTools

    Bitte melde dich an, um diesen Link zu sehen.

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

    YMMV, but I find the opposite being true: Take the attached geocalc64.g64 as an example. My nibconv-version (based on revision 620, not the one attached to this posting) converts iit to d64 without errors, your revision 633 fails at 2 sectors.

  • YMMV, but I find the opposite being true: Take the attached geocalc64.g64 as an example. My nibconv-version (based on revision 620, not the one attached to this posting) converts iit to d64 without errors, your revision 633 fails at 2 sectors.

    Hello Markus,

    I get the same exact same two errors on my version and your version, and build 623 from SVN which just has your patches to the old version. What am I missing?

    --

    Peter Rittwage

    C64 Preservation Project

    Bitte melde dich an, um diesen Link zu sehen.

    NIBTools

    Bitte melde dich an, um diesen Link zu sehen.

  • YMMV, but I find the opposite being true: Take the attached geocalc64.g64 as an example. My nibconv-version (based on revision 620, not the one attached to this posting) converts iit to d64 without errors, your revision 633 fails at 2 sectors.

    Actually, this is a strangely "defective" G64 image. It lacks the extra Kryoflux data in the header that I use to signal the re-sync process, but it is not synced. If I force it with "-$' it is error-free.

    --

    Peter Rittwage

    C64 Preservation Project

    Bitte melde dich an, um diesen Link zu sehen.

    NIBTools

    Bitte melde dich an, um diesen Link zu sehen.

  • Well, I see.

    Kryoflux can actually export g64 in two variants: With mastering information and without. So it is a bad idea to rely on the presence of the mastering information (which are the extension you mentioned).

    Anyway, the above sample file wasn't a kryoflux one. It is a valid g64 from nibtools (with geos 2.0 tail gaps) [no more info 'cause I did not create it]. I installed it in vice, and after installation it cannot be converted to d64 (before installation that was possible).

    What about forcing resync whenever d64 output is requested?

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

  • If you look at the data, track 18 sector 0 data sector has FF FF AA - this is invalid and bit shifted. nibread can't ever output this that I have ever seen... It should be FF FF 55.

    It's the same with the other "bad" sector. It just so happens it can be fixed with -$...

    I wonder if VICE is somehow doing this when writing back to the image (modifying). I would have to experiment with that. If so, that opens a big can of worms.

    --

    Peter Rittwage

    C64 Preservation Project

    Bitte melde dich an, um diesen Link zu sehen.

    NIBTools

    Bitte melde dich an, um diesen Link zu sehen.

  • I agree.

    Start with a perfectly aligned g64. Do some sector writes with vice (x64). By chance, you'll find theese bit shifts (not every write attempt, but sometimes).

    So you're right, nibconv does not create such files. But consider that g64 images are used by vice. And after use one may find it convenient to convert them to d64.

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

  • Agree that in these cases your method can be a better way. I will look at it further in the next weeks. Likely I will find another way to trigger the shifting... perhaps just from headers not found as you did.

    --

    Peter Rittwage

    C64 Preservation Project

    Bitte melde dich an, um diesen Link zu sehen.

    NIBTools

    Bitte melde dich an, um diesen Link zu sehen.

  • Well, for the time in between I am going to add 1 line of code to sync align tracks in case of d64 output.
    BTW: I've uploaded my current changes to github: Bitte melde dich an, um diesen Link zu sehen.

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

  • Makes sense.

    --

    Peter Rittwage

    C64 Preservation Project

    Bitte melde dich an, um diesen Link zu sehen.

    NIBTools

    Bitte melde dich an, um diesen Link zu sehen.

  • Es gab - bedingt durch meinen Patch, der Disketten, deren Sollinhalt von Track k tatsächlich auf Track k+n gespeichert ist, verarbeiten soll, leider eine Regression. Das d64 war fehlerhaft,

    Anbei eine Korrektur dieses Problems. Jetzt sollten die erzeugten d64 wieder stimmen.


    My patch that should process disks on which the content which should be on track k is actually stored on track k+n had a regression. The resulting d64 was buggy.

    Attached is a fixed version. The resulting d64 should now be correct again.

    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.

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

    Ich habe das heute mal auf einen Original C64 mit 1541 getestet - dazu mit einer Zoomfloppy und cbmfrmt & d64copy die d64 von MD 05/90 auf einer 5 1/4"-Diskette gebracht und dann mit den C64 ausprobiert. Siehe da: Sie funktioniert!
    In diesem Fall haben also die Emulatoren recht, weil sie sich wie der echte C64 mit 1541 verhalten.

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


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


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

    Ich habe das g64, welches auf diese Art von MD 04/90 erzeugt wurde, per Zoomfloppy und 1571 auf eine 5,25" Disk gebracht. Läuft problemlos auf echter Hardware - sowohl mit 1541 als auch 1571.

    Das ist die fehlende Bestätigung, dass das Template richtig ist, wenn es denn noch eine bedurfte.


    Für die Querleser: Der Fehler im Template ist ja inzwischen beseitigt.

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

  • Agree that in these cases your method can be a better way. I will look at it further in the next weeks. Likely I will find another way to trigger the shifting... perhaps just from headers not found as you did.

    One more problem with nibconv: Consider attached g64 image. It is created with nibread & nibconv (by someone unknown). Two bugs of the original nib have been corrected by me using g64conv (I assume the original disk had theese errors because of the age).
    Converting the g64 to d64 using nibconv you'll see that the whole tracks 1 to 5 (all sectors) are causing error 4 (DATA NOT FOUND). But that is no true, e. g.

    open 1,8,15
    open 2,8,2,"#"
    printBitte melde dich an, um diesen Link zu sehen.,"u1 2 0 1 0"

    can read e. g. Track 1 Sektor 0 without any error. The same with nibwrite and test with a real 1541 / 1571 Floppy - no error. Same result with Kryoflux and test on a real 1571. So the image should be ok.

    Currently I have no idea what triggers this problem.


    Edit: The problem was present in the g64 before editing with g64conv, too. But for some reason, I'll make examples with corrected images as they might be used by someone for other purposes.

    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.

    Einmal editiert, zuletzt von markusC64 (20. März 2016 um 20:13)

  • Sorry, but I am not seeing what you are seeing. The data sectors on those tracks are all corrupt (and not bit shifted).

    All data sectors start with 55. These start with 56, so they are never found.

    I cannot read these sectors, for example- try a Fast Hack'em fast copy, or just try to copy the files. You can't- the data is bad.


    >open 1,8,15
    >open 2,8,2,"#"
    >printBitte melde dich an, um diesen Link zu sehen.,"u1 2 0 1 0"

    This causes the drive to go to track 1 and wait for further instructions. It doesn't read from tracks 2-5 that are bad.

    Try:
    printBitte melde dich an, um diesen Link zu sehen.,"u1 2 0 2 0"

    You will see the error.

    --

    Peter Rittwage

    C64 Preservation Project

    Bitte melde dich an, um diesen Link zu sehen.

    NIBTools

    Bitte melde dich an, um diesen Link zu sehen.

  • With track 2, I am getting this read error, too.

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

  • With track 2, I am getting this read error, too.

    Yes, the data is corrupted in that image.

    --

    Peter Rittwage

    C64 Preservation Project

    Bitte melde dich an, um diesen Link zu sehen.

    NIBTools

    Bitte melde dich an, um diesen Link zu sehen.

  • Yes and no. I think that's the copy protection of TopDesk from Geos. This is a dump of an unused original Geos 2.5 Disk. Not used, not installed, just as mastered.

    So the curruption is wanted...

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

  • Yes and no. I think that's the copy protection of TopDesk from Geos. This is a dump of an unused original Geos 2.5 Disk. Not used, not installed, just as mastered.

    So the curruption is wanted...

    OK, so what is the problem?

    --

    Peter Rittwage

    C64 Preservation Project

    Bitte melde dich an, um diesen Link zu sehen.

    NIBTools

    Bitte melde dich an, um diesen Link zu sehen.