Disassemble Blog: Ihatovo Monogatari

[lytron]

Stunde 44
Disassembled: 45.177 / 1.048.576 Bytes (4,308%)
Gehört: Ween - Quebec

... weiter gehts.

Stunde rum, Resümee:
Oh, das ist so markig, wie die Prozente hier hochschießen.
Liegt daran, dass ich noch zwei (unkomprimierte) Tilemaps gefunden habe. Weiterhin habe ich ein halbes Dutzend Einträge der Jump Table hinzugefügt, was mich sehr freut, denn ich habe jetzt das Gefühl, wirklich vorwärts gekommen zu sein. Ich bin gespannt, was das alles ist, wenn ich mal am Wochenende/nächste Woche mich inhaltlich genauer damit auseinandersetzen werde.

[ikari_01]

Code: Alles auswählen

	JSL DerGeldVerbrenner		; $009042 = $0000:1042
	JSL SetzMalKaffeeAuf.l		; $009426 = $0000:1426
	BNE LuckyLoop
	BNE SpringInsFeld
	.DW BrummBrumm	; $EF5F = $0000:6F5F

BITTE MACH WEITER

[lytron]

Code: Alles auswählen

	JSL DerGeldVerbrenner		; $009042 = $0000:1042
	JSL SetzMalKaffeeAuf.l		; $009426 = $0000:1426
	BNE LuckyLoop
	BNE SpringInsFeld
	.DW BrummBrumm	; $EF5F = $0000:6F5F

BITTE MACH WEITER

Ich lache gerade Tränen über mich selbst (wohl auch aus Scham); ich hatte die Hoffnung, dass das keiner sieht...
Die Namen waren spontan entstanden, ich brauchte die Dinger und wusste nicht, was ich schreiben sollte.

Das ist wie mein Excel-VBA-Kurs, wo mein Instructor meinte: "Wählt immer selbsterklärende Variablennamen ", und dann zwei Tage später meinen Code vorne auf dem Projektor zeigte, wo dann die Variablen "helfi" und "helfi2" auftauchten...

Wo ich dich gerade hier am Schlafittchen habe: Kannst du mir den Anfang von SPCIntro4 erklären? (Der kritische Teil steht am Ende von Stunde 39 beschrieben). Ich verstehe das Akkumulator-Verkleinern, dann 16-Bit-Wert-Laden, dann XBA nicht...

[ikari_01]

A hat m.E. 8 Bit am Anfang von SPCIntro4. Die letzte Änderung des Statusregisters vorm Jump nach SPCIntro4 ist "SEP #$20" in SPCIntro3.
D.h. da ist dir das Disassemblen vermutlich verrutscht, in der Annahme, dass M=0.
Wenn man den Code

Code: Alles auswählen

B7 F0 C8 EB A9 00 80 0B [etc.]

von SPCIntro4 unter der Annahme M=1 disassembliert, bekommt man:

Code: Alles auswählen

	LDA [$F0], Y
	INY
	XBA
	LDA #$00.b
	BRA $0B			; $0005:1F9E "RepeatingLoop1Komma5"

Und insgesamt:

Code: Alles auswählen

; ROM: $0005:1F8B
	SPCIntro4:
	LDA [$F0], Y
	INY
	XBA
	LDA #$00.b
	BRA RepeatingLoop1Komma5
	RepeatingLoop3:
	XBA
	LDA [$F0], Y
	INY
	XBA
	RepeatingLoop2:
	CMP $2140.w
	BNE RepeatingLoop2
	INC a
	RepeatingLoop1Komma5:
	REP #$20
	STA $2140.w
	SEP #$20
	DEX
	BNE RepeatingLoop3
	RepeatingLoop4:
	CMP $2140.w
	BNE RepeatingLoop4
	RepeatingLoop5:
	ADC #$03.b
	BEQ RepeatingLoop5

Beispielsweise angenommen, das LDA [$F0], Y liefert ein #$5A zurück:
A=#$xx5A. (xx = alter Kram)
Nach dem XBA:
A=#$5Axx
nach dem LDA #$00.b:
A=#$5A00.
Und das wird dann in RepeatingLoop1Komma5 nach dem REP #$20 nach $2140/2141 geschrieben.

[lytron]

