nibread Allround-Optionen?

Zitat von Goethe

Was mache ich falsch?

Das G64 Format beinhaltet einige Positionsangaben, wo der Track in der Datei zu finden ist. Das führt dazu, dass das selbe g64 durch mehrere verschiedene Dateen darstellbar ist. Schon allein deswegen ist ein Binärvergleich selten sinnvoll.

Sync-Längen werden geschätzt durch verbrauchte Zeit (mehr kann die 1541/70/71 Hardware nicht).

Und dann gibt es noch die weak bits, die eine 1541/70/71 prinzipell auch nur bedingt lesen kann. Auch dort wird es bei mehreren Leseversuchen Unterschede geben.

Daher kann man Dumps eigentlich nur vergleichen, wenn man die per g64conv in eine textuelle Darstellung überführt.

PS: Kannst mir auch ein paar Dumps zukommen lassen. Ich würde dann mal schauen, wo die Unterschiede sind.

Zitat von Goethe

Die logische Folgefrage ist natürlich - woran (an welchen nibread Fehlermeldungen) erkenne ich, ob ich eine "1%" Disk erwischt habe...

Gar nicht. Ich habe hier das Spiel "Frankie crahed on jupiter" liegen als Original. Das kann keines der genannten Verfahren lauffähig kopieren. Und dennoch gibt es keinen für den Benutzer erkennbaren Fehler. Nur Kryoflux bekommt ein g64 hin, welches im Emulator läuft - aber nicht mehr zurückgeschrieben werden kann.
Ich fürchte, Du musst per VICE Indizien bekommen. Gerne noch weitere Emulatoren befragen.

Nachtrag:

Zitat von Goethe

nibread -e3 -E40 -v -V imagename

Dagegen ist nichts einzuwenden. Auch wenn "-e3" verzichtbar ist, weil der Default 10 ist. Und der Endtrack ist per Default 41, also noch gründlicher. "-v" ist eh Geschmackssache (seit einer neueren Version ist der Default offenbar verbose, die Variable wird im Programm mit 1 vorinitialisiert).
Und zu "-V" kann ich nichts sagen...

Nachtrag 2: Für Härtefälle "imagename" mit der Endung ".nb2" versehen (aber bitte nur dann). Dann wird jeder Track in allen 4 Geschwindigkeiten mehrfach gelesen und alles in der .nb2 gespeichert. Halftracks inklusive.
Leider hat noch keiner eine echte Idee gehabt, diese Fülle an Informationen bestmöglich auszuwerten. "nibconv" geht zwar, stellt sich aber nicht besser an als bei einen normalen ".nib". Sei es, wie es sei. Man liest so jedenfalls alles ein, was die Floppy liefern kann.

Zitat von Goethe

Das Spiel funktioniert... Getestet mit XAP1541-Kabel und WinVice3 und "Real IEC Device"... Allerdings musste ich "loading from a 1541 drive?" mit "no" beantworten.
Bin jetzt gerade zu faul den echten C64 anzuschließen.

Was mache ich falsch?

Du verwendest einen fiesen Hack im Emulator, der vollständig inkompatibel zu sämtlichen Fastloadern ist.

Zitat von Goethe

Das Spiel funktioniert... Getestet mit XAP1541-Kabel und WinVice3 und "Real IEC Device"... Allerdings musste ich "loading from a 1541 drive?" mit "no" beantworten.
Bin jetzt gerade zu faul den echten C64 anzuschließen.

Was mache ich falsch?

Die Verbindung via "Real IEC Device" ist zu simpel um eine vernünftige Verbindung zu gewährleisten (u.A. keine Fastloader, siehe Unseen), und eigentlich in der Praxis wenig probat. Das ist etwa dasselbe als würdest du Vice mit True Drive Emulation auf Off betreiben, auch da läuft das Spiel wenn du "loading from a 1541" mit "no" abhakst.

Kannst du eines der Auslese-Ergebnisse dieser Disk mal hier anhängen?

