Disassemble Blog: Ihatovo Monogatari

[Svambo]

Mir als Unwissendem gebührt es eigentlich nicht, hier Tipps zu geben, aber ...


Versuch doch nochmal, dir den Geiger anzusehen. In der Log-Datei könntest du sowas relativ problemlos nachvollziehen...

[lytron]

Versuch doch nochmal, dir den Geiger anzusehen. In der Log-Datei könntest du sowas relativ problemlos nachvollziehen...

Danke, aber wenn das Ding auf meinem PC nicht läuft, kann ich auch nichts machen... :/

[lytron]

Stunde 5
Disassembled: 640 / 1.048.576 Bytes (0,061%)
Gehört: Wamdue Project - Program yourself

So. Dank ikaris großartiger Hilfestellung werde ich wohl jetzt leicht herausfinden können, wo die DMA-Daten liegen, und dann auch weitermachen. Aber zuerst werde ich das, was ikari erklärt hat, irgendwie versuchen, auf Englisch als Kommentare zu vermerken.

~~~
Gerade beim Kommentieren befürchte ich, habe ich bei SPCIntro3 so etwas wie einen Daten-Transfer erkennen können (AFAIK funktioniert der SPC-Datentransfer ja immer mit einem stetig um-1-abnehmenden Counterwert. Und ich befürchte, das wird X sein. Das schlimme ist, dass ich mich dann damit nochmal auseinandersetzen muss, weil ich, wenn ich recht habe, irgendwo auch schon Musikdaten ausfindig machen kann.
~~~
Okay, der Aufruf der DMA-Funktion ist quasi auch ein Schlag ins Wasser. Es werden keine Grafikdaten übertragen; es wird ein "fixed Transfer" eingestellt, und als zu übertragende Datenmenge $0000 eingetragen - selbstredend, dass der "fixierte" Byte $00 ist. VRAM-Großreinemache. One DMA to rule them all.
~~~
Ich wunder mich, warum die immer wieder Interrupts disablen und zweimal den Native-Mode starten. Ich denke, da gibt es wahrscheinlich wieder eine Ausnahme der Sonderregel im seltenen Sonderfall, weshalb das sinnhaft ist. Wie gesagt: Wenn ich es nicht verstehe, hat sich die Überlegung bereits im Vorhinein erübrigt, ob das vielleicht ein Fehler von deren Seite war.
~~~
$49 und $4A sind offensichtlich für den BG1-H-Scroll gedacht...

Stunde um, Resümee:
Insgesamt eine unaufgeregte Stunde. Kommentiert, DMA betrachtet, weitergemacht.
Die gefundene, weitere Subroutine dient dazu, die BG-Scroll-Register für BG1 bis BG3 entsprechend der Werte in DP-Register $49 bis $54 anzupassen. Diese Register wurden vor ihrem Premieren-Aufruf alle auf null gesetzt, natürlich. Aber das ist gut, dann kann ich damit wenigstens schonmal beim nächsten Mal einige Variablennamen vergeben. Juhu.

Oh, und was ich mir auch noch als TO DO setzen sollte: Endlich mal den Header dem Original anpassen.

[lytron]

Stunde 6
Disassembled: 778 / 1.048.576 Bytes (0,074%)
Gehört: Die Sterne - In Echt (mit Bonustracks)
So. Freitag abend. Die Arbeit ist getan. Ich bin geschlaucht. Es geht weiter. Variablennamen. Header. Dann Disassemble. Hell yeah.

~~~
Öööh... dieses Mal gibts wohl wieder nicht so viel zu sagen. Beim OAM-Low-Table-Clearen wird nur die X-Koordinate gecleart (und der neunte X-Bit im Hightable gesetzt), ansonsten wird das nichts gecleart. Bzw.: Es wird zwischen $0200 und $0420 nichts weiter gecleart. Das ist die "RAM-Spiegelung" der OAM-Daten.

Stunde um, Resümee:
Stunde um? Wirklich schon? Hm.
Es gibt wirklich nichts zu berichten. Es wurde weiter initiiert, es wurde weiter ganz viel überall null gespeichert.
Dieser "Blog" soll, neben viel Technikgebabbel auch einen ungefähren Eindruck geben, was man(/ich) so in einer Stunde Disassembling alles erleben kann. Und das kann auch mal nix sein. Das wird sehr häufig nix sein. Jetzt gerade habe ich ein paar Variablennamen eingesetzt, weil mir das mal später nützlich sein kann. Danach habe ich noch eine Subroutine gefunden, die später mal die Sprites deaktivieren wird. Das ist die nächste Subroutine nach der DMA-Subroutine, die eindeutig so gestrickt ist, dass sie immer mal wieder im Verlauf des Programms aufgerufen werden wird --- das ist eine "Ah, gut zu wissen."-Information. Allerdings nur ein kleiner Krümel im großen Ganzen, und das Gefühl, massig was gerissen zu haben, hat man dadurch selbstverständlich nicht. Aber der Abend ist noch jung...

[lytron]

Stunde 7
Disassembled: 918 / 1.048.576 Bytes (0,088%)
Gehört: Tomohito Nishiura - Professor Layton and the Mask of Miracle OST

Es geht weiter mit dem Subroutinieren. Ich rechne noch mit einigem Gecleare, bis es mal "richtig losgeht".

~~~
Gut. Ich kann mich glücklich schätzen, dass ich vor zwei Wochen mal ikari_01 gefragt habe, wo eigentlich der SRAM liegt, denn augenscheinlich wird der hier auch geprüft.
Zuvor habe ich die Subroutine bearbeitet, die ich vor ein paar Tagen erwähnte, beim Überfliegen erblickt zu haben. Die Subroutine, die nicht den flexiblen DMA macht, sondern sehr strikt die Spritedaten überträgt. Und da hätte ich mir auch logisch schon denken können, warum man das in einer gesonderten Funktion mit festen Werten macht:
Es handelt sich um die Übertragung der OAM-Daten, und die sind, wie so oft (und in der Stunde zuvor erwähnt), im RAM abgelegt und werden dann per DMA übertragen. In derselben Subroutine wird im DMA Channel 1 dann auch gleich der CGRAM übertragen. Das bedeutet, im gleichen Atemzug habe ich dann herausfinden können, wo im RAM diese Daten "gespiegelt" werden.
~~~
Als ich gerade die nächste Subroutine untersuchte, sah es so aus, als wäre es dafür prädestiniert, ikari_01 wieder um Hilfe anzurufen, aber beim Auseinandernehmen hat sich zusehens herausgestellt, dass es sich um die Prüfung der Spielstände handelt. Es werden die ersten acht Bytes geprüft, ob sie bestimmte Bytes enthalten (ich muss gleich gucken, ob ich die richtig geschrieben habe, ich glaube, da steht dann als ASCII-Buchstaben gesehen soetwas wie "IHA_ram." o. ä.), wenn nicht, werden die betreffenden 512 Bytes erstmal plattgemacht (Schibboleth, anyone?).
Das ganze läuft verschachtelt ab. Es wird eine Subroutine aufgerufen, die wiederum eine Subroutine aufruft. Die Zweite, Untergeordnete, führt das Ganze in Abhängigkeit des Werts von X aus (LDA $700000.l, X); in der ersten Subroutine wird diese zweite dreimal hintereinander mit unterschiedlichen X-Werten aufgerufen.
Der Punkt, übrigens, wo ich gemerkt habe, dass ich hierfür ikaris Hilfe (noch ) nicht brauchte, war, als ich realisierte, dass ich gar nicht im RAM ($7E), sondern im SRAM ($70) hantierte.
~~~
Die Stunde ist um, und ich will mal gucken, ob sich das Ding jetzt mit so vielen angefangenen Baustellen überhaupt kompilieren lässt.
Und, *oh*, ich will mal schauen, ob ich ohne SRAM-signalisierendem Byte im Header auf Bank $70 zugreifen kann!

Stunde um, Resümee:
Okay, man muss es jetzt mal offen aussprechen: Da ich meine "Untersuchungen" hier noch auf der Meta-Ebene dokumentiere, ist der Zeitverbrauch verfälscht. Das merke ich gerade heute, wo ich mitten in der Arbeit abbreche, um richtiges Disassemblen zu testen und ansich zu kompilieren (auch, um oben auf meine chice Byte-Zahl und damit einen statistischen Wert zu kommen).
Außerdem sind die zwanzig Stunden stumpfes Überlegen nicht drin, die ich ohne ikaris Hilfe zusätzlich gehabt hätte.
Mal schauen, ob ich heute abend noch dazu komme.

Jetzt ist Wochenende.
Es ist Freitag.
Ich bin jung.
Ich hau jetzt richtig auf die Kagge.
Ich gehe jetzt fernsehen.
Vielleicht mache ich nachher noch weiter, vielleicht gehe ich aber auch gleich nach dem Fernsehen ins Bett, es ist ja schon spät...

[lytron]

Stunde 8
Disassembled: 1.016 / 1.048.576 Bytes (0,097%)
Gehört: Tomohito Nishiura - Professor Layton and the Mask of Miracle OST

Wieso sagt mir denn keiner, dass das Fernsehprogramm so kacke ist? Aber bitte, dann mache ich halt weiter...

~~~
Um das von der letzten Stunde nachzureichen: Die acht Save-Game-Slot-Validierungsbyte sind (in dieser Reihenfolge): $49, $48, $41, $5F, $52, $61, $6D, $2E, und das macht als ASCII-Buchstaben "IHA_Ram.". Logischerweise muss dann nur, um einen Spielstand zu löschen, einer der Bytes, vornehmlich einer der ersten beiden, durch etwas anderes, zum Beispiel null, ersetzt werden, und beim anschließenden Aufruf der Subroutine wird dem Rest des Spielstands der Abstieg in den Orkus bereitet.
~~~
Ah, kultig. Irgendwo habe ich mal gelesen gehabt, dass eine "Checksum" bei Spielständen gebildet wird. Für die, die nicht wissen, was das ist: Jeder Byte kann als eine Zahl zwischen 0 und 255 angesehen werden. Jetzt addiert man alle 512 Bytes eines Spielstands (bzw., in diesem Fall, 510, weil 2 Byte der Speicherplatz für die Checksum sind). Sobald die Zahl bei dieser Additionskette die 255 überschreitet, wird der Übertrag weggeschmissen, quasi die Zahl wieder minus 255 gerechnet. Und die Zahl am Ende speichert man ab. Wenn man Spieldaten auf ihre Vernünftigkeit prüft, addiert man wieder alle Zahlen und vergleicht sie mit diesem Wert. Stimmt die Zahl nicht überein, ist der Spielstand Schrott und geht dann sehr schnell den Weg jedes Mafiafeindes.
Genau diesen Kram habe ich dann hier gefunden.
~~~
Nachtrag, mein Fehler: Die Checksum hat nicht 255 als Maximum, sondern 256 * 256 - 1, also ~32.000. Sixteen Bit, Baaaybeh.
~~~
Coole Sache. Wird der Save-Game-Slot gecleart, wird auch der/die/das Carry-Flag vorm Subroutinen-Ende gecleart, wenn alles takko ist, wird es gesetzt. Ganz einfache Methode, ohne zusätzliche Variable "von der Subroutine aus nach außen" mitzuteilen, ob hop oder top. Schlaue Hunde, die!
~~~
Coole Sache, die zweite. Nachdem ich den Check-Save-Game-Slot-Kram durchhatte, bin ich in die übergeordnete Subroutine gegangen, und habe festgestellt: Bevor das erste Mal die untergeordnete Subroutine aufgerufen wird, wird in $70:0000 #$0000 gespeichert. Folglich wird der erste Spielstand dann gecleart. Ferner stellte ich fest, dass insgesamt viermal diese Subroutine durchläuft, nämlich für $0000, $0200, $0400 und $0600 auf Bank $70. Ich weiß aber, dass das Spiel nur Speicherplätze hat. Folglich gehe ich davon aus, dass ein temporärer Spielstand in $0000 hochkopiert wird, und wenn man im Spiel speichert, einfach nur wieder herunterkopiert wird (nach $0200/$0400/$0600). Nur so ne Theorie.
Schlaue Hunde, das!
Boah, für sowas mach ich das. ^.^
Dafür, und um das Ding zu übersetzen. Aber die Übersetzung ist nur Makulatur.

Stunde um, Resümee:
Auch wenn ich ganz knapp unter der Ein-Promill-Marke den Tag und dieses Vorhaben verlassen werde, bin ich doch sehr zufrieden. Der SRAM-Kram war wirklich so, wie ich dachte, und das ist doch super. Hübsch programmiert, und direkt beim Disassemblen verständlich. So mag ich das. Und jetzt langsam werden wohl langsam die interessanten, relevanten Sachen kommen. Die zum Gucken. Sehr bald wird wohl der Teil mit den Grafiken kommen. Worauf ich dann auch mal gespannt bin. Der VRAM ist ja zumindest schon einmal "eingeteilt" worden (also, die Einstellungen, wo die Tilemaps und Tilesets liegen werden, wurden bereits gespeichert). Das heißt, bald kommen die ersten Screenshots auch hier. Bald kommen die großen Sprünge in meinem Bytecounter oben (Bilddaten, die ich erkenne, werde ich als "disassembled" zählen, deshalb; und das können dann gut und gerne mal drei- bis vierstellige Werte werden).
Aber:
Nicht mehr heut, nicht mehr heut...

EDIT: Tausender-Punkt vergessen. Endlich darf ich einen setzen, yeah!

[ChronoMoogle]

Wie, was? Der SRAM ist nicht interessant und relevant? :D
Ich finde fuer RPGs und Konsorten ist es recht wichtig sowas zu verstehen :)
Guter Fortschritt lytron^^