A hat m.E. 8 Bit am Anfang von SPCIntro4. Die letzte Änderung des Statusregisters vorm Jump nach SPCIntro4 ist "SEP #$20" in SPCIntro3.
D.h. da ist dir das Disassemblen vermutlich verrutscht, in der Annahme, dass M=0.

War da wohl betriebsblind. Jetzt kann ich weitermachen. Vielen lieben Dank für die umfassende Antwort!

[lytron]

Stunde 45
Disassembled: 45.408 / 1.048.576 Bytes (4,330%)
Gehört: Ihatovo Monogatari OST

... Ich werde jetzt den Fehler in meinem Disassemble im SPCIntro4 korrigieren, und danach werde ich mich wieder im Getümmel tümmeln, um weitere Daten zu bergen.
Domo arigato, ikari-sensei.

~~~
Oh, kultig. Nach dem ersten Auswerfen der Angel in die Jump Table ziehe ich gleich den nächsten dicken Fisch an Land. Woran ich das erkenne? Es fängt mit STZ $4200.w, STZ $212C.w an. Und das heißt... Bytes, Bytes, Bytes! ^.^
~~~
Hm. Reichlich merkwürdig. Warum wird im Laden von Grafikdaten plötzlich im SRAM rumgefeudelt?
Zwei Register werden gecleart.
~~~
Okay, nix mit großer Counter-Abfeierei. Altbekanntes. Das Kanji-Letterset.
~~~
Verrückte Welt. Ein Großteil meiner Zeit habe ich gerade auf eine neue Subroutine verbraten. Diese jene welche ist eine Mischung aus diesen Flexi-DMA-Geschichten (also: Verschiebe den Rückkehrpunkt im Stack um 8 Byte und behandle das Übersprungene als Daten) und dem Tilemap-Dekompressor (oder vielmehr: Schreiber), den ich am Wochenende ausgegraben habe. Leider kriege ich gerade die Funktionsweise nicht auf den Schirm... da hilft aller Kaffee nichts... :-/
~~~
Übrigens gehe ich davon aus, gerade mitten im Menü-Screen angekommen zu sein. Irgendwie. Hier werden bestimmte Bytes aus einem Save-Game-Slot geladen und jeweils dann dieselbe Subroutine aufgerufen. Ich fantasier mir zusammen, dass das der Byte ist, der über den Text für den Spielstand entscheidet (wobei das insofern sinn mächte, da das ja der einzige Wert ist, der aus einem Spielstand geladen werden muss, ohne dass der Spielstand geladen wurde). Mal schauen. Ein guter Punkt, um hier abzubrechen, zu kompilieren und dann beim nächsten Mal weiterzuschauen.

Stunde rum, Resümee:
Gerade noch etwas lustiges herausgefunden:
Diese Subroutine, die für die Spielstände aufgerufen wird, wird nur zweimal aufgerufen. Diese Subroutine befindet sich direkt im Anschluss an die aufrufende Soubroutine. Wortwörtlich "im Anschluss". Das heißt: Er ruft zweimal die Subroutine auf und läuft beim dritten Mal in denselben Codebereich hinein. Und das "RTS", das zweimal die aufgerufene Subroutine beendet, beendet beim dritten Durchlauf die aufrufende Subroutine selbst. Sehr geschickt gemacht, woll?

Zum Abschluss mal etwas Miyazawa-Spezifisches:
Hier das erste Video, was ich aus der Anime-Umsetzung von "Gauche the Cellist" gerade gesehen habe. Kawaiiiii. ^.^

[lytron]

Stunde 46
Disassembled: 45.701 / 1.048.576 Bytes (4,358%)
Gehört: Tomohito Nishiura - Professor Layton and the Mask of Miracle OST

... ich bin hier noch nicht fertig.

~~~
Stunde rum, Resümee:
*zipp* Schon ist die Stunde vorbei. Das war gerade ein recht großer Klimbim, mit dem ich noch nicht fertig geworden bin. Ein recht langer Text mit vielem Hin- und Hergespringe, und vielem Abgleichen von zwei Byte im SRAM.
Ich bin gespannt auf den Zeitpunkt, wenn ich herausfinde, ob das alles überhaupt Sinn macht.

[lytron]

Stunde 47
Disassembled: 45.870 / 1.048.576 Bytes (4,375%)
Gehört: Radiohead - Hail to the Thief. (The Gloaming.)

Mein Suppenhuhn tanzt den Schleiertanz.

Das war ein politisches Statement.

Im Subtext.

