Disassemble Blog: Ihatovo Monogatari

[lytron]

Stunde 102
Disassembled: 204.558 / 1.048.576 Bytes (19,508%)
Gehört: Hiroki Kikuta - Secret of Mana OST

Nach einem Vormittag, an dem ich mich künstlerisch für das SNES ausgetobt habe, werde ich mal wieder sachlich und steige in die Welt der Opcodes ein.

~~~
Grmpf. Ich bin nicht gerade schnell und nicht gerade produktiv, gerade. Ich disassemble für drei Minuten und suche mir für zehn Minuten was anderes zu tun. Einmal, weil diese Subroutine kein Ende nimmt, und ein zweites Mal, weil sie so dämlich unübersichtlich ist, weil so viel gebrancht wird. Hrmpf.
~~~
Es sind noch $29B Byte bis zum Anfang des Maus-BIOS... und ich befürchte, die werde ich noch hiermit vollkriegen. :/
~~~
Und keine zwanzig Bytes später war ich mit der Subroutine fertig.
*husthust*
Mir dräut, dies schadet meiner Außenwirkung.
~~~
Oh, klasse, eine neue Jump Table in der nächsten Subroutine. o_ô
~~~

Stunde rum, Resümee:
Man kraucht so vorwärts. Die große Subroutine habe ich abgeschlossen und deren Nachfolger ebenfalls (bis auf den darin hingesprungenen Jump Table-Eintrag), und es ist noch nicht ersichtlich, wofür alle dessen Funktionen dienen. Das zu ergründen macht erst Sinn, wenn der Rest, nämlich der Verwendungszweck, disassembled ist.

[lytron]

Fire Striker benutzt mindestens dieselbe Sounddaten-Transfer-Subroutine wie Ihatovo Monogatari.

[lytron]

Stunde 103
Disassembled: 211.114 / 1.048.576 Bytes (20,133%)
Gehört: The Receiving End of Sirens - The World sings Mi Fa Mi

Bevor ich wieder arbeite, mal ein bisschen was anderes.

Warum ich immer noch per Hand disassemble und nicht Geigers Log-Feature für SNES9x benutze
Zu Beginn dieses Projekts war das einzige Programm, mit dem ich disassemblen konnte und auf dessen Leistung ich mich verlassen konnte. Mehr oder weniger.
Wie ich es gewiss schon einmal erwähnte, disassemble ich mit einem Online-Disassembler, in dessen Textfeld ich den Hexcode kopiere. Das Problem ist, dass dieser Disassembler nicht immer richtig merkt, ob mein Akkumulator oder die Index-Register acht oder sechzehn Bit groß ist. Folglich interpretiert er das gern falsch und ab dann sind die nächsten Befehle falsch gedeutet. Das ist hakelig und ärgerlich, aber ich kann damit umgehen.
Vor einiger Zeit gab mir Svambo den Geiger, also den SNES9x-Emulator mit Log-Funktion, und auch wenn es sich um ein sehr hervorragendes Tool handelt, werde ich es für dieses Projekt nicht nutzen. Der Grund ist: Mit meinem Disassembling kann ich entscheiden, was ich disassemble; mit dem Geiger muss ich solange spielen, bis ich eine bestimmte Passage im Code bei der Ausführung selbst erreiche.
Desweiteren ist das Branching sehr problematisch. An Verzweigungen wird immer dem Programmfluss gefolgt. Folglich, wenn eine Abzweigung genommen wird, wird dieser gefolgt. Habe ich eine Subroutine, in der fünf mal gebrancht wird, und jeder Branch wird genommen, habe ich sechs Segmente dieser Subroutine, über die Logfile(s) verteilt.
Aus diesen Gründen disassemble ich per Hand und nicht mit dem Geiger.