[lytron]

Stunde 9
Disassembled: 1.160 / 1.048.576 Bytes (0,111%)
Gehört: (Suffer Like G Did - Orange EP, Raspberry EP) x3

Vernünftig betrachtet ist es totale Verschwendung, dass sich Millionen Kinder am Morgen des fünfundzwanzigsten Dezembers die Chance auszuschlafen entgehen zu lassen, nur um sich die Zeit mit Dingen zu vertreiben, die zwei, drei Stunden später immer noch an derselben Stelle stehen würden.
Jetzt nehmen wir mal an, das Kind ist größer, hat weniger Chancen auszuschlafen als ein reguläres Schulkind und freut sich nicht auf materielle Güter, sondern auf Untersuchungen technischer Daten, die seit zwei Jahrzehnten unverändert im Internet kursieren.
Gott, bin ich doof. Ich sollte schlafen.

~~~
Gut, jetzt gerade werden hier recht wilde Zahlen in den (W?)RAM gespeichert. Eigentlich nichts, was mich hellhörig macht; bisher war es ja auch oft genug so, dass Register so vorbereitet wurden und anschließend Subroutinen aufgerufen wurden, die für flexible Nutzung ausgelegt sind. Jetzt gerade gibt es nur einige STA 700010.l Befehle, die mich schon stutzig machen. Soll heißen: Es wird in den SRAM gespeichert. Noch bevor überhaupt was auf dem Bildschirm passiert. Meine Zeit. Wo kommen wir denn da hin.
~~~
Öhm... erst im Nachgang fällt mir auf, was da in die SRAM-Register gespeichert wird. "$00". ~_~
~~~
Öhm, ich check das nicht wirklich. Am Ende kommt ein "Jump to Subroutine", aber die Subroutine beginnt mit einem "TSB $CA02". Das sind drei Bytes, dessen letzter "$CA". Die nächsten Bytes sind dann ganz viele "$CA"s (= DEX). Deswegen schätze ich, dass da irgendwas falsch interpretiert ist. Oder so. Ich werde jetzt erstmal meinen Deassemblierten Kram mit der Original-ROM abgleichen, eine Lösung dieses Knotens wäre nämlich, wenn ich einfach was falsch gemacht habe, einen Byte vergaß und dadurch ein "JSR" gesehen habe, wo keins hingehört.
~~~
Die Fehler, die ich jetzt beim Disassemblen gemacht hatte, hatten keine Auswirkungen auf den Jump-Befehl. Wie sagt doch so schön Harald Lesch? "Nützt alles nichts, da müssen wir drüber reden...". Also: Auf auf, nach $0D18!
~~~
Boah. BOOOOAAAH. Hab ich ein Schwein!
Bzw.: Nein, habe ich nicht.
Ich weiß jetzt: Wenn ich einen 8-Bit-Akkumulator habe und LDA #$6DFF.w schreibe, zickt mein Assembler nicht. Gut, so eine logische Prüfung zu erwarten, ist wohl ziemlich heftig für so ein kleines Programm.
Zumindest habe ich Schwein gehabt, weil ich in halbwegs passabler Zeit meinen Fehler gefunden habe. Trotzdem denke ich, dass ich lieber schlafen gehen sollte.
~~~
Jetzt steht hier LDA #$16, LDA#$17... Fehler beim Disassemblen? Fehler beim Programmieren...? Flag-Gedöns, dass ich nicht checke?
~~~
Gut, bis hierher, und nicht weiter. Ich bin mir nicht so ganz sicher, ob ich an dieser Stelle alles richtig gemacht habe. Ich befürchte, ich habe irgendwo ein REP-#$20-Schild überfahren und habe deswegen bis hierher so komische Zahlenwerte. Ich werde sehen. Gerade eben habe ich NMI und Auto-Joypad-Interrupts enabled, das heißt, es geht jetzt wohl richtig los.
(Für Menschen mit normalen Hobbys: Dass diese Interrupts enabled sind, bedeutet, ab diesem Zeitpunkt gibt es Animationen auf dem Bildschirm und die Controller-Buttons werden abgefragt, ob sie gedrückt sind oder nicht).
Anschließend folgt eine Batterie an Jump-Subroutine-Longs, also geht es jetzt wirklich wirklich los. Und ja, nur eins der "wirklichs" wird kursiv. Die Welt ist eben ungerecht. Und hätte ich jetzt "eben ungleich" geschrieben, würde ich mir selbst auf die Schulter klopfen. Aufgrund eines versteckten Oxymorons. Ich schweife ab.

