Disassemble Blog: Ihatovo Monogatari

[lytron]

Wichtige, inhaltliche Sache:

Ich werde wohl für eine Übersetzung auf "Ihatov Story" umsatteln, da viele Übersetzungen von Kenji Miyazawas Werken das so wieder geben (oder aber auch "Ihatove" - es geht wohl maßgeblich um die phonetische Nachbildung mit allen Mitteln.

So oder so wäre für eine adäquate Übersetzung jemand von Nöten, der sich mit Miyazawa auskennt - das Spiel ist in Anlehnung an sein Werk entstanden, und ich würde mich freuen, wenn man ein qualitativ hochwertiges Produkt fertigen könnte, das sich so gut in den Kanon einfügt, wie das japanische Originalspiel zulässt.

Übrigens gab es auch einen vierteiligen Nachfolger via SatellaView, mit Soundlink. Natürlich finden wir das auch in ChronoMoogles Undumped-Liste wieder.

(Wave your arms and say: 'Lost forever'!)

Zurück zum Disassembling: Im Anhang mal ein upgedatetes Baumdiagramm. Ich finde diese Seite supercool, aber ich denke, ich sollte der Übersichtlichkeit halber diese Baumdiagramme zerlegen.

Edit: Nachtragi-tragi: Der Code für den Baum. Diesmal nicht via <code>-Befehl, weil man da die Einrückungen mit Leerzeichen nicht rauskopieren kann.

[ChronoMoogle]

Das Tolle: sind die Daten disassembled und die Roms finden sich immer noch nicht an, findet sich vielleicht eines Tages jemand, der den Satellaviewnachfolger anhand der Disassembleaufzeichnungen und hochgeladener Nico Nico Videos (ich habe leider noch nicht nachgeforscht ob es dazu Aufzeichnungen gibt... aber man findet welche zu recht vielen Soundlinkspielen) nachbauen kann. Dies passierte auch schon mit den BS Zeldas.

Okay... Vielleicht etwas weit gedacht.

[lytron]

Das Tolle: sind die Daten disassembled und die Roms finden sich immer noch nicht an, findet sich vielleicht eines Tages jemand, der den Satellaviewnachfolger anhand der Disassembleaufzeichnungen und hochgeladener Nico Nico Videos (ich habe leider noch nicht nachgeforscht ob es dazu Aufzeichnungen gibt... aber man findet welche zu recht vielen Soundlinkspielen) nachbauen kann. Dies passierte auch schon mit den BS Zeldas.

Klingt nach einem Job für mich, hah!

Bitte nicht. Bitte nicht. Bitte nicht. Bitte verlangt das nicht von mir. >____<

Würde mich interessieren, ob es dazu Videos gibt. Danach zu googlen führt nichts. Warum muss man sich überhaupt bei Nico Nico anmelden, um da Videos gucken zu können? Das ist doch poopoo, so.

[lytron]

Stunde 26
Disassembled: 3.113 / 1.048.576 Bytes (0,297%)
Gehört: Hajime Mizoguchi - Best Wishes

Mal eine lange Vorrede:
Dank der Baumdiagramme, die ich in letzter Zeit hier hinterlassen habe, speziell anhand des letzten, kann man nachvollziehen, wo in den Verästelungen des Programmes ich weitermachen werde.
Ich werde nämlich jetzt nicht, wie es logisch und vernünftig wäre, bei "HellAwaits" weitermachen, auch wenn ich da noch nicht fertig bin (signalisiert durch die drei Punkte neben "Matroshka", sondern werde schauen, was das für eine letzte Subroutine im FirstBigMainLoop ist. Einfach, weil ich nicht noch einen Arbeitstag damit verbringen will, mir das Hirn zu zermartern, was das wohl sein mag.
Desweiteren habe ich meine paar Brocken Englisch übereinandergestapelt und den Betreiber des SatellaView-Blogs, den ich hier auch schon gelinkt habe, mal angehauen, wo der seine Screenshots her hat... er hat auf die Frage nicht geantwortet, aber sagte mir, er wolle mir zuliebe seine verbliebenen Screenshots von BS-IM hochladen. ^.^
Ich habe ihn übrigens mal in die International Area dieses Boards eingeladen, wie ich das mit jedem tu, der mir begegnet, der SNES-Content produziert.
Aber jetzt, auf an den Zahlen-Grabbeltisch.

~~~
Öhm... ikariii... O_O

Code: Alles auswählen

	LDX Buttons_Hold_L.w	; $37
	CPX #$F0C0
	BEQ Intro_Button_Push
	RTL
	Intro_Button_Push:
	LDX #$07FF.w
	LDA #$00.b
	ClearAllSaveGamesLoop:
	STA $700000.l, X
	DEX
	BPL ClearAllSaveGamesLoop

Verstehe ich das richtig? Wenn A, B, X, Y, Start und Select gedrückt gehalten werden, wird der komplette SRAM gekillt? O_O
~~~
Muha. Am Ende des ganzen Tirilis kommt ein "Branch Long", und da musste ich mir erst die Bestätigung anlesen, dass es genauso wie ein normales Branching funktioniert. Allerdings spuckt mein Disassembler da einen unbrauchbaren Wert aus... folglich könnte ich jetzt mit dem Taschenrechner nachrechnen, oder raten und mich annähern. Ich habe geraten und voll ins Schwarze getroffen. Nach Abschluss der Prozedur wird wieder an die Stelle gesprungen, an der man ganz zu Anfang nach der ersten SPC-Subroutine stand. Quasi: Wenn alle genannten Knöpfe gedrückt werden, wird der SRAM gecleart und alles auf Anfang gesetzt.
Das ist schön, aber nicht das, was ich gewollt habe. Eigentlich will ich etwas, das mir sagt: Ich guck mir die gedrückten Knöpfe an, und wann da dieser oder jener bei ist, dann verlasse ich den FirstBigMainLoop und mache mal TitleScreen oder Menü. Aber vielleicht ist das ja Teil einer Subroutine, die in "HellAwaits" noch kommt. Ansonsten wird die Auswahl ein bisschen eng... :/
~~~
Hm. So viel von der Stunde noch übrig. Und alles auseinandergenommen. "HellAwaits". Den SRAM-Killer. Alles fertig. Was mach ich jetzt? Auf zur Jumpmap. Ich nenne das nächste Scheusal: "NewNextHell".

Stunde rum, Resümee:
Ich kann nicht glauben, dass ich wirklich mal weit mehr als hundert Byte disassembled haben soll. Andererseits habe ich schon das Gefühl, richtig was geschafft zu haben. Die "NewNextHell" ansich habe ich auch schon disassembled, sie ruft nur selbst eine Subroutine auf, der ich noch nicht nachgegangen bin.
Allem Anschein nach ist diese neue Subroutine in "NewNextHell" dafür zuständig, zu warten und dann den Bildschirm auszuschalten. Was wiederum bedeuten würde, die einzelnen Einträge auf der Jumpmap sind nicht einzelne Szenen des Intros (der ja selbst aus einer Folge verschiedener Szenen mit minimalen Animationen besteht), sondern "nur" größere Bestandteile und nicht alle wesensgleich: Der Eine, erste Eintrag lädt die Daten, der nächste kümmert sich um das Timing, der nächste lädt die nächsten Daten etc.
Mal schauen. Ich bin übrigens auch recht erfreut darüber, dass der Platz in den ersten $1000 Byte der ersten ROM eng wird. Man kommt dann doch vorwärts. Und ich freue mich auf das Wochenende, wo ich hoffentlich ausgeschlafen genug sein werde, endlich mal zu deuten, was ich da disassemble.

[ChronoMoogle]

Ist es richtig, dass das ein Code ist, um im Spielstandauswahlbildschirm seine Spielstaende zu loeschen?
Falls ja, werde ich das in unsere Tipps und Tricks Sektion aufnehmen^^

[lytron]

Ist es richtig, dass das ein Code ist, um im Spielstandauswahlbildschirm seine Spielstaende zu loeschen?
Falls ja, werde ich das in unsere Tipps und Tricks Sektion aufnehmen^^

Sieht für mich eher so aus, als wäre das innerhalb des Intros, aber ja, ich denke, damit kann man die Spielstände löschen. Ich möchte das aber nochmal am Wochenende prüfen. Kann sein, dass ich da Käse rede.

[lytron]

Stunde 27
Disassembled: 3.156 / 1.048.576 Bytes (0,301%)
Gehört: (Teile aus dem Ihatovo Monogatari-OST, die von Hardcore-Gamer bereitgestellt werden) x7

Morgen, ja, morgen...
... morgen will ich mal mich wirklich mit dem "Sinn" einzelner Sachen beschäftigen. Für jetzt/heute stelle ich mal stumpfes Disassemblen auf den Plan. Was auf Anhieb verstanden wird, ist schön, aber viel denken will/kann ich heut nicht.

~~~
Vorab: "Ihatov Praise" hat absolut was von Green Sleeves, nicht wahr?
~~~
Die stehen ungemein darauf, am Anfang einer Subroutine eine Variable zu laden und dann anhand der Zero-Flag einen Branch zu machen (BNE/BEQ); der Branch führt immer ein halbes Dutzend Bytes vor den Anfang der Subroutine, und dessen Aufgabe ist es dann, den Normalzustand herzustellen und dann die Subroutine zu beenden. "Aha...", sagt der Laie, " 'st legitim", sagt der Kenner. Würde auch anders funktionieren, ist eben nur eine Gepflogenheit der Selbst-/Datenstrukturierung.
~~~
Wo wir gerade beim Thema sind:

Code: Alles auswählen

 (hier denke man sich ein "JSL $009082.l", was logischerweise zu $1082 führt)
; ROM: $0000:0107F
	ShortExit:
	DEC $75.b
	RTL
	
; ROM: $0000:01082
	LDA $75.b
	BNE ShortExit

$75 ist irgendeine Form von Counter, nicht wahr, mein lieber Prof. Holmes?
~~~
Kurzer Einschub zum Soundtrack - in der "Music Festival"-File hört man immer einen kleinen arhythmischen "Hüpfer", wenn der Streicherpart zum Akkordeonpart wechselt und andersherum. Da rede ich mir mal ein, dass das eine Miniatur-Ladezeit ist.
~~~
Also. Vor dem Ende von "HellAwaits" wird $75 auf #$40 gesetzt, $74 auf einen anderen, kleineren Wert. $75 ist der Timer-Counter. Wenn = 0, dann wird die Helligkeit einen runtergedreht. Dann wird $75 mit dem Wert aus $74 befüllt und es geht wieder von vorne los. Ist $55 = 0 (wobei $55 immer in das INIDISP-Register gespeichert wird, also dessen Direct-Page-Variablen-"Spiegelung" ist), wird $90 erhöht, wobei das der Jumpmap-Counter ist.
Desweiteren, da ja der komplette FirstBigMainLoop durchlaufen wird, taucht da ja auch irgendwo (ganz bestimmt, aber abgesichert habe ich mich nicht) die Subroutine auf, bei der mir ikari_01 beim Verständnis geholfen hat - die mit dem "VBLANK-Bit"-Byte. Womit dann gleichgesetzt ist, dass eine Dekrementierung von $75 gleich einem Frame ist.

... das ist ganz schön viel Verständnis für eine Arbeitssitzung, in der nur stumpf disassembled wird...

Stunde rum, Resümee:
Viele Sachen erklären sich von selbst, je mehr Daten man hat, die man deuten kann.
Übrigens erklärt sich mir auch, weshalb bisher nicht, wie ich dachte, eine "richtige" Prüfung der Game-Buttons kommt - dasHector-Logo kann man nicht überspringen. In den nächsten Subroutinen wird es wohl erst soweit sein, dass derartiges geprüft wird.
Ich bin mal gespannt, zu sehen, weshalb die Jumpmap mit #$10 anfängt, bei #$11 weitermacht und dann im Anschluss daran zu #$16 springt. Warum nicht in einheitlicher Reihenfolge? Warum die Sprünge dazwischen? Des weiteren bin ich gespannt, ob überhaupt der "FirstBigMainLoop" jemals verlassen werden wird, oder ob das gesamte Spiel über die Jumpmap läuft. Wäre möglich. Wäre ebenso möglich, dass es sich in einer Unterfunktion der JumpMap noch einmal verschachtelt. Ich werde sehen.

[lytron]

Stunde 28
Disassembled: 3.322 / 1.048.576 Bytes (0,317%)
Gehört: Tomohito Nishiura - Professor Layton and the Unwound Future OST

Weiter im Disassemblen! Auf zum dritten JumpMap-Eintrag (Wir zählen mal "NextStep" noch nicht dazu)!

~~~
Hah, disassembling des nächsten Eintrags ging sogar recht pronto, bis jetzt, und die enthaltenen Daten sind sogar für mich recht lesbar; auch, weil viele mir bereits bekannte DP-Register bedient werden und es ansich "HellAwaits" sehr ähnelt. Folglich habe ich wohl richtig gelegen, als ich diese Subroutine "TransferPrepPoem". Als kleinen Funny Fun habe ich, als mir aufgefallen ist, dass in "TransferPrepPoem" nur BG3 angeschaltet wird, mal getestet, auf welchem BG das Gedicht liegt.
Also ZSNES gestartet und BG1 und BG2 ausgeschaltet.
Das Gedicht war dann trotzdem sichtbar.
*bäm bäm bäm* Ich hatte Recht!
Was heißt das? Nun, wenn ich morgen mir mal die Mühe machen werde und mir die ganzen Sachen genau anschauen werde, werde ich (mehr oder weniger) schnell die Adressen der Grafikdaten ausfindig machen. Einerseits wird dann oben der Byte-Counter in die Höhe schnellen, was ein netter Nebeneffekt ist. Andererseits habe ich dann wohl schon einen wirklich sehbaren Teil des Games disassembled. Was cool ist.
Und das werde ich dann morgen auch mal testen, denn eigentlich müsste es ganz einfach sein, das Programm in einer sinnfreien Endlosschleife laufen zu lassen: Einfach statt

Code: Alles auswählen

 LDA #$16
STA $90

etwas anderes einsetzen, nämlich:

Code: Alles auswählen

 LDA #$10
STA $90

Dann wird die Grafikdatenübertragung und das Ausblenden des Logos in Endlosschleife laufen. Das Logo wird aufblitzen, ausblenden und wieder aufblitzen.
Ey, das wird cool, ey!
Vielleicht schaff ich das ja schon morgen... ^.^

Stunde rum, Resümee:
Ich habe die "TransferPrepPoem" und die nachfolgende Routine ("ShowPoem") bis auf ein, zwei von "TransferPrepPoem" abzweigende Subroutinen komplett disassembled. Hey, könnte die abgehende die Button-Dingens sein? Könnte sein, ab da klappt das... und eigentlich mächte das auch so Sinn, die SkipIntro-Prozedur in eine eigenständige Subroutine auszulagern, auf die dann zu jedem Zeitpunkt verwiesen werden kann. Aber schauen wir mal, schauen wir mal.
Ich bin über das Tempo der letzten Stunde erstaunt. Ich denke, wenn ich morgen in etwa so viel Zeit hierauf verbringen kann, wie ich es letzten Samstag konnte, wird das Ding hier derbe durch die Decke gehen. ^.^ Zumindest empfinde ich gerade so, dass innerhalb dieser und/oder der letzten Stunde der Punkt erreicht worden ist, wo alle "Werkzeuge" zur Verfügung stehen. Ich konnte viele der aufgerufenen Subroutinen bereits bestehenden Sprungmarken zuordnen, u. a. auch Sachen aus "NextStep"/"DerGrosseVerzweiger", die hier das erste Mal im Programmverlauf auftreten. Ist das nicht cool? Ist das nicht cool!?!
Ich denke, das Ding wird hier jetzt sehr schnell vorwärts gehen, bis die Spielstände geladen werden (ich rechne damit, dass ich da ewig hängen werde), aber sobald das absolviert ist und die Spielengine per se steht...
... könnte ich quasi schon durch sein.
Bizarr, nicht?
Das, was dann noch kommen wird, sind eigentlich bestimmte programmierte Events, aber das Gröbste wird dann stehen. Ich wage eine vorsichtige Schätzung: 70% und mehr. Aber bevor ich schätze, sollten lieber andere schätzen. Und bevor andere schätzen, sollte ich lieber weitermachen.

[lytron]

Stunde 29
Disassembled: 3.668 / 1.048.576 Bytes (0,350%)
Gehört: Tomohito Nishiura - Professor Layton and the Unwound Future OST

Ein Stündchen kann ich heute noch.

~~~
Ich sollte das Maul nicht so weit aufreißen!
Mit beachtlicher Treffergenauigkeit hat dieses Spiel bisher solches Verhalten bestraft, genauso wie jetzt gerade.
Natürlich nichts mit Buttons oder so. Sondern: Sprung auf Bank $0A, Sound-Schingeling!
Mal gucken, ob ich da innerhalb dieser Stunde durchkommen werde.
~~~
Es ist ein klarer Nachteil, wenn man nicht versteht, was gerade vor sich geht.
Aber ein Vorteil beim Disassemblen auf Bank $0A ist, dass alles wenigstens schön beieinanderliegt.

Stunde rum, Resümee:
Wer viel disassembled, hat wenig zu berichten.
Ich habe die ganze Zeit eine nicht enden wollende Subroutine auf Bank $0A auseinandergenommen, und ich bin noch nicht komplett fertig mit der Verästelung dieser jener welcher. Es fehlt nur noch eine Sprungadresse, aber was heißt das schon, wenn es von dort aus sich ins Tausendste und Abertausendste verfeinert, zergliedert, zerfasert?
Ein klarer Vorteil ist, dass das alles sehr kompakt liegt. Einmal sind die Sprungadressen auf Bank $0A wesentlich näher beieinander als auf Bank $00, ansich ist es hilfreich, dass alles Sound-spezifische (bisher) auf Bank $0A liegt und damit separiert.
Dennoch, irgendwann muss ich mich zumindest soweit hineinwurschteln, alsdass ich herausfinde, wo wenigstens die Musikdaten liegen.
Soweit für heute. Morgen werde ich dann mit der "Aufarbeitung" meiner Schätze von Bank $00 beginnen.

[lytron]

Before getting back to work again, here are some screens of BS Ihatovo Monogatari; English Satellaview author MaddHatts was so kind to upload them.

BSIhatovoMonogatari.gif (8.13 KiB) 3466 mal betrachtet

BSIhatovoMonogatari_screenshot1.gif (10.31 KiB) 3466 mal betrachtet

BSIhatovoMonogatari_screenshot2.gif (5.05 KiB) 3466 mal betrachtet

BSIhatovoMonogatari_screenshot3.gif (7.65 KiB) 3466 mal betrachtet

Another news is:
I PMed Kiddo on Youtube on BS-Ihatovo Monogatari yesterday and he wrote that there's a video of BS Tantei Club in which at the end an BS-IM commercial can be seen. Looked it up, didn't found it yet.

If you wonder: I wrote in English because MaddHatts could possibly stop by and so he can be sure I got the credits for the screenshots correct.
But, now I will start into working hour 30, and my report will be in Krautspeak, again.

[lytron]

Stunde 30
Disassembled: 3.668 / 1.048.576 Bytes (0,350%)
Gehört: I am Spartacus - Forward!

Diese Stunde nur mal gucken. Und verstehen.

~~~
Huch, habe ich doch glatt einen JSL-Befehl übersehen. Glücklicherweise ist die Subroutine schon disassembled.
~~~
Wir erinnern uns an mein "$0440 + $6FE"? Ich Dulli, ich! Es ist vielmehr ein $0440 + [$6FE], und [$6FE] = $0000, zu Beginn. So, äh, wünscht man sich das...
...?
~~~
Streicht den nachfolgenden Punkt, siehe unten.
Jetzt fällt mir gerade erst auf, wie geschickt das hier ist:

Code: Alles auswählen

	REP #$20.b
	LDA $00.b
	STA $0441.w, X
	LDA $02.b
	STA $0443.w, X
	LDA $05.b
	STA $0446.w, X
	LDA #$0000.w
	SEP #$20.b

Auch wenn A = 16 bit ist, werden immer nur Bytewerte hineingelesen. Zur Info: Es wird jedes mal vor einem SEP #$20 eine 16-Bit-Null in den Akkumulator geladen, damit so kein Tinneff passieren kann. Aber so werden jetzt mindestens eins, zwo, drei Cycles gespart. Pro Aufruf, versteht sich.
~~~
Hah, kultig, wie alles in einandergreift. Offenkundig ist die Variable $06FE der "Pointer" für den nächsten freien DMA-Slot in der "DMA-Pipeline" ab $0440. Das muss ich jetzt alles nur irgendwie in der File vermerken. Auf Englisch. :-/
~~~
Okay. Das hier ist, was ich mal zur Diskussion stellen möchte (erst der Code, dann meine Interpretation):

Code: Alles auswählen

	StatChanger:
	LDX #$6800.w
	LDY #$3000.w
	STZ $4200.w		; Disable Interrupts
	STZ $212C.w		; No BGs or Sprites on Mainscreen
	LDA #$80.b
	STX $00.b			; 
	STY $05.b
	STA $2100.w
	LDX #$2FFF.w
	LDA #$00.b
	ClearPartOfWRAM:
	STA $7FB000.l, X
	DEX
	BPL ClearPartOfWRAM
	LDX #$B000.w
	STX $02.b
	LDA #$7F.b
	STA $04.b
	JSL Shiftling.l		; $008956 = $0000:0956
	JSL VRAM_DMA.l		; $008AA2 = $0000:0AA2
	RTL

; ROM: $0000:0956
	Shiftling:
	SEP #$20.b
	LDX $06FE.w
	LDA #$FF.b
	STA $0440.w, X
	LDA $04.b
	STA $0445.w, X
	REP #$20.b
	LDA $00.b
	STA $0441.w, X
	LDA $02.b
	STA $0443.w, X
	LDA $05.b
	STA $0446.w, X
	LDA #$0000.w
	SEP #$20.b
	INX
	INX
	INX
	INX
	INX
	INX
	INX
	INX
	STZ $0440.w, X
	STX $06FE.w
	RTL

	VRAM_DMA:
	LDX #$0000.w
	CheckForNextVRAMDMA:
	LDA $0440.w, X
	BEQ NoMoreVRAMDMA ;$0000:0AE0
	LDA #$80.b
	STA $2115.w	; VRAM transfer increment after writing to $2119
	LDY $0441.w, x
	STY $2116.w
	LDA #$01.b
	STA $4370.w
	LDA #$18.b
	STA $4371.w	; DMA to $2118.w (VRAM)
	LDY $0443.w, X
	STY $4372.w
	LDA $0445.w, X
	STA $4374.w
	LDY $0446.w, X
	STY $4375.w
	LDA #$80.b
	STA $420B.w
	INX
	INX
	INX
	INX
	INX
	INX
	INX
	INX
	BRA CheckForNextVRAMDMA
				; Next is $0000:0AE0
	NoMoreVRAMDMA:
	STZ $0440.w
	LDX #$0000.w
	STX $06FE.w
	STX $13FE.w
	RTL

These: "StatChanger" transferiert die komplette Bank $7F (minus zwei Bytes) in den VRAM.falsch

StatChanger macht zwischendrin noch irgendwas mit den DP-Registern $00-$07, was aber hier nicht genutzt wird (außer $04). falsch
StatChanger macht die Lichter aus (STZ $4200, STZ $212C, FBLANK mittels #$80 --> $2100) und cleart den Teil vom RAM von $7FB000 bis $7FFFFF. Vielleicht wird der von anderen Subroutinen als Zwischenspeicher benutzt, keine Ahnung.
Danach wird die Variable $04 mit #$7F gefüllt und es geht zum "Shiftling".

"Shiftling" dient der Vorbereitung der Register für VRAM_DMA. Es wird $06FE in X geladen, um als variabler Teil des Offsets (oder wie man das nennen will) zu dienen. Dann werden die Register der Pipeline für VRAM_DMA befüllt. $0440 ist ein Byte-großer Bit, der Ein/Aus-Schalter für VRAM_DMA (ungleich $00 bedeutet "ein"). Variable $04 kommt in $0445, das ist die Source Data Bank. Das ist auch der einz-

-Oh, shit.
Da ist ja gar keine Raute vor dem $02.

Ich...
... muss nachdenken.

~~~

Gut, ich bin wieder da, ich habe mich wieder gefangen.

These: "StatChanger" transferiert $7F:B000 bis $7F:FFFF in den VRAM (von $6800 bis $97FF).

...

Ich schaue gerade in den Init-Teil, und stelle Fest, das wird sogar genutzt, ey! Ab $6800 liegt BG1 Tilemap und die anderen beiden in $800er-Schritten (wie ich den vorigen Begriff sinnhaft verbal aussprechen sollte, ist mir schleierhaft). Ich schätze, da die Tilemaps auch mal größer sein könnten, wird deshalb prophylaktisch $3000 statt der hier nur benötigten $1800 transferiert / gecleart.

Da ich den Dingens hier verstanden habe, werde ich das jetzt nicht so detailliert erklären, wie ich es vorhatte.

StatChanger bereitet die Variablen $00 bis $06 vor ($07 kommt gar nicht vor), Shiftling schmiert das in die VRAM_DMA-Pipeline $0440 bis $0447 (der letzte Teil deaktiviert nur einen etwaig nachfolgenden DMA im zweiten Pipeline-"Slot" ab $0448), und VRAM_DMA macht einen VRAM-DMA.

Dementsprechend werde ich jetzt einiges kommentieren können. Und ein bisschen was auch umbenennen.

Stunde rum, Resümee:
Ich habe Kopfschmerzen.
Das Arbeiten mit so vielen Fenstern macht mich ein wenig irre. Außerdem hatte ich ein wenig an "StatChanger" zu knacken, bis da bei mir der Groschen auf die richtige Art und Weise gefallen ist. Ferner glaube ich, werde ich jetzt gut eine Stunde damit beschäftigt sein, allein die ganzen Variablennamen richtig zu setzen...
... aber ich will meine mentalen Kapazitäten nicht hierrauf verwenden, sondern auf das Projekt selbst. Horrido.

[lytron]

Stunde 31
Disassembled: 3.668 / 1.048.576 Bytes (0,350%)
Gehört: Harmony of a Hunter - 101% Run (disc 1)

Diese Stunde nur mal umbenennen. Und ROM Map schreiben.

~~~
Okay, knapp ne halbe Stunde, jetzt bin ich soweit mit dem Umbenennen durch. Die Einträge für den VRAM_DMA_Slot haben jetzt Variablennamen, genauso wie der Slot_Pointer. "Shiftling" heißt jetzt "PrepVDMA", "StatChanger" heißt jetzt "TilemapClearVRAM". Das ist zumindest ansatzweise selbsterklärend.
Als nächstes werde ich noch ein bisschen die ROM-Map erweitern.

Stunde rum, Resümee:
Dokumentationen sind eine ideale Möglichkeit, Zeit zu verbrennen.

Echt, ey.

[lytron]

Stunde 32
Disassembled: 4.660 / 1.048.576 Bytes (0,444%)
Gehört: Death Cab for Cutie - Daytrotter Session, Transatlanticism

Noch einmal in die "Exegese" von "HellAwaits", nachdem die erste in Stunde 30 versandet ist.

~~~
Der nächste Stolperstein ist "Quetzalcoatl", und das ist in gewisser Weise die Verschmelzung der vormals bekannten VRAM-Pipeline-Präparation und dem Flexi-DMA-Dönekens von Anno Dazumal.
~~~
"Quetzalcoatl" is now called "Flexi_PrepVDMA".
~~~
Okay, ich werde schauen, ob ich gerade die ersten Grafik-Daten gefunden habe. Dieser DMA wird nach $3000 im VRAM gehen. *init nachschau* Wie erwartet liegt dort das BG1-Tileset.
Also lege ich mal eine neue Hex-Datei (oder, wie sie auch gern genannt werden, eine Binärdatei) an, und schmeiße dort die ersten $400 Byte von Bank 02 aus der Original-ROM rein. Nur aus Gründen der Selbstwertgefühl-Steigerung schaue sie mir in Tilemolester an und sehe dort:

Tilemolester.png (4.47 KiB) 3458 mal betrachtet

Im Spiel sieht das dann so aus:

Screen.png (941 Bytes) 3458 mal betrachtet

Sexy, nicht? Da sind so also, die ersten Grafikdaten. Bytecounter +$400. Das sind, in Dezimalzahlen, mal eben 1024 Byte. Danke fürs Gespräch.
~~~
Als zusätzlichen, wenn auch unnötigen, Spaß werde ich jetzt die Rohdaten für Flexi_PrepVDMA mal ummodeln. Zur zeit steht da:

Code: Alles auswählen

JSL Flexi_PrepVDMA.l	; $00898A - $0000:098A
.DB $00, $30, $00, $80, $02, $FF, $03

~~~
Schade, hat nicht funktioniert, das mit Labels zu machen. kann ich es nur ein wenig entzerren:

Code: Alles auswählen

JSL Flexi_PrepVDMA.l	; $00898A - $0000:098A
.DW $3000			; VRAM Destination
.DW $8000			; Source Address
.DB $02			; Source Bank
.DW $03FF			; Data Size

~~~
Ah, kultig.
Also:
Wahrscheinlich findet ihr das Gekrzldzl rechts unten auf dem Tilemolester-Screenshot komisch. Jetzt gerade sehe ich, was das ist. Augenscheinlich sind das die Farb-Daten. Aber nicht alles. Das ist ein lustiger Spaß, hahaha!
Also. Es werden per PrepVDMA $0400 Daten gezogen, right?
Die Farbdaten sind bei $0340 bis $035F. Das heißt:
$0000 bis $033F sind Tiles, $0340 bis $035F sind Farben... und was ist der Rest?
Ich gehe mal ganz kräftig davon aus, dass es die Tilemap ist. Dazu werde ich mir die "Matroshka" in der nächsten Stunde mal zu Gemüte führen, aber ich rechne damit, dass die verbliebenen Bytes die komprimierte Tilemap sind (also, es fehlen die vielen, vielen Nullen für die leeren, schwarzen Tiles).
Aber das schaue ich mir in der nächsten Stunde an.
~~~
Oh, super, gerade fest gestellt, dass ich die falsche Subroutine für "NewNextHell" gehalten habe. Oha, oha, das... das wird noch ein Nachspiel haben, fürchte ich.
~~~

Stunde rum, Resümee:
"A great Leap ahead". Grafikdaten gefunden, Kopfi-Schmerz ein wenig überwunden, HellAwaits fast komplett absolviert. Als nächstes kommt die "Matroshka", und dann ist auch HellAwaits soweit, eigentlich, durch.
Natürlich habe ich es bisher immer bereut, schon vorher zu sagen, was in Subroutinen drin ist.

[lytron]

Stunde 33
Disassembled: 4.660 / 1.048.576 Bytes (0,444%)
Gehört: Invalids - Eunoia

Wir öffnen die "Matroshka".

~~~
Erstaunlich. Es ist, wie ich dachte, und es ist, quasi, recht einfach.
Es werden einige Mini-DMAs gemacht. Es wurde ja zu Beginn von HellAwaits der komplette Raum für die Tilemaps gecleart. "Matroshka" hat jetzt die Aufgabe, die Zeilen aus dem letzten Rest der vorhin gefundenen Grafikdaten zu nehmen und daraus VRAM_DMA-Pipeline-Einträge zu generieren. Danach geht die Post ab und der Rotz ist im VRAM. Fertig ist die Laube. Woll?
~~~
Die "Matroshka" heißt jetzt übrigens "DecompressHectLogoTilemap". Vielleicht ein wenig länger, aber sagt mehr aus.
~~~
Wahrscheinlich kann ich die Subroutine bald nochmal umbenennen. Und der Name wird sogar kürzer werden!
Der Grund ist eine ganz einfache Überlegung: Wozu der Aufwand, wenn man die Subroutine nur einmal nutzen würde? Vielleicht nutzen die das ja auch für das Gedicht im Intro, was als nächstes kommt.
~~~
Fertig. Wow. "HellAwaits" ist fertig. Mensch. Da kann ich es doch mal umbenennen. Heißt jetzt "JT10_HectLogo_Load".
~~~
Hm. Jede Zeile ist $18 lang. Es sind sechs Zeilen. $18 * 6 = $90. Allerdings sind $360+ $90 = $3F0 und nicht $400. Folglich habe ich den Counter oben gefakt!
Und ich werde ihn nicht runterdrehen!
Was wollt ihr dagegen tun, huh? Mir meinen Doktortitel aberkennen, huh?
~~~
Zu meiner Verteidigung: Den Header und die Jumpmap habe ich bis dato nicht mitgezählt, die trügen wohl dazu bei, dass ich schon mehr als 4.660 Bytes hätte.
~~~
Okay, ein erster Test meiner Re-Assembleten ROM führt zu keinem sichtbaren Ergebnis, aber ich glaube, das liegt an der Sound-Subroutine, die ich gestern abend nicht noch fertig gemacht habe. Auf jeden Fall sehe ich im VRAM-Viewer von NO$SNS die Farben und die Tiles. Yeeeeah!
~~~
Hm. Mein Test hat ergeben: Daran lags nicht. Kacke, wo geht hier was schief!? :/

Stunde rum, Resümee:
In jedem Fall bin ich schon mal ein gutes Stück vorwärts gekommen. Ich glaube, ich werde gleich mal den verbliebenen Rest von den Musikdaten machen, vielleicht wird dann ja alles gut.
Denn: Eigentlich müsste meine ROM jetzt schon ein Logo zeigen und verschwinden lassen, bevor es sich selbst zerstört.

[lytron]

Stunde 34
Disassembled: 4.778 / 1.048.576 Bytes (0,456%)
Gehört: (Nick Drake - Pink Moon) x2

Wir suchen die undichte Stelle.

~~~
Okay, die Subroutine ist es nicht. Dank NO$SNS kann ich wohl sehen, dass das Ding in einem Loop auf Bank $0A hängen bleibt. Allerdings ist da nichts falsch. Ich rechne mal damit, dass irgendein Wert nicht richtig in ein DP-Register gespeichert wird, dass es deshalb hängt. Mal schauen. Ansonsten muss ich mich wirklich an Bank $0A setzen... >_<
~~~
Okay, ich gleiche gerade die gesamte ROM ab, soweit ich sie disassembled habe. Habe schon eine Abweichung gefunden, ich hoffe, das bewirkt was... :/

Stunde rum, Resümee:
Es hilft alles nichts. Ich weiß nicht, woran es liegt, aber er verfängt sich in einem ewigwährenden Loop bei 0005:1EEF und ich weiß nicht, wieso. Ich befürchte, dass es damit zusammenhängt, dass er irgendwo Daten aus der ROM lädt, die bei mir null sind, die nicht null sein dürfen. Es ist... bedrückend. :/
Bis ich mich dann mal an Bank $0A heranwage, werde ich jetzt erstmal mit der Jump Table auf Bank $00 weitermachen. Da weiß ich wenigstens, wie es funktioniert. :/