Warum ich Geigers Log-Feature für SNES9x benutze und nicht immer noch per Hand disassemble
Ich hatte in letzter Zeit einige Möglichkeiten, den Umgang mit dem Geiger-Tool zu üben, und werde ab jetzt die Logfiles nutzen. Das Branching istkacke, aber mit meinem Per-Hand-Disassemble wenn überhaupt nur minimal besser. Der entscheidende Faktor ist bereits das, was Svambo selbst angeführt hat, als er mir das Tool nahegelegt hat: Zeitersparnis. Ich erhoffe mir, auf diese Art und Weise das Projekt schneller vorantreiben zu können, und schneller zu Ergebnissen zu kommen. Außerdem bieten die Logs im besten Fall die Möglichkeit, ein wenig über den Tellerrand hinauszuschauen zu sehen, was mit den jetzt gerade errechneten Ergebnissen in der drittnächst aufgerufenen Subroutine erreicht wird.
Am effektivsten bei der Entscheidung, ob ich den Geiger oder den Web-Disassembler nehme, ist schlichtweg das Kombinat aus beiden. Es wird sicherlich auch Momente geben, wo ich schneller zum Ziel komme, wenn ich gewisse stetig überbranchte Bytes per Hand nachdisassemble und einfüge, als wenn ich auf die Log warte.

Und spätestens jetzt hat Svambo einen festen Platz auf meiner Dankesliste für dieses Projekt verdient. Anderer Dank geht an ikari_01 für steten Beistand in Assemblerfragen seit der ersten Stunde, ChronoMoogle für den zündenden Funken und steten Arbeitsanschub, Moi für die Plätzchen und den Tee und euch allen anderen für den Support und die Motivation hier aus dem Forum.

Soweit dazu, ich fange jetzt an.
Ich habe gestern schon einmal eine Log vorbereitet; sie begann ab dem "Neues Spiel starten" und geht bis zum Einsammeln des ersten Items im Wald. Jetzt muss ich die Sachen aus meiner Log herausschmeißen, die ich eh schon in meiner ROM habe. Dank meiner ROM Map kann ich das aber tun, ohne wie blöd in meinen einzelnen ASM-Files rumzuscrollen. Yay!
~~~
Vielleicht kann ich jetzt schon wieder einen neuen Counter aufmachen, hah.
Ich habe die Log einmal im Original, wie sie aus dem Geiger kam, und einmal ein "Worklog", aus dem ich alles herauslösche, was ich schon berarbeitet habe. Die Original-Logdatei war/ist 438 KB groß (wobei ich mit einer wesentlich größeren gerechnet hätte; zwei Game-Intros, die ich mal geloggt habe, waren gut eineinhalbmal so groß), mein Worklog ist gerade bei 410 KB. Und jetzt gerade stehe ich vor der kompletten Sound-Geschichte, die ich schon disassembled habe. Das heißt, noch einmal wird ein großer Teil der Schere anheimfallen. Yay!
~~~
ZU PRÜFEN: Die Tastenkombination, um den SRAM zu clearen, steht im Main-Loop. Damit ist ja auch ein Neustart des Spiels verbunden. Wird der Stack-Pointer auch zurückgesetzt? Wenn nicht, ließe sich das Game vermutlich so crashen, wenn man x-mal diese Kombination während einer Inbetriebnahme macht.
Warum man soetwas als normaler Gamer tun sollte, sei mal dahingestellt.
~~~
Zwanzig Minuten zu Gange, immer noch ncihts neues in der Worklog, aber dafür bin ich schon bei 375/438 KB.
So schnell wird die nie wieder schrumpfen!
Fällt mir ein, was ich für die Nicht-Programmierer erwähnen sollte: Das, was in der Log steht, ist nur Code, und natürlich kein Byte Grafik-, Text- oder Sounddaten. Das wird nachträglich im Schritt der Code-Exegese erfolgen.
~~~
So, jetzt bin ich bei 366/438 KB, und die Worklog-Geschichte entfaltet noch eine Blüte der Schönheit. Jetzt bin ich nämlich an dem Punkt angekommen, ab dem ich meine ROM Map auch mal aktualisieren muss, weil disassemblete Sachen in den ASM-Files stehen, aber nicht in der ROM-Map vermerkt sind...
~~~
Huh, was ist hier los? Da ist ja mittenmatsch ein Teil, den ich noch gar nicht disassembled habe. Wo wirdn der aufgerufen!?
~~~
Wow, in der Tat, ich habe das Ding übernommen. Mensch, hat sich das doch schon gleich gelohnt! Geiger rockt! Svambo rockt! Dann füge ich die Subroutine jetze ein! Und nenne die Sprungmarke fürs erste... GeigerSvamboRockt! Hah!
~~~
ZU PRÜFEN: Wäre vermutlich später mal wichtig zu wissen, ob ein entscheidender Unterschied zwischen den ganzen Flexi_DMA-Subroutinen ist, wann die DMAs ausgeführt werden. Es scheint dort einen Unterschied zu geben. Manche Sachen werden direkt gestartet, weil das Speichern eines Werts in $420B mit zum Programm gehört, manche Sachen werden nur in DMA-Pipe geschmissen und bei der nächsten Abarbeitung (im nächsten Frame?) erledigt.
~~~