Stunde um, Resümee:
Ein Promille! Gleich nach dem Aufstehen!
Nun gut, so sieht das Wochenende vieler aus...
Ich bin jetzt, wobei ich doch davon ausging, dass ich sowieso schon einen 8-Bit-Akku habe, wieder an ein SEP #$20 gekommen, das mich sehr verwirrt. Ich habe mal als Kommentar direkt dahinter geschrieben, wo genau sich das in der ROM befindet - ich könnte mir vorstellen, dass der Introloop genau hier wieder anfängt. Wir wissen schon. Wenn man dem "Push Start" nicht nachkommt und die Musik irgendwann zu Ende ist, fängt alles wieder von vorn an.
Vielleicht hier.
Wer weiß.
Mal sehen, was die nächste Stunde bringt...

[lytron]

Stunde 10
Disassembled: 1.276 / 1.048.576 Bytes (0,122%)
Gehört: Souvaris - A Hat

Okay, weiter geht es. Ab in den Subroutinen-Sumpf. Ich werde ihn trockenlegen, huargh.

~~~
Super. Ich fange an, und frage mich schon wieder, ob ich im richtigen Film bin.
Dieses Mal bin ich aber wirklich richtig, dieses Mal ist es auch wirklich ein Jump-Befehl, wo ich einen gesehen habe.
~~~
Herzlich willkommen an den Grenzen meines technischen Verständnisses:

Code: Alles auswählen

	QuestionableSR1:
	LDA $0100.w
	STA $0102.w
	STZ $0100.w
	LDA #$FF.b
	STA $0103.w
	QuSR1Loop:
	LDA $0103.w
	BNE QuSR1Loop
	LDA $4210.w
	LDA $0102.w
	STA $0100.w
	CLI
	RTL

Das ist meine Übertragung, mein Disassembler hat das hier ausgespuckt (Achtung, die Adresse beim BNE ist falsch; einer der mir bekannten Bugs des Disassemblers. Die Adresse müsste -$0100 sein):

Code: Alles auswählen

00078D 	AD 00 01 	LDA $0100.w
000790 	8D 02 01 	STA $0102.w
000793 	9C 00 01 	STZ $0100.w
000796 	A9 FF 		LDA #$FF
000798 	8D 03 01 	STA $0103.w
00079B 	AD 03 01 	LDA $0103.w
00079E 	D0 FB 		BNE $089B
0007A0 	AD 10 42 	LDA $4210.w
0007A3 	AD 02 01 	LDA $0102.w
0007A6 	8D 00 01 	STA $0100.w
0007A9 	58 		CLI 
0007AA 	6B 		RTL 
0007AB 	68 		PLA 
0007AC 	40 		RTI 

