Hello, Guest the thread was called2.3k times and contains 23 replays

last post from frank128 at the

ZoomFloppy & Copy Protection

  • Kurios. Habe mit Kryoflux meine kopiergeschützte originale Uridium Floppy in ein G64 Image umgewandelt. VICE 2.4 kann mit diesem G64 Image das Spiel problemlos starten. VICE "stürzt" (geht in den Moniotor Mode) dagegen nach einer Minute (augenscheinlich) korrektem laden ab, wenn ich die originale Floppy in einem echten 1571-Drive via ZoomFloppy an VICE angeschlossen habe. Warum ist dass so?


    Mit dem selben 1571-Drive an einem echten C128D (mit abgeschaltetem internen Drive) läuft das Spiel mit der originalen kopiergeschützten Floppy ohne Probleme.


    Das 1571-Drive scheidet somit für mich als Ursache aus. Liegt es also an der ZoomFloppy? Oder hat VICE einen Bug in Verbindung mit der Zoom Floppy ("Real IEC Gerät")?

  • Ich denke das sollte nicht funktionieren. OpenCBM reicht IIRC keine GCR-gerechte Verbindung durch, und das ganze ist in Vice sowieso recht frickelig und rudimentär. Vice sollte sich also wohl so verhalten als hätte man ein D64 von dieser Diskette gemacht wo der Kopierschutz natürlich nicht drin ist, sprich die Kopierschutzabfrage ist erfolglos und das Programm lädt nicht. Vulgo "Absturz".

  • OpenCBM reicht IIRC keine GCR-gerechte Verbindung durch


    Was genau ist eine "GCR-gerechte Verbindung"?


    PC FDDs sind über die Bitstream Ebene an den FDC auf dem Motherboard angebunden. Commodore Laufwerke doch wohl eher auf einer höheren Protokollebene - über den IEC-Bus. Und auf der sollte GCR keine direkte Rolle spielen - die GCR-Dekoderung erfolgt im (intelligenten, aber auch langsamen) autarken FDD. Über den Channel sollten doch nur CBM Floppy Befehle gehen.


    Egal wie die 1541/71 durch den Kopierschutz manipuliert wird, die Zoom-Floppy sollte den IEC Traffic doch einfach nur 1:1 tunneln. Wo ist da das GCR-Problem?



    Vice sollte sich also wohl so verhalten als hätte man ein D64 von dieser Diskette gemacht wo der Kopierschutz natürlich nicht drin ist, sprich die Kopierschutzabfrage ist erfolglos und das Programm lädt nicht. Vulgo "Absturz".


    VICE hat G64-Support und damit sollte die 1541/71 Drive Emulation auch mit GCR klarkommen. In meinen oben beschriebenen Szenario tut sie das auch. Bei der Anbindung über die Zoom-Floppy wird dieser Teil von VICE auch nicht genutzt. Das ist Sache des autonomen (echten) 1541/71 FDD.


    ... die Verbindung Vice-zu-Floppy ist keine vollwertige. Alles ausser purem LOAD kann man damit so ziemlich vergessen.


    Dann würden doch die nibtools, die protokollmäßig recht weit unter agieren, nicht funktionieren?

  • Was genau ist eine "GCR-gerechte Verbindung"?


    PC FDDs sind über die Bitstream Ebene an den FDC auf dem Motherboard angebunden. Commodore Laufwerke doch wohl eher auf einer höheren Protokollebene - über den IEC-Bus. Und auf der sollte GCR keine direkte Rolle spielen - die GCR-Dekoderung erfolgt im (intelligenten, aber auch langsamen) autarken FDD. Über den Channel sollten doch nur CBM Floppy Befehle gehen.


    Egal wie die 1541/71 durch den Kopierschutz manipuliert wird, die Zoom-Floppy sollte den IEC Traffic doch einfach nur 1:1 tunneln. Wo ist da das GCR-Problem?


    Ein Kopierschutz beruht darauf, zu erkennen, dass die Disk kopiert wurde. Dazu gibt es mehrere Möglichkeiten, die aber immer irgendwie mit den Daten auf der Disk zu tun haben, nicht mit den Daten, die an den Host übertragen werden. Das einfachste Beispiel dafür ist der Killer-Track: GCR sorgt dafür, dass nie mehr als ein paar '1'-Bits hintereinander kommen. Kommen doch mehr '1'-Bits, ist es eine Sync-Marlierung für den Sektoranfang. Das CBM-DOS macht jetzt nichts anderes als zu warten, bis der Sync vorrüber ist, wartet also auf eine '0'. Wenn man jetzt die ganze Spur mit '1'-Bits füllt (also GCR '1' Bits, nicht Datenbits - die würden sofort in '0'/'1'-Folgen umgewandelt), dann hängt sich die Floppy, wenn man mit Standardmethoden darauf zugreift, einfach auf, denn der Sync ist nie zu Ende.
    Eine andere Mehode fragt z.B. die Lage der Sektoren zwischen den Spuren zueinander ab: diese ist dank fehlender Indexlochabfrage nämlich zufällig. All das findet sich im Datenstrom zum Hostrechner nicht wieder, kann aber zur Identifizierung von Kopien benutzt werden.
    Da gibts noch viele andere Dinge, die man abfragen kann, ich hoffe, das Prinzip ist klar geworden. Die Image-Formate bilden nur den lesbaren Inhalt der Disks ab, nicht aber die tatsächliche physikalische Lage auf der Disk, die für den Kopierschutz oft ausschlaggebend ist.

  • Egal wie die 1541/71 durch den Kopierschutz manipuliert wird, die Zoom-Floppy sollte den IEC Traffic doch einfach nur 1:1 tunneln. Wo ist da das GCR-Problem?


    Man kann aber an einem normalen PC und insbesondere via USB den IEC-Traffic nicht 1:1 tunneln - das müsste mit Mikrosekunden-Auflösung passieren und USB hat IIRC 1ms lange Zeitslots. Wenn man in VICE ein Laufwerk per OpenCBM einbindet ist das daher eher mit einer High-Level-Laufwerksemulation (ohne Truedrive) vergleichbar, die für Datenträgerzugriffe auf das externe Laufwerk statt auf eine Image-Datei zurückgreift.


    Mit GCR hat das natürlich erstmal nicht so viel zu tun.


    Quote

    Dann würden doch die nibtools, die protokollmäßig recht weit unter agieren, nicht funktionieren?


    Die nibtools müssen lediglich eine Diskette lesen oder schreiben und können das Protokoll zwischen Laufwerk und Zoomfloppy im Microcontroller der Zoomfloppy behandeln, ohne sich um das zusätzliche Problem einer synchron zum echten Laufwerk agierenden, zyklenexakten C64-Emulation kümmern zu müssen.

  • Die Image-Formate bilden nur den lesbaren Inhalt der Disks ab, nicht aber die tatsächliche physikalische Lage auf der Disk, die für den Kopierschutz oft ausschlaggebend ist.


    Wenn Image-Formate nur den lesbaren Inhalt der Disk abbilden verwundert es mich, warum der Kopierschutz mit dem G64-Image funktioniert, aber mit der realen Hardware (einer 1571) und der originalen Game Floppy angebunden über ZoomFloppy & openCBM nicht. Rein intuitiv hätte ich es umgekehrt erwartet.

  • Es gab ja auch Originale, die sich bei einer "Fälschung" dann selbst formatiert haben.
    Nicht, dass sowas noch passiert! :bgdev

    Wenn ein lichtundurchlässiger Schreibschutz-Aufkleber drauf ist, ist sowas schon hardwaremäßig gar nicht möglich :prof:

  • Ist aber leider so. Diese real drive IEE Funktion in ihrer jetzigen Form ist eher Spielkram, mit dem man mal Directory von zu transferierenden Disks checken und evtl mal paar One-Filer Starten kann. :)


    Also ein Problem von VICE, nicht von openCBM & Zoomfloppy?


    Wenn ja, treiben sich hier im Forum VICE Entwickler herum, bei denen man nachfragen kann?

  • Also ein Problem von VICE, nicht von openCBM & Zoomfloppy?


    Ist es ein Problem, wenn ein Feature nicht das macht was der Benutzer erhofft hat?


    Quote

    Wenn ja, treiben sich hier im Forum VICE Entwickler herum, bei denen man nachfragen kann?


    Was für Fragen sollen denn noch offen sein?

  • Meine Erwartungen an diese Funktion sind doch naheliegend und kein überflüssiger Feature-Schnickschnack.


    Gut, möglicherweise könnte man das in der Doku besser beschreiben als es jetzt ist. Fakt ist jedoch, dass OpenCBM in der VICE-Anleitung im Abschnitt "Settings for file system devices" beschrieben ist und die sind sämtlichst nicht so 1541-kompatibel wie du es gerne hättest.


    Quote

    Wann bekommt VICE eine bessere IEC Implementierung?


    VICE hat eine einwandfrei funktionierende IEC-Implementierung, um sie voll auszunutzen musst du lediglich die True Drive Emulation einschalten und den gewünschten zu emulierenden Laufwerkstypen auswählen.


    Ein echtes Laufwerk mit einer unter Windows oder vergleichbaren Betriebssystemen laufenden Emulation anzusprechen geht nur mit genau den Einschränkungen, die die OpenCBM-Implementierung in VICE hat. Die Emulation so zeitexakt zu gestalten, dass beliebige Fastloader-Protokolle in der Emulation mit einem echten Laufwerk reden können ist technisch nicht machbar, die Gründe dafür habe ich bereits genannt.


    Ich würde sagen ein Schreibschutzaufkleber bringt da mal garnix, da die Abfrage soweit ich weiß in Software umgesetzt wird also kann man das auch per Software umgehen und plötzlich wird das geliebte Spiel formatiert ^^


    Nö, die Laufwerkselektronik verhindert die Umschaltung in den Schreibmodus, so lange die Schreibschutz-Lichtschranke unterbrochen ist.