Stunde rum, Resümee:
Ich habe die gesamte Zeit jetzt gebraucht, diese übersehene Subroutine einzubinden. Und die ist nicht lang gewesen.
Allerdings enthielt sie einen Flexi-DMA-SR-Aufruf, wobei ich diese Subroutine ganz zu Beginn dieses Projekts disassembled habe und dort noch einige Dinge im "Style" anpassen musste.
Der DMA übertrug folgende Daten:

Neue Bitmap (2).jpg (117.65 KiB) 4773 mal betrachtet

Diese Grafikdaten haben dann doch den Counter-Wert "gerettet".
Das ist das Menü, aber ich frage mich, ob die Schriftzeichen unten eventuell auch in Textboxen genutzt werden. I heavily doubt that.

[ChronoMoogle]

Verstehe, dann hat echte Handarbeit also doch noch seine Vorteile gegenueber automatisierteren Verfahren. Und hey! Ein font-tileset! Ich rieche schon die ersten Textdumps, auch wenn du vermutest, dass es nur zum Menue und nicht den Textboxen gehoert...!
Desweiteren Glueckwunsch zur 20% Marke,　es geht ja doch gut vorrann!

PS: Lustige Sache mit Fire Striker. Das Spiel wurde auf den Treffen auch schon oefter mal zu viert gespielt

[lytron]

Mal schauen, ob es da was zu dumpen gibt. Ich müsste mein Dumping-Tool (eine gepimpte Excel-Tabelle) auch nochmal weiterbauen...

Firestriker, las ich irgendwo, soll gar nicht mal so gut sein. Eher frustrierend. Kann ich nicht bewerten, habe es nur für diesen technischen Bla mal angetestet, unter der Woche, vorm Schlafen Gehen.
Aber Hect Games sind bestimmt überhaupt die Renner schlecht hin. Es gibt nur einen Grund, warum ihr auf euren Usertreffs nicht stundenlang über die Throroughbred Breeder-Reihe diskutiert: Die Sprachbarriere.

Ein Spiel mit sprechenden Pferden!

Da gibts für Moi kein Halten mehr!

[ChronoMoogle]

Firestriker ist ein solides Spiel mit recht einzigartigen Spielprinzip (im Prinzip Zelda meets Breakout). Es ist zwar nicht leicht... aber frustrierend? Nee.

[lytron]

Stunde 104
Disassembled: 211.440 / 1.048.576 Bytes (20,164%)
Gehört: Six Galery - Breakthroughs in Modern Art, Lions - Roosevelt EP x 2

Weiter.

~~~
Ist das die Möglichkeit? Schon wieder eine Subroutine übersehen.
Du sollst fortan heißen... KiddoSuperstar.
~~~
Noch eine Sache, die Kacke beim Disassemble nach Log-Dateien ist: Wenn gebrancht wird, der Branch nicht genommen wird, und mitten ins Nichts führt.
~~~
So. KiddoSuperstar war so ein Ding. Vier Vergleiche, vier Branches ins Nichts, weil keiner der vier Branches genommen wurde. Gerade alle per Hand hinterher disassembled.
~~~
Hui, toll, ich habe noch zwei Unter-Subroutinen einer Subroutine vergessen. Außer KiddoSuperstar. PandaBlackEdition und DreimerRhymer.
~~~
Toll. PandaBlackEdition sind ebenfalls Verzweigungen in den den blauen Dunst. Also, wieder Disassemblen von Hand.
~~~