Warum sollte $0103 irgendwann von selbst null werden? Wirre Sache, aber scheinbar tut es das, ansonsten hätte man von Ihatovo Monogatari schon früher mehr gehört. Als "das Spiel, das nicht geht".
~~~
Ah, ah, schön. Ich weiß zwar noch nicht, was hier gemacht wird, aber irgendwas wird per Channel 7 geDMAt. Und damit erklärt sich, weshalb Channel 7 nicht gecleart wurde. Und das heißt: Ich hatte rääähächt. Sagt es allen. Sagt ihnen nur vier Worte: Ich - hatte - recht - Huargh.
~~~
Die Subroutine ab $0000:0AA2 ist sehr interessant; ich habe ihr noch keinen Namen gegeben. Aber scheinbar wird ab $0440 eine "Pipeline" von zu-DMAisierenden-Daten abgelegt (natürlich wieder die 8 Byte für die DMA-Register in der richtigen Reihenfolge). Ausgefuchste Hunde, diese Leute!
~~~
Gut, nachdem ich geprüft habe, dass ich das richtig disassembled habe, will ich jetzt mal schauen, was das eigentlich ist.
~~~
Weird. Die besagte Subroutine habe ich jetzt VRAM_DMA getauft.
Seltsam ist, dass sie tatsächlich halbwegs umsonst durchlaufen wird. Hm. Wobei: Jein.
Wenn meine Theorie stimmt und überhalb des SEP #$20 die Wiederholung des Intros beginnt, kann zwischenzeitlich etwas anderes in $0440 geschrieben worden sein. Beim ersten Durchlauf steht #$00 in $0440. Das wird in der Subroutine festgestellt und dann alles recht pronto beendet. Das einzige, was hierdurch bewirkt wird, ist, dass #$0000 in $06FE und $13FE gespeichert wird. Und das wird sicherlich auch wieder für irgendetwas nützlich sein. Vielleicht sogar in einer der nächten Subroutinen. Schauen wir mal.
Ich werde jetzt erst einmal die ROM-Map aktualisieren.

Stunde um, Resümee:
Es geht vorwärts, und gerade ist die Motivation recht hoch. Ich bin mal gespannt, ob die Menge an Registerwert-Setzungen vor der JSL-Traube dazu beitragen wird, schnell zu verstehen, wozu die RAM-/DP-Register genutzt werde, oder ob gleich eine Subroutine kommt, die die Verwirrung darüber noch komplettiert.

[lytron]

Stunde 11
Disassembled: 1.347 / 1.048.576 Bytes (0,128%)
Gehört: Fortuna Quartett & Helmut Abel - Astor Piazzolla: Oda para un hippie

Gut. Drei Subroutinen geklärt, sind noch sechs offen.