Zitat von Goethe

Die Härtefalloption image.nb2 ist ja dann auch nicht wirklich sinnvoll, wenn man mit der Infoflut nichts anfangen kann.

Nein. Sollte es mal passieren, dass die Disk aufgibt, so wäre die .nb2 das einzige, was man noch hat. Und wenn da alles drin ist, was die Floppy zu lesen imstande ist, so besteht Grund zur Hoffnung, dass man damit später was anfangen kann.

Nachtrag 1: Ich habe exemlarisch mal Maniac Mansion verglichen: Wie zu erwarten variieren die Sync-Längen zwischen den Versuchen. Und bei Track 37ff. wo der Kopeirschutz ist, gehen die Ausleseversuche weit auseinander, weil er sich mal für Speed 0 und mal für Speed 1 entschieden hat. Hier ist ein .nb2 hilfreich, da dort alle Speeds drin sind. Wenn man dann irgendwann bemerkt, dass er sich für die falsche Speed entschieden hat, kann man aus der Datei die richtige extrahieren. Offenbar beinhalten die Tracks > 36 so viele ungültige Daten, dass eine exakte Speedbestimmung schwer ist. Wobei es auch vorkommen könnte, das Tracks von Schreibgerät bei der Produktion gar nicht beschrieben worden sind und Zufallsinhalt enthalten.

Nachtrag 2: Auf den Tracks 1 bis 36 sind die Daten bis auf Synclänge identisch. Bei Tracks 37 - Ende bekomme ich so viele Unterschiede, dass ich einen Vergleich nicht hinbekomme.

Zitat von Goethe

Moonmist scheint OK zu sein. Bin mir nicht sicher, ob Infocom Spiele überhaupt Kopierschutz hatten.

Nein, hatten sie nicht (jedenfalls keinen "harten", buchstäblichen, Schutz vor dem Kopieren der Disk...). Das Auslesen als G64 scheint mir gut gelaufen zu sein, daraus resultierende D64 sind zumindest identisch. Allerdings scheint mir die Disk an sich selbst durch was auch immer kaputtgeschrieben zu sein. Auf Track 35 sind 11 Blocks quasi leerformatiert (S0 bis S10) in denen eigentlich Spieldaten stehen sollten, beim Spielen würde das also an irgendeinem Punkt abhusten. Ich bin kein Fachmann für nibread, denke aber nicht dass sich dieses Fehlerbild durch falsches Auslesen mit nibread erzielen liesse, insofern würde ich auf echten Diskfehler tippen, so als ob jemand einen leeren Track 35 drauf zu kopieren versucht hat.

Edit:
Halt, Kommando zurück. Die Diskette ist völlig in Ordnung und auf's Bit identisch mit anderen Originalen. Man muss nur vernünftige Tools benutzen...

(mit micro64disktool konvertiert erhält man ein 40Track-D64 in dem Track 35 die Originaldaten korrekt enthält, konvertiert man das mit DirMaster auf 35 Tracks wird Track 35 anscheinend geplättet - konvertiert man mit nibconv erhält man gleich ein 35Track-D64...)

Zitat von Goethe

wie kann man identifizieren, welcher Kopierschutz (falls überhaupt) vorhanden ist

Mit etwas Erfahrung merkt man das an prägnanten Verhaltensweisen oder Meldungen bei erfolgreichem oder erfolglosem Passieren eines Kopierschutzes, oder weiss einfach was man zu erwarten hat wenn ein bestimmter Hersteller aus einer bestimmten Ära vorliegt. Ein Blick z.B. in diese Datenbank hilft allerdings auch:

http://c64preservation.com/dp.php?pg=database

Zitat von Goethe

Welche Tools nutzt ihr, um entstandende G64 Dateien inhaltlich zu begutachten bzw. zu vergleichen?

g64conv und dann ein einfaches Tool, welches Text-Dateen vergleicht.

Zitat von Goethe

