1.) Gibt es eine Alternative zu CBMXfer? Eventuell für ImgCopy?
CBMXFer ist ein GUI für die Kommandozeilentools von OpenCBM. ImgCopy ist eines dieser Tools, ob CBMXFer darauf zurückgreift weiss ich aus dem Kopf nicht. CBMXFer ist der verbesserte Nachfolger von GUI4CBM4Win, was also eher nicht eine gute Alternative wäre. Es gibt Leute, die schwören auf PRGMover (ich nicht so sehr). Ich persönlich bevorzuge die OpenCBM-Kommandozeilentools direkt auf der Kommandozeile.
Zitat
2.) Wie kann ich herausfinden, ob eine Diskette kopiergeschützt ist oder nicht?
Muss man halt "kennen". Manche Kopierschutzverfahren äussern sich in spezifischen Symptomen wenn sie normal laden oder von einer schlechten Kopie laden (wo also der Kopierschutz greift). Es gibt gesammelte Datenbanken, in denen festgehalten ist, was für Spiele welche Verfahren haben (sollte man ggf. wissen um z.B. nibtools korrekt einzusetzen). Grundsätzlich kann man sagen, dass es sich kaum lohnt, Originaldisketten gerade von grösseren Spieleherstellern nur als D64 zu kopieren, denn die sind mit grösserer Wahrscheinlichkeit kopiergeschützt (Ausnahmen bestätigen die Regel; natürlich gibt's auch haufenweise Originale, die garnicht kopiergeschützt sind). Und falls doch nicht, kann man aus dem extrahierten Image im Nachhinein immer noch ein D64 machen.
Zitat
3.) Wie kann ich herausfinden, welche Disketten 35 und welche 40 Tracks haben?
Siehe oben. Bestimmte Kopierschutzverfahren "leben" sowieso jenseits von Track 35, deswegen macht es bei low-level Kopien wenig Sinn, weniger als 40 Tracks zu lesen. Sollten dort keine Daten sein, kann man die überschüssigen Tracks hinterher immer noch abschneiden.
Zitat
4.) Wie kann ich herausfinden, welcher Chip in meinem Laufwerk verbaut ist?
Aufmachen und reinkucken.
Zitat
5.) Ist es bei alten Disketten besser, den "Warp-Mode" bei d64copy/imgcopy zu deaktivieren?
Ja. Wenn eine Diskette sich schwer lesen lässt, ist es durchaus sinnvoll, die Warp Level stufenweise zu reduzieren bis die Kopie zufriedenstellend ist. Ist von Fall zu Fall verschieden, macht aber im Zweifelsfall immer Sinn. Siehe dazu z.B. die Parameter von d64copy ("-t/--transfer"), dort ebenso die Lesewiederholung ("-r/--retry-count").
Manche alten Disketten sind so schwachbrüstig, das jeder Leseversuch andere Lesefehler in anderen Blöcken produziert. Jedes D64 von derselben Diskette wäre da also unterschiedlich. Es gibt Werkzeuge, die solche "vielen unterschiedlichen Versuche" zusammenführen können, sprich die "guten" Blöcke hernehmen und ein fehlerarmes bis fehlerfreies Image ausspucken.
Zitat
Vielen Dank, das hilft mir weiter. Wie kann ich herausfinden, ob der Fehler im Daten- oder im Leerbereich ist?
Mit entsprechenden Tools reinschauen und prüfen. "DirMaster" ist naheliegend, auf der Kommandozeile z.B. "d64scan" (Vorsicht, kann leider nicht mit 40Track-D64 umgehen). Im Grunde alles, was die BAM anzeigen kann, so dass man sieht ob der entsprechende fehlerhafte Block als belegt markiert ist. Und im Zweifelsfall durchaus auch den Block direkt anschauen, um zu checken, mit was für Daten man es da zu tun hat.
Wir reden hier natürlich von "eigenen" bzw. bespielten Leerdisketten, nicht von Originalen. Also typischerweise das, was man als D64 auslesen würde (falls man keine einzelnen Files ausliest).
Zitat
Sondern nur als G64 oder FDI?
Als irgendein low-level Format, also mit nibtools naheliegenderweise NIB (oder die komprimierte Variante NBZ), auch G64. Auch FDI und P64 sind low-level Formate. D64 ist ein high-level Format, das nützt nichts bei einem Kopierschutz.
(Der Witz an low-level Formaten ist der, dass der Kopierschutz de facto mitkopiert wird. Solche Formate enthalten simpel ausgedrückt (weitgehend) die GCR-Daten wie der Lesekopf der Floppy sie sieht, also auf "niedrige Ebene". Ein D64 enthält lediglich die "fertigen" Daten wie der C64 sie sieht, also auf "hoher Ebene".)