~~~
Okay. Beim ersten Blick auf die erste Subroutine ist die Funktionsweise klar, der Sinn noch nicht wirklich. Es ist wieder eine DMA-Funktion, wieder vollkommen flexibel (in Abhängigkeit zu den Registern ab $0700), DMA-Channel 7. Es ist mir noch nicht ganz klar, wozu eine weitere DMA-Subroutine benötigt wird; sinnhaft wird es in jedem Falle sein, ich habe ja gelernt, die Arbeit dieser Programmierer nicht qualitativ in Frage zu stellen.
~~~
Ah, okay, die Pipeline (die "To Do"-Liste) für diese Funktion reicht bis $077F und wird rückwärts abgearbeitet. Gleich mal ein Vermerk in der ROM Map gemacht. Das Ding wächst auch beträchtlich...
~~~
Oh. Jetzt, wo ich es mir genau anschaue, verstehe ich es, wozu dieses Ding gut ist. Der Datensatz in der Pipeline enthält nicht bloß die Werte für die DMA-Register, sondern auch noch Werte für Register $2115 und $2116. Wieder eine VRAM-Transfer-Subroutine, flexibler als die vorherige.
~~~
Ich bin wirklich gespannt, was ich mit diesem Wissen aus dem vorherigen großen Register-Beschreiben herauslesen kann. Aber erst muss ich mich in Geduld üben, erst will ich die Subroutine komplett übertragen haben.
Habe ich die Kanne Kaffee wirklich schon zu zwei Dritteln leer?
~~~
Hrrrm... Also, es gibt eine Reihe von Befehlen, die die Register um $0700 betreffen. Da werden die Register alle auf 0 gesetzt. Allerdings macht das Ding vor $0770 Halt. Das heißt... keine Ahnung. Vielleicht wird ein DMA durchgeführt; ich schätze nicht. Nicht im ersten Anlauf. Vielleicht im zweiten?
~~~
Hui, es ist so ungemein sexy (wenn auch nur fürs Selbstwertgefühl), wenn man was im Code ändert, assembled und einfach nur die Hexzahlen angucken muss, um zu wissen, ob funktioniert hat, was man wollte. ^.^
Okay, ich habe jetzt noch ein bisschen Zeit, und die nächste Subroutine ist recht groß, also kümmer ich mich jetzt *endlich mal* um den Header.
~~~
Okay, bevor ich den ROM-size-Byte ändere, werde ich in nocashs FullSNES-Doc mal nachschauen, was er bewirkt. Nicht, dass es mir alle Jump-Adressen zerschießt. Und das kurz vorm Ende der Stunde!
~~~
ROM-Hack-City schreibt:

$ffda => Licensee code. If this value is $33, then the ROM has an extended header with ID at $ffb2..$ffb5.

In der Original-ROM steht $35. Ich schätze, das ist dem wohl ähnlich. Noch etwas, was ich in FullSNES nachschauen muss. Mensch, warum benutze ich überhaupt diese ROM-Hack-City-Seite!?
... weil die im Vergleich zum FullSNES kram halbwegs übersichtlich aufgebaut ist.
~~~
Wenn mir mal langweilig ist, kann ich ja mal gucken, wo die restlichen Interrupt-Vektoren hingehen... außerdem kann ich ja mal meinen Header mit dem Original abgleichen. Aber das mache ich später.

Stunde um, Resümee:
Da wieder herzlich wenig ansich Zusammenfassbares geschehen ist, weil ich nur eine weitere DMA-Subroutine aufgegabelt habe und ein bisschen Unfug in den Header geschrieben habe, hier jetzt mal eine kurze Zusammenfassung der letzten paar Stunden für diejenigen, die jetzt erst zugeschaltet haben:
Öh... nichts.
Ich denke, ich bin gerade dem Initialisieren des SNES entstiegen. Initialisieren heißt: Es werden überall Startwerte hingespeichert, weil man nicht weiß, was an den Speicherstellen ansonsten drin steht, und man will keine Risiken eingehen, dass irgendein Tinneff geschieht.
Jetzt gerade gehe ich davon aus, dass ich am Anfang des Intros stehe, wo soweit alles vorbereitet wird, um Grafikdaten zu übertragen und gleich das Logo des Programmierteams ("hector") anzeigen zu lassen. Dazu haben sie viele Unterfunktionen geschrieben, die dazu ausgelegt sind, von jeder Stelle des Programms ausgehend ausführbar zu sein (was bei weitem nicht selbstverständlich ist; bei vielen Unterfunktionen muss man in deren Nähe sein, ansonsten mag einen das Programm nicht mehr und kollabiert).
Das interpretiere ich so, als wäre ich gerade im Werkzeugschuppen des Programms unterwegs: Allerlei nützliche Sachen, "die wir später mal wieder brauchen werden", gucke ich mir gerade an. Das heißt: Für die spätere Disassemble-Arbeit wird man immer wieder darauf zurückgreifen können, dass ich diese Funktionen schon auseinander genommen habe. Aber selbstverständlich ist das an dieser Stelle eher prozess-verlangsamend, wenn man davon ausgeht, hier schnell zu erwarten, dass ich die ganzen hübschen Grafiken finde.
Es ist zwar im Kleinen, das heißt für den Intro, nicht zwangsläufig alles nötig, aber es zeigt, dass das hier alles für einen größeren Rahmen ausgelegt ist. Das hier ist ein Spiel, und keine Slideshow.

