Disassemble Blog: Ihatovo Monogatari

[lytron]

Stunde 111
Disassembled: 214.142 / 1.048.576 Bytes (20,422%)
Gehört: Peter Tschaikowski - Der Nußknacker (zweite Stunde), Lions - Roosevelt EP

Noch ne Stunde Arbeit.

~~~
Okay, interessant: Nach dem Menü gelangt man entweder zu Jump-Table-Eintrag $08 oder $00. $08 ist offensichtlich der, der für ein neues Spiel zuständig ist. $08 ruft $09 auf, $09 ruft $0A auf. Derzeit habe ich noch einige der Unterverästelungen von $0A zu klären, aber gerade habe ich herausgefunden, dass der nächste JT-Eintrag $01 ist. Das heißt, scheinbar laufen an dieser jenen Stelle dann die Fäden zwischen "Spiel laden" und "Neues Spiel" wieder zusammen.
~~~
Ach du liebe Zeit. Eine Subroutine setzt bei Adresse $16C5 an. Eine andere hört bei $16C2 auf. Dazwischen sind zwei Byte mit dem Inhalt "$FF".
Es ist klar, dass man irgendwo irgendwie den verbliebenen Platz auf einer Bank füllen muss, da man nie und nimmer-nicht eine Bank auf den Byte genau vollkriegt. Aber warum an dieser Stelle? Warum nur zwei Byte? Fragen über Fragen...
Vielleicht werden die zwei Byte ja für einen festen DMA-Transfer gebraucht. Wer weiß. Sinn mächte es nicht. Aber egal.
~~~
Jaaaaa... es ist Feiertag! Ich habe frei! Der dörfische Spielmannszug steht zur Sekunde unter meinem Fenster und spielt den immerselben Mai-Marsch, um von der senilen Nachbarschaft Spirituosen zu erspielen. Yay!
Nein, ich möchte sagen: Ich habe Zeit, ich habe Ruhe, ich hatte Schlaf - und folglich kann ich jetzt auch wirklich arbeiten. Folglich schreibe ich mehr, folglich werde ich wohl weniger Bytes disassemblen können.
Gerade habe ich eine Sache auseinander genommen, die ein VRAM-Tileset-Bereich-Clear-DMA vorbereitet. Dabei werden die beiden oberen $FF-Bytes genutzt. Jetzt ist die Frage, ob damit nur die zweite Hälfte des BG3-Tilesets gecleart wird, oder ob auch noch das komplette Tileset von BG1/2 mitgelöscht wird. Ich habe die Frage mal im snes-projects-Chat gestellt, mal schauen, ob die Antwort kommt.
~~~
Oddities!
Ich habe mal investigatives Karpaltunnelsyndrom betrieben: Die nächste Subroutine sah so seltsam aus, hat in mir doch eine Vermutung geweckt, folglich habe ich mal wieder eine Kopie der Original-ROM gemacht und selbige mit dem Hexeditor umgefusselt.
Und ich hatte mit meiner Vermutung recht.

Ihatovo Monogatari (J) - Kopie_00000.png (18.93 KiB) 5742 mal betrachtet

Ladies and Gents, we're right inside the textbox!
Habe ich dann meine zweite Vermutung getestet und die beiden $FFs durch $00s ersetzt, und auch diese Vermutung erwies sich als korrekt:

Ihatovo Monogatari (J) - Kopie_00001.png (10.54 KiB) 5742 mal betrachtet

Bäääääm! Ich bin ein H4><z0r!
~~~
Bäääääm! Ikari_01 hat mich gerettetetet!

Code: Alles auswählen

[10:25] <+ikari_01> lytron: 
[10:25] <+ikari_01> A30/2
[10:25] <+ikari_01> 518.00000000000000000
[10:25] <+ikari_01> 2AE8+518
[10:25] <+ikari_01> 3000

Bäääääm! Was ist das ein H4><z0r!
~~~
Und nochmal Bäääääm!
Ich wunderte mich, dass im *Tileset* geändert wird, und nicht in der Tilemap. Und meine Vermutung prüfte ich mittels NO$SNS, und auch hier, bäääääm, erwies sich meine Vermutung als richtig:

textbox.jpg (155.29 KiB) 5742 mal betrachtet

Die Tilemap für die Textbox ist immer gleich, es werden die *Tiles* bearbeitet; das heißt, taucht in einer Textbox dasselbe Schriftzeichen zweimal auf, sind auch zwei Tiles im VRAM dasselbe. Diese Handhabung scheint üblicher zu sein als die Anpassung der Tilemap, auch wenn das für mich auf den ersten Blick weniger logisch erscheint. Ich meine, dass LostTemplar soetwas mal über FEoEZ auch im Chat erwähnt hat...
~~~

Stunde rum, Resümee:
Konnte dann gerade noch den Großteil des verbliebenen Geäders von JT-Eintrag $0A absolvieren, einige Subroutinen, die sich mit dem Malen des Textbox-Rahmens beschäftigen. Sobald ich mehr Zeit habe, mich mit dem Code eingehend zu beschäftigen, werde ich vielleicht auch schon auf die Textbox-Tiles zusteuern, und dann kann ich ernste Vorbereitungen für den Text-Dump treffen. =)

206 von 438 KB.

PS:

Code: Alles auswählen

[10:25] <+ikari_01> lytron: 
[10:25] <+ikari_01> A30/2
[10:25] <+ikari_01> 518.00000000000000000
[10:25] <+ikari_01> 2AE8+518
[10:25] <+ikari_01> 3000
[10:26] <lytron> Danke, das macht sinn.
[10:27] <lytron> Das ist, übrigens, das clearen des letzten Rests des Tile*set*s für BG3; das wiederum für Textboxen genutzt wird.
[10:28] <lytron> Der Text wird in einzelne Tiles hineingesetzt und jede Textbox hat dieselbe Tilemap, statt dass die Tilemap gemäß den Zeichen angepasst wird.
[10:28] <lytron> Scheint aber usus zu sein, es sorum zu machen.
[10:28] <lytron> domo arigato, ikari-sensei! :)
[10:30] * +MarcoEagleEye (~MarcoEagl@euirc-ec12b569.adsl.alicedsl.de) Quit (Client exited)
[10:46] * RedScorpion (~RedScorpi@euirc-1b72fe82.cust.telecolumbus.net) has joined #snesprojects
[10:46] * ChanServ sets mode: +qo RedScorpion RedScorpion
[10:57] <+ikari_01> lytron: da man japanische Zeichen eh zusammenkopieren muss, weil die Tilemap nicht genug verschiedene Einträge und das VRAM nicht genug Platz hat... ;)
[11:06] * LostTemplar (~LostTempl@euirc-b9b0311c.superkabel.de) has joined #snesprojects
[11:12] <lytron> Ach ja, die teuflischen Kanji...
[11:12] <lytron> ... ich vergaß.
[11:37] <LostTemplar> Sinn, du ergibst ihn nicht!

