Beiträge von markusC64 im Thema „geoWrite Fehler beim Starten auf dem TC64“

    Das ist ja merkwürdig... das Image ist suboptimal. Das muss ich nochmal genauer prüfen, jedoch ist da bei Track 14 Sektor 8 eine Stelle, die nibconv so nicht verarbeiten will. Der nicht dokumentierte Parameter "-$" hilft zwar, deutet jedoch an, dass da was ist, wie es nicht sein sollte.


    Ein Blick ins Image zeigt, dass nach dem Sektor keine GAP da ist - wie das sein kann, das ist jetzt die Frage.

    Ein Teil des Rätsels ist zu 99% geklärt. Mangels anderer verwertbarer Infos habe ich die gleiche Diskette aus der Geos 2.5 Packung als Referenz hergenommen(*). Und siehe da: Es ist die selbe Ursache wie unter Bitte melde dich an, um diesen Link zu sehen. beschrieben. Damit wäre "to confirm this is not specific to boot disks" aus der Seite beantwortet: Ja, es tritt auch bei Nicht-Boot-Disketten auf.


    (*) Natürlich deswegen, weil wir davon einen Kryoflux Dump der komplett unbenutzten Packung haben.

    Frage: Hat nur GeoWrite diesen SN Check? Oder auch andere Apps?

    Fast alle anderen Apps von Berkeley Softworks.

    Deswegen habe ich mir gegönnt, alle Geos-Systemdisketten auf die selbe Seriennummer zu installieren - und falls das nicht möglich ist (wie bei Geos 1.x) dann die Seriennummer der Systemdisketten nachträglich anzupassen.

    So hat mein ganzer Satz alles die selbe Seriennummer.

    Wenn ich übrigens versucht habe, geoWrite direkt in MP3 zu installieren, kam einfach nichts mehr - leerer Bildschirm.

    Ist bekannt, Installieren geht in MP3 nicht... Die Ursache dürfte da liegen:

    GEOS comes with driver code for the 1541 and 1571 disk drives, which contains logic to upload code to the drive, execute it, and send commands, status messages and block data back and forth. The protection code reuses the driver to execute custom code and retrieve the result.

    But the disk drivers don’t export this functionality as an API. Instead of adding this to the disk drivers as a private API, the authors of the protection chose to do some hacky stuff to get to these functions instead ...

    Übersetzt:

    Zitat

    GEOS wird mit einem Treibercode für die 1541- und 1571-Diskettenlaufwerke geliefert, der eine Logik zum Hochladen von Code auf das Laufwerk, zum Ausführen des Codes und zum Senden von Befehlen, Statusmeldungen und Blockdaten hin und her enthält. Der Schutzcode verwendet den Treiber wieder, um kundenspezifischen Code auszuführen und das Ergebnis abzurufen.

    Die Plattenlaufwerkstreiber exportieren diese Funktionalität jedoch nicht als API. Anstatt sie als private API zu den Platten-Treibern hinzuzufügen, haben sich die Autoren des Schutzes dafür entschieden, einige hackige Sachen zu machen, um zu diesen Funktionen zu gelangen ...

    Und jene privaten Funktionen innerhalb des Diskettentreibers werden wohl nicht gefunden. Ansonsten ließt sich der ganze Rest der Beschreibung nämlich so, als müsse er auch in MP3 funktionieren.

    Übrigens eine sehr lesenswerte Beschreinbung des GeoWrite-Kopierschutzes. Englisch sollte man allerdings können.

    Wenn ich mal Zeit habe, prüfe ich die These nach. Das ist eigentlich nicht schwer: Man ersetzt den Block mit der Kopierschutzabfrageroutine einfach durch einen Code, der sofort "alles ok" sagt, ohne in der Floppy einen Code auszuführen. Wenn es dann klappt, ist es wie vermutet die Kopierschutzabfrage.

    darkvision Was meinst Du, könnte ich mit der Ursachenvermutung richtig liegen?

    In MP3 kann man die Seriennummer einstellen. Dann wird es laufen.

    Wobei für MP3 es sich empfiehlt, die Patches von Werner et al. für geoWrite anzuwenden. Sind auch in der Wolke und können in einer MP3 Ramdisk problemlos angewendet werden.

    Ich hoffe, dass ich bald dazu komme, die Images nochmal zu überprüfen. Dass uns (mir und Werner) das Problem durchgegangen ist... ist am Ende wohl menschlich.

    Auf der anderen Seite stellt sich dann das Problem: Zur Benutzung ist ein regenerierter Kopierschut natürlich ausreichend, aber eine echte Archivierung ist das dann auch nicht mehr. Man kann es nur falsch machen.

    Könnte aber sein, dass die Disk genauso noch in einer anderen archivierten Packung drin ist, das würde helfen.

    Das ist ja merkwürdig... das Image ist suboptimal. Das muss ich nochmal genauer prüfen, jedoch ist da bei Track 14 Sektor 8 eine Stelle, die nibconv so nicht verarbeiten will. Der nicht dokumentierte Parameter "-$" hilft zwar, deutet jedoch an, dass da was ist, wie es nicht sein sollte.

    Ein Blick ins Image zeigt, dass nach dem Sektor keine GAP da ist - wie das sein kann, das ist jetzt die Frage.

    Geeignete Programme bekommen daraus jedoch noch jeden Sektor fehlerfrei gelesen, so dass man daraus ein D64 und aus dem D64 dann ein neues G64 mit neu erzeugten Kopierschutz generieren kann.

    Da ich im Moment sowieso meine neue Beta von g64conv testen will, habe ich die besagten Umwandlungen damit mal gemacht. Probier bitte die neue G64 aus.