Und damit kenne ich mich aus!
Hitomi, over and out.

[lytron]

Stunde 12
Disassembled: 1.703 / 1.048.576 Bytes (0,162%)
Gehört: Tangled Hair - Apples EP, Colour - Anthology

Hm. FullSNES oder Subroutine?
Hm.
...
...
Kein' Bock auf Header.

~~~
Hm. Die auseinandergenommene Subroutine ist nicht superlang, wie ich dachte, sondern superkurz (im Hexeditor kann man schonmal ein $6B übersehen. ). Und es ist... *trommelwirbel*... ein VRAM-DMA.
~~~
Und gleich die nächste superkurze Subroutine. Nomen est Omen: "Counter, or what?"

Code: Alles auswählen

	CounterOrWhat:
	INC $2D.b
	DEC $2E.b
	BPL NoCounterReset
	LDA #$02.b
	STA $2E.b
	NoCounterReset:
	RTL

~~~
Okay, die nächste Subroutine dient dem Auslesen einer Tabelle auf verschachtelte Art und Weise.
Im Genauen heißt das: Rechne diesen Counter weiter, um das Register zu erhalten, in dem du nachschauen musst, um zu wissen, in welchem Register einer Tabelle du schauen musst, welchen Wert du als nächstes nehmen musst. Da ich nirgendwo einen Resetwert für die Tabellen-Adresscounter gefunden habe, gehe ich mal davon aus, dass die Tabelle 256 Byte groß ist. Folglich habe ich jetzt eine Viertelstunde lang herumformatiert, um diese Bytes in die Datei zu bekommen. Monotone Arbeit, aber gut für meinen Disassembled-Bytes-Counter.
Nächster Vorteil: Der aus der Tabelle geladene Byte wird nicht gespeichert, sondern verweilt im Akkumulator. Das heißt: Mit der letzten Subroutine dieses JSL-Clusters werde ich wohl erfahren, wozu diese Tabelle und diese Funktion gut sind. Bis dahin heißen sie "QuestionableSR2" und "QuestionableTable".
Tja.
~~~
Oh, ich habe eine Subroutine im Cluster übersehen!

Stunde um, Resümee:
Es lichtet sich. Die Bank 0 in meiner ROM füllt sich allmählich, und viele Lücken zwischen den Subroutinen füllen sich (mit... Subroutinen! ). Mal schauen. Ich bin gespannt, wo das alles hinführt.

[ikari_01]

Warum sollte $0103 irgendwann von selbst null werden? Wirre Sache, aber scheinbar tut es das, ansonsten hätte man von Ihatovo Monogatari schon früher mehr gehört. Als "das Spiel, das nicht geht".

$0103 wird vermutlich in der VBlank-NMI-Routine einmal pro Frame inkrementiert, so dass relativ weit am Anfang des nächsten VBlanks dann #$00 drinsteht. Die Schleife wäre dann einfach nur ein "warte aufs nächste VBlank, weil du gleich irgendwas machen sollst, das außerhalb des VBlanks nicht funktioniert".

Schnapp dir mal den 16Bit-NMI-Vektor und guck dir die Routine an der Stelle an, ich wette da steht irgendwo ein INC $0103 o.ä.

[lytron]

Warum sollte $0103 irgendwann von selbst null werden? Wirre Sache, aber scheinbar tut es das, ansonsten hätte man von Ihatovo Monogatari schon früher mehr gehört. Als "das Spiel, das nicht geht".

$0103 wird vermutlich in der VBlank-NMI-Routine einmal pro Frame inkrementiert, so dass relativ weit am Anfang des nächsten VBlanks dann #$00 drinsteht. Die Schleife wäre dann einfach nur ein "warte aufs nächste VBlank, weil du gleich irgendwas machen sollst, das außerhalb des VBlanks nicht funktioniert".

Schnapp dir mal den 16Bit-NMI-Vektor und guck dir die Routine an der Stelle an, ich wette da steht irgendwo ein INC $0103 o.ä.

Ich bin dafür, dass wir in diesem Forum neben "Positiven Tradingpoints" auch "Positive Codingpoints" einführen.

Danke dir, mache ich beizeiten.

[lytron]

Stunde 13
Disassembled: 1.814 / 1.048.576 Bytes (0,173%)
Gehört: Echt - Freischwimmer

