[Problem] C64: Spieldateien aus Disk Images entpacken

[indy4-fan]

0

Hallo,

vielleicht gibt es ja hier den ein oder anderen C64-Experten, der mir mit meinem Problem weiterhelfen oder evtl. Denkfehler ausräumen kann.

Folgendes:

Ich möchte die einzelnen Spieldateien/Ressourcen aus diversen C64 Disk Images extrahieren. Genauer gesagt geht es um einige Level9 Text Adventures, welche ich mit ScummVM spielbar machen möchte. ScummVM basiert auf dem Level9-Interpreter und laut diesem sollen auch die C64-Versionen (mit Grafiken) spielbar sein, jedoch benötigt man für jedes Spiel jeweils die "Gamedat"-Ressourcen für jedes der bis zu 4 Kapitel und die Line-Grafiken in einem C64-Grafikformat. Ausprobiert habe ich es mit "The Archers".

Soweit ich das nun schon verstanden habe, besteht das C64 Disk Image im Grunde genommen aus einer .PRG-Datei. Diese habe ich auch bereits geschafft, mit einem entsprechenden Tool ("DirMaster") zu extrahieren.

Nun der nächste Schritt: Laut Doku des Level9-Interpreter müssen nun unter Umständen die immer noch komprimierten Dateien weiter entpackt werden. Dafür gibt es eigens ein Tool ("l9cut"). Dieses erkennt zwar ein C64-Programm in der .PRG-Datei, kann damit jedoch nichts anfangen und empfiehlt mir, einen Snapshot daraus zu erstellen und diesen dann zu entpacken.

Gesagt, getan: nach etwas Recherche habe ich dann das Disk Image mit dem Vice Emulator geladen und das Spiel gestartet. Das Erstellen des Snapshots war dann auch kein Problem. Jedoch wird dabei offenbar immer nur ein "Jetzt"-Zustand des Spiels gespeichert.

Denn: l9cut konnte nun tatsächlich Spieldateien aus diesem Snapshot extrahieren, jedoch nur das 1. Kapitel (von 4). Und tatsächlich: Der Interpreter hat das Spiel nun erkannt, jedoch fehlen noch die Grafiken.

Nun die genaue Frage: Wenn also diese Spieldateien tatsächlich irgendwie existieren, komprimiert in der .PRG-Datei, wie komme ich dann da am besten ran? Oder verstehe ich da etwas falsch, wie das Dateisystem beim C64 aufgebaut ist?

Ansonsten fällt mir nur ein, das Spiel tatsächlich in dem Emulator durchzuspielen, um an die anderen Kapitel ranzukommen und als Snapshot zu speichern. Und die Grafiken dann als Screenshot speichern. Nur klingt das ziemlich aufwändig und kompliziert. Leider wird auch nirgends in der Level9-Interpreter-Doku genauer beschrieben, wie man denn nun an die Ressourcen rankommen soll.

[indy4-fan]

0

Hat sich mehr oder weniger erledigt.

Laut weiterer Recherche ist es nicht möglich, irgendwie Ressourcen aus der .PRG zu extrahieren, weil es sich dabei um ein strukturelles Set von Anweisungen handelt (wohl am ähnlichsten zu Assembler, würde ich mal sagen). Demnach kann man wohl tatsächlich das Ganze nur aus RAM-Snapshots herauslesen und die Bilder muss man bestenfalls Screenshots aus Screenshots re-kreieren.

Meine selbst aus den Snapshots extrahierten Gamedats liefen auch tatsächlich nur mit dem Level 9 Interpreter, jedoch nicht mit ScummVM.

Glücklicherweise bin ich aber im Archive auf eine Collection gestoßen, die ScummVM-kompatible Gamedats inkl. der Grafiken enthält! Offenbar stammen diese aus Snapshots vom Hoxs64-Emulator (soviel hat mir jedenfalls ein schneller Blick in den Hex-Editor gezeigt).

Ich werde diese Pakete gern demnächst hier verfügbar machen, da ich ohnehin eine ScummVM IF-Collection geplant hatte, die fehlt hier meines Wissens noch und wird eher weggelassen in anderen Paketen.

[tomwatayan]

0

Also generell schließt sich das nicht zwingend aus. Das Problem wird nur wahrscheinlich sein, dass es zu den damaligen Zeiten noch nicht etablierte Standards für den Aufbau einer Executable gab. Bei Windows-Anwendungen ist das z.B. in der Regel ziemlich einfach, Resourcen zu entpacken, weil das Format schon in der Definition Header vorsieht, die neben dem Programmcode andere Resourcen identifizieren (zum einen das Icon, aber auch zusätzliche Bilder und vieles mehr, wenn man möchte).
Den C64 sehe ich in dem Zusammenhang auf einer Ebene mit den ganzen Cartridges für Konsolen. Selbst wenn man eine Diskette hatte, gab es nicht unbedingt immer ein etabliertes Dateisystem auf der Diskette, sondern manchmal nur den kleinen Pflichtloader und der hat den Rest der Diskette dann in einer ganz individuellen Weise eingelesen.

