Ich hatte mir vor Jahren extra wegen des legendären "Option Board" (ich habe die "normale" und die "Deluxe" Version) einen separaten alten DOS-PC zugelegt. Das ISA Board funktioniert nur mit CPUs unter 33 MHZ Taktfrequenz. Und der Rechner kommt jetzt in die Jahre und erkennt FDDs nicht mehr zuverlässig. Meine Frage ist nun, wie relevant ist eigentlich noch das "Option Board (Deluxe)" in Anbetracht der modernen Flux Lösungen?
"The Option Board is an add-in disk controller for the IBM PC that can defeat weak-bits schemes, custom formats, long tracks, you name it. 99% of floppies with disk-based protections made before 1990 can be duplicated perfectly by the Option Board ... Transcopy stands for "Transition Copier", which describes how it works; it simply copies the flux reversals (transitions) on the disk, without a care as to what the data on the disc actually is."
Gibt es systembedingt irgend etwas, was das "Option Board" besser kann als KryoFlux, SuperCard und FluxTeen ? "Weak Bits" Support?
"Option Board" überflüssig durch KryoFlux, SuperCard und FluxTeen ?
-
Gibt es systembedingt irgend etwas, was das "Option Board" systembedingt besser kann als KryoFlux,SuperCard und FluxTeen ?
Da es ja meistens ums Lesen von Disketten geht, kann keine Erweiterung systembedingt mehr Informationen liefern als das Floppylaufwerk.
Von da her ist die nachgelagerte Software der entscheidene Teil.
Und daher würde ich auf ein aktuelles System setzen für das auch Support vorhanden ist.
Was sind Weak Bits?
-
Wenn Du die Seite ganz herunterscrollst, kannst Du mein Option Board sehen: http://www.z80.eu/transfercpm.html
Relevant ist es wohl nicht für viele, eben weil die Steckkarten nicht so verbreitet waren, denke in den USA sah das besser aus.
Die Transcopy - Image-Dateien hatten leider fast bei jedem Versionssprung auch eine andere Struktur, das kommt noch erschwerend hinzu.
Die Kopien sind aber zumindest so gut, dass jeglicher Kopierschutz mitkopiert wird, auch z.B. bei solchen schweren Fällen wie bei "Visi On" von Visicorp.
Ich suche schon lange nach einer Möglichkeit, die .TC Dateien in ein anderes Format umwandeln zu können.
-
Weak Bits werden mal als 0, mal als 1 gelesen.
-
Weak Bits werden mal als 0, mal als 1 gelesen.
Äh, warum, wozu? Absicht oder zufällig?
-
Wenn Du die Seite ganz herunterscrollst, kannst Du mein Option Board sehen: http://www.z80.eu/transfercpm.html
Die sieht ganz anders aus als hier
Hardware / Central Point Software / Deluxe Option Board // retrocmp / retro computing
Oder ist das Unterschied zwischen Normal und Deluxe?
-
Weak Bits werden mal als 0, mal als 1 gelesen.
Äh, warum, wozu? Absicht oder zufällig?
Absicht. Das war eine Variante des Kopierschutzes für Floppydisks, die mit den damals gängigen Laufwerken (eigentlich) nicht reproduziert, sondern nur im Kopierwerk des Herstellers erzeugt werden konnte.
Die Logik dahinter:
Die Weak Bits wurden so schwach geschrieben, dass sie beim Lesevorgang genau an der Grenze zwischen "0" und "1" lagen. Dadurch wurde, je nach Zufall, vom Laufwerkskopf bei mehreren Durchläufen eben manchmal eine 0, manchmal eine 1 erkannt und geliefert. Die Kopierschutzroutine hat das genutzt und eine gewisse Anzahl [y] an Leseversuchen durchgeführt. Waren dabei nicht mindestens [1 bis x] Ergebnisse unterschiedlich (wegen der kippelnden Bits), dann wurde das Programm abgebrochen, weil damit eine vorliegende Disketten-Kopie erkannt wurde. Die gängigen Laufwerke und Kopierprogramme konnten nämlich nur "richtige" 1er und 0er schreiben, so dass bei einer Kopie eben kein solches Bit-"Kippeln" auftrat.
Diese Art des Kopierschutzes hatte vor allem zwei Probleme:
(1) Die Magnetisierung musste an der vorgesehenen Stelle der Diskette verlässlich genug und dauerhaft nahe am Kipp-Punkt zwischen 0 und 1 liegen, damit *jedes* Laufwerk bei mindestens einem von x Leseversuchen ein vom Rest abweichendes Ergebnis las. Das konnte schon damals aufgrund von Bauteiletoleranzen bei den Leseköpfen schiefgehen; was die jahrzehntelange Lagerung solcher Originaldisketten dann noch mit solch grenzwertiger Magnetisierung macht, kann sich jeder vorstellen, der heute noch so ein Original in die Hand kriegt.
(2) Dieser Kopierschutz ist eben nur genau DAS - ein KOPIERschutz, der gegen die gängigsten Kopierprogramme und Nibbler schützen sollte. Gegen Cracker war das naturgemäß nutzlos. Da musste nur die entsprechende Prüfroutine identifiziert und entweder rausgeworfen oder mit dem vorgesehenen "Erfolgsergebnis" vorbelegt werden (falls dieser Wert als Flag mehrfach im späteren Programmablauf abgefragt oder gar als Decoder für gecrypteten Programmcode verwendet wurde). Dabei half, dass (a) die Weak Bits i.a. in einem ansonsten nicht für andere Daten genutzten Block oder Bereich aufgebracht wurden und (b) durch das i.a. nicht vorhersagbare Ergebnis des Bit-"Kippelns" aus den x Leseversuchen kein immer gleiches Byte / Word als verlässlicher Dekodierwert für gecrypteten Code erzeugt werden konnte.
Eine andere Form des Kopierschutzes, der lange nur im Kopierwerk aufgebracht werden konnte, war das Schreiben mit zu breiter Spur. Dadurch wurden auf der Diskette gleich 2 oder 3 nebeneinander liegende Spuren gleichzeitig und exakt parallel mit den gleichen Daten beschrieben. Dadurch konnte man durch Spurwechsel beim Lesen des Tracks über direkte Programmierung des Steppermotors i.a. ohne Fehler den Spurinhalt auslesen, während Kopien (zumindest beim C64, aufgrund Fehlens einer Hardsektorierung / Indexlochauswertung) parallele Spuren nie versatzfrei exakt identisch beschreiben konnten. Da führten dann die programmierten Spurwechsel zu Datenmüll und Absturz, wenn in das geladene Ergebnis ein Einsprung erfolgte...
Hach, das weckt Erinnerungen an selige C64-Zeiten... Custom Tape Formate (Pavloda & Co.), Bad Block Diskformate, Autostart durch "Überladen" der 64K-Grenze, Nutzung "illegaler" Opcodes beim 6510, usw. Nix, was man nicht knacken konnte, der ewige Wettlauf... herrlich, zumindest in der Rückschau.
-
Wenn Du die Seite ganz herunterscrollst, kannst Du mein Option Board sehen: http://www.z80.eu/transfercpm.html
Die sieht ganz anders aus als hier
https://retrocmp.de/hardware/optionboard/dob.htm
Oder ist das Unterschied zwischen Normal und Deluxe?
Ja, die (anderen) Karten dort sind "jünger", mit der abgebildeten Karte geht wohl auch HD-Disketten, nicht nur DD-Disketten zu kopieren.
-
Alles anzeigen
Weak Bits werden mal als 0, mal als 1 gelesen.
Äh, warum, wozu? Absicht oder zufällig?
.
.
.
Hach, das weckt Erinnerungen an selige C64-Zeiten... Custom Tape Formate (Pavloda & Co.), Bad Block Diskformate, Autostart durch "Überladen" der 64K-Grenze, Nutzung "illegaler" Opcodes beim 6510, usw. Nix, was man nicht knacken konnte, der ewige Wettlauf... herrlich, zumindest in der Rückschau.
Würde gern mehr solcher Details lesen ... und ggf auch auf meiner Webseite übernehmen
-
Was sind Weak Bits?
Das sind Bits, die unter Verletzung der Codierungsregeln (z.B. MFM) auf die Diskette geschrieben wurden. Beim Zurücklesen bekommen diese Bits einen zufälligen Zustand. Kopiert man eine solche Diskette, nehmen sie natürlich (weil beim Kopieren die Verletzung nicht mitkopiert wird) einen festen Zustand ein - Kann man für Kopierschutz nutzen, denn man kann so eindeutig eine kopierte Diskette erkennen.
-
Soweit ich weiß, haben "Weak Bits" nichts mit der geschriebenen magnetischen Feldstärke ("Stärke der Magnetisierung") zu tun, sondern mit dem Timing der Magnetisierungswechsel. Das Timing der Wechsel wird genau in den Grenzbereich der beiden Zeitfenster gesetzt, die beim Lesen den Unterschied zwischen einer 0 und einer 1 ausmachen. Dadurch entsteht an dieser Stelle ein zufälliges Leseergebnis. In der grafischen Darstellung der "flux transitions" von Kryoflux oder HxCFloppyEmulator lassen sich diese Stellen leicht erkennen.
Normale Floppycontroller halten beim Schreiben ihr Timing präzise ein, denn schließlich ist es das Ziel, die Daten einwandfrei reproduzierbar aufzuzeichnen.Eine "schwache Magnetisierung" wäre wegen der Vielzahl an Laufwerken mit ihren unterschiedlich rauschenden Verstärkern sowie der Anfälligkeit gegenüber schon geringsten externen magnetischen Einflüssen für diese Kopierschutzmethode ungeeignet.
-
Soweit ich weiß, haben "Weak Bits" nichts mit der geschriebenen magnetischen Feldstärke ("Stärke der Magnetisierung") zu tun, sondern mit dem Timing der Magnetisierungswechsel. Das Timing der Wechsel wird genau in den Grenzbereich der beiden Zeitfenster gesetzt, die beim Lesen den Unterschied zwischen einer 0 und einer 1 ausmachen.
Ah, danke für die Klarstellung, das klingt logisch! Wobei gerade die hardwarenahen / hardwarebasierten Kopierschutzmechanismen desöfteren Probleme je nach vorhandener Gerätschaft machten. Ich hatte mich seinerzeit mit diversen Kopierschutzvarianten vor allem auf dem C64 "beschäftigt", ist nun aber schon fast 40 Jahre her, da verklärt sich doch manches. Zumal die "Weak Bits", wie geschrieben, nur den drögen Diskettenkopierern das Leben schwermachen sollten / konnten, indem sie 1:1-Kopien der Originaldisketten erheblich erschwerten. Solche Schutzmaßnahmen haben i.a. beim Cracken nur für ein kurzes Schmunzeln gesorgt - da das Bit-Lese-Ergebnis eben wirklich relativ zufällig als 0 oder 1 ausging, konnte nur das Vorhandensein von Weak Bits geprüft und ggf. ein Flag gesetzt oder passend verzweigt werden. Also weitgehend "copy-proof", aber in keinster Weise "crack-proof". Aber das ginge jetzt zu tief in die Materie, auch noch darüber zu philosophieren, wie man die entsprechenden Schutzroutinen geeignet zu verbergen versuchte - mehr als ein Versuch war das jedenfalls nie...
Auf jeden Fall wäre eine aktuelle Version einer Kopier- Hard-und-Software interessant, die auch mit solchen Abstrusitäten wie Weak Bits und Parallel-Tracks zurechtkommt, damit man wirklich originalidentische Kopien erzeugen könnte, um eben nicht irgendwann nur noch "kopierschutzbefreite" Versionen zu haben...
-
Gibt es systembedingt irgend etwas, was das "Option Board" systembedingt besser kann als KryoFlux,SuperCard und FluxTeen ?
Da es ja meistens ums Lesen von Disketten geht, kann keine Erweiterung systembedingt mehr Informationen liefern als das Floppylaufwerk.
Von da her ist die nachgelagerte Software der entscheidene Teil.
Und daher würde ich auf ein aktuelles System setzen für das auch Support vorhanden ist.
Die Herausforderung ist hier eher das Zurück-Schreiben auf eine neue (physikalische) Diskette (ohne Verlust des Kopierschutzes). Images für Emulatoren erzeugen ist da wohl weit einfacher zu realisieren.
-
Die Kopien sind aber zumindest so gut, dass jeglicher Kopierschutz mitkopiert wird, auch z.B. bei solchen schweren Fällen wie bei "Visi On" von Visicorp.
Ich suche schon lange nach einer Möglichkeit, die .TC Dateien in ein anderes Format umwandeln zu können.
Das "jeglicher Kopierschutz mitkopiert wird" halte ich etwas für übertrieben. Siehe meine Versuche beim Kopieren von "Lemmings".
https://www.forum64.de/index.p…elche-methoden-und-tools/
https://www.forum64.de/index.p…oflux-weak-bit-protection
Das Gerücht mit der Sabotage der eigenen Software durch Centralpoint ist allgemein bekannt:
"From the "I Thought They Couldn't Be Bought" file:For you users of the COPYIIPC OPTION BOARD, I just found out some
disheartening news. I have a legit copy of ALACRITY, a $2000 financial
software package that works with FRAMEWORK (Ashton-Tate) from a
company in Canada. Hating copy protection, if I couldn't create a
unprotected copy, I AT LEAST wanted to be able to make a back up of
the key disk. But my OPTION BOARD kept either hanging up or dumping
out during disk write on a certain track, under any setting. Calling
CP Software resulted in them telling me it's probably my 386, use it
on an AT. Tried it on an AT Clone (CSS Labs), same result. Another
call, "it's probably the controller card on your AT is not producing
tight enough signal, even if it's within spec. If you use it on a
REAL IBM XT you'll be fine." OK, open cases and swap boards around
on an IBM XT, no luck, same error. Another (toll) call, "You're using
software version 4.2? You have the silver dot on the diskette label?
That's the best we've got, we'll get back to you." Yeah, sure.
One of my "inside" contacts has done some contract work for Central
Point Software up in Oregon. He provided me an OLDER version of the
Option Board software, and told me he'd bet money it'd work, since
I knew the protection scheme was Superlok 3.0. "OLDER?" "Trust me!"
He was right. The word is that the owner of Central Point made an
agreement with the SoftGard/Superlok president that the Option Board
software schemes he wrote and kept updated would work on AN ORIGINAL
but not back up A COPY. Some "clever" (?) software publishers are
thwarting Option Board owners by shipping ORIGINALS that are really
ONCE-REMOVED OPTION BOARD COPIES. That stinks! Therefor, the
"pre-agreement" versions of the option board software will still work,
when the latest version doesn't. If you've got version 3.2 or 2.7,
hold on to it."
-
Ich weiß nicht genau, wie das Option Board funktioniert, aber: Alles, was versucht, Bytes zu lesen oder zu schreiben, wird an den weak Bits scheitern - denn die sind ja eben nicht in den kodierten Bytes, sondern dazwischen. Deswegen muß auch alles, was einen Floppy-Controller hat, ebenfalls dran scheitern.
-
Die Weak Bits wurden so schwach geschrieben, dass sie beim Lesevorgang genau an der Grenze zwischen "0" und "1" lagen. Dadurch wurde, je nach Zufall, vom Laufwerkskopf bei mehreren Durchläufen eben manchmal eine 0, manchmal eine 1 erkannt und geliefert.
Ich glaube die "Weak Bits" wurden auf dem Format Layer (GCR/MFM), und nicht auf der Flux Ebene (Magnetische Feldstärke) erzeugt. Nach meinem Verständnis kann man mit nicht GCR/MFM konformen Kodierungen "Weak Bits" erzeugen. Transcopy hat eine dedizierte "Copy weak bits?" Option (siehe Screenshot). Transcopy/Das Option Board kann für einzelne Bits in einem Sektor/Spur keine gesonderte Feldstärke beim Schreiben auf eine Floppy erzeugen. Das kenne ich nur bei 8" FDDs, und betrifft dann eine ganze Spur.
-
Ich weiß nicht genau, wie das Option Board funktioniert, aber: Alles, was versucht, Bytes zu lesen oder zu schreiben, wird an den weak Bits scheitern - denn die sind ja eben nicht in den kodierten Bytes, sondern dazwischen. Deswegen muß auch alles, was einen Floppy-Controller hat, ebenfalls dran scheitern.
Was Du vom Floppy Laufwerk bekommst sind Impulse, die einen Magnetfeld Wechsel anzeigen. Die Länge der einzelnen Impulse sind hier irrelevant. Der Abstand der Impulse, die Umdrehungszahl, und die TPI Werte sind wichtig. Nachgelagert ist die Interpretation dieser Impulsfolgen, die je nach Kodierung in Bits und Bytes, Sync Markierungen etc. umgewandelt werden.
-
Die Logik dahinter:
Die Weak Bits wurden so schwach geschrieben, dass sie beim Lesevorgang genau an der Grenze zwischen "0" und "1" lagen. Dadurch wurde, je nach Zufall, vom Laufwerkskopf bei mehreren Durchläufen eben manchmal eine 0, manchmal eine 1 erkannt und geliefert. Die Kopierschutzroutine hat das genutzt und eine gewisse Anzahl [y] an Leseversuchen durchgeführt. Waren dabei nicht mindestens [1 bis x] Ergebnisse unterschiedlich (wegen der kippelnden Bits), dann wurde das Programm abgebrochen, weil damit eine vorliegende Disketten-Kopie erkannt wurde. Die gängigen Laufwerke und Kopierprogramme konnten nämlich nur "richtige" 1er und 0er schreiben, so dass bei einer Kopie eben kein solches Bit-"Kippeln" auftrat.
Das ist zwar ein uraltes Gerücht, stimmt deswegen aber leider trotzdem nicht.
Es geht von der irrigen Annahme aus, dass auf einer Floppy "Bits" als Bereiche mit "Nord-/Südpol" (mit einer bestimmten magnetischen Feldstärke) gespeichert würden. Das ist aber nicht so, und würde auch garnicht funktionieren.
Eine Floppy kann nur Flußwechsel schreiben und lesen - Also Übergänge zwischen einem magnetischen Nord- und Südpol. Deswegen muß sie den Schreib- und Lesetakt des Bitstroms in den Bitstrom selber einarbeiten, damit der beim Lesen zurückgewonnen werden kann. Dazu werden in den Bitstrom immer wieder Bits eingeschoben, die, je nach Kodierungsart (FM, MFM, oder eher exotisches wie GCR) ein bestimmtes Muster ergeben müssen, dass sie beim Lesen wiedererkannt werden. Vereinfacht gesagt werden bei Weak Bits jetzt Taktbits eingeschoben, die nicht diesem vorgeschriebenen Muster folgen - der Controller "stolpert" jetzt bei der Taktrückgewinnung und erzeugt genau an diesen Stellen zufällige Bits.
Da das Schreiben der Taktbits i.A. der Floppy-Controller macht, kann man solche "fehlerhaften" Disketten mit einem Floppy-Controller auch nicht erzeugen.
-
Die Herausforderung ist hier eher das Zurück-Schreiben auf eine neue (physikalische) Diskette (ohne Verlust des Kopierschutzes).
Wenn ich mir nur die Zeit zwischen den ReadData-Impulsen merke (wie es TeenCopy und Kryoflux m.W. machen) und ich erzeuge beim Schreiben das gleiche zeitlichen WriteData sollte auch die WeakBits erhalten bleiben.
BTW, jeder FloppyController fuer Softsectored Disks erzeugt Bitmuster, die nicht nach FM und MFM kodiert sind. Diese Muster stellen die eindeutigen AdressMarks dar, ohne die man den Sector Header und Data Field gar nicht erkennen koennte.
-
BTW, jeder FloppyController fuer Softsectored Disks erzeugt Bitmuster, die nicht nach FM und MFM kodiert sind. Diese Muster stellen die eindeutigen AdressMarks dar, ohne die man den Sector Header und Data Field gar nicht erkennen koennte.
Das macht er aber nur beim Formatieren, und da macht er es eben nach einem anderen Standardmuster - beliebige Bits kann man damit nicht schreiben.
-
Es geht von der irrigen Annahme aus, dass auf einer Floppy "Bits" als Bereiche mit "Nord-/Südpol" (mit einer bestimmten magnetischen Feldstärke) gespeichert würden. Das ist aber nicht so, und würde auch garnicht funktionieren.
Da hatte ich wohl Dein vorheriges Posting falsch interpretiert und Dich über Dinge beehrt, die Du vermutlich besser kennst als ich.
-
Ich weiß nicht genau, wie das Option Board funktioniert, aber: Alles, was versucht, Bytes zu lesen oder zu schreiben, wird an den weak Bits scheitern - denn die sind ja eben nicht in den kodierten Bytes, sondern dazwischen. Deswegen muß auch alles, was einen Floppy-Controller hat, ebenfalls dran scheitern.
Das Option Board (meine Version) hat keinen FDC Chip / keinen Floppy-Controller. Da wird zwar das Kabel "durchgeschleift", um auch an die Daten/Datenleitung des Laufwerks zu kommen, aber das Option Board nimmt das Ganze auf wie ein Tonbandgerät (jeder Vergleich hinkt).
-
BTW, jeder FloppyController fuer Softsectored Disks erzeugt Bitmuster, die nicht nach FM und MFM kodiert sind. Diese Muster stellen die eindeutigen AdressMarks dar, ohne die man den Sector Header und Data Field gar nicht erkennen koennte.
Das macht er aber nur beim Formatieren, und da macht er es eben nach einem anderen Standardmuster - beliebige Bits kann man damit nicht schreiben.
Da Floppy Controller keine Rolle bei Kryoflux und FluxTeen spielen, sollte eine Kopie hier kein grundsätzliches Problem sein. Beim "Option Board" ist das wegen der unklaren proprietären Implementierung so eine Frage.
"it simply copies the flux reversals (transitions) on the disk, without a care as to what the data on the disc actually is."
Das klingt auch nach etwas, was unabhängig von einem FDC funktioniert. Dabei ist das OB direkt mit dem FDC des Host Systems verbunden. -
Das ist zwar ein uraltes Gerücht, stimmt deswegen aber leider trotzdem nicht.
Ja, das hat ADM12 schon heute morgen korrigiert. - danke für die Richtigstellung dazu. Da sieht man, dass die "Erinnerung" an die stark vereinfachte (und falsche) Feldstärkenerklärung deutlich mehr Beharrungsvermögen im Gedächtnis hatte, als das seinerzeit durchaus vorhandene Wissen um die GCR-Kodierung und physische Aufzeichnungsformate. Jetzt, wo Du es sagst, kommt die Erinnerung auch langsam wieder - Flußwechsel, die Sync-Markierung bei der 1541, die 4-zu-5-Bit-Kodiertabelle, mit der GCR das timingtötende Auftauchen von mehr als 2 aufeinanderfolgenden 0-Bits oder mehr als 9 "1"-Bits ( = Sync) vermied, aber eben auch die Datenmenge "aufblähte"...
Ist schon spannend, wie das seinerzeit hard- und softwaretechnisch gelöst wurde, vor allem um Kopierer zu behindern.
Hat nix genutzt.
-
BTW, jeder FloppyController fuer Softsectored Disks erzeugt Bitmuster, die nicht nach FM und MFM kodiert sind. Diese Muster stellen die eindeutigen AdressMarks dar, ohne die man den Sector Header und Data Field gar nicht erkennen koennte.
Das macht er aber nur beim Formatieren, und da macht er es eben nach einem anderen Standardmuster - beliebige Bits kann man damit nicht schreiben.
Das stimmt.
Ich wollte mehr darauf, das auf jeder Diskette inkonforme Bitmuster zu finden sind. Sogar noetig sind.
So hoert's sich besser an.
-
Das "jeglicher Kopierschutz mitkopiert wird" halte ich etwas für übertrieben.
Nun ja, beim C64 / 1541 sieht man eigentlich, dass man ohne besondere Hardware JEDEN Kopierschutz mit kopieren kann.
Es genügt eine normale Standard 1541.
Und ein Nibble Copy (MNIB).
Der Beweis, das Disketten Image (G64) läuft auf dem VICE.
Das Problem ist also nicht das LESEN.
Das Problem ist immer das SCHREIBEN.
Wir sind in der Lage alle original Disketten samt Kopierschutz zu kopieren.
Wir können es aber (in vielen Fällen) nicht ohne Spezial Hardware zurück schreiben auf eine Diskette.
-
Alles anzeigen
Das "jeglicher Kopierschutz mitkopiert wird" halte ich etwas für übertrieben.
....
Das Problem ist also nicht das LESEN.Das Problem ist immer das SCHREIBEN.
Wir sind in der Lage alle original Disketten samt Kopierschutz zu kopieren.
Wir können es aber (in vielen Fällen) nicht ohne Spezial Hardware zurück schreiben auf eine Diskette.
Zustimmung. Für mich war das Zurückschreiben auf eine Diskette immer das finale Ziel eines Floppy Disk Kopierprogramms. Das Erstellen von Images und deren Nutzung in Emulatoren war für mich eher ein Abfallprodukt. Da kann man dann ja auch gleich die gekrackten Versionen nutzen, bei denen der Kopierschutz ausgeschaltet wurde.
-
Alles anzeigen
Das "jeglicher Kopierschutz mitkopiert wird" halte ich etwas für übertrieben.
Nun ja, beim C64 / 1541 sieht man eigentlich, dass man ohne besondere Hardware JEDEN Kopierschutz mit kopieren kann.
Es genügt eine normale Standard 1541.
Und ein Nibble Copy (MNIB).
Der Beweis, das Disketten Image (G64) läuft auf dem VICE.
Das Problem ist also nicht das LESEN.
Das Problem ist immer das SCHREIBEN.
Wir sind in der Lage alle original Disketten samt Kopierschutz zu kopieren.
Wir können es aber (in vielen Fällen) nicht ohne Spezial Hardware zurück schreiben auf eine Diskette.
Ich bin mir ziemlich sicher, dass es noch keiner geschafft hat, Rapidlok-Disketten zu kopieren, ohne zumindestens ein bißchen zu cracken.
-
Gibt es systembedingt irgend etwas, was das "Option Board" besser kann als KryoFlux, SuperCard und FluxTeen ? "Weak Bits" Support?
Um auf die ursprüngliche Frage zurückzukommen ...
Ich kenne Option Board nur aus den diversen Berichten. So wie ich das verstehe, gibt es dazu eine spezielle Software die auf Kopierschutz spezialisiert ist.
Für FLUXTEEN kann ich sagen, das hier von ungeschützten Disketten ausgegangen wird. Bei sehr einfachen Methoden kann es sein, dass funktionsfähige Kopien erstellt werden. Bei Weekbits gehe ich davon aus, dass es vermutlich nicht funktioniert, da FLUXCOPY nur einen Zustand kopiert und nicht nach sich ändernden Bits umsieht.
Bei den Weekbits schließe ich mich der Meinung von ADM12 an:
Soweit ich weiß, haben "Weak Bits" nichts mit der geschriebenen magnetischen Feldstärke ("Stärke der Magnetisierung") zu tun, sondern mit dem Timing der Magnetisierungswechsel. Das Timing der Wechsel wird genau in den Grenzbereich der beiden Zeitfenster gesetzt, die beim Lesen den Unterschied zwischen einer 0 und einer 1 ausmachen. Dadurch entsteht an dieser Stelle ein zufälliges Leseergebnis.In der grafischen Darstellung der "flux transitions" von Kryoflux oder HxCFloppyEmulator lassen sich diese Stellen leicht erkennen.
Wenn ich mir nur die Zeit zwischen den ReadData-Impulsen merke (wie es TeenCopy und Kryoflux m.W. machen) und ich erzeuge beim Schreiben das gleiche zeitlichen WriteData sollte auch die WeakBits erhalten bleiben.
Das dachte ich auch, als ich mit dem FLUXCOPY-Projekt begonnen habe. Leider läßt sich eine Diskette nicht wirklich 1:1 auf eine andere kopieren. Bei FM mag das vielleicht noch gehen, nicht aber bei MFM, etc. Bei FM liegen die einzelnen Fluxwechsel zeitlich noch relativ weit auseinander, sodass sie sich nicht gegenseitig beeinflussen. Bei MFM beeinflussen sich benachbarte, unterschiedlich lange Fluxwechsel. Sie werden beim Wiedereinlesen länger oder kürzer als sie geschrieben wurden. Daher gibt es auch die Write Precompensation um den Effekt zu minimieren. Dieser ist wiederum auch je nach Laufwerk unterschiedlich. Hängt offenbar mit den Schreib-/Leseköpfen zusammen.
Also FLUXTEEN ist jedenfalls betreffend kopiergeschützter Programme kein Ersatz für das Option Board.
Aber vielleicht hat jemand ein Kryoflux-Image (.raw) oder Fluxcopy-Image (.FLX) von einer Diskette mit Weekbits.
Würde ich mir gerne näher ansehen, wie von ADM12 beschrieben.
Grüße
PAW
-
Ich habe hier mal ein prominentes Beispiel von Weak / Flakey Bits visualisiert.