[lytron]

Stunde 112
Disassembled: 214.532 / 1.048.576 Bytes (20,459%)
Gehört: Der witzigste Vorleseabend der Welt (erste Stunde)

Morgen wieder arbeiten. Da will ich heute lieber noch was schaffen. So jung kommen wir nicht mehr zusammen.

~~~
Stunde rum, Resümee:
Ich, äh, habe da ein wenig geschafft, ja.

192 / 438

[ChronoMoogle]

Woah! Bald kommt also der Textdump!! Das bedeutet jede Menge geschaffte Bytes und endlich die Grundlage fuer die Uebersetzung $__$
Splendid!

[lytron]

Stunde 113
Disassembled: 214.912 / 1.048.576 Bytes (20,496%)
Gehört: Kenji Ito - Seiken Densetsu OST, Lions - MTNZ EP

Mehr von gleichem.

~~~
Hmpf. Fängt ja schon wieder gut an. Subroutinen werden aufgerufen und sofort beendet. Und warum? Weil ihr eigentlicher Inhalt überbrancht wird. Darf ich mir dann wieder von irgendwo aus der Log zusammenklamösern. Bestenfalls.
~~~
Gut, diese Minisubroutine brancht zwei Mal und ruft dabei je eine Subroutine auf. Die erste dieser Untersubroutinen ist vergleichsweise lang (~100 Byte) und brancht auch um einiges. Yay, wahrscheinlich mache ich heute nur das.
~~~
UND da darf ich wieder anfangen, per Hand zu disassemblen.
~~~
Okay, ich habe keine Ahnung, was das hier macht, aber es sieht interessant aus:

Code: Alles auswählen

	Adagio:
	REP #$30.b
	LSR A
	BCS AdaJump2
	LSR A
	BCS AdaJump3
	LSR A
	BCS AdaJump4
	LSR A
	BCS AdaJump5

	LDA #$0000.w
	SEP #$20.b
	STZ $1821.w
	CLC
	RTL

	AdaJump2:
	LDX #$0008.w
	LDY #$0000.w
	BRA AdaJump1
	; B428
	AdaJump3:
	LDX #$FFF8.w
	LDY #$0000.w
	BRA AdaJump1

	AdaJump4:
	LDX #$0000.w
	LDY #$0008.w
	BRA AdaJump1

	AdaJump5:
	LDX #$0000.w
	LDY #$FFF8.w

	AdaJump1:

Ich vermute wie doof ins Blaue hinein, dass es was mit der Spritebewegung zu tun hat...? Würde insofern passen, alsdass die Figur sich immer nach einem Raster bewegt, und sich immer 8 Pixel auf einmal bewegt.
~~~
Mehr und mehr erhärtet sich meine Vermutung, dass dieses tentakelartige Monstrum mit dem Perlweiß-Schwiegersohngebiss die Steuer-deine-Spielfigur-Subroutine ist. Bzw., es bereitet scheinbar die Werte vor. $10 enthält die X-Position, wo es hingehen soll, bzw. $14 die Y-Position. Und... brummsel, brummsel... ist das in $1822/4 die momentane X- und Y-Position!?
Gleich mal testen!
~~~

iha.png (114.05 KiB) 5722 mal betrachtet

Bäääm!
In der Tat! Es funktioniert, wie ich dachte. $1822/3 enthalten die X-Position, $1824/5 die Y-Position, und der Low Nybble von $182C entscheidet über die Blickrichtung von unserem Kofferträger. Beim rechten Bild habe ich die X-Position geändert und das Männeken an eine Position versetzt, an der er im normalen Spiel unmöglich ankommen kann (da, schrägrechtsunten vom Bahnhofsvorsteher der Weg versperrt ist).
Bäääm! Ich habe das rausgekriegt und Bäääm! Ich hatte mit meiner gefühlten Einschätzung oben rechtgehabt!
Wie... unerwartet.
Ich werde jetzt mal die ROM Map entsprechend erweitern und irgendwann, wenn mich die Lebenslust umbringt (Songzitat! Songzitat!), kann ich ja mal die vorhandene Datei danach durchsuchen und guck0rn, wo das alles auftritt. Woozah, das könnte einiges um einiges erleichtern...
~~~
Und meine nächste Vermutung ist...
Eine Liste von Zwei-Byte-Adressen der Spielfiguren-Grafiken liegt am Anfang von Bank $1C. Badabing.
~~~

Stunde rum, Resümee:
Bäääääm! Einfach nur Bäääääm!
Empfinde ich alles wieder als guten Fortschritt.
Ich muss beim nächsten Mal nur dran denken, bei Subroutine B1BA weiterzumachen. 178 von 438.

[lytron]

Stunde 114
Disassembled: 215.156 / 1.048.576 Bytes (20,519%)
Gehört: Kenji Ito - Seiken Densetsu OST, unununium88 - Shadowrun Revamp

Ich wollte bei B1BA weitermachen!
~~~
Subroutine $B1BA, Arbeitsname "Bieber", enthält wieder einiges Nicht-Geloggtes. Oh no! Zusätzlich Arbeit!
~~~
Es sind 35 Minuten vergangen und ich bin jetzt mit B1BA/Bieber durch. Und natürlich wird hier auch wieder weiterverzweigt in andere Subroutinen. ABER als nächstes werde ich erst einmal schauen, ob ich da was falsch disassembled habe.
~~~
Gut, ich habe jetzt noch einmal allein eine Viertelstunde aufs Bugfixing verbracht, und habe trotzdem ungefähr zehn falsche Bytes über die ganze Subroutine verteilt, ide ich jetzt nicht fixen werde.
Denn: Diese Bytes sind immer nach dem Aufruf einer bestimmten Subroutine, und sie bilden einen Branchbefehl *in einen anderen Befehl hinein*. Folglich gehe ich davon aus, dass es sich dabei wieder um Bytes handelt, die überhaupt nicht als Befehle zu interpretieren sind, sondern wieder als Daten für die zuvor aufgerufene Subroutine sind.

Allerdings werde ich das erst in der nächsten Stunde prüfen können, da ich jetzt nur noch zehn Minuten habe. Die werde ich jetzt für ein längst überfälliges Update meiner ROM-Map nutzen. Soweit ich kommen mag.

~~~
Stunde rum, Resümee:
Ich habe mich faktisch nur mit Bieber beschäftigt. Die ganze Stunde über.
Ich vermute, Bieber hat mit der Hauptfigur-Steuerung mit der Maus zu tun, aber das ist nur in den blauen Dunst hineinvermutet.
Ich hoffe, das UEFA Champions League Finale kommt bald, weil ich dann nicht mehr zwanzig mal täglich die Heinekenwerbung auf Youtube sehen muss (aus Respekt gegenüber dem uploadenden Youtuber lass ich die immer durchgurgeln).
Außerdem denke ich, ist Sommerwärme und Sommerhelligkeit nicht förderlich für ein für mich produktives Arbeitsumfeld.
176/438

