Burstnibbler

  • Hallo,

    wie im anderen Thread angekündigt habe ich mich daran gemacht, den Burstnibbler v2.0 zu disassmblieren, um den anschließend so zu verändern, dass der eine REU unterstützt. Ziel soll es sein, dass man aus der REU den Disketteninhalt auch verlustfrei zu einer g64/nib-Datei machen kann.
    Der erste Schritt ist getan: Ich habe das Programm disassembliert. Die Reste von der ehemaligen Kopierschutzabfrage sind entfernt. Dabei habe ich festgestellt, dass die gecrackte Version noch immer einige Schutzmechanismen beinhaltet, die selbige vor Veränderungen schützt. Auch diese sind entfernt.

    Anbei eine um die Schutzmechanismen entfernte Version. Als kleine Neuerung gegenüber den verfügbaren Versionen kann man die Aufforderung, die Quelldiskette mit Schreibschutz zu versehen, mit der Taste "I" wie Ignorieren bestätigen. Dann geht es auch ohne Schreibschutz weiter (es erscheint aber derzeit auf den Bildschirm kein Hinweis auf die Taste I).

    Versionsnummer ist hochgesetzt worden, damit Verwechslungen vermieden werden.


    Um es klar zu stellen: Diese Version hat noch keinen REU-Support.
    Dateien
    ---
    Meine Github-Projekte: github.com/markusC64/
    1541 Ultimate II Firmware Releases: github.com/markusC64/1541ultimate2/releases
    1541 Ultimate II Update instructions: github.com/markusC64/1541ultimate2/wiki
  • Ja. Eigentlich wollte ich damit warten, bis etwas mehr an Änderungen fertig ist. Sollte ich jedoch Angebote bekommen, dass jemand mir bei dem Projekt helfen möchte, würde ich das auch eher machen.

    Jetzt hätte ich gerne Feedback, ob die Version bei Euch funktioniert. Ich habe damit jedenfalls zwei Geos-Disketten erfolgreich kopiert. Es macht ja kaum sinnvoll sein, mit einer Version,die nicht richtig läuft, weiterzumachen.

    PS: Durch das Entfernen der Kopierschutzreste stürzt die Version im VICE nicht mehr ab, wie die vorherigen Burstnibbler-Versionen.

    Nachtrag: Mit dem unmodifizierten Quelltext ist das so eine Sache. Die Version auf dem Regenerator ist beim Assemblieren mit acme 1 Byte länger (.BYTE durch !byte sowie .TEXT durch !pet ersetzt, damit acme den Quelltext "mag"). Dadurch schlagen die Schutzmechanismen an und das ganze macht Probleme.
    ---
    Meine Github-Projekte: github.com/markusC64/
    1541 Ultimate II Firmware Releases: github.com/markusC64/1541ultimate2/releases
    1541 Ultimate II Update instructions: github.com/markusC64/1541ultimate2/wiki
  • markusC64 schrieb:

    Mit dem unmodifizierten Quelltext ist das so eine Sache. Die Version auf dem Regenerator ist beim Assemblieren mit acme 1 Byte länger (.BYTE durch !byte sowie .TEXT durch !pet ersetzt, damit acme den Quelltext "mag"). Dadurch schlagen die Schutzmechanismen an und das ganze macht Probleme.

    Was zeigt ein Binärvergleich an? Klingt nach einem absolutem Zugriff, wo ursprünglich eine Zeropage-Adressierung war.
  • Leider knapp vorbei. Regenerator hat am Ende der Datei ein 0-Byte zu viel generiert - am Ende eines DATA-Bereiches.

    Ein Bindiff zeigt aber noch, dass die !pet eine andere Kodierung wählen, als das Original. Aber die Anzeige passt (es geht ausschließlich um Texte für den Bildschirm) - insofern ist das für mich erst einmal egal. Dadurch resultieren recht viele Unterschiede, dass ist das zuerst nicht gesehen habe.

    Muss wohl, als ich Probleme hatte, noch eine Änderung gehabt haben.
    ---
    Meine Github-Projekte: github.com/markusC64/
    1541 Ultimate II Firmware Releases: github.com/markusC64/1541ultimate2/releases
    1541 Ultimate II Update instructions: github.com/markusC64/1541ultimate2/wiki
  • markusC64 schrieb:

    Ein Bindiff zeigt aber noch, dass die !pet eine andere Kodierung wählen, als das Original. Aber die Anzeige passt (es geht ausschließlich um Texte für den Bildschirm)
    ACME benutzt für PetSCII die gleiche Codierung wie der Tastaturtreiber des C64 ('a' => 65, 'A' => 193), für etliche Zeichen gibt es aber alternative Codes: CHR$(97) ergibt z.B. ebenfalls 'A'. Schick mir bitte mal den Diff, ich kann dann eine entsprechende Konvertierungstabelle in der ACME-Lib anlegen.
    Yes, I'm the guy responsible for the ACME cross assembler

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Mac Bacon ()

  • Nicht nötig. Ich habe festgestellt, dass !raw die richtigen Ergebnisse liefert. Dennoch oder gerade deswegen lade ich den Sourcecode der Version 2.0 hoch. Er liefert exakt die gleiche Binary wie in der CSDB zu finden ist.

    Habe das Gefühl, die !raw könnte man per Hand besser hinbekommen, als Regenerator das gemacht hat.
    Dateien
    ---
    Meine Github-Projekte: github.com/markusC64/
    1541 Ultimate II Firmware Releases: github.com/markusC64/1541ultimate2/releases
    1541 Ultimate II Update instructions: github.com/markusC64/1541ultimate2/wiki
  • Nun noch ein paar neue Sourcecodes. Im Vergleich zu dem Binary aus dem Threadstart haben die den Fix "!raw" statt "!pet" bereits eingebaut. Das ist der einzige Unterschied.

    In Version 2.3pre sind lediglich die Schutzmechanismen deaktiviert, die Abfrage auf die Taste "I" ist jedoch nicht enthalten - das ist der einzige Unterscheid zu Version 2.3.
    Dateien
    ---
    Meine Github-Projekte: github.com/markusC64/
    1541 Ultimate II Firmware Releases: github.com/markusC64/1541ultimate2/releases
    1541 Ultimate II Update instructions: github.com/markusC64/1541ultimate2/wiki
  • 14 Download, und kein einziger hat eine Rückmeldung für mich bereit? Nun denn, dann muss ich davon ausgehen, dass die Version funktioniert. Bei Problemen wird sich temdentiell ja eher gemeldet.

    Wobei sich die Frage stellt, ob die Version besser als Version 1.9 funktioniert. Ich bin nämlich am Überlegen, ob ich mit dieser Version weitermachen soll oder auf Version 1.9 als Grundlage wechseln soll. Was meint ihr?
    ---
    Meine Github-Projekte: github.com/markusC64/
    1541 Ultimate II Firmware Releases: github.com/markusC64/1541ultimate2/releases
    1541 Ultimate II Update instructions: github.com/markusC64/1541ultimate2/wiki
  • markusC64 schrieb:

    Wobei sich die Frage stellt, ob die Version besser als Version 1.9 funktioniert. Ich bin nämlich am Überlegen, ob ich mit dieser Version weitermachen soll oder auf Version 1.9 als Grundlage wechseln soll. Was meint ihr?
    Mh, ich kann das leider im Moment nicht testen, da meine Floppy mit Parallel Kabel sich gerade bei meinem Bastler befindet zwecks Lichtschranken-Mod.

    Aber, was ist denn der Unterschied von 1.9 und 2.3?
    --------------------------------------------------------------------------------------------------------
    - SCPU V1 16MB - SCPU V2 16MB - RL 16MB - FD2000 - CMD HDD 4GB CF Karte - Rear Admiral Thunderdrive -
    1541II+Speedcontrollbox+Ramboard+SuperCard - EF3 Prototyp mit ONS Shooter Collection - SD2IEC - 1571+XAP
  • Der selbe wie der Unterschied zwischen 1.9 und 2.0. :)
    Zu der omniösen Version 2.0 habe ich leider keine Infos finden können - nur dass 1.9 die letzte offiziell releaste Version sein soll.
    Es ist ja noch nicht einmal klar, welche Version damals modifiziert worden ist, um die 2.0 zu erhalten.

    Nun denn, eine Version muss gut funktionieren.

    Nachtrag: Über die von mir reingepatchte Taste "I" rede wir nicht. Die kann ich ja auch in 1.9 reinpatchen. Das ist also kein Argument.
    ---
    Meine Github-Projekte: github.com/markusC64/
    1541 Ultimate II Firmware Releases: github.com/markusC64/1541ultimate2/releases
    1541 Ultimate II Update instructions: github.com/markusC64/1541ultimate2/wiki
  • Die Unterschiede zwischen der 1.9 und der 2.0 müsste 'WoMo' kennen, jedenfalls hab ich ihm vor laaanger Zeit mal die 2.0 aus den Untiefen meiner Disksammlung rausgesucht, um mehr darüber zu erfahren.
    Weiß nicht ob er hier angemeldet ist ?! Denke aber schon.
    was ich noch so suche:
    Commodore VC-1515 Drucker, 1350 Maus, Amiga 1020 Laufwerk
  • Wow, recht beliebt, der Burstnibbler. Ich weiß inzwischen, dass ich mit der Version 1.9 weiterarbeiten werde. Die Version 2.0 von CSDB, worauf die zuvor geposteten Version basieren, hat gegenüber Version 1.9 ein Defizit: Dolphin DOS 3.0 wird in Version 1.9 unterstützt, in Version 2.0 aber nicht. Demnach wird Version 2.0 wohl eine gecrackte und gepatchte Version sein, die echt älter als Version 1.9 ist.

    Nun den, also das ganze nochmal mit Version 1.9 :rolleyes:

    Die Sourcen sind diesmal mit ein paar "!if"'s versehen. So kann sowohl das kopiergeschützte Original, als auch eine Version mit entfernten Schutz und auch eine Version mit Patch für das Ignorieren des fehlenden Schreibschutzes erzeugt werden. Wahlweise mit Basic-Start, Autostart (nur C64, so ist das beim Original) oder nur das Programm (per SYS startbar, Original beim C128. Wird gestartet über Loader auf Track 1 Sektor 0).

    Alles gewonnen aus einer nicht gecrackten Version von Burstnibbler 1.9.
    Dateien
    ---
    Meine Github-Projekte: github.com/markusC64/
    1541 Ultimate II Firmware Releases: github.com/markusC64/1541ultimate2/releases
    1541 Ultimate II Update instructions: github.com/markusC64/1541ultimate2/wiki

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von markusC64 ()

  • markusC64 schrieb:

    Dolphin DOS 3.0 wird in Version 1.9 unterstützt,
    Das gleiche gilt auch für Prologic DOS Classic, das ebenfalls ein abweichendes Parallelkabel verwendet. Mit einem original 1.9 geht das.
    Zuletzt repariert:
    21.2. Logitech M570 Microschalter ausgetauscht - geplante Obsoleszenz durch Billigtaster?
    19.11. Toshiba 3,5" Floppy defekter Elko durch Kerko getauscht auf Motorplatine
    27.11. 1541B Dauerlauf, Elko im Resetschaltkreis defekt, nicht der 7406 wie zuerst verdächtigt!
  • Da war aber etwas dazu in der Version 2.0 drin mit Erkennung von Prologic DOS... kann ich aber (leider) nicht ausprobieren. Ebenso wie Dolphin DOS 3.0 - habe ich auch nicht. Aber ohne Erkennung kann das eigentlich nicht funktionieren...
    ---
    Meine Github-Projekte: github.com/markusC64/
    1541 Ultimate II Firmware Releases: github.com/markusC64/1541ultimate2/releases
    1541 Ultimate II Update instructions: github.com/markusC64/1541ultimate2/wiki

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von markusC64 ()

  • markusC64 schrieb:

    um den anschließend so zu verändern, dass der eine REU unterstützt.
    Werden nur Commodore REU unterstütz oder auch andere REU/Speicher (z.B. der 1541 Ultimate, SCPU, RL)?


    markusC64 schrieb:

    dass man aus der REU den Disketteninhalt auch verlustfrei zu einer g64/nib-Datei machen kann.
    Können die Datei direkt auf eine 1541 Ultimate geschrieben und benutzt werde?
    Somit könnte ich diverse Original Games, in die neue Welt, retten ^^

    Gruss C=Mac.
  • Noch habe ich leider den REU-Support noch nicht implementiert. Aber selbstverständlich werden original CBM REUs als auch das TC64 als auch die 1541 Ultimate * funktionieren. Wobei ich das TC64 nicht prüfen kann. Die REU muss lediglich (als einzige Voraussetzung) groß genug sein, um den eingestellten Kopierjob aufnehmen zu können.

    Der Plan ist so ähnlich wie bei der ZoomFloppy: Man erzeugt am C64 eine .xyz (Endung steht noch nicht fest (bei der ZoomFloppy ein .nib). Das konvertiert man anscjhließend am PC in ein g64.

    Aber vorher gibt es erstmal eine Version mit REU-Support. Wenn man dann per 1541 U* den Inhalt der REU abspeichert, hat man eigentlich alle benötigten Informationenn zum PC übertragen und hat alles zusammen, um ein g64 zu erstellen.

    Nur brauche ich noch etwas Zeit. Der Assemblercode ist nicht zum Lesen optimiert worden :)
    ---
    Meine Github-Projekte: github.com/markusC64/
    1541 Ultimate II Firmware Releases: github.com/markusC64/1541ultimate2/releases
    1541 Ultimate II Update instructions: github.com/markusC64/1541ultimate2/wiki

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von markusC64 ()

  • markusC64 schrieb:

    als auch die 1541 Ultimate * funktionieren.
    :thumbup:

    markusC64 schrieb:

    Die REU muss lediglich (als einzige Voraussetzung) groß genug sein, um den eingestellten Kopierjob aufnehmen zu können.
    Bei der 1541 Ultimate hat man ja 16 MB, sollte reichen.

    markusC64 schrieb:

    Das konvertiert man anscjhließend am PC in ein g64.
    Direkt am C64 ist dies nicht möglich?
    Ich bin kein Programmierer und hab null Ahnung, sorry für's doofe Fragen.


    markusC64 schrieb:

    Nur brauche ich noch etwas Zeit.
    Kein Problem, eilt nicht, wie immer es reicht bis gestern :D

    Gruss C=Mac.