[Heinrich Reich]

0

Oha, ich sehe jetzt hier zum ersten Mal einen gelöschten Beitrag (bzw. einen Hinweis, dass er gelöscht wurde). Scheint die Formatierung des cgboards nicht ganz sauber abbilden zu können. Sehr schräg .

[Mustrum]

0

Oha, ich sehe jetzt hier zum ersten Mal einen gelöschten Beitrag (bzw. einen Hinweis, dass er gelöscht wurde). Scheint die Formatierung des cgboards nicht ganz sauber abbilden zu können. Sehr schräg .

In der Tat. Ich habe dort mal geantwortet, diesen Text aber kurz darauf hin mit delete geändert, Beitrag löschen mag die Forumssoftware wohl nicht.

[Traxx Amiga EP]

1

Ich hatte im Purebasic Forum mit der Hilfe eines Kollegen ein C64er Disk und Tape Modul geschrieben welches aus unzähligen Disk und Tape Formate den Inhalt auflisten und je nach Möglichkeit extrahieren kann.

Purebasic
Github



Kannste ja mal reingucken. Vielleicht hilft dir das weiter oder vielleicht das C64er Studio um ein paar ecken oder guggste mal beim Mirror vom Arnold FTP drauf.

[indy4-fan]

0

Also generell schließt sich das nicht zwingend aus. Das Problem wird nur wahrscheinlich sein, dass es zu den damaligen Zeiten noch nicht etablierte Standards für den Aufbau einer Executable gab. Bei Windows-Anwendungen ist das z.B. in der Regel ziemlich einfach, Resourcen zu entpacken, weil das Format schon in der Definition Header vorsieht, die neben dem Programmcode andere Resourcen identifizieren (zum einen das Icon, aber auch zusätzliche Bilder und vieles mehr, wenn man möchte).
Den C64 sehe ich in dem Zusammenhang auf einer Ebene mit den ganzen Cartridges für Konsolen. Selbst wenn man eine Diskette hatte, gab es nicht unbedingt immer ein etabliertes Dateisystem auf der Diskette, sondern manchmal nur den kleinen Pflichtloader und der hat den Rest der Diskette dann in einer ganz individuellen Weise eingelesen.

Ich denke mit viel Coding Erfahrung und Reverse Engineering Kenntnissen wäre das schon möglich. Wäre interessant zu wissen, wie der Ersteller von dem Paket aus dem Archive das gemacht hat. "Gruby" nennt er sich, hat das Paket aber nicht selbst dort hochgeladen. Keine Ahnung, wie man den kontaktieren könnte.

Ich hatte im Purebasic Forum mit der Hilfe eines Kollegen ein C64er Disk und Tape Modul geschrieben welches aus unzähligen Disk und Tape Formate den Inhalt auflisten und je nach Möglichkeit extrahieren kann.

Purebasic
Github



Kannste ja mal reingucken. Vielleicht hilft dir das weiter oder vielleicht das C64er Studio um ein paar ecken oder guggste mal beim Mirror vom Arnold FTP drauf.

Hey, super, danke. Das werd ich mir auf jeden Fall mal aufheben, vielleicht brauch ich es noch einmal. Das C64 Studio ist sicherlich interessant, wenn man auf dem C64 programmieren will. Ich hab früher viel mit Windows Scripting gebastelt und bissl C++. Aber jetzt krieg ich das kaum noch in den Kopf rein, da platzt mir der Schädel.

Sind ja auch noch einige C64-Versionen von den Scott Adams Spielen offen. Einige werden schon nativ von ScummVM unterstützt, die Datafiles und Grafiken werden gleich direkt aus dem .D64/.T64-Dateisystem gelesen. Da muss man also nicht viel basteln. Nur erstmal erraten, welches jetzt das richtige Disk Image/ROM ist, welches unter ScummVM funktioniert, da immer nur ausgewählte in den Detection Tables gelistet sind, aber nicht erklärt wird, welches das nun ist. Das macht richtig Laune...

Weiß nicht, ob man auch einfach andere ROMs zur Aufnahme reporten kann, aber die nehmen es ja immer ganz genau damit, dass es sich auch um ein Original handelt und das wäre dann ja nicht der Fall. Bei den Apple II Hi-Res Adventures von (Pre-)Sierra war das schon genau so ein Drama.

[marka]

0

Schau mal hier:

https://github.com/geraldholdsworth/DiscImageManager