nibconv: Fehlerkorrekturen

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.

Zitat von markusC64

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)?

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

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.

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

Zitat von markusC64

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

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

Zitat von GenerationCBM

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?

Zitat von markusC64

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.

http://markus.brenner.de/binary/mnib35.zip
http://markus.brenner.de/binary/mnib_cvs.zip

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.