Alles anzeigenOK. Kleiner Ausflug zum Kopierschutz von Burstnibbler 1.5 / 1.9: Burstnibbler 1.9 hat den selben Kopierschutz wie die Version 1.5.
Nun denn, machen wir es doch etwas ausführlicher: Turbonibbler 2.2 hat keinen Kopierschutz.
Burstnibbler 1.5/1.9 hat einen Autostart. Nach dem Programmstart wird Track 2 Sektor 0 gescuht. Nach dem Erkennen des Blockheaders wird die Geschwindigkeit auf 0 umgestellt und der Datenblock gelesen. Dabei wird geprüft, ob die Sync-Länge genügeng lang ist und ob dabei kein Lesefehler auftritt. Ist beides erfüllt, wird von einem Original ausgegangen.
Ein Test auf zu langer Sync findet nur implizit statt: Wenn es einen Overflow bei der Messung gibt und dann ein zu kleienr Wert rauskommt, ist das Messergebnis hal: Sync zu kurz.
Bei Turbonibbler 4.0 st der Kopierschutz ähnlich, aber anders implementiert: Die Datei selbst ist nur 1 Block lang und startet per Autostart den Mini-Lader.
Letzterer führt per "B-E" den Block 18/4 (bzw. 18/3) aus. Dort drin versteckt ist eine Laderoutine, die den eigentlichen Turbonibbler 4.0 zum C64 überträgt, beginnend ab einen fest einkodierten Block. Kommt er beim Verfolgen der Blockchain auf Track 10 an, so wird das gleiche Verfahren zum Laden des Blocks genutzt wir bei Kopierschutz von Burstnibbler 1.5/1.9: Datenblock in Speed 0, Synclängenprüfung (wieder ohne explizite Obergrenze), und zwar während der Übertragung zum C64.
So kommt es, dass Turbonibbler 4.0 nach dem Laden im C64 ohne weiteren Kopierschutz zu finden ist.
Von meiner D64 von Burstnibbler 1.9 weiß ich, dass Filemaster den gleichen Kopierschutz wie Turbonibbler 4.0 hat, besitze aber den Inhalt der Sektoren mit falscher Schreibgeschwindigkeit nicht.
Auffällig ist bei der BN 1.5-Diskette:
Bei den Tracks 2 bis 10 fehlen jeweils die Sektoren 1, 6 und 11. Dafür sind die Sektoren 0, 5 und 10 jeweils mit falscher Schreibgeshwindigkeit geschrieben und verbrauchen so mehr Platz.
Dadurch, dass jene Tracks relativ leer sind (im Vergleich zu normal), kann es passieren, dass eine Kopie dann zu große Lücken zwischen den Sektoren hat (wenn die nicht gleichverteilt werden über den Track), so dass de DOS-Routine, welche den nächsten Sync abwartet, aufgibt (jene hat ein Timeout von 20ms).
Nachtrag: Eine Kopie kann also an 3 Dingen scheitern:
(1) Mehrere Speeds pro Track
(2) Synclängenprüfung
(3) Verteilung der Lücken
Danke für die Info.
Ich glabe, dass stand sogar in der Burst Nibbler Anleitung,
dass genaue Synclängenprüfung nicht kopiert werden kann.