Stunde rum, Resümee:
Interessante Sache. KiddoSuperstar lädt einiges aus den SRAM-Registern und speichert entsprechend einen Wert in $1063. PandaBlackEdition lädt einen bestimmten Wert in Abhängkeit vom Wert in $1063 in den Akkumulator. DreimerRhymer speichert den Wert in A in ein Direct Page-Register für einen Indirect Long Indexed LDA-Befehl und transferiert dann entsprechend irgendwelche Daten von A nach B. Interessante Sache. Hängt alles drei zusammen. Wie, müsste ich mal genauer gucken. Aber cool. Cool cool cool.

[lytron]

Stunde 105
Disassembled: 211.826 / 1.048.576 Bytes (20,201%)
Gehört: Kuniaki Haishima - Monster OST

Es geht weiter-weiter. Und fiel mir neulich auf: Wenn ich durch diese Log-Datei durchbin (noch 349 von 438 Kilobyte), müsste mein Programm... funktionieren. Ich meine, dann habe ich Maps, Bewegungen, Textboxes und auch Item aufsammeln. Dann, ich kann es mir kaum vorstellen, habe ich sogar schon einen großen Teil der Engine. Das ist, äh, irgendwie schwer vorstellbar! ^_^
Aber wir werden sehen, wie es laufen wird, und auch, wie schnell es laufen wird. Bisher war das Disassemblen aufgrund des Branching nicht so schnell, wie ich erhofft hatte. Wir werden sehen.

~~~
Hm. Was ist das? Was ist das nur!?

Am Ende dieser Subroutine habe ich ganze vier weitere Subroutinen nicht weiter disassembled. Ich muss hier aufgehört haben zu arbeiten. Das wird es sein. Ich muss hier aufgehört haben zu arbeiten...
~~~

Stunde rum, Resümee:
Ich sah viele Dinge, ich verstehe nur nicht, recht darüber zu berichten...
Wie man sieht, habe ich in dieser Stunde fast 400 Byte hinzugefügt; sonst lag meine Höchstleistung bei 200 bis 300, und gerade habe ich noch nicht einmal von Anfang bis Ende nur damit beschäftigt, Daten aus der Log in meine ASM-Datei zu packen. Ich stand am Fuße einer Subroutine, von der ich nicht wusste, ob ich sie bis zum Ende der Stunde komplett in die Datei eingepasst, kompiliert und auf Fehler geprüft bekäme und so ließ ich sie vorerst aus und entfernte aus dem weiteren Verlauf der Log-Datei noch viele überschüssige, weil bereits disassemblete Code-Passagen.
Folglich ist meine Log-Datei nur noch 292 von anfänglichen 349 bei ursprünglichen 438 Kilobyte groß.
Nur zum Verständnis: Diese Log-Datei wird im kommenden nie und nimmer so schnell abnehmen wie bisher, und wird auch nicht gleichmäßig abnehmen. Ein Beispiel: In einer Subroutine wird ein Wert geladen, verglichen, und da der Vergleich positiv ist, wird nicht abgezweigt und die Subroutine beendet. Die Abzweigung indes ist ein Batzen Code, der 400 Byte lang ist und ich folglich mindestens zwei Stunden brauche, das Ding per Hand zu zerlegen. Während dieser zwei Stunden nimmt meine Log-Datei um obengenannte vier, fünf Zeilen ab, was nicht mal einem Kilobyte entspricht.
Folglich ist dieses stete Nennen der Log-Datei-Größe in keinster Weise etwas, was einem hilft, abschätzen zu können, wie lange ich noch brauchen werde, um die Log-Datei komplett abgearbeitet zu haben. Es ist nur für ein psychologisches Hilfsmittel, um mir selbst zu vergewissern, wie viel ich schon geschafft habe. Motivation ist alles!

[lytron]

Stunde 106
Disassembled: 211.826 / 1.048.576 Bytes (20,201%)
Gehört: Tsukasa Tawada - Ihatovo Monogatari OST

Weiter ins schnöde Log-File-Slashing.