[lytron]

Stunde 115
Disassembled: 215.156 / 1.048.576 Bytes (20,519%)
Gehört: Wamdue Project - Resource Toolbook, Volume One

Es ist Frühling, es pustet ein laues Lüftli durchs Fenster, es ist noch nicht so hell, dass ich nichts mehr auf dem Bildschirm was sehen kann. Ich will dann mal diese Rahmenbedingungen nutzen, um mich tatsälich einmal mit dem Inhalt des bereits eingefügten Programmsalats zu beschäftigen. Auch wenn ich mit gewissem Respekt mich da dranbegebe. Ich werde mit Jump-Table-Eintrag null anfangen, was ja theoretisch das New-Game sein sollte. Oder, ach nee, das war acht, also mache ich JT08.
Das fängt ja schon guuut an. ^^
~~~

Stunde rum, Resümee:
Hochinteressant!
Und total anstrengend, das jetzt in Worte zu kleiden!

Ich habe gut eine halbe bis Dreiviertelstunde damit verbracht, mir zwei Subroutinen noch einmal anzuschauen, die ich schon einmal verstanden hatte. Ich hatte sie bereits kommentiert. Aber jetzt habe ich sie noch einmal neu kommentiert, und das wesentlich ausführlicher. Die Subroutinen beschäftigen sich mit dem Transfer von Sprite-Paletten, was jetzt ansich nicht unbedingt sooo handlungstreibend ist.
Außerdem habe ich ein bisschen die ROM-Map und die define.asm gepimpt. Letztere ist die Datei, in die ich hineinschreibe, wie ich gern einzelne Register ansprechen möchte. Z. B. $182C als HeroFDir oder $1822 als HeroXPos - dazu später mehr -, auch wenn ich nur wegen der Kürze für die Hauptfigur dieses Spiels die Bezeichnung "Hero" verwende.
Die verbliebene Zeit verbrachte ich dann schlussendlich mit dem tatsächlichen JT-Eintrag (dieser Paletten-Klimbim wird darin aufgerufen, insofern war das nicht offtopic).
Nach der Palettensubroutine war ich nur ungefähr eine Minute mit dem JT-Eintrag ansich beschäftigt.
Ich erwähne es noch einmal: Derzeit läuft dieser JT-Eintrag noch unter dem Namen "NextStep", und hat diesen Namen vor ungf. hundert Arbeitsstunden bekommen, da es nämlich genau dieser Jump-Table-Eintrag ist, den ich fälschlicherweise zu ganz zu Anfang disassemblete. Mit dem Eintrag ansich war ich fertig, es hing nur an einer einzigen Subroutine, die ich noch klären musste.
Und die hieß "DerGrosseVerzweiger", in deren Mitte ich übrigens das Disassemblen vor ungf. hundert Stunden abbrach. Diesen Namen trägt dieses Dingens zurecht. Es macht zunächst ein bisschen Brimborium mit Variablen (dazu später mehr) und ruft dann folgende Subroutinen auf:

Code: Alles auswählen

	JSL ClearOAMTemp.l		; $008CBC = $0000:0CBC
	JSL TakeAnotherGuess.l	; $00B5BF = $0000:35BF
	JSL GoFlyAKite.l		; $00B81A = $0000:381A
	JSL KirlianChoices.l		; $00B8F6 = $0000:38F6
	JSL Schicksalsberg.l		; $00DD36 = $0000:5D36
	JSL Tsukasa.l			; $00E498 = $0000:6498
	JSL Tawada.l			; $00B054 = $0000:3054
	JSL TileMapBuilder.l		; $00B620 = $0000:3620
	JSL Suspicious_NeighboUr.l	; $00B6B3 = $0000:36B3

Die erste Subroutine erklärt logischerweise, was sie tut. Die beiden letzten sind mir auch klar. Die letzte, übrigens, ist dem TileMapBuilder in der Funktionsweise komplett gleich, allerdings bedient sie andere (Ziel-)Adressen (im VRAM). Bisher war ich nur zu faul, den Namen der Subroutine mal zu korrigieren. Bleiben nur die anderen Subroutinen mit den Platzhalternamen.
Was das Ganze für mich gerade so spannend bis kopfnussig macht, ist:
In diesem Programm verwendet man Listen in Listen für Listen über Listen, die Informationen über Listen weitergeben.
Ich versuche es mal so realitätsnah wie möglich wiederzugeben:
Vor dem Aufruf vom großen Verzweiger muss exakt eine Variable mit einem Wert befüllt werden.
Im großen Verzweiger selbst wird dieser Wert in einen Index für eine Liste umgewandelt. Index heißt in diesem Zusammenhang: Den wie-vielten Eintrag einer Liste man haben will. Also, die Variable wird ein Index. Aus der Liste werden drei Doppelbyte-Werte in drei Variablen gestopft, dann begeht man obige Verzweigungstat.
Ich habe mir vorhin noch "TakeAnotherGuess" komplett anschauen können, habe danach dann aufgehört (weils ein glatter Schnitt war).
In "TakeAnotherGuess" wird einer dieser drei Doppelbyte-Werte geladen und als Index für eine Tabelle genommen (überrascht?). Dank meiner Spielerei von vor ein paar Stunden weiß ich, dass der von dieser Liste geladene Wert die Blickrichtung des Helden ist, ansonsten wäre es jetzt nur irgendein unbekannter Byte-Wert, der in ein Register mir unbekannten Nutzens transferiert wird.
Der zweite Wert, der aus dieser Tabelle geladen wird, dient als Index für eine andere Tabelle (überrascht!?!). Damit werden die Variablen ab $1000 befüllt, wobei mir noch im Hinterkopf hängt, dass die vom Tilemap-Builder verwandt werden. Nachdem das absolviert wird, wird der nächste Eintrag aus der Liste geladen, die bereits die Blickrichtung und diesen letztgenannten Index enthielt.
Und was ist das für ein Wert? Naaa...?
Natürlich ein Index! Für eine Tabelle, die die X- und Y-Koordinaten der Spielfigur enthalten. Warum auch nicht.
Erinnert ihr euch, dass ich in den Siebziger-Stunden, glaube ich, zehn Stunden lang an einer Subroutine hing, und sie nicht entschlüsselt bekam? Dass ich verstand, was sie macht, aber nicht, wie? Das ist übrigens der TileMapBuilder gewesen. Und folglich gilt selbiges Unverständnis auch für den Suspicious Neighbo(u)r.
Und ich befürchte, dass ich mich damit noch einmal ganz intensiv auseinandersetzen muss. Urgs.

Um dieses Schlusswort zu schreiben, habe ich übrigens vierzig Minuten (*nach* der Arbeitsstunde) gebraucht. Falls sich jemand noch wundert, weshalb ich nach einem Arbeitstag maximal stupides, wortkarges Disassembling hinbekomme.

[lytron]