~~~
Gut, ich habe jetzt eine halbe Stunde auf den Abgleich einer ellenlangen Subroutine mit vielen Sprungmarken mit beknackten Namen verbracht. Das motiviert nicht unbedingt.
Asi war: Ich finde heraus, dass ein Branchbefehl einen Byte zu wenig hat, also die Sprungmarke einen Ein-Byte-Befehl weiterverschoben muss. So schaue ich denn nach und stelle fest... die Sprungmarke steht vor einem Zwei-Byte-Befehl... :-/
Glücklicherweise hatte ich nur einen Ein-Byte-Befehl vorher vergessen, aber einen Disassemblefehler kann man nie ausschließen. >_>
~~~

Stunde rum, Resümee:
Quasi nichts erreicht, mal wieder. Außer oben genanntem Abgleich konnte ich noch einen Jump-Table-Eintrag auseinandernehmen, der einige Variablen bedient hat und ansonsten noch zweimal die Subroutine aufgerufen hat, die ich vor einem oder zwei Tagen gefunden habe, die quasi den Tilemap-Dekompressor aufruft. Ich bin mal gespannt, herauszufinden, wo das alles hinführt.

[lytron]

Stunde 48
Disassembled: 45.870 / 1.048.576 Bytes (4,375%)
Gehört: Astor Piazzolla - Historia para un idolo, Volumen 2

Ich frage mich, wie viele versaute Anagramme ikari aus "Suppenhuhn" zustande kriegt?

~~~
Gut. Wir erreichen SPCIntro mit folgendem:
A: #$80, X: #$1870, Y: #$0004 --- $2142: #$0700
Dann geht es so weiter:

Code: Alles auswählen

	SPCIntro4:
	LDA [$F0], Y
	INY
	XBA
	LDA #$00.w
	BRA IntoTheRepeatingLoop
	RepeatingLoop3:
	XBA
	LDA [$F0], Y
	INY
	XBA
	RepeatingLoop2:
	CMP $2140.w
	BNE RepeatingLoop2
	INC a
	IntoTheRepeatingLoop:
	REP #$20
	STA $2140.w
	SEP #$20
	DEX
	BNE RepeatingLoop3
	RepeatingLoop4:
	CMP $2140.w
	BNE RepeatingLoop4
	RepeatingLoop5:
	ADC #$03.b
	BEQ RepeatingLoop5

Es wird der nächste, der fünfte Byte der Daten in A geladen (und Y inkrementiert). Das ist #$20. Mittels XBA in den versteckten Byte getauscht und #$00 nachgeladen, macht also:
A: #$(20)00, X: #$1870, Y: #$0005 --- $2142: #$0700
Dann IntoTheRepeatingLoop.
Dann wird A entschrumpft und in $2140 (und $2141) gespeichert.
~~~
Okay, grob überflogen tut es genau das, was im Tutorial bei wiki.superfamicom.org über den wirklichen Transfer-Akt beschrieben wird.
Dort heißt es:

Transferring Data
1. Write the first byte to be transferred to port $2141.
2. Write $00 to port $2140.
3. Wait for $2140 to be $00.
4. Write the next byte to be transferred to port $2141.
5. Increase the value in $2140 by 1, and write it back.
6. Wait for $2140 to be the same as the value written.
7. Goto step 4 until all bytes are transferred.

Das geschieht hier. Mit dem Speichern von #$2000 in $2140 (oder, um genau zu sein: #$00 in $2140 und #$20 in $2141) werden die ersten beiden Schritte ausgeführt.
Dann wird A verkleinert (und enthält jetzt #$00, mit #$20 in der Manteltasche).
X wird verkleinert. Der Vollständigkeit halber:
A: #$(20)00, X: #$186F, Y: #$0005 --- $2142: #$0701(?)
Da X nicht null ist, wird zu RepeatingLoop3 gebrancht.
Hier wird aus der Manteltasche geholt und in die Manteltasche gelegt:
A: #$(00)20, X: #$186F, Y: #$0005 --- $2142: #$0701(?)
Als nächstes wird der nächste Byte geladen (#$CD), Y inkrementiert, gemanteltascht (es ist wieder #$00 vorne), der wird mit $2140 verglichen und so lange gewartet gewartet, bis $2140 dem Inhalt von A entspricht (Schritt 3). Dann wird A inkrementiert und wir fangen wieder von vorne an:
A wird entschrumpft, der Inhalt von A (#$CD01) wird in $2140 und $2141 gespeichert (Schritt 4 und 5), wobei durch das Inkrementieren von A, das eben gerade erst geschehen ist, die Voraussetzung für Schritt 5 erfüllt wurde, und bei #$CD handelt es sich um den "next byte" aus Schritt 4.

Gut. Das machen wir jetzt noch #$186F + 1 mal, bis alles drüben ist. Dann... ja, was dann?

Code: Alles auswählen

	BVS SPCIntro4	; $0005:1F8B
	PLP
	LDA #$EB00.w
	RTS

Es wird #$EB00 in den Akkumulator geladen. Wohin geht dann die Reise...?
...
Zurück. Also, ganz zurück. Auf Bank 00. Wo genau wurde denn jetzt diese SR aufgerufen...? >_<
~~~
Okay, das ist seltsam.
Natürlich wird auf Bank 00 nichts noch "abschließend" zu diesem Prozess gemacht. Das heißt, der Abschluss muss noch innerhalb oben zerstückelter Prozedur geschehen.
wiki.superfamicom.org sagt dazu:

Ending Transfers
1. Write 0 to port $2141.
2. Write the address to begin execution to ports $2142 and $2143, with the low byte written to $2142.
3. Increase the value in $2140 by 2, and write it back.

Schritt 1 erfolgt - in meiner extrahierten SPC-Data-Datei ist $1874 bis $1876, also wo der Soundtransfer endet, je "#$00". Die anderen beiden Schritte würde ich so deuten, dass es dort auch direkt um die Ausführung geht, auch wenn das bei wiki.superfamicom.org explizit mit dem Ende des Transfers in Verbindung gebracht wird.

Stunde rum, Resümee:
Ich kann zwar theoretisch sagen, wo die Sounddaten zu ende sind, bin aber dennoch unschlüssig. Das Interessante ist, dass der nächste Byte nach dem Dreimal #$00 in $1874 bis $1876 ein "#$07" ist. Folglich ergibt ein 16-Bit-Load von $1876 (und $1877) ein "#$0700", was die Transfer-Beginn-Position war und vermutlich auch die Execution-Beginn-Position ist. Obs so ist? Wir werden sehen. In jedem Fall habe ich jetzt einiges zum Umbenennen und Kommentieren. Aber das... in der nächsten Stunde.
Überhaupt könnte ich jetzt wohl mindestens eine Stunde mit kleineren Ramsch-Arbeiten füllen. Hach ja, da geht die Zeit dahin... ~_~

(Dieses Mal keine Dateien, weil *nichts* geändert wurde)

[ikari_01]

Code: Alles auswählen

	BVS SPCIntro4	; $0005:1F8B
	PLP
	LDA #$EB00.w
	RTS

Es wird #$EB00 in den Akkumulator geladen. Wohin geht dann die Reise...?

Ich plädiere eher für:

Code: Alles auswählen

	PLP
	LDA #$00.b
	XBA
	RTS

8-Bit-Akkumulator und so.

[lytron]

Ich plädiere eher für:

Code: Alles auswählen

	PLP
	LDA #$00.b
	XBA
	RTS

8-Bit-Akkumulator und so.

Schon wieder...!

Danke, ist korrigiert.

[lytron]

Stunde 49
Disassembled: 45.870 / 1.048.576 Bytes (4,375%)
Gehört: Ween - Quebec

Umbenennen! Umbenennen!

~~~
Aufs Umbenennen habe ich gerade keine Lust mehr, dafür habe ich jetzt von einer dieser Adresse-im-Stack-verschiebenden, tilemap-dekompressierenden Subroutine herausgefriemelt, was die übergebenen Werte bewirken. Allerdings mit mäßigem Erfolg. Ich weiß, von wo die Laden, und kann mir denken, was sie tun, aber ich kann es nur prüfen, indem ich eine Kopie der Original-ROM mache, in dieser die Daten bei der Zieladresse zerkraute und mir dann im ZSNES anschaue, ob genau das kacke aussieht, was ich mir dachte.
Und dafür bin ich gerade nicht motiviert. *achselzuck* Vielleicht morgen.
~~~

Stunde rum, Resümee:
Es... tut sich nicht viel. Quasi.
Ich habe eine in letzter Zeit viel genutzte Subroutine jetzt herausgefunden. Ganz offensichtlich ist sie dazu da, den Kanji-Text hübsch darzustellen. Die Kanjis sind 16x16 Pixel bei einem Tileset, das aus 8x8-Pixeln besteht. Dementsprechend wird die besagte Subroutine dazu genutzt, die obere und untere Reihe der Tilemapeinträge in einem Stück durchschreiben zu können.
Das Tolle ist:

• Ich habe eine Subroutine, die den DMA-Transfer von Daten in den VRAM ermöglicht.
• Darauf sattelt eine Subroutine auf, die die DMA-Register mit Werten aus Direct-Page-Registern füttert
• Darauf sattelt eine Subroutine auf, die Tilemap-Daten entsprechend eines Direct-Page-Register-Werts in bestimmte längen schneidet und in einzelnen Zeilen übereinander anordnet und diese Daten in die entsprechenden Direct-Page-Register einsortiert
• Darauf sattelt jetzt noch eine Subroutine auf, die entsprechend eines Werts im SRAM unterschiedliche Tilemap-Daten-Stränge zum Zerschneiden übergibt (offensichtlich die Spielstandbeschriftungen)

Sehr interessanter Kram, eigentlich. Aber gerade fangen die Buchstaben wieder vor meinen Augen an zu tanzen... ich mach morgen weiter.

[lytron]

Stunde 50
Disassembled: 45.870 / 1.048.576 Bytes (4,375%)
Gehört: Heinz Erhardt

Zur Übersicht werde ich nun noch einmal von vorn beginnen, zu schauen, in welcher Reihenfolge die Jump-Table-Einträge uffjeroofn werden. Irgendwo bin ich vom rechten Weg abgekommen.

"Ich suche meinen Weg und-" - "Deeeiiinen Weg!? Alle Wege sind meeeiiine Wege."

~~~
$10 - Hector-Logo wird geladen.
$11 - Hector-Logo bleibt onscreen ($40 Frames lang).
$12 - Hector-Logo fadeout.
$16 - ... Hallali.
~~~
Problem bei Eintrag $16: Es geht wieder um Sound, also sollte ich mich zunächst damit auseinandersetzen.
~~~
So. Eintrag $16 hat gleich zwei Verweise auf die Bak $0A. Wir starten in den Ersten mit:
$F4: #$00 --- $F7: #$00 --- $0114: #$00 --- $0115: #$00
~~~
Gut, die Subroutine "WorkingWithF7" der Subroutine "DerSoundBrei" macht beim ersten Aufruf nichts.
$F4: #$00 --- $F7: #$00 --- $0114: #$00 --- $0115: #$00
~~~
Öhm, fein. Die zweite Subroutine macht auch nichts, aber selbiges rührt daher, dass $0114 und $0115 null sind. Dementsprechend wird es interessant zu sehen, was bei anderen Werten geschieht.
~~~
Hm. Komisch. Es werden hier gewisse Register geladen ($0110 und $0112), die vorher keine Werte bekommen haben... hm. Da der RAM ja zu Beginn komplett geleert wird, gehe ich davon aus, dass nichts passiert.
~~~
Gut. Der Rest von "DerSoundBrei" ist ebenfalls... interessant. Außer, dass die Variablen $F4 bis $F7 in die APU-Register gespeichert wird, wird danach darauf gewartet, dass $2141 dem Wert von $F5 entspricht, und dann wird die Subroutine beendet.
Da $F5 leer ist, wird damit theoretisch der Transfer von neuem beendet (weil, siehe vergangene Stunde, #$00 muss in $2141, um einen Transfer zu beenden). Ich schaue mal, was der zweite Verweis auf die Bank $0A tut.
~~~
$EF = #$01 --- $F3 = #$01 --- $102D = #$01.
$F4-$F7 = #$00.
Hm. Bei "FourAPULoops" wird etwas bezüglich $F7 und AND #$20 gemacht. $F7 kommt in $2143, das heißt der High Byte einer SPC-Adresse. Ist, äh, der Adressraum nicht nur von $0000 bis $1FFF? Wie auch immer.
~~~
Guuut...
SPCEnigmaPart1 ist jetzt noch das letzte, was ich machen werde.
Stunde rum, Resümee:
$F3 wird mit 3 multipliziert, währenddessen wird #$0A800F.l in $F5 bis $F7 geladen. Das Ergebnis der Multiplikation wird in Y gezogen, und Y als "Pointer" (ist das an dieser Stelle richtig verwandt?) für eine Tabelle verwandt, die ab besagter Adresse (Also: Bank $0A, ab $000F) liegt.Dort werden drei Werte heraus gezogen und in $F0 bis $F2 gespeichert. Und ich schäääätze, dass es sich bei den Daten in der Table ab $000F um Adressen von Sounddaten handelt. Einfach aufgrund der Tatsache, dass das, was früher mal SPCIntro1 hieß, danach aufgerufen wird.

Ob dem so ist... nächste Stunde.

[lytron]

Stunde 51
Disassembled: 45.870 / 1.048.576 Bytes (4,375%)
Gehört: Invalids - Eunoia

Wir springen hineijen in die Happy Happy Sunshine Welt der Bank 0A.
Habt ihr auch alle euren Maya-Kalender rebootet?
Antwort:
Das macht der von selber, man muss nur ein CLC machen.
~muhaha~


... beziehungsweise CLV, beziehungsweise...
... ach, egal.
~~~
Also. $F3 enthielt #$01. Das mal drei ergibt #$03, laut Adam Giant, einem deutschlandstämmigen amerikanischen Rechenschieber, der finanziell derart gutgestellt war, dass er in New York seine eigene Sportmannschaft...
... aber egal.
Folglich werden die Werte ab $0A8012 in die Register $F0 bis $F2 gespeichert werden. Dort steht... (übrigens steht ab $0A800F: "$00 $00 $00". Immer gut!): $13 $92 $0B. Das macht $0B9213, das macht $0005:9213 in der ROM.

Ich glaube... ich werde erstmal diese drei bzw. sechs Byte in meiner ROM nachtragen, und dann noch ein bisschen umbenennen. Meinertreu, ich bin ein wenig schusselig, heute.
~~~

Stunde rum, Resümee:
Damnit. Ich verliere hier so wahnsinnig viel Zeit.
Ich habe den alten SPC-Intro heavy kommentiert (auf Engelisch), und dabei festgestellt, dass ich was falsch verstanden hatte. Nicht nur haben die Sounddaten einen Vier-Byte-Header (Zieladresse/Datengröße), sondern auch einen Vier-Byte-"Footer", wobei die von mir festgestellten dreifach "$00" ein Teil dieses "Footers" sind. Einmal müssen die nämlich "$0000" enthalten, damit beim BVS-Befehl nicht nochmal der Transferloop angestoßen wird, und der restliche Doppelbyte ist die Startadresse. Wirklich sehr elegant geschrieben.
Weniger elegant, mehr gestelzt, mein englischer Kommentar:

Code: Alles auswählen

; ROM: $0005:1F77
	LoadSoundDataToSPC:
					; With SR, Data is transfered to the SPC.
					; In the first part (till the "BRA TransferByte..."), It's checked if the SPC is ready for
					; transfer. The whole other thing is relatively the same as explained at
					; http://wiki.superfamicom.org/snes/show/Transferring+Data+from+ROM+to+the+SNES+APU
					
					; The part at "SPC_Data_Header" is executed TWICE in the transfer. First time, at the very
					; beginning of the transfer, it extracts 4 Byte of a "header" of the data (two byte SPC destination
					; address, two byte data size of the transfer). I separated these headers from the real data in
					; my include-files.
					; 
					; The data size double-byte is transfered to 16-bit-X that is decremented in the transfer loop.
					;
					; Next is the transfer loop itself. It works with 16-bit-A. One Byte contains the real data, one byte
					; the constantly incremented counter value, both get stored into the corresponding registers in one
					; step.
					; As soon as X is 0, the transfer loop will be left. The last byte of data _IS ALWAYS_ $00, so not
					; only the 65816, but also the SPC700 gets to know that transfer has ended (*nudge* "The agreed
					; sign!!1").
					; After this, the SPC_Data_Header-thing is run a second time, this time reading a 4 byte "footer",
					; if you want so. The first two byte have to be $00 $00. They're TAXed, and if they're something
					; else, the 65816 would jump at the BVS into the transfer loop again, never-ever leaving it.
					; The last two byte are the start address of the music data. This seems to be always/in most cases
					; the same address as the one where the transfer started, so this will bear striking resemblance of
					; the two byte in the header. Afterwards, this is finished.
	PHP
	REP #$30.b
	LDY #$0000.w
	LDA #$BBAA.w
	SPC_BootLoop:		; When #$BBAA appears in $2140, then the SPC is booted
	CMP $2140.w
	BNE SPC_BootLoop
	SEP #$20.b
	LDA #$CC.b
	BRA SPC_Data_Header		; $0005:1FB1
; ROM: $0005:1F8B
	GettingToSPCTransfer:
	LDA [$F0], Y
	INY
	XBA
	LDA #$00.w
	BRA IntoTheTransferLoop
	SPCTransferLoop:			; Beginning of the REAL Transfer Loop
	XBA
	LDA [$F0], Y			; Load Data for transfer
	INY
	XBA
	RepeatingLoop2:
	CMP $2140.w
	BNE RepeatingLoop2
	INC a				; Increment "Counter value" for $2140
	IntoTheTransferLoop:
	REP #$20				; 16-bit A
	STA $2140.w			; With 16-bit A, the Counter-value gets stored in $2140 and the loaded data byte gets to $2141
	SEP #$20
	DEX
	BNE SPCTransferLoop		; End of the REAL Transfer Loop; as long as DEX doesn't make X = 0, loop
	RepeatingLoop4:
	CMP $2140.w
	BNE RepeatingLoop4
	RepeatingLoop5:
	ADC #$03.b
	BEQ RepeatingLoop5
; ROM: $0005:1FB1
	SPC_Data_Header:
	PHA
	REP #$20
	LDA [$F0], Y
	INY			
	INY
	TAX
	LDA [$F0], Y
	INY
	INY
	STA $2142.w
	SEP #$20
	CPX #$0001.w	; X contains the number of remaining bytes to transfer.
	LDA #$00.b		; If X isn't zero, the carry-flag gets set by the CPX above
	ROL a		; If carry-flag is set, A is now #$01, else it is #00
	STA $2141.w	; If #$00 is stored here, SPC is signalized that the transfer has ended, else not.
	ADC #$7F.b	; If Carry-Flag was set, A=$01 --- $01 + $7F = $80, Overflow-Flag is set, loop won't be left (BVS)
	PLA			; Thanks a lot to ikari_01 for his help on this! Otherwise I would have never understood this. >_<
	STA $2140.w
	RepeatingLoop1:
	CMP $2140.w
	BNE RepeatingLoop1
	BVS GettingToSPCTransfer	; $0005:1F8B
	PLP
	LDA #$00.b		; This line and the following clear the "invisible 8 Bit" of the Accumulator
	XBA
	RTS

Hm. ABER...
Aus ungeklärten Gründen funktioniert es nicht mehr. Also werde ich in der nächsten Stunde einen General-Abgleich vollziehen. Auf allen Bänken. Oder zumindest auf Bank $00 und $0A.

[lytron]

Stunde 52
Disassembled: 52.210 / 1.048.576 Bytes (4,979%)
Gehört: Invalids - Eunoia

Abgleichimon. Pokéball, los!

~~~
Hey. Ursprünglich wollte ich mal den Verlauf der Jump Table folgen.
Dadurch bin ich in den SPC-Kram gekommen.
Dadurch war ich ins Kommentieren des vorhanden SPC-Krams gekommen.
Und dadurch jetzt zum Abgleich.

Gut, dass ich mir jetzt einen Weg Zurück aus schriftlichen Brotkrumen gelegt habe.
~~~
Gut. Zwanzig Minuten für einen Abgleich, mit dem Ergebnis: Ich habe an einer Stelle dieses Sound-Transfer-Loops gesagt, er möge $00.w (=$0000) in einen 8-Bit-Akkumulator laden. Ich gehe mal davon aus, dass er brav #$00.b geladen hat, und die restlichen #$00.b für einen Opcode gehalten hat - BRK. Feierabend. Schön. Jetzt taucht wenigstens wieder das Hector-Logo auf und verschwindet. Jetzt kann ich ja wieder mit meinen Sounddaten experimentieren...
~~~
Okay, ich habe den Schrott nach dem "Footer" auskommentiert und das Hektorlogo erscheint trotzdem. Damit zähle ich diese Sounddaten jetzt als "decoded". Counter, spring! ^.^
~~~

Stunde rum, Resümee:
Ich... bin fast durch. Ich habe noch eine ellenlange SPC-Subroutine vor mir, die viel komisches tut, und dann habe ich den Soundkrams wohl erstmal hinter mir. Theoretisch. Theoretisch.