~~~
Gut, öhm... es wird immer peinlicher. Die von mir letztstündig umgangene Subroutine war bereits disassembled. Es wird nur irgendwo in deren Mitte hereingesprungen und nicht an deren Anfang, so erkannte ich sie nicht auf Anhieb.
~~~
Ein weiterer Nachteil daran, wenn man eine Log nutzt, ist, dass man nicht nachvollziehen kann, wie man von einer Codepassage zur nächsten kommt, weil man bereits-geloggten Code nicht mitausgibt (da es ansonsten schlichtweg unlesbar ist, da zehntausend Durchläufe desselben Loops dargestellt werden, nur weil der Spieler für eine halbe Sekunde keinen Button drückt). Gerade *hoffe* ich, das ich den Sprung im Log damit erklären kann, dass ich gerade den nächsten JT-Eintrag erreicht habe.
~~~
*puh*
Es ist so. Jetzt bin ich bei JT08. Und, offensichtlichie wurde diese (Haupt?)-Jumptable wohl für mehr Einträge ausgelegt, als sie tatsächlich enthält, da an vielen Stellen ein JTSuperReturner eingefügt ist. Der JTSuperReturner enthält, für ASM-Kundigen, ein "RTS". Für die Unkundigen: Datt Ding macht nix.
Gut zu wissen, wenn man das Spiel irgendwann mal erweitern will.
~~~
Wie man merkt, gurke ich gerade eher über die Jump Table und schaue sie mir an, bzw., um genauer zu sein, füge die Adressen als Kommentare und die JTSuperReturners ein. Interessanterweise ist ein SuperReturner zwischen den HectLogo-JT-Einträgen und dem TitleScreen. War da eventuell mal was zwischen geplant (irgendeine zusätzliche Einblendung o. ä.)? *achselzuck* Wahrscheinlich nicht, da zwischen HectLogo und Titlescreen ja noch das Gedicht und der Intro kommen.
~~~
Stunde rum, Resümee:
Ich musste auf der Hälfte abbrechen, was doof ist. Jetzt liegt da noch ein ungeordneter Klumpen in der File, in den ich nie und nimmer wieder reinfinde, wenn ich jetzt abbreche. Und eigentlich hätte ich noch genug anderes zu tun. Manno.

[lytron]

Stunde 107
Disassembled: 212.370 / 1.048.576 Bytes (20,253%)
Gehört: Mahtulu - Fault Linex2

Bringen wir zuende, was wir begannen.

~~~
Stunde rum, Resümee:
Wir brachten zuende, was wir begannen.

[ChronoMoogle]

Mir faellt gerade auf, dass du 2x Stunde 105 hast. Gehoert das so? :)
Und: Ist das Intro und das Startmenue eigentlich schon fertig? Habe irgendwie nicht so richtig den Ueberblick, was du gerade disassemblest :D

[lytron]

Danke für den Hinweis, habe ich korrigiert.

Das Menü steht in seiner Gänze, gerade verliere ich mich irgendwo im New Game. Ich habe mich mit dem Code nicht näher auseinandergesetzt; ich habe kommentiert, was ich auf Anhieb verstanden habe, und gegen Ende habe ich nur noch stumpf die Log-File umgewandelt.

[lytron]

Stunde 108
Disassembled: 212.865 / 1.048.576 Bytes (20,253%)
Gehört: Reno Dakota - Popularity EP, Kuniaki Haishima - Monster OST

Da ich gern dieses Projekt fortführe, aber selten genug noch Zeit habe, mich eine Stunde konzentriert dranzusetzen, mache im mal glatt weiter.

~~~
Stunde rum, Resümee:
Jaaa, es geht voran.
Durch das Logfile-Schlachten bin ich mehr "vom Produkt entfremdet". Ich gucke mir den Code in dieser Phase nicht mehr allzu genau an, weil ich es nicht muss. Dementsprechend habe ich nichts spannendes zu berichten. Außerdem bin gerade sehr davon angetan, wie schnell es hier von statten geht: Ich habe in dieser Stunde 495 Bytes hinzufügen können, die Logfile ist gerade bei 243 von 438 Kilobyte. Für alles wird seine Zeit kommen. Gerade finde ich immer mehr Jump Tables jenseits der ersten, großen. Langsam gehts ans Eingemachte. Dennoch kann ich mir immer noch nicht so recht vorstellen, vergleichsweise schnell dann doch alles in "meinem Programm" zu haben. Das treibt mich gerade auch eher beim stupiden Disassemlben nach vorne.