elche Tools gibt es, um aus einer NB2 Datei mit verschiedenen Varianten dann zielgerichtet ein G64 zu erzeugen?
Hier müsste es dann ja ein Tool geben, bei dem ich anhand verschiedener Parameter verschiedene Sets der Rohdaten (z.B. mit/ohne Halftracks, verschiedene Speedparameter) für die Nutzung im G64 auswähle.

nibconv macht ein g64, welches eigentlich gleich sein sollte wie eins, welches aus einer nib erstellt worden ist.
Wenn das versagt, würde ich den Quelltext mir so patchen, dass er für gwählte Tracks eine fest einprogrammierte Abweichung machen würde (k. Auslesebersuch in Speed i nehmen).
Schwer wird es "nur", wenn auf einen rack mehrere Speeds vorkommen... dann wäre ich ratlos... und hoffen, dass ich irgendwie an die Streamiles eines Dumps mit Kryoflux rankomme. Oder wenn ich die Disk hätte einen solchen Dump selbst machen. Allerdings soll das nur bei wenigen Spielen vorkommen...

Zitat von Goethe

Falls es keine "logische" Erklärung gibt, würde ich mal probieren, ein verifiziertes G64 des Spiels auf die Originaldisk neu aufzuspielen.

Es gibt keinen Grund, die Originaldisk herzunehmen. Du kannst eine einfach "Leerdisk" nehmen.

Zitat von Goethe

Speziell zu Alter Ego Female - woran könnte es liegen, dass das Spiel nicht mehr funktioniert, obwohl doch zumindest laut Auslesevorgang "alles ok" ist, speziell auch Track 17, bei dem Vice dann stehen bleibt?

Das ist ein Activision-Spiel mit Xemag (Fat Track 35). Ich könnte es spontan nicht beschwören, aber gut möglich dass das der zuschlagende Kopierschutz ist. Ist dann also nicht hinreichend gut ausgelesen (und irgendwie habe ich speziell Alter Ego da als besonders kitzelig in dunkler Erinnerung). Mach mal ein D64 daraus (wo per Definition dieser Schutz nicht existieren kann) und starte das Spiel davon. Ich würde fast erwarten, dass der Kopf während des Starts nach Track 35 fährt um den Schutz (erfolglos) zu prüfen, dann nach 17 wo es als "Kopie" dann endet.

Lese ich das richtig ( http://c64preservation.com/dp.php?pg=eafat )? Wenn ja, dan würde es ja reichen, den Track einzulesen und rack 36 durch eien Kopie von Track 35 im Image zu ersetzen, um die perfekte Kopie zu haben.
Alignment und Daten wären dann perfekt gleich, wie es laut der Seite sein sollte.

Nuja, wenn dann das: http://c64preservation.com/dp.php?pg=xemag2
Aber da steht natürlich fast das gleiche, von den Tracknummern und Keiths Disassembly mal abgesehen. Probier's halt mal aus, versuch macht kluch.

Die ehemals beigefügte Version habe ich in der F64 Wolke gefunden. Sie müsste eigentlich funktionieren.

PS: .nbz ist eine komprimierte Version von .nib. Kann per nibconv und nibwrite wie eine .nib benutzt werden.

Wenn ich Deinen Dump nehme und Track 17 von der Version aus der Wolke ersetzend einfüge ins g64, so kommt das VICE über die Kopeirschutzabfrage hinweg.

Sieht ein bisschen so aus als wären auf Track 17 Spielstanddaten. Jedenfalls gibt's da Namensunterschiede (Spielernamen?) und einige unterschiedliche Daten/Blöcke. Ansonsten Unterschiede nur noch im Directory.

Mag sein. Und es könnte sein, wenn man eine Floppy hat, die auffällig von 300 RPM anweicht, dass dann noch etwas anderes auf den Track gebrickt wird. Der Spielstand selbst muss ja vom Hersteller eingeplant gewesen sein, dass der geschrieben wird.

Bis jetzt wissen wir ja nur, dass irgend etwas auf Track 17 den stört.