Hello, Guest the thread was called749 times and contains 18 replays

last post from Stephan Scheuer at the

Zwei neue Anpassungen für die 1581/cmd/sd2iec.

    Heute habe ich mal was für die Nutzer der 1581/cmd/sd2iec gemacht. Was ödes... Trackloader rippen:D


    Das erste Programm heißt "The Body Transparent". Bei dem "Spiel" habe ich den Track & Sektor - Lader/Saver entfernt.

    Nachden ich 97 Files gerippt hatte, ersetzte ich der Lader durch die standard Kernal Routinen ($ffd5/$ffd8).

    So dürfte das Programm von allen bekannte Speichermedien laufen. Der Gamecode ist übrigens irgendein Compilat, zumindest was ganz übles.


    Das zweite Programm heißt "L.A. Crack Down". Das Spiel hatte 2 Diskseiten randvoll mit Track & Sektor - Lader/Saver Daten.

    Ich also erstmal 224 Files gerippt. Naja, dann fing der Spass erst richtig an. Grafikmodus ständig falsch, Zeichensatz wurde nicht

    ganz richtig dargestellt, $0300 war mit Gamedaten belegt usw. Letzendlich habe ich geschafft, den T&S-Lader durch die standard

    Kernal Routinen ($ffd5/$ffd8) zu ersetzen. So durfte auch das Programm von allen bekannte Speichermedien laufen.


    Da das Ersetzen eines Tracklader und Tracksaver nicht so ganz einfach ist, ich die Games auch nicht bis zum Schluss duchgespiel

    habe, können Bugs auftreten. Sie sollten eigentlich nicht auftreten. Naja, warten wir es ab.:)


    Aus "L.A. Crack Down" mache ich auf alle Fälle ein EasyFlash. Nachdem alles gerippt ist, ist ein EasyFlash zu machen, kein Problem.8)


    Viel Spass mit den Anpassungen.


    Stephan

    Ja, eine Blick auf die Magnetic Scrolls Adventures hatte ich schon geworfen. Das war vor etwa 3 Jahre. Eine Menge Notizen hatte ich mir auch über die Laderoutine gemacht. :)

    Leider hatte ich zu der Zeit nicht das Wissen, um einen so komplexen Lader zu rippen. In den drei Jahren habe ich mein Wissen über Trackloader natürlich stark erweitert, so

    dass ich nachher mal eine weiteren Blich in die Laderoutine riskiere. Vom Schwierigkeitsgrad, ist es eine glatte 10, bei 1-10 Wertungspunkte.:thumbup:

    Quote from Pyramidenkopf

    Wäre es da möglich standard Kernal loading einzubauen?

    Ich bin sicher, daß es Stephan hinkriegen würde, einen "Kernal-Load" einzubauen, aber empfehlen würde ich es nicht.

    Die Adventures von Magnetic Scrolls bestehen aus folgenden Teilen:

    1.) Emulator für die virtuelle Maschine (resident im Speicher, wird zu Spielbeginn geladen)

    2.) Beschreibbare Programmdaten für den Spielstand (resident im Speicher)

    3.) Programmcode für die virtuelle Maschine (wird dynamisch nachgeladen)

    4.) Strings (werden dynamisch nachgeladen)

    5.) Bilder in der Form von Bitmaps oder Sprites (werden optional nachgeladen)

    Nur die Bilder/Sprites können hierbei als eine Datei aufgefaßt werden, die an einem Stück geladen werden kann. Programmcode und Strings kann man sich eher als Datenbank vorstellen. Genauer gesagt betrachtet der Emulator die Diskette als großen Arbeitsspeicher seiner virtuellen Maschine. Da dieser virtuelle Speicher zu groß ist, um komplett in den Speicher des C64 zu passen, lädt der Emulator nur diejenigen Abschnitte, die er gerade benötigt und packt sie zur schnelleren Bearbeitung in einen Cache. Dieser Cache ist sektorweise organisiert wie auch die Diskette als Datenträger des virtuellen Speichers. Entsprechend handelt es sich bei dem Schnellader nicht um einen Dateilader, sondern um einen reinen Sektorlader. Der Emulator sagt dem Laufwerk, welchen Sektor er für seinen Cache haben will, und daraufhin wird dieser geladen.

    Das bedeutet, daß das übliche Kernal-Load in Form des Ladens einer Datei nicht funktionieren kann. Stattdessen müßte ein Schnellader-Ersatz die Sektoren selbst mit Hilfe der Laufwerksbefehle (U1) von DIskette holen. Das an sich wäre noch machbar, jedoch entstehen dadurch einige Nachteile:

    - Das Laden eines Sektors mittels des U1-Befehls ist noch langsamer als das Laden mit dem "Schnellader" des Spiels. Dabei ist der "Schnellader" in Wirklichkeit kein richtiger Schnellader, denn er überträgt die Bytes auch nur mittels bitweisem Handshake. Der Geschwindigkeitsvorteil ergibt sich allein durch die eingeschränkte Kommunikation mit dem Laufwerk an sich, doch bereits dies macht sich bei den häufigen Zugriffen schon bemerkbar. Mit einem Sektorlader auf Kernal-Basis dürfte der Spielfluß noch zäher werden als im Original.

    - Was den SD2IEC anbelangt, so würde auch hier gelten, daß das Spiel beim Sektorladen abtestet, ob die richtige Diskette eingelegt wurde. Es erkennt dies an der Disketten-ID. Möchte ein Programm dies per Kernal ebenfalls überprüfen, wäre hierzu eine eigene Routine notwendig, die diese ID checkt, bzw. man müßte nach jedem Sektor zusätzlich noch den Fehlerkanal auslesen. Aaarghh.....

    - Ein wichtiger Grund, warum die Entwickler einen eigenen Lader verwenden, ist die damit verbundene Fähigkeit, gleichzeitig einen IRQ laufen zu lassen und Sprites anzuzeigen. Bei einem Kernalload müssen IRQ und Sprites komplett ausgeschaltet werden, doch gerade von diesen beiden macht das Spiel fortwährend Gebrauch. (Die schwarzen Zeilen zwischen Bitmap-Graphik und Textausgabe werden mit schwarzen Sprites erzeugt, da ohne diese Sprites die Bildschirmanzeige an dieser Stelle stark flimmern würde.) Mit Hilfe des Kernals zu laden würde also bedeuten, bei jedem Laden eines Sektors zunächst den IRQ abzuschalten sowie die Sprites, dann den Sektor zu laden und anschließend IRQ und Sprites wieder einzuschalten. Das Ergebnis wäre ein sehr starkes Geflacker, das ich mir persönlich nicht antun möchte. Wenn Du wissen willst, wie sich das in etwa anfühlt, kannst Du mal das Adventure "Gruds ins Space" spielen. Hier lädt das Originalprogramm die Sektoren mittels U1-Befehl vom Laufwerk und deaktiviert dafür jedesmal seinen IRQ. Das Flackern ist bereits ziemlich nervig, und dabei werden im Gegensatz zu Magnetic Scrolls nur 2-3 Sektoren geladen und auch nur dann, wenn der Spieler einen neuen Raum betritt. Bei Magnetic Scrolls hingegen wird ständig auf das Diskettenlaufwerk zugegriffen, weil nicht nur Bilder, sondern auch Programmcode und Strings geladen werden müssen, d. h. nach fast jeder Aktion kommt es zu einem starken Flackern. Dies in Kombination mit dem noch langsameren Laden dürfte auch dem Hartgesottesten den Spaß verderben. Es gibt halt einen Grund, warum man sich damals[tm] dazu entschlossen hat, einen eigenen Lader zu verwenden.

    Wenn man das Geflacker nicht haben möchte, kann man natürlich die Graphik einfach abschalten (auch keine Spritegraphik!), doch käme dies einer Amputation des Spiels gleich. Kann man machen, würde aber dem Spiel nicht gerecht. Auf dem CPC, der von Haus aus keinen Interrupt parallel zu Diskettenzugriffen erlaubt, hat man dies so gelöst, daß das angezeigte Bild automatisch herausgescrollt wird, sobald auf das Laufwerk zugegriffen wird. Das wäre noch die praktibelste Lösung, würde aber immer noch die C64-Version arg verstümmeln.

    Naja, dann lasse ich es, das Game für das sd2isc umzusetzen. Ich möchte es nicht mit einem Kernalloader verunstalten. Es würde sich genauso verhalten, wie du es oben beschrieben hast.

    Für die anderen Laufwerke hätte ich einen IRQ-Loader, der auch mit Track- & Sektordaten arbeiten kann. Die Disk-ID zur erkennung der eingelegten Seite, hätte ich auch entfernt, wiel das

    ganze Game dann locker auf einer 1581/FD-2000 passt. An den Programmcode für die virtuelle Maschine hätte ich mit Sicherheit auch nichts geändert.


    "Tangled Tales" hatte ich mir eben auch mal angesehen. Ich würde das gerippt bekommen und auch den Lader angepasst bekommen.. Nur ist das Game nicht so mein Ding.


    PS: "The Body Transparent" hat auch einen reinen Sektorlader. Der Programmcode sah mir auch aus, wie eine Virtual Machine.

    Das was ich für die "Magnetic Scrolls Adventures" z.B. "The Pawn" mache, ist eine Diskdecryptor. Das Programm entschlüsselt die Tracks von "01;03 bis 08;01" und von "1D;00 bis 20;0F".
    Es können auch noch mehr werden. Die Laderoutine ist sehr schweigsam. Die übergabe der Track- und Sektordaten an das Laufwerk sucht auch seines Gleichen. Hatten die Coder einen Paranoia?

    Die entschlüsselten Daten werden wieder zurück auf Disk geschrieben. Aus dem Spiel wird die Dercryptor Routine entfernt. Ich machen das, weil ich gehört hatte, dass diese Games eine Passwortabfrage

    im Game haben. Im verschlüsselten Code kann man unmöglich etwas ändern. Bild 1 zeigt den entschlüsselten Track 01 Sektor 17. Der Decryptor funktioniert schon, nun muss ich das alles noch automatisieren.

    Infos zu den Decrypter Arbeiten bei "The Pawn". Die Disk Seite 1 ist komplett entschlüsselt. Zudem habe auch ich gleich die

    Passwortabfrage, die nach 100 Abweisungen auftaucht, entfernt. Den IIRQ-Lader werde ich auch rausschmeissen, und durch

    einen besseren ersetzen. Bei dem jetzigen Lader merkt man, wenn Daten entschlüsselt werden. Der wird dadurch langsamer.

    Achja, die Virtual Machine ist aufgebaut, wie ein gewöhlicher Runtime-Code von einem Austrocompiler oder den Basic64-Compiler von Data Becker.

    Das Bild zeigt eine Text, den ich nach dem entschlüsseln, gefunden habe. Nice:)8)

    Für dich kann ich die Passwortabfrage ja so gestalten, dass nach jeder zehnten Anweisung, ein Wort aus dem Handbuch abgefragt wird. Heheh:)
    Achja, man kann z.B. im Ladercode, der sich ab $1820 befindet, eine kleines Unterprogramm einbauen. Es geht auch an anderen stellen im Code.

    Aber Vorsicht, einige Bereiche sind geschützt und würden das Spiel zum Absturz bringen.


    Das hier mittels JSR aufrufen.

    -----------

    LDA #$01

    STA $523F

    RTS

    ----

    Keine Passwortabfrage mehr.:)


    Stephan

    Von "The Pawn" und den anderen "Magnetic Scrolls" Adventures ist eine REU und SCPU Anpassung ohne Weiteres möglich.

    Auch würde eine Anpassung an die 1581/CMD-Hardware funktionieren. Zur Easyflash Anpassung kann ich noch nichts sagen.:)
    Falls jemand den Diskdecryptor haben möchte oder die decrypted d64 images, kann ich diese mit anhängen.


    Für Interessierte, im Codefenster ist der IRQ-Loader, C64 Teil zu sehen.


    Quote from Stephan Scheuer

    Von "The Pawn" und den anderen "Magnetic Scrolls" Adventures ist eine REU und SCPU Anpassung ohne Weiteres möglich. Auch würde eine Anpassung an die 1581/CMD-Hardware funktionieren.

    :thumbsup: Wenn es einer schafft, bist Du das.:thumbup:

    Quote from Stephan Scheuer

    Falls jemand den Diskdecryptor haben möchte oder die decrypted d64 images, kann ich diese mit anhängen.

    Hier! Hier! Hier!:zaunpfahl:^^

    Falls es Dir nichts ausmacht, würde ich gerne auch erfahren, wie der Kopierschutz funktioniert bzw. wie Du den entfernt hast, oder schlicht alles, was Du so an Informationen herausgefunden hast.:whistling:

    Eine kleine Frage nebenbei: Ich habe oft gelesen, daß bei Magnetic Scrolls-Adventures angeblich die CPU im Diskettenlaufwerk für den Parser verwendet wird, z. B. im C64-WIki:

    Quote

    Da das Laufwerk ohnehin während des Spiels eingeschaltet bleiben muss, wird die CPU der Floppy vom Programm als Co-Prozessor genutzt.

    Hast Du dafür irgendwelche Anhaltspunkte gefunden?

    Die CPU im Diskettenlaufwerk wird nur zum decoden der T&S Datas genutzt und natürlich auch um die Daten an den C64 zu übertragen.

    Das ist zumindestens bei "The Pawn" so. Ich nehme aber mal an, dass die anderen Spiele genau so aufgebaut sind. Die entschlüsselten

    D64 Images sind natürlich so nicht lauffähig. Du müsstest den Sprung zum Decrytor Unterprogramm "jsr e1a56" mittels RTS deaktivieren,

    dann könnte es funktionieren. Das es mit der SCPU und REU läuft, kann ich mal so sagen, weil bei beiden Speichermedien der IRQ nicht

    deaktiviert werden muss, im gegensatz zum Easyflash oder sogar zum Kernalloader. Das Image "pawn main file decrypt" enthält die entschlüsselte

    Hauptdatei und den decryptor (start $c000) für die erste Seite des Spiels. Der Passwort Kopierschutz wird im Grunde nicht deaktiviert sondern nur

    überlistet. Jetzt im Code der VM rumzuwühlen um genau den Sring zu erwischen, der für ein inc $523f,cmp #$64 oder ähnlich verantwortlich ist,

    setze ich den aktuellen Wert immer wieder auf #$01. Das ist genauso wirkungsvoll aber bedeutend einfacher.


    Falls noch Fragen sind, immer her damit. Ich bin nun in der Lage, den ganze Trackloader zu rippen und in ladbare Files umzuwandeln.


    PS: Wenn man das Laufwerk ausschaltet, killt man den Floppytreiber. Auf der C64 Seite hängt das Spiel dann in einer Warteschleife $DD00 fest.:)


    Sorry, die Seite 2 war falsch. Nun stimmt es.:)


    Hätte vorher nicht gedacht, dass man es hinbekommen würde, einige dieser Magnetic Scroll Adventures an das SD2IEC anpassen zu können. Gehofft hatte ich das natürlich schon, da Spiele wie "The Pawn" oder "Fish" echt gut sind.


    Da ich mich aber erinnere, dass ich Cracks beider Spiele (mit dem 1541-Ultimate und einem 1541-Floppy) nichtmal mit dem "Action Replay 6" Diskcopy von d64 auf echte Disketten kopieren konnte (zumindest keine dann lauffähigen), sondern dafür extra das Kopierprogramm "Maverick" im Nibble-Modus nehmen musste (damit ging's dann), war mir schon klar, dass diese Games wohl auch grosse Probleme machen werden, wenn man versuchen würde, sie auf IDE64/SD2IEC Hardware lauffähig zu machen.


    Sehr gute Arbeit, dass dies nun anscheinend doch zu klappen scheint. Top!

    Die Anpassung am SD2IEC oder auch Easyflash wäre möglich, nur ist das Gameplay dann nicht mehr so gut, weil bei Diskzugriffe immer der IRQ gesperrt werden muss.

    Zudem müssen die Sprites deaktiviert werden und ein paar andere Sachen auch.

    Das du das Spiel nicht so einfach kopiert bekommst, liegt an der Arbeitsweise der Kopierprogramme. Du muss eines nutzen, das die Disk-ID der gesammten Disk richtig kopiert.

    90sekunden Copy oder Masterkopie sollten funktionieren. Das Game nutzt die Disk-ID als Seitenerkennung.


    PS: Das ich es geschafft habe, die Passwortabfrage zu entfernen, hätte ich auch nicht gedacht. Das hatte vorher keiner geschafft.

    Quote from Stephan Scheuer

    Das du das Spiel nicht so einfach kopiert bekommst, liegt an der Arbeitsweise der Kopierprogramme. Du muss eines nutzen, das die Disk-ID der gesammten Disk richtig kopiert.

    Die von dir genannten, oder halt eben "Maverick" im Nibble-Modus. Wie ich schon geschrieben hatte, klappte es damit auch. Da sieht man auch mal, wie ausgereift das 1541Ultimate ist, denn ich hatte diese beiden Games mit "Maverick" unter Zuhilfename das 1541U und eines normalen 1541 Floppys ja sogar von d64 auf echte Disketten kopiert. Läuft einwandfrei.


    Einziger kleiner Nachteil - "Maverick" im Nibble-Modus hat dann keine Verify-Funktion mehr. Man muss hier dann also eine echte Diskette nehmen, die man vorher geprüft hat und von der man dann genau weiß, daß sie noch fehlerfrei funktioniert.



    Schade, dass es dann diese Gameplay Probleme geben würde, hatte gehofft man könnte vor allem "The Pawn" dann übers SD2IEC zocken, aber okay, wird dann wohl doch nichts werden.


    Jetzt hoffe ich, dass irgendwann dann noch die Nostalgia Version von "Toki" und die 64K Version von "Super Bread Box" an das SD2IEC angepasst werden. Davon abgesehen, fällt es einem dann schon langsam schwer, noch gute/interessante Games zu finden, die noch keine SD2IEC-kompatible Version haben. Ein paar gibts aber noch, bei denen es sich lohnen würde.


    Das Preview von "Spooky" etwa, wäre eventuell noch interessant


    https://csdb.dk/release/?id=161194


    Es ist zwar nur ein Preview und vielleicht wird nie ein komplettes Spiel draus, aber schon das Preview bietet überragende Sprite-Animationen und einfach geile Grafik. Das Game besteht aus zwei Files und vom zweiten File wird während des Spiels nachgeladen ab und zu. Deshalb funktioniert das Teil auch nicht am SD2IEC blöderweise.

    Och, ich wüsste da schon noch so einige Spiele für das SD2IEC und das Easyflash. Aber mittlerweile wird es schwerer, weil zunehmend Trackloader ins Spiel kommen.

    Bei "The Pawn" ist das letzte Wort noch nicht gesprochen. Es gibt ja auch IRQ-Loader die mit dieser Hartware funktionieren.:)

    Aber da muss ich noch einiges testen. Ich möchte doch alle Magnetic Scrolls Spiele an diverser Hardware anpassen.:)

    Toki ist natürlich nicht vergessen und "Super Bread Box" auch nicht.