[lytron]

Stunde 109
Disassembled: 213.226 / 1.048.576 Bytes (20,335%)
Gehört: Jochen Malmsheimer - Zwei Füße für ein Halleluja

Weiter, weiter.

~~~
Ich surfe die Log-File, um eine viel verzweigende Subroutine zusammenzu bauen. Ich hoffe, ich habe jetzt alle Teile beieinander; aber so wird es natürlich auch nicht unbedingt übersichtlicher, weil die Log-File jetzt damit nicht mehr "im Fluss" ist. Gewisse Teile fehlen. Aber, hey, egal, wenn ich nach dem Inhalt schauen werde, werde ich wohl eh JT-Einträge-weise vorgehen.
~~~

Stunde rum, Resümee:
Es ist ein klarer Vorteil, diese Log-File zu haben. Es geht schneller, und gerade ist es für mich sehr angenehm, die Stunden hier zu absolvieren, da es ein Arbeiten nach Stempeluhr im positivsten Sinne ist: Ich fange an, übertrage sechzig Minuten stumpf, höre auf, fertig.
Doof ist es nur, wenn man hier was spannendes lesen will. Sorry, nee, gibt es nicht. Aber, na ja, schauen wir mal. Es sind noch eineinhalb Wochen bis Himmelfahrt, wenn ich bis dahin die Logfile fertig habe, kann ich an dem langen Wochenende mich vier Tage lang damit intensiv beschäftigen. Aber ich will mich nicht darauf festlegen, dass ich dann dazu geneigt sein werde, mich derart eingehend damit zu beschäftigen.

Darf ich noch einmal an den Hinweis aus der ersten Stunde erinnern, dass ich mir vorbehalten habe, dieses Projekt auf ewig schleifen zu lassen, wann immer mich dazu gelüstet?

[lytron]

Stunde 110
Disassembled: 213.700 / 1.048.576 Bytes (20,380%)
Gehört: Peter Tschaikowski - Der Nußknacker (erste Stunde)

Heute rocke ich die Butze, heute hau ich auf den Putz, dass selbiger bröckelt. Hell yeah!

~~~
Ich zerlege gerade wieder einen Koloss und bin überrascht, dass es dort doch einige Loops drin gibt. Scheint sich schon um so eine Art "Ober-Subroutine" zu handeln; auch wenn es nicht unbedingt viele Aufrufe von "Unter-Subroutinen" gibt, ist durch allerlei Loops doch einiges an Daten hier in Bewegung.
~~~
Okay, jetzt muss ich prüfen, ob ich gerade irgendetwas vollends zerschossen habe!
Yay, ich liebe sowas. Das ist die Spice of my life.
... und das Spice muss schließlich fließen...!
~~~

Stunde rum, Resümee:
*hust*
Ganz so gerockt habe ich dann doch nicht, wie ich wollte. Aber wenigstens wieder eine größere Subroutine geschafft. Von der ich wirklich denke, dass ich da durch aus dran gescheitert wäre, wenn ich nicht die Log-File (219 von 438 KB) genutzt hätte. Denn bei dieser jenen Logfile kann ich wenigstens sehen, wo diese Jump-Table-Einträge mich hinführen. Denn, bei der gerade hier zusammengesetzten Subroutine war nicht unbedingt ersichtlich, wie sich der Zeiger für die Jumptable errechnet. Folglich wird es schwierig, nachzuschauen, an welcher Stelle es weiterginge.
Wie auch immer, einiges geschafft, und irgendeinen DMA habe ich gerade gefunden. Mehr und mehr sind DMAs meine besten Freunde, denn dort kann ich dann schlussendlich auch erkennen, wozu all diese Zahlenumformungen führen. Dort konnte ich gerade erkennen, dass etwas aus dem WRAM in den VRAM übertragen wird, wobei das Ziel im VRAM andeutet, dass es eine Tilemap ist. Das ist schon mal viel!