JSL-Cluster everywhere. Eine "Altlast" in Form einer übersehenen Subroutine, eine vor mir, und dann... vielleicht noch mehr. Vielleicht hatte ich mich verguckt und die JSL-Anhäufung ist noch nicht zuende.

~~~
Scheinbar habe ich gerade wieder den Jackpot in puncto DP-Reg.-Bedeutung gezogen. In dieser Subroutine werden zehn bis zwanzig DP-Register geladen und in Register um $2115 gespeichert. Das heißt, die werden wohl auch genutzt, um die Bildschirmeinstellungen zu "spiegeln". Soll mir recht sein.
~~~
Okay, da es hier um viele Screen-Einstellungen geht, werde ich wohl in dieser Stunde zu nichts anderem kommen, als Variablennamen zu setzen und zu schauen, welche Werte wohl bereits oben im Init hineingespeichert wurden.
Danach kann ich ja ikaris Tipp wegen des VBLANK-Vektors zu befolgen. Wohl aber nicht mehr in dieser Stunde.
~~~
Gah, ganz weit oben wurden schon einmal diese ganzen Werte gleichzeitig in die Register und in diese Variablen gespeichert. Wäre ich schlau gewesen, hätte ich da schon diesen ganzen Variablen-Bla machen können.
~~~
Ich habe ewig gebraucht, um zu checken, wer das im Bonustrack auf "Freischwimmer" ist, der dem Echt-Bassisten zum Geburtstag gratuliert. Bis dahin war es für mich nur irgendein "Helge aus Mühlheim".
~~~
Durch das nachträgliche Namen-Einfügen habe ich gesehen, dass an einer Stelle in das DP-Register, das für $2100 zuständig ist, $0F gespeichert wird. Das heißt, es wurde schon so vorbereitet, dass beim nächsten Update der Bildschirm-Register der FBLANK ausgemacht wird. Hätte ich das mit den Register-Benennungen nicht gemacht, hätte ich das nicht gesehen.

Stunde rum, Resümee:
Also dieser Variablen-Kram ist wohl das denkbar unbefriedigendste, was es gibt. Vielleicht, weil man im Programm keinen Byte vorwärts kommt (nicht wegen dem Counter, sondern ansich), es verwirrend ist, und außerdem die Gefahr birgt, im Nachhinein Funktionierendes zu zerschießen.
Nächstes Mal mache ich aber den VBLANK-Vektor.

[lytron]

Stunde 14
Disassembled: 1.923 / 1.048.576 Bytes (0,183%)
Gehört: Reno Dakota - You scalded me, Bravo! (3x), Bloc Party - Silent Alarm

Jetzt mache mich mal an den VLBANK-/NMI-Vektor.

~~~
Öhm... wo war doch gleich der Vektor?
Muss ich doch nochmal auf ROM Hack City zurückgreifen! Oh noes!
Ah, bei $7FEA für den Native Mode, $10 weiter für den Emulation Mode. Mal gucken, ob die unterschiedlich sind.
~~~
Sind beide gleich. Gehen zu $(8/0)7AD. Das kommt mir so bekannt vor...?
~~~
Okay, es stopft ein Loch zwischen zwei Subroutinen, daher.
~~~
Ah, jetzt macht es endlich "klick" bei mir, weshalb $4210 geladen wird und die geladenen Daten nicht verarbeitet werden. Da war ja was mit einem VBLANK-Flag, das durchs Laden gecleart wird.
~~~
Da steht ein "STZ $0103" im VBLANK-Interrupt-Klärer. Noch ein Codingpunkt als Prämie für ikari.
$0103 ist anscheinend ein zu groß geratener Bit - Der kann wohl nur $FF und $00 für $FF=Warte auf nächsten VBLANK.
~~~
Der VBLANK-Klärer ist ein angestochenes Hornissennest.
(Da schreibe ich "Hornissennest" und verliere mich um ein Haar im Youtuben)
Da wird in Abhängigkeit von einigen Variablen gearbeitet, was ich gerade nicht so wirklich nachvollziehen kann. Aber scheinbar gehört die "QuestionableSR1" mit zu den weitergehenden Bearbeitungen des VBLANK-Klärers. In dieser Subroutine steht auch etwas von LDA $4210.
Ferner scheint der VBLANK-Klärer auch einen "IRQ-Klärer" o. ä. zu enthalten...?
~~~
Okay, mit dem VBLANK bin ich durch... ich verstehe es (noch) nicht und werde mich da auch nicht dran begeben, vorerst (bis ich herausbekomme, wozu die Variablen $0100 bis $0103 gut sind...).
~~~
Den IRQ-Vektor habe ich mir auch angeschaut. Er führt direkt auf ein RTI. Ich schätze, bei den restlichen Vektoren wird es wohl auf dasselbe hinauslaufen, auch wenn jeder woanders hinführt.

Stunde um, Resümee:
ikari hatte Recht.