Stunde 116
Disassembled: 215.156 / 1.048.576 Bytes (20,519%)
Gehört: Strawberry Girls - French Ghetto

Weiter im großen Verzweiger.
~~~
"GoFlyAKite" ist ungf. dreimal so groß wie "TakeAnotherGuess" und enthält wieder einige Tabellen. Die liegen alle auf Bank $02. Vermutlich alle hintereinander.
~~~
Bäääääm!
Für euch zur Orientierung:
"GoFlyAKite" war die Subroutine mit den Forenuser-Namen-Verballhornungen. "SvamboGeigerRockt" z. B. konnte ich schon zuvor feststellen, dass es ich dabei um einen bloßen Transfer der Item-Menü-Grafiken handelt (und dementsprechend änderte ich soeben den Namen). Desweiteren habe ich noch als zu klärende Subroutinen den Dreiklang KiddoSuperstar, PandaBlackEdition und DreimerRhymer, desweiteren Teleprompter, Sylviania, NACHT_TOUR und Decola.
Vom Dreiklang betrachte ich den letzten zuerst (das ist, wie wenn man ein Buch von hinten liest: Man will wissen wies ausgeht). Und dort sehe ich:

Bäääääm!

Die von mir in der Stunde zuvor betrachtete Transfer-Routine für die Palette kann zwar flexibel von unterschiedlichen Stellen laden, speichert sie aber immer nur an eine feste Stelle. Es sind immer die ersten $40 Byte (also die ersten beiden Paletten) im CGRAM für die Hintergründe (also wirklich-wirklich die ersten beiden Paletten).
Am Ende von DreimerRhymer werden wieder Daten transferiert, auf feste Art und Weise. Und zwar alle BG-Paletten ab Palette 4.
Folglich:
Es gibt eine Subroutine für die ersten zwei Paletten,
es wird wohl eine für die dritte Palette geben,
denn es gibt dann noch für den Rest der BG-Paletten (siehe oben),
und eine für die Sprite-Paletten.

Weeey!
~~~
Woozah. Diese Einträge in der Liste für diese Rest-der-BG-Paletten sind vergleichsweise groß (für Paletten; da es viele Paletten sind), je, was sagte ich, $A0 Byte (= 160 Byte). In DreimerRhymer wird u. A. auch Eintrag $2B aufgerufen. Folglich, wenn es $2C (= 44) Einträge gibt ($00 bis $2B), sind das schon mal... $1B80 Byte! O_O
7040 Byte!
~~~
Das nächste ist eine Tabelle mit DMA-Einträgen.
Das haben die ganz geschickt gemacht, der große Verzweiger ist offensichtlich der General-Grafikbeschaffer, der halbwegs flexibel allerlei Grafiken zusammenzimmert... mithilfe von ungelogen einem dutzend Listen. Und ich komme ein wenig in Probleme, weil ich nicht einschätzen kann, ob zwischen den Listen noch was anderes liegt, oder ob die nahtlos aneinander pappen. Das sähe ich erst, wenn ich nachrechnen würde, wie viele Einträge in eine Liste passen, die bis zum nächsten Listenanfang reichen würde, und dann der FAll eintritt, dass selbiger Eintrag auch aufgerufen würde. Mal schauen.
~~~
Stunde rum, Resümee:
KiddoSuperstar, PandaBlackEdition, DreimerRhymer: Dreifach verschachtelte Paletten-Zusammenstellung.
Teleprompter: Zusammenbauen von DMA-Pipeline-Einträgen.
Sylviania: Zusammenbauen von, ich meine, Tilemaps?
NACHT_TOUR: Rechnerei und anschließender zweifacher Sprung in DieChinesischeMauer (zwecks irgendeiner Dekompression) mit Werten aus einer bestimmten Liste.
Decola: Zweifacher Sprung in DieChinesischeMauer (zwecks irgendeiner Dekompression) mit Werten aus einer bestimmten Liste.

Außerdem kommen gerade alle "Jugendsünden" wieder zum Vorschein, da ich sowohl den TileMapBuilder als auch DieChinesischeMauer in ihrer Gänze nicht verstanden habe. Ich weiß, jaaa, dass da was dekomprimiert wird. Aber wie... und schlussfolgerlich was es ist, weiß ich nicht.

[ChronoMoogle]

Wow jetzt bist du wirklich am puzzlen, nicht?
Was gehoert wie zusammen und was bewirkt letztendlich was...
Ich hoffe bald knackst du den Da Vinci Code

[lytron]

Ich hoffe bald knackst du den Da Vinci Code

Mach ich, und damit kläre ich dann auch den Verbleib des Bernsteinzimmers, wo das Lexikon zum Voynich-Manuskript liegt.

Ja, gerade geht es ganz gut vorwärts. Ich könnte jetzt auch diesen Kram liegen lassen und beim nächsten Mal erst einmal nach dem Textbox-Kram gucken, aber ich würde mich besser fühlen, wenn ich das hier zuerst absolvieren würde.

[lytron]

Stunde 117
Disassembled: 215.156 / 1.048.576 Bytes (20,519%)
Gehört: Chrono Symphonic

So ungern ich es auch tu, ich steige noch einmal in den TileMapBuilder und in DieChinesischeMauer ein. Wenn ich aber das Gefühl habe, da nichts reißen zu können, brech ich das ab.

~~~
Liebe gute Güte, ich steh auf dem Schlauch!

Code: Alles auswählen

	ReadOutChunk:
	LDY $00.b
	LDA [$0C.b], Y
	ASL a
	ASL a
	ASL a		; *8
	CLC
	ADC $08.b		; + Var $08
	TAX
	LDY $02.b
	LDA $7F1000.l, X
	STA $0D00.w, Y
	LDA $7F1002.l, X
	STA $0D02.w, Y
	INC $00.b
	INC $00.b
	TYA
	INC a
	INC a
	INC a
	INC a
	AND #$007F.w
	STA $02.b
	DEC $04.b
	BNE ReadOutChunk

Also nehme ich den Kram mal hier auseinander, sehr zu eurem, äh, Entertainment.
$0C bis $0E enthält eine Adresse im WRAM, Bank $7F; ich hatte mir vormals notiert, dass an diese Stelle Daten kopiert wurden, aus denen man sich die Tilemap baut, also glaube ich mir mal.
Y enthält den Index für das Laden, in Ordnung.
Ah, $08 ist gar nicht ein fester Wert... hey! Ich könnte mir da was vorstellen!
Was, wenn $08 die Tilemap-Einstellungen enthält, also: "Dreh dieses Tile, gib ihm höchste Priorität" o. ä.? Mal schauen, wo $08 gesetzt wird.
~~~
Oookay... $08 wird aus $B3 generiert. $B3 wird aus $10 erstellt, $10 aus $1002.
$1002 wird gesetzt, bevor der Tilemap-Builder aufgerufen wird und konserviert somit das Ursprungsstadium.
$10 wird am Anfang vom TileMapBuilder mit dem Wert von $1002 gesetzt.
In einem Loop wird $10 bei jedem Durchlauf um #$0008 erhöht. Zuvor wird $B3 jedoch mit dem Wert von $10 gesetzt. Danach (und vor der Erhöhung von $10) geht es in die Subroutinen TMB_ValueMod und TMB_PickUp (innerhalb des Loops, ja).
TMB_ValueMod rechnet zwar mit $B3, ersetzt den Wert aber nicht, und damit ist das gerade egal.
~~~
Okay, und in $08 wird druch $B3 gesetzt. $08 enthält Bit 3 von $B3 (LDA $B3, AND #$0008), dieser wird dann einmal nach rechts verschoben (LSR a) und in $08 gespeichert. Da, wie ich bereits sagte, mit jedem Loopdurchlauf auf $10, als0 $B3, 8 addiert wird, heißt das: $08 schwingt immer zwischen #$00 und #$04 hin und her.
Folglich: Vergiss meine Theorie mit den Tilemap-Daten wegen Spiegelung und so. Überhaupt, der dort mit $08 errechnete Wert wird zu einer Adresse! Also!
Also... weitergucken.
~~~
In Ordnung, ich verstehe, wie es funktioniert, ich verstehe nur nicht, weshalb man einen solchen Aufwand betreibt...
... beziehungsweise, oh, ooooh, vielleicht doch.
... beziehungsweise, nein.
Ich sah, dass der Adresswert geladen wird, dann die Bits dreimal nach Links verschoben werden (3x ASL a) und dann $08 draufaddiert wird (siehe oben). Zunächst dachte ich: "Hey, vielleicht haben sie die Adressen durch acht geteilt, damit sie drei Bits mehr für höhere Adressen haben. Aber, nein, die drei Bits werden ja rausgeschmissen, und sind folglich total nutzlos. Warum also!?
Bizarr ist auch, dass dieser #$04/#$00-On/Off-Switch beim Laden ist; für mich wäre soetwas bei der Ausgabe logischer.
Aber egal, ich kümmere mich nun zuerst um $BB. Ich weiß auch nicht warum. Ich hatte mir das notiert.
Aaah, ach ja, weil $BB die Adresse in $0C bildet.
~~~
So. Habe gerade eine Stunde anderweitig verdaddelt, u. a. versucht, einen indischen Super-Nintendo-Fan über ein paar Infos zum SNES in seinem Heimatland auszuquetschen. Well, whatever, zurück zum Thema.
~~~
Ah, ach ja. $BB herauszubekommen ist der größte Grütz wo gibt. Weil sich das Ding aus drei Variablen errechnet. Also gucke ich erstmal, was man so mit $B3 alles macht. Dazu kann ich ja auch mal die Zeichnung von anno dazumal raussuchen.
~~~
Okay, kein Durchbruch, aber ein Fortschritt, ist:
$B3(/$B4) enthält kombinierte Daten:

• Bit 0-2:
• Bit 3: Für $08. On/Off
• Bit 4-7: Gehen in $B7/B8 (geteilt durch 16), Gehen in $B9 ein (nach weiterer Umrechnung)
• Bit 8-15: Gehen in $B7/B8 (geteilt durch 16)

~~~
Urgh...
bitte fragt mich nicht, wie ich jetzt dazu komme, die Herkunft und Beschaffenheit von $AC zu klären.
In jedem Fall werde ich jetzt eine von den vielen, vielen Tabellen von gestern durchsuchen, weil dort Werte in $1008 geladen werden, die eins zu eins in $AC übertragen werden, weil ich wissen will, ob die Werte in $1008 auch mal was anderes als #$01 oder #$02 sein können. Oh hell yeah.
~~~
Bääääm! Das steht gar nicht in den Tabellen drin, Hah!
~~~
Urgh... DieChinesischeMauer scheint (auch) dazuzudienen, $1008 zu berechnen. >___<
~~~
Aha! So komme ich hier hin!
$AC formt letzten Endes $22 und $23, und die haben mit $20 zu tun, und $20 entsteht aus $B7, und $B7 entstammt $B3. Logisch, oder? Nicht!? Dann guck halt auf meine Zeichnung von damals und nerv mich nicht, Maaaaann!
Der Wert in $B7 wird jeden zweiten Loop-Lauf (also, vom großen Hauptloop des TileMapBuilders) erhöht, weil: $B7 = $B3 : 16, und $B3 wird jedes Mal um 8 erhöht.
~~~
Es bringt alles nix, ich muss das mit Zahlen durchspielen.
... *was* muss ich mit Zahlen durchspielen?
*das*:

Code: Alles auswählen

	ModulateVar24:
					; Until now, I've only seen cases that this Subroutine is executed
					; where $AD/$AE were loaded into A and their value was $0020 or $0010
					
					; This subroutine is built to be executed with both a 16 bit A and a 8 bit A
					; Hence the "STZ $23" and "REP #30". Both are without effect if A is already 16 bit.
	STZ $23.b
	STA $22.b			; Stores $AD in $22 and $AE in $23
	PHP
	PHX
	REP #$30.b
	LDA #$0000.w
	STA $24.b
	LDX #$000F.w
	ModVar24Loop:
	LDA $20.b
	LSR a
	STA $20.b
	BCC DoNotChange24	; Branches if a bit has fallen out of $20 through LSR
	LDA $24.b
	CLC
	ADC $22.b
	STA $24.b			; 
	DoNotChange24:
	LDA $22.b
	ASL a
	STA $22.b			; $22 * 2
	DEX				; DEC LoopCounter
	BPL ModVar24Loop
	LDA #$0000.w
	PLX
	PLP
	RTL

Für $22/$23 kann ich quasi feste Werte nehmen. Ich nehme #$0020. Dort können nur #$0020 oder #$0010 drin sin. Also spiele ich mit #$0020 durch und kann ja immer noch dann das Ergebnis einmal im Kopf nach rechts verschieben (also, durch zwei teilen) und hätte das Ergebnis von $22/$23= #$0010. Wie auch immer.
$20 fängt an mit $0000 und wächst, wie gesagt, jedes zweite Mal MainLoop um eins.
~~~
Stunde rum, Resümee:
Hier mal ein paar Ergebnisse meiner Rechnerei:

Code: Alles auswählen

;		.	.	$22 = #$0010	$23 = #$0020
; $20 = #$0000:	#$FFF0		#$FFE0
; $20 = #$0001:	#$FFE0		#$FFC0
; $20 = #$0002:	#$FFD0		#$FFA0
; $20 = #$0003:	#$FFC0		#$FF80
; $20 = #$0004:	#$FFB0		#$FF60

Habe ich dann jetzt auch mal so mit in meine ASM-Datei hineinkommentiert.
Überhaupt habe ich alles nennenswerte, was ich jetzt herausgefunden habe, dort als Kommentar vermerkt. Weil ich das hier bestimmt nicht nochmal lesen werde!
So. In jedem Fall habe ich jetzt schon mal ein wenig mehr, womit ich arbeiten kann. Mal sehen, was es bringt.

[lytron]

Stunde 118
Disassembled: 215.156 / 1.048.576 Bytes (20,519%)
Gehört: Hiroki Kikuta - Seiken Densetsu 2 OST

Der Trick beim Tilemap-Builder liegt darin, dass nicht viel multipliziert wird, sondern dass bei den eingangs gesetzten Variablen einzelne Bits oder Nybbles für unterschiedliche Funktionen stehen.
~~~
Ach, kacke, das bringt alles nix. Ich log den Rotz.
~~~
Gut, es ist genau wie ich schrieb, nur anders rum!
Die Zahlen sind eigentlich:

Code: Alles auswählen

;		.	.	$22 = #$0010	$23 = #$0020
; $20 = #$0000:	#$0000		#$0000
; $20 = #$0001:	#$0010		#$0020
; $20 = #$0002:	#$0020		#$0040
; $20 = #$0003:	#$0030		#$0060
; $20 = #$0004:	#$0040		#$0080

Folglich... macht das nichts anderes als multiplizieren. Mh... ~_~
~~~
Gut, habe jetzt diese Subroutine umbenannt. MANN! Warum so kompliziert?! Es gibt extra Register für Multiplikationen, und das geht sicherlich schneller als dieser Loop-Tinnef.
MEMO AN MICH SELBST: Ich kann ja mal testen, ob ich das durch Multiplikation ersetzen kann und damit dann speicherplatz spare.
~~~

Stunde um, Resümee:
Ich könnte eigentlich direkt weitermachen, aber ich weiß nicht, ob ich es tu.
Um den Überblick zu behalten, nutze ich jetzt die ROM-Map, um den Schmarrn irgendwie darzustellen.

Code: Alles auswählen

; $B3 - At $0000:3620:	xxyy.yzzz
			x = Bit 7 and 6 become Bit 1 and 0 for $BA (VRAM Dest. Address - HIGH BYTE)
			y = Bit 5 to 3 become Bit 7 to 5 for $B9 (VRAM Dest. Address - LOW BYTE)
			z = ?
; $B4 - At $0000:3620:	????.????

; $B5 - At $0000:3620:	xxxy.zzzz
			x = ?
			y = Bit 4 becomes Bit 2 for $BA (VRAM Destination Address - HIGH BYTE)
			z = Bit 3 to 0 become Bit 4 to 1 for $B9 (VRAM Dest. Address - LOW BYTE)
; $B6 - At $0000:3620:	????.????

;

; $B9 - At $0000:3620:	VRAM Destination Address - LOW BYTE
			yyyz.zzz0
			y = Bit 7 to 5 are Bit 5 to 3 of $B3
			z = Bit 4 to 1 are Bit 3 to 0 of $B5
			0 = always 0
; $BA - At $0000:3620:	VRAM Destination Address - HIGH BYTE
			0000.0xyy
			0 = always 0
			x = Bit 2 is Bit 4 of $B5
			y = Bit 1 and 0 are Bit 7 and 6 of $B3

Zu dumm, dass viele der Einzel-Bits auch noch eine zweite Verwendung finden... Aaaah...

[lytron]

Stunde 119
Disassembled: 215.156 / 1.048.576 Bytes (20,519%)
Gehört: Hiroki Kikuta - Seiken Densetsu 2 OST

Ich mache weiter, im Endeffekt reine ROM-Map-Pflege. Und Verständnisprozess gleichermaßen.

~~~
Stunde rum, Resümee:
Statt, dass ich jetzt prosaisch schreibe, was ich gemacht habe, poste ich einfach mal den Auszug aus der ROM-Map, was ich gerade alles zusammengeschrieben habe.

Wenn wer durchsteigt, mag er es mir erklären:

Code: Alles auswählen

; ==================================================
; DIRECT PAGE REGISTERS (VARIABLES) $0000-$00FF:
; ==================================================
;
; $00 - At $0000:3620:	0000.xxxx
;			x = Bit 3 to 0 are Bit 7 to 4 of $B1.
;				Bit 3 to 0 become Bit 4 to 1 for $B9 (VRAM Dest. Address - LOW BYTE)
; $01 - At $0000:3620:	0000.0000 - Always empty.
;
; $0C - At $0000:3620:	Bank-$7F-Address - LOW BYTE
; $0D - At $0000:3620:	Bank-$7F-Address - HIGH BYTE
; $0C - At $0000:3620:	Bank-$7F-Address - BANK BYTE - ALWAYS #$7F!
;
; $10 - Intro Sequence:	A doublebyte-sized Timer - LOW BYTE
;	At $0000:3620:	A doublebyte-sized temporary storage - LOW BYTE
;			See $B3/$B4 for further detail
; $11 - Intro Sequence:	A Doublebyte-sized Timer - HIGH BYTE
;	At $0000:3620:	A doublebyte-sized temporary storage - High BYTE
;			See $B3/$B4 for further detail
;
;
; $13 - In Intro, used as a storage for the x-Position in the Mini-Train-Scenes.
;
; $20 - At $0000:3620:	Doublebyte-sized storage for $B7/$B8; gets multiplied with $22/$23, Result in $24/$25
; $21 - At $0000:3620:	Doublebyte-sized storage for $B7/$B8; gets multiplied with $22/$23, Result in $24/$25
; $22 - At $0000:3620:	Doublebyte-sized storage for $AD/$AE; gets mulitplied with $20/$21, Result in $24/$25
; $23 - At $0000:3620:	Doublebyte-sized storage for $AD/$AE; gets mulitplied with $20/$21, Result in $24/$25
; $24 - At $0000:3620:	Doublebyte-sized result of $20/$21 * $22/$23; Bits 3 to 0 are always 0
; $25 - At $0000:3620:	Doublebyte-sized result of $20/$21 * $22/$23
;
;
;
; $B1 - At $0000:3620:	yyyy.zzzz
;
;			In the beginning of TileMapBuilder, $1000 is stored in $B1 (and so $1001 in $B2).
;
;			y = Bit 7 to 4 become Bit 3 to 0 for $B5 (and Bit 4 to 1 for $B9)
;				They also become Bit 3 to 0 for $00
;			z = ?
;
; $B2 - At $0000:3620:	xxxx.yyyy
;
;			In the beginning of TileMapBuilder, $1000 is stored in $B1 (and so $1001 in $B2).
;
;			x = Bit 7 to 4 become Bit 3 to 0 for $B6
;			y = Bit 3 to 0 become Bit 7 to 4 for $B5
;
;
;
; $B3 - At $0000:3620:	xxyy.yzzz
;			****.*---
;			°°°°.----
;
;			In each run of the TileChunkLoop, $B3's value is replaced by $10's value.
;			$10's value itself is $1002's value.
;
;			x = Bit 7 and 6 become Bit 1 and 0 for $BA (VRAM Dest. Address - HIGH BYTE)
;			y = Bit 5 to 3 become Bit 7 to 5 for $B9 (VRAM Dest. Address - LOW BYTE)
;			z = ?
;			* = In each run of the TileChunkLoop, $10's value gets incremented by 8
;				TileChunkLoop is run $20 times.
;				By this, every constellation of Bits in these marked bits is
;				executed exactly once.
;				E. g. if $B3 is in the first loop run %0101.1001, it would be
;				%0101.0001 on the $20th loop run.
;				Bit 0 of $B4 gets of course incremented, too, at some point of the loop!
;			° = Bit 7 to 4 become Bit 3 to 0 for $B7 (= $20)
;
; $B4 - At $0000:3620:	++++.°°°°
;
;			In each run of the TileChunkLoop, $B4's value is replaced by $11's value.
;			$11's value itself is $1003's value.
;			$B4's value gets incremented a run of the loop. See * at $B3 for further detail.
;
;			+ = Bit 7 to 4 become Bit 3 to 0 for $B8 (= $21)
;			° = Bit 3 to 0 become Bit 7 to 4 for $B7 (= $20)
;
;
;
; $B5 - At $0000:3620:	yyyy.zzzz
;			---*.----
;			y = Bit 7 to 4 are Bit 3 to 0 of $B2
;			z = Bit 3 to 0 are Bit 7 to 4 of $B1
;				and become Bit 4 to 1 for $B9 (VRAM Dest. Address - LOW BYTE)
;			* = Bit 4 becomes Bit 2 for $BA (VRAM Destination Address - HIGH BYTE)
; $B6 - At $0000:3620:	0000.xxxx
;			0 = Always 0
;			x = Bit 3 to 0 are Bit 7 to 4 of $B2
;
;
;
; $B7 - At $0000:3620:	Bit 7 to 4 are Bit 3 to 0 of $B4
;			Bit 3 to 0 are Bit 7 to 4 of $B3
;			Gets stored in $20
; $B8 - At $0000:3620:	Bit 7 to 4 are Bit 3 to 0 of $B3
;			Bit 3 to 0 are ALWAYS 0
;			Gets stored in $21
;
;
;
; $B9 - At $0000:3620:	VRAM Destination Address - LOW BYTE
;			yyyz.zzz0
;			y = Bit 7 to 5 are Bit 5 to 3 of $B3
;			z = Bit 4 to 1 are Bit 3 to 0 of $00
;			0 = always 0
; $BA - At $0000:3620:	VRAM Destination Address - HIGH BYTE
;			0000.0xyy
;			0 = always 0
;			x = Bit 2 is Bit 4 of $B5
;			y = Bit 1 and 0 are Bit 7 and 6 of $B3
;
; $BB - At $0000:3620:	WRAM Destination Address
;			Is the sum of $B5/$B6 and $24/$25, multiplicated with 2
;

Natürlich ist da noch nicht alles drin. Ich muss wohl noch eine Stunde reinstecken.

[lytron]

Stunde 120
Disassembled: 215.156 / 1.048.576 Bytes (20,519%)
Gehört: Hiroki Kikuta - Seiken Densetsu 2 OST

Noch einmal, mit Gefühl. Und eher aus Langeweile, meine Winamp-Playlist neu zu bestücken, mit dem SoM-OST auffe Ohrn.
Der einzige "Outcome" all dieser Variablen sind im Endeffekt die Variablen $BB und $742/$752. Die bilden die VRAM- und die WRAM-Adressen, von wo nach wo etwas übertragen wird. Vielleicht kann ich das ganze ja sogar ein wenig runterbrechen, dass ich aus den "Eingabevariablen" die Endergebnisse im Kopf errechnen kann. Vielleicht.
Eingabevariablen sind nämlich, interessanterweise, auch nur vier bzw. fünf Byte. $1000 bis $1003 und $1008.
Mal schauen.

~~~
In Ordnung. Ich komme ein bisschen weiter, aber wirklich verständlich wird der Kram wohl erst, wenn ich ein Bildchen male.
Also mal ich ein Bildchen.
In Excel.
Warum auch nicht.
~~~
Bildchen fertig:

Schaubild TileMapBuilder.png (47.89 KiB) 5675 mal betrachtet

Und irgendwie, neeh, macht es nix übersichtlicher. Warum so kompliziert? Warum fünf Variablen, wenn man es mit vieren auch machen könnte!? Ich begreif es nicht...
Ich werde jetzt *irgendwie* diese Stunde zuende bringen.
~~~
Oh, okay, das ist noch wichtig:
$0742/$0743 erfüllen *zwei* Funktionen. Alles bis einschließlich der orangenen 0 sagen beim Transfer von WRAM zu VRAM, wo es hinmuss, während alles darunter (grün, blau) den Ort angibt, wo etwas innehalb des Temps gespeichert werden muss.
Keine Ahnung, ich benenne lieber jetzt noch ein paar Subroutinen um.
~~~
Hm. Gerade mal gesehen, $A4 wird in zwei Subroutinen vom großen Verzweiger als ein Jump-Table-Index genutzt. Das ist eine der drei Variablen, die zu Beginn des großen Verzweigers aus einer Liste geladen wird. Aus der ersten Liste, die die Subroutine konsultiert, übrigens.

Stunde rum, Resümee:
Ich hatte heute frei! Und ich habe den ganzen Tag diesem Projekt gewidmet!
Und es gibt am Ende des Tages kein Resultat, das mich zufrieden stellt!

Yeah, dafür hat man frei!

[lytron]

Stunde 121
Disassembled: 215.156 / 1.048.576 Bytes (20,519%)
Gehört: OC-Remixes zu Link's Awakening (Der Hauptteil der Remixes)

Mal schauen, ob ich heute und morgen noch Stunde 122 und 123 schaffe. Persönliche Zielsetzung, quasi.
Nachdem sich das alles gestern als nicht so sinnhaft erwiesen hat, quasi, versuche ich es mal an DieChinesischeMauer.

~~~
Ooookay. Zwei Minuten was gemacht.
Ich habe geguckt, wo die Subroutine aufgerufen wird, und was davor und danach passiert.
Sie wird zur Zeit nur einmal aufgerufen (es gibt einen zweiten Aufruf, genannt: "AnotherBrick", da "schaltet" man sich nach den ersten zehn, zwanzig Befehlen "dazu"), und danach wird ein DMA von WRAM, Pos. $7E4000 nach VRAM Pos. $3000 durchgeführt, wobei bei $3000 das Tileset für BG1/2 liegt.
Am Anfang von DieChinesischeMauer wird eine Adresse, die für den weiteren Verlauf der Subroutine wichtig ist, auf $7E4000 gesetzt.
... und ich hätte da jetzt eine Vermutung, was die Subroutine macht.
Übrigens: Der OC-Remix "Animal Village Greenwich Village" von BenCousins lohnt sich nicht. Für Anhänger jeglicher Musikrichtung.
~~~
Dieser Kram hat sich bis jetzt leichter gestaltet als der TileMapBuilder, wird aber wohl noch anziehen.
Das Ding war das, was gebraucht wurde, um den Schriftzug auf dem Titelbildschirm zu komprimieren, übrigense.
~~~
Gerade chunke ich die chinesische Mauer.
Wenn ihr euch daran erinnert, wie selbige Subroutine an Ihren Namen kam: Ich wusste nicht, was sie macht, und sie ist elendig lang.
Deshalb, wie erwähnt, chunke ich sie. Was ich damit meine ist. Ich fasse immer ungf. fünf bis zehn Befehle zusammen und sage, was sie machen. Ich forme aus den einzelnen Befehlen kleine "Sinneinheiten". Die haben zwar auch nicht viel Aussagekraft durch sichselbst ("Lade von [$76], speichere in [$79]"), sind für mich aber ziemlich verständlicher, da ich bei vielen Variablen schon weiß, was sie machen.
Weil sie hier, im Gegensatz zum TileMapBuilder, hundertpro nur jeweils *eine* Funktion haben.
~~~
Stunde rum, Resümee:
So gut wie auf die Sekunde genau bin ich mit dem Chunken fertig. Sieht jetzt so aus:

Code: Alles auswählen

; ROM: $0000:10EB
	DieChinesischeMauer:
	LDX #$4000.w			; Setting up an address for [$79]-commandos: $7E4000
	STX $79.b
	LDA #$7E.b
	STA $7B.b
	BRA Froschschenkelfresser
	
	; ROM: $0000:10F6
	AnotherBrick:
	STX $79.b				; Setting up an address for [$79]-commandos: X contains the address on bank $7E (WRAM)
	LDA #$7F.b
	STA $7B.b
	BRA Froschschenkelfresser	; Useless Line? Can be removed?
	
	Froschschenkelfresser:
	PHB
	LDA #$00.b
	LDX #$0000.w
	KonservenSamba:			; Clears 7E:2C00 to 7E:3BEF
	STA $7E2C00.l, X
	INX
	CPX #$0FEF.w
	BNE KonservenSamba
	
	; Setup $1C80/1 4/5/6/7 E/F
	LDX #$0FEE.w
	STX $1C8E.w
	LDY #$0000.w
	STY $1C80.w
	STY $1C84.w
	STY $1C86.w
	
	; Setup $1C82/3
	LDA [$76], Y
	STA $1C82.w			; Exit Value - Low byte
	INY
	LDA [$76], Y
	STA $1C83.w			; Exit Value - High byte
	LDY $76.b
	INY
	INY
	INY					; Note - Two bytes are loaded, and four INYs? Byte 3 and 4 are skipped?
	INY
	STY $76.b
	
	; Exit if $1C86 = $1C82
	SoOderSo:
	LDY $1C86.w
	CPY $1C82.w
	BEQ ChinesischerAnfang
	
	; Bit-Shift $1C80/1
	LSR $1C81.w			; $1C81 div 2, Byte pushed out of $1C81 into Carry Flag
	ROR $1C80.w			; Carry Flag transfered as MSB into $1C80
	
	; Branch if $1C81's LSB is 1
	LDA $1C81.w
	LSR a
	BCS SiebzehnVorwaerts	
	
	LDY $1C84.w
	LDA [$76], Y
	INY
	STY $1C84.w
	STA $1C90.w
	
	LDA #$FF.b
	STA $1C81.w
	LDA $1C90.w
	STA $1C80.w
	
	; Branch if $1C80's LSB is 0
	SiebzehnVorwaerts:
	LDA $1C80.w
	LSR a
	BCC ZweiDVorwaerts
	
	; Load Byte from [$76], store in $1C90 and [$79], increment both indices
	LDY $1C84.w
	LDA [$76], Y
	INY
	STY $1C84.w
	STA $1C90.w
	LDY $1C86.w
	STA [$79], Y
	INY
	STY $1C86.w
	
	LDA $1C90.w
	LDX $1C8E.w
	STA $7E2C00.l, X
	INX
	STX $1C8E.w
	LDA $1C8F.w
	AND #$0F.b
	STA $1C8F.w
	BRA SoOderSo
	
	ZweiDVorwaerts:
	; Load Byte from [$76], store in $1C88, increment index
	LDY $1C84.w
	LDA [$76], Y
	INY
	STY $1C84.w
	STA $1C88.w
	
	; Load Byte from [$76], store in $1C8A, increment index
	LDY $1C84.w
	LDA [$76], Y
	INY
	STY $1C84.w
	STA $1C8A.w

	; Store upper nybble of $1C8A as lower nybble of $1C89
	LSR a
	LSR a
	LSR a
	LSR a
	STA $1C89.w
	
	; Remove upper nybble of $1C8A and increment it twice
	LDA $1C8A.w
	AND #$0F.b
	INC a
	INC a
	STA $1C8A.w
	
	; Set Counter $1C8C to #$00 (Start Setup)
	LDA #$00.b
	STA $1C8C.w
	BRA NaechsterBefehlAusgelassen
	
	; Increment Counter $1C8C (recurring)
	GuggelGuggel:
	INC $1C8C.w
	
	NaechsterBefehlAusgelassen:
	; Prepare Load from RAM-TEMP-Index in A
	CLC
	LDA $1C88.w
	ADC $1C8C.w
	XBA
	LDA $1C89.w
	ADC #$00.b	; Seems useless, but pic is broken without - some Flag Stuff?
	AND #$0F.b
	
	; Transfer Load-from-RAM-TEMP-Index to X
	PHA
	XBA
	PHA
	PLX
	
	; Load from RAM TEMP, store in [$79] and $1C90, increment Store-Index
	LDA $7E2C00.l, X
	STA $1C90.w
	LDY $1C86.w
	STA [$79], Y
	INY
	STY $1C86.w
	
	; Store Loaded Value at a different place in RAM TEMP, increment Store-Index
	LDA $1C90.w
	LDX $1C8E.w
	STA $7E2C00.l, X
	INX
	STX $1C8E.w
	
	; Cut off upper nyblle of $1C8F (high byte for RAM-TEMP-Index)
	; keeps RAM-TEMP-Index in the borders of RAM-TEMP (not bigger than $0FFF)
	LDA $1C8F.w
	AND #$0F.b
	STA $1C8F.w
	
	; $1CBC = Counter, $1C8A = Limit
	; If limit is reached, leave this "bonus loop" and go on with the normal stuff.
	LDA $1C8C.w
	CMP $1C8A.w
	BNE GuggelGuggel
	BRL SoOderSo

Und die meisten OC-Remixes habe ich gleich wieder von der Festplatte geschmissen, übrigens.

[ChronoMoogle]

Haettest du mir nicht per Chat gesagt, was sie z.B. macht, waere ich nach dem lesen dieses Blogposts keinen Zinken schlauer
Eventuell solltest du das noch aufnehmen.