Meist verstehe ich nur die Verärgerung
... Hab null Ahnung von dem ganzen, aber mach immer wieder spaß durchzustöbern.
Kann dir nur auf die Schultern klopfen und sagen: "Gib nicht auf!" =)
Good job!
LG
Dravno
Disassemble Blog: Ihatovo Monogatari
Moderatoren: ikari_01, d4s, Redscorpion
-
Dravno
- SNES-Programmer
- Beiträge: 115
- Registriert: 10. Oktober 2012, 21:09
- +Positive Tradingpoints+: 1 von 1
Re: Disassemble Blog: Ihatovo Monogatari
Ich lese jeden deiner Einträge.
Meist verstehe ich nur die Verärgerung...
Hab null Ahnung von dem ganzen, aber mach immer wieder spaß durchzustöbern.
Kann dir nur auf die Schultern klopfen und sagen: "Gib nicht auf!" =)
Good job!
LG
Dravno
Meist verstehe ich nur die Verärgerung
... Hab null Ahnung von dem ganzen, aber mach immer wieder spaß durchzustöbern.
Kann dir nur auf die Schultern klopfen und sagen: "Gib nicht auf!" =)
Good job!
LG
Dravno
-
lytron
- Code Bro
- Beiträge: 2664
- Registriert: 12. August 2012, 20:18
- +Positive Tradingpoints+: 12 von 12
- Wohnort: ハノーファー区
- Kontaktdaten:
Re: Disassemble Blog: Ihatovo Monogatari
Hallo und danke, Dravno! 
Wenn hier allzu oft es so rüberkommt, als wäre ich verärgert, dann ist das...
... gut!
Freut mich, dass nicht nur Leute einen Blick riskieren, die voll und ganz auf das Thema eingefahren sind.
Entertainment for everyone! Yay!
Nicht wirklich, ich weiß, aber trotdem...
... Danke.
Wenn hier allzu oft es so rüberkommt, als wäre ich verärgert, dann ist das...
... gut!
Freut mich, dass nicht nur Leute einen Blick riskieren, die voll und ganz auf das Thema eingefahren sind.
Entertainment for everyone! Yay!
Nicht wirklich, ich weiß, aber trotdem...
... Danke.
pantalytron: ルトロンはくそのディスアセンブラだよ！
Perikles hat geschrieben:Man muss sich das mal reinziehen: die Idee ist scheiße, die theoretische Ausarbeitung ist scheiße, die praktische Umsetzung ist scheiße und der so entstehende Anspruch noch beschissener.
-
lytron
- Code Bro
- Beiträge: 2664
- Registriert: 12. August 2012, 20:18
- +Positive Tradingpoints+: 12 von 12
- Wohnort: ハノーファー区
- Kontaktdaten:
Re: Disassemble Blog: Ihatovo Monogatari
Ich hab den Kiddo ganz dolle genervt, da hat er für mir das hier rausgesucht:
pantalytron: ルトロンはくそのディスアセンブラだよ！
Perikles hat geschrieben:Man muss sich das mal reinziehen: die Idee ist scheiße, die theoretische Ausarbeitung ist scheiße, die praktische Umsetzung ist scheiße und der so entstehende Anspruch noch beschissener.
-
lytron
- Code Bro
- Beiträge: 2664
- Registriert: 12. August 2012, 20:18
- +Positive Tradingpoints+: 12 von 12
- Wohnort: ハノーファー区
- Kontaktdaten:
Re: Disassemble Blog: Ihatovo Monogatari
Kann hier wer japanisch?
Ich habe mal diese Inhaltsangaben aus einem japanischen Blog zu der Satellaview-Variante des Spiels gefunden. Leider barriert die Sprachbarriere.
Barrierenartig.
Und Google-Translate hilft nicht so wirklich.
Source
Source
Ich habe mal diese Inhaltsangaben aus einem japanischen Blog zu der Satellaview-Variante des Spiels gefunden. Leider barriert die Sprachbarriere.
Barrierenartig.
Und Google-Translate hilft nicht so wirklich.
* 1997/ 3/ 2 *
☆ＢＳイーハトーヴォ物語 第１夜
第１章「カイロ団長」
賢治さんの手帳を探すことになった主人公は、まず「アリの花畑」に向かうことになりました。
そこで聞いた話は、カイロ団長に関する噂。
アマガエル相手にお酒を売るお店を出しているトノサマガエルですが、あまり街の評判は良くないようです。
手帳は見つかるのでしょうか？
第２章「虔十公園林」
次に向かったのは虔十という少年のいる村。
行ってみると、どうやら大切にしていた杉の苗を盗まれてしまったようです。
手帳も大事ですが、可哀相な虔十も放ってはおけません。
さて、杉の苗は無事見つかるでしょうか？
* 1997/ 3/ 9 *
☆ＢＳイーハトーヴォ物語 第２夜
第３章「土神ときつね」
手帳の１冊を、どうやらきつねが拾ったようです。
きつねの住む土神の森へ行くと、そこには１本の美しい樺の木がありました。
どうやら、土神は樺の木に心を寄せている様子。
何事も起こらないと良いのですが……。
第４章「グスコーブドリの伝記」
今度は、賢治さんが度々立ち寄るという、火山局を訪ねてみることにしました。
そこには、街を襲う寒波に立ち向かおうとしている青年、グスコーブドリの姿がありました。
さて、どうやったらこの寒さから街を救うことができるでしょうか？
* 1997/ 3/16 *
☆ＢＳイーハトーヴォ物語 第３夜
第５章「オツベルと象」
イーハトーヴォの商人オツベルが手帳を集めているという情報を耳にしました。
行ってみると、そこには１匹の白象がいます。
オツベルは、どうやら白象を言いくるめて、こき使おうというつもりのようです。
白象は平気な顔で仕事をこなしていましたが……。
第６章「セロ弾きのゴーシュ」
イーハトーヴォの街は音楽祭一色です。
ゴーシュの金星楽団も、コンクール優勝目指して猛練習。
ところが、どうもゴーシュの調子がよろしくありません。
コンクールはもうすぐなのに、ゴーシュはうまくセロを弾くことができるのでしょうか？
~~~* 1997/ 3/23 *
☆ＢＳイーハトーヴォ物語 第４夜
第７章「雪渡り」
手帳もあと残すところ１冊なのですが、だんだん手がかりもなくなってきました。
たまたま訪れた雪渡りの村で、主人公は１匹のきつねと少年たちに会います。
どうやら、そろそろきつねの幻灯会があるらしいのです。
大人には行くことは許されないというのですが……。
最終章「銀河鉄道の夜」
ようやく全ての手帳が揃いました。
賢治さんからの手紙には、後生車の地へ来いとあります。
クーボー博士によると、それはどうも「幻想第４次」への入口だということでした。
さあ、この先主人公を待ち受けているのはどんな世界なのでしょう？
Source
* 1997/ 5/ 4 *
☆ＢＳイーハトーヴォ物語（再）第１夜
第１章「カイロ団長」
賢治さんの手帳を探すことになった主人公は、まず「アリの花畑」に向かうことになりました。
そこで聞いた話は、カイロ団長に関する噂。
アマガエル相手にお酒を売るお店を出しているトノサマガエルですが、あまり街の評判は良くないようです。
手帳は見つかるのでしょうか？
第２章「虔十公園林」
次に向かったのは虔十という少年のいる村。
行ってみると、どうやら大切にしていた杉の苗を盗まれてしまったようです。
手帳も大事ですが、可哀相な虔十も放ってはおけません。
さて、杉の苗は無事見つかるでしょうか？
◎今週のヒント
「ホテルの支配人さん」
と
「井戸端の男の子たち」
手帳の中身が読めるようがんばってくださいね。
* 1997/ 5/11 *
☆ＢＳイーハトーヴォ物語（再）第２夜
第３章「土神ときつね」
手帳の１冊を、どうやらきつねが拾ったようです。
きつねの住む土神の森へ行くと、そこには１本の美しい樺の木がありました。
どうやら、土神は樺の木に心を寄せている様子。
何事も起こらないと良いのですが……。
第４章「グスコーブドリの伝記」
今度は、賢治さんが度々立ち寄るという、火山局を訪ねてみることにしました。
そこには、街を襲う寒波に立ち向かおうとしている青年、グスコーブドリの姿がありました。
さて、どうやったらこの寒さから街を救うことができるでしょうか？
◎今週のヒント
「市役所の受付の人」
と
「カルボナード島の船頭さん」
手帳の中身が読めるようがんばってくださいね。
* 1997/ 5/18 *
☆ＢＳイーハトーヴォ物語（再）第３夜
第５章「オツベルと象」
イーハトーヴォの商人オツベルが手帳を集めているという情報を耳にしました。
行ってみると、そこには１匹の白象がいます。
オツベルは、どうやら白象を言いくるめて、こき使おうというつもりのようです。
白象は平気な顔で仕事をこなしていましたが……。
第６章「セロ弾きのゴーシュ」
イーハトーヴォの街は音楽祭一色です。
ゴーシュの金星楽団も、コンクール優勝目指して猛練習。
ところが、どうもゴーシュの調子がよろしくありません。
コンクールはもうすぐなのに、ゴーシュはうまくセロを弾くことができるのでしょうか？
◎今週のヒント
「街に帰ったらすぐにかまネコ」
と
「街の西の家の男とは２回話す」
手帳の中身が読めるようがんばってくださいね。
~~~* 1997/ 5/25 *
☆ＢＳイーハトーヴォ物語（再）第４夜
第７章「雪渡り」
手帳もあと残すところ１冊なのですが、だんだん手がかりもなくなってきました。
たまたま訪れた雪渡りの村で、主人公は１匹のきつねと少年たちに会います。
どうやら、そろそろきつねの幻灯会があるらしいのです。
大人には行くことは許されないというのですが……。
最終章「銀河鉄道の夜」
ようやく全ての手帳が揃いました。
賢治さんからの手紙には、後生車の地へ来いとあります。
クーボー博士によると、それはどうも「幻想第４次」への入口だということでした。
さあ、この先主人公を待ち受けているのはどんな世界なのでしょう？
◎今週のヒント
「カイロ酒場のアマガエル」
と
「黒ネコと話し忘れるな」
手帳の中身が読めるようがんばっ
てくださいね。
Source
pantalytron: ルトロンはくそのディスアセンブラだよ！
Perikles hat geschrieben:Man muss sich das mal reinziehen: die Idee ist scheiße, die theoretische Ausarbeitung ist scheiße, die praktische Umsetzung ist scheiße und der so entstehende Anspruch noch beschissener.
-
lytron
- Code Bro
- Beiträge: 2664
- Registriert: 12. August 2012, 20:18
- +Positive Tradingpoints+: 12 von 12
- Wohnort: ハノーファー区
- Kontaktdaten:
Re: Disassemble Blog: Ihatovo Monogatari
Stunde 63
Disassembled: 145.048 / 1.048.576 Bytes (13,833%)
Gehört: Meine Familie im Wohnzimmer
Familientag! Familientag!
Was könnte es schöneres geben, als am Computer zu sitzen und zu arbeiten!
~~~
Die innere der beiden Subroutinen von gestern, zur Zeit "DasBaskenland" genannt, macht folgendes:
Der Wert in A wird mittels dreifachem ASL mit 8 multipliziert, dann in $02 zwischen gespeichert, in X gezerrt und als Index genutzt, um ab $04B000 was zu laden. Das Geladene wird geANDet, mit #$00FF, das heißt: Dank 16bit-Akkumulator werden 16bit geladen, von Interesse ist aber nur der erste der beiden Byte, also schmeißen wir den zweiten mittels AND #$00FF wech.
Selbigen Wert multiplizieren wir mit 32 (fünf mal ASL a und packen ihn in X. Wir speichern #$10 in $00 und #$00 in $01.
Schon betreten wir den ersteren, größeren Loop:
In diesem jenen wird der eben gezweiunddreißigfachte, ge-x-te Wert als Versatz genommen, um ab $04A3E0 zu laden. Y, der weiter oben geleerte Index, wird zum Speichern in der Upper Class des CGRAM-Temp genutzt. Selbiges geschieht in dem kleineren, inneren Loop ("BaskenHoola"). "Baskenhoola" wird verlassen, wenn $00 null erreicht. $00 enthält #$10, also #16, also eine 16-farbige, doppelbytegroße Palette, also eine Platte groß genug für einen Sprite, dann geht es bereits zum Ende des größeren Loop, "BaskenHoop".
Offensichtlich ist "BaskenHoop", wie ich gestern bereits verlauten ließ, dazu da, eine ganze halbe CGRAM-Größe, namentlich die obere, zu befüllen. Das zeigt sich dadurch, dass der "BaskenHoop" dadurch durchbrochen wird, dass Y = #$100, also #256, also 512 / 2, also die Hälfte des CGRAMs in Größe, verlassen wird.
~~~
So. Das Mittagessen hinter mich gebracht... und nebenbei die Grundzüge von Skat gelernt. Weiter.
Wie sieht der "BaskenHoop" im zweiten Durchlauf aus?
Es wird nur der einmal incrementete $02 genommen.
Lassen wir es noch einmal kurz auf uns wirken.
Es werden zwei Tabellen bei $04B000 und $04A3E0 ausgelesen. Der Wert in $B000 wird genommen, mal 32 genommen, und dann mit $A3E0 als geladen. Das heißt, ab $A3E0 sind die Paletten abgelegt, ab $B000 liegt die Tabelle für die Palettensets. FOLGLICH:
Kann in 8er-Schritten anvisiert werden, aber es werden immer 16 in einer Reihe übertragen. Soll heißen:
Ich sage "null": Er überträgt 0 - 15. Ich sage "eins": Er überträgt 8 - 23 und so weiter. Guuut... die Differenz von $A3E0 und $B000 beträgt $C20. Daaa... immer $10 Byte übertragen werden, heißt das, dass bei der Tabelle die Einträge zwischen $00 und $C1 liegen müssen, daaa ab einem Eintrag mit $C2 oder höher Werte ab $B000 übertragen würden, was ja ganz offensichtlich keine Farbwerte mehr sind.
Folglich habe ich dann damit wieder was zum Rippen und wieder einfügen.
~~~
Oh, ähm, mein Fehler. Es sind $20 Byte, folglich sind es nicht $C2 Paletten, sondern nur die Hälfte: $61, also 91, also Palette $00 bis $60.
Stunde rum, Resümee:
Gut, diese Stunde war über den Tag hinweggestückelt, aber es war eine Stunde, jawollja!
Ich habe jetzt noch die Paletten alle eingefügt, es fehlen nur noch die Palettensets direkt im Anschluss. Nääächstes Mal...
Disassembled: 145.048 / 1.048.576 Bytes (13,833%)
Gehört: Meine Familie im Wohnzimmer
Familientag! Familientag!
Was könnte es schöneres geben, als am Computer zu sitzen und zu arbeiten!
~~~
Die innere der beiden Subroutinen von gestern, zur Zeit "DasBaskenland" genannt, macht folgendes:
Code: Alles auswählen
DasBaskenland:
REP #$30.b
ASL a
ASL a
ASL a ; $001E * 8 = $00F0
STA $02.b
LDY #$0000.w
BaskenHoop:
LDX $02.b
LDA $04B000.l, X ; $04B000 = $0002:3000
AND #$00FF.w ; = 005D
ASL a
ASL a
ASL a
ASL a
ASL a ; = 0BA0 (*32)
TAX
LDA #$0010.w
STA $00.b
BaskenHoola:
LDA $04A3E0.l, X ; =
STA $0900.w, Y
STA $0B00.w, Y
INX
INX
INY
INY
DEC $00.b
BNE BaskenHoola
INC $02.b
CPY #$0100.w
BNE BaskenHoop
LDA #$0000.w
SEP #$20.b
RTLSelbigen Wert multiplizieren wir mit 32 (fünf mal ASL a und packen ihn in X. Wir speichern #$10 in $00 und #$00 in $01.
Schon betreten wir den ersteren, größeren Loop:
In diesem jenen wird der eben gezweiunddreißigfachte, ge-x-te Wert als Versatz genommen, um ab $04A3E0 zu laden. Y, der weiter oben geleerte Index, wird zum Speichern in der Upper Class des CGRAM-Temp genutzt. Selbiges geschieht in dem kleineren, inneren Loop ("BaskenHoola"). "Baskenhoola" wird verlassen, wenn $00 null erreicht. $00 enthält #$10, also #16, also eine 16-farbige, doppelbytegroße Palette, also eine Platte groß genug für einen Sprite, dann geht es bereits zum Ende des größeren Loop, "BaskenHoop".
Offensichtlich ist "BaskenHoop", wie ich gestern bereits verlauten ließ, dazu da, eine ganze halbe CGRAM-Größe, namentlich die obere, zu befüllen. Das zeigt sich dadurch, dass der "BaskenHoop" dadurch durchbrochen wird, dass Y = #$100, also #256, also 512 / 2, also die Hälfte des CGRAMs in Größe, verlassen wird.
~~~
So. Das Mittagessen hinter mich gebracht... und nebenbei die Grundzüge von Skat gelernt. Weiter.
Wie sieht der "BaskenHoop" im zweiten Durchlauf aus?
Es wird nur der einmal incrementete $02 genommen.
Lassen wir es noch einmal kurz auf uns wirken.
Es werden zwei Tabellen bei $04B000 und $04A3E0 ausgelesen. Der Wert in $B000 wird genommen, mal 32 genommen, und dann mit $A3E0 als geladen. Das heißt, ab $A3E0 sind die Paletten abgelegt, ab $B000 liegt die Tabelle für die Palettensets. FOLGLICH:
Kann in 8er-Schritten anvisiert werden, aber es werden immer 16 in einer Reihe übertragen. Soll heißen:
Ich sage "null": Er überträgt 0 - 15. Ich sage "eins": Er überträgt 8 - 23 und so weiter. Guuut... die Differenz von $A3E0 und $B000 beträgt $C20. Daaa... immer $10 Byte übertragen werden, heißt das, dass bei der Tabelle die Einträge zwischen $00 und $C1 liegen müssen, daaa ab einem Eintrag mit $C2 oder höher Werte ab $B000 übertragen würden, was ja ganz offensichtlich keine Farbwerte mehr sind.
Folglich habe ich dann damit wieder was zum Rippen und wieder einfügen.
~~~
Oh, ähm, mein Fehler. Es sind $20 Byte, folglich sind es nicht $C2 Paletten, sondern nur die Hälfte: $61, also 91, also Palette $00 bis $60.
Stunde rum, Resümee:
Gut, diese Stunde war über den Tag hinweggestückelt, aber es war eine Stunde, jawollja!
Ich habe jetzt noch die Paletten alle eingefügt, es fehlen nur noch die Palettensets direkt im Anschluss. Nääächstes Mal...
- Dateianhänge
-
- Stunde 63.rar
- (133.93 KiB) 147-mal heruntergeladen
pantalytron: ルトロンはくそのディスアセンブラだよ！
Perikles hat geschrieben:Man muss sich das mal reinziehen: die Idee ist scheiße, die theoretische Ausarbeitung ist scheiße, die praktische Umsetzung ist scheiße und der so entstehende Anspruch noch beschissener.
-
lytron
- Code Bro
- Beiträge: 2664
- Registriert: 12. August 2012, 20:18
- +Positive Tradingpoints+: 12 von 12
- Wohnort: ハノーファー区
- Kontaktdaten:
Re: Disassemble Blog: Ihatovo Monogatari
Stunde 64
Disassembled: 145.048 / 1.048.576 Bytes (13,833%)
Gehört: Kante - Zombi
Die Sprite-Palettenset-Tabelle muss noch "übergesetzt" werden. Umgetopft, sozusagen.
~~~
Ich gehe mal einfach aufgrund der Struktur der Bytes davon aus, dass diese Tabelle $30 Einträge hat.
~~~
Ich habe nicht den blassesten Schimmer, weshalb dort an dieser einen Stelle eine Vier in eine der SPC-Variablen geschrieben wird. Ich vermute und ich hoffe, dass es einfach nur der "Auslösebefehl" ist, die Musik zu starten. Aber so wirklich geneigt, mich damit auseinanderzusetzen, bin ich nicht.
~~~
Ach, Andie MacDowell ist diese Schnäpfe aus der L'Oréal-Werbung.
~~~
So. Wie man denn dann an solchen Aussagen sieht: Es fällt mir schwer, etwas sinnhaftes in die Arbeitszeit gedrückt zu bekommen. Meine Ömme verweigert sich jeglichem Verständnis der verbliebenen Subroutinen des aktuellen Jump-Table-Eintrags. Es handelt sich um viele Umformungen von unbekannten Variablen, die abschließend scheinbar u. a. dafür genutzt werden, für einen flexiblen Transfer eines Teils des WRAMs genutzt zu werden. Zu dumm, dass Buchstaben beginnen, auf dem Bildschirm zu tanzen, wenn ich sie mir anschaue.
Das ist bei den Zweit-Controller-Subroutinen glücklicherweise nicht so, also versuche ich mich mal an diesen.
~~~
Stunde rum, Resümee:
Wowy, wie... unproduktiv. Okay, ich habe diese Tabelle drin, aber ansonsten nur Fragezeichen in meinem Kopf. Wirr. Nur wirr.
Aber, das ist wohl die gute Nachricht: Es funktioniert wirklich, mittels Start, Select und den vier Farbbuttons den SRAM zu löschen.
Disassembled: 145.048 / 1.048.576 Bytes (13,833%)
Gehört: Kante - Zombi
Die Sprite-Palettenset-Tabelle muss noch "übergesetzt" werden. Umgetopft, sozusagen.
~~~
Ich gehe mal einfach aufgrund der Struktur der Bytes davon aus, dass diese Tabelle $30 Einträge hat.
~~~
Ich habe nicht den blassesten Schimmer, weshalb dort an dieser einen Stelle eine Vier in eine der SPC-Variablen geschrieben wird. Ich vermute und ich hoffe, dass es einfach nur der "Auslösebefehl" ist, die Musik zu starten. Aber so wirklich geneigt, mich damit auseinanderzusetzen, bin ich nicht.
~~~
Ach, Andie MacDowell ist diese Schnäpfe aus der L'Oréal-Werbung.
~~~
So. Wie man denn dann an solchen Aussagen sieht: Es fällt mir schwer, etwas sinnhaftes in die Arbeitszeit gedrückt zu bekommen. Meine Ömme verweigert sich jeglichem Verständnis der verbliebenen Subroutinen des aktuellen Jump-Table-Eintrags. Es handelt sich um viele Umformungen von unbekannten Variablen, die abschließend scheinbar u. a. dafür genutzt werden, für einen flexiblen Transfer eines Teils des WRAMs genutzt zu werden. Zu dumm, dass Buchstaben beginnen, auf dem Bildschirm zu tanzen, wenn ich sie mir anschaue.
Das ist bei den Zweit-Controller-Subroutinen glücklicherweise nicht so, also versuche ich mich mal an diesen.
~~~
Stunde rum, Resümee:
Wowy, wie... unproduktiv. Okay, ich habe diese Tabelle drin, aber ansonsten nur Fragezeichen in meinem Kopf. Wirr. Nur wirr.
Aber, das ist wohl die gute Nachricht: Es funktioniert wirklich, mittels Start, Select und den vier Farbbuttons den SRAM zu löschen.
pantalytron: ルトロンはくそのディスアセンブラだよ！
Perikles hat geschrieben:Man muss sich das mal reinziehen: die Idee ist scheiße, die theoretische Ausarbeitung ist scheiße, die praktische Umsetzung ist scheiße und der so entstehende Anspruch noch beschissener.
-
lytron
- Code Bro
- Beiträge: 2664
- Registriert: 12. August 2012, 20:18
- +Positive Tradingpoints+: 12 von 12
- Wohnort: ハノーファー区
- Kontaktdaten:
Re: Disassemble Blog: Ihatovo Monogatari
Stunde 65
Disassembled: 145.048 / 1.048.576 Bytes (13,833%)
Gehört: Harmony of a Hunter - 101% Run (disc 1)
Kennt jemand das Gameboy-Spiel "Mole Mania"? Ich meine, außer wrampi, der das sicherlich dreifach in seiner Sammlung hat. Ich kenne es nicht. Eigentlich nur von Screenshots aus der Club Nintendo, hah.
Wie dem auch sei, ich bin per Zufall auf ein Lied aus dem Soundtrack gestoßen. Und das ist gerade mal eins der besten Lieder für den Gameboy, die ich gehört habe. Woah. Hätte ich nie gedacht.
Ich habe vorhin zunächst einmal probeweise mir den Sourcecode angeguckt, ob ich heute für die wirre Subroutine mehr Verständnis zeigen kann; denn, wenn nicht, hätte ich mich nun zuerst um das gekümmert, was ich sowieso tun muss...
... aber es ist geglückt. Gleich dazu mehr.
Vorher noch etwas in eigener Sache:
Super-Metroid-Spielern sei dieser Remix aus "Harmony of a Hunter - 101% Run" sehr ans Herz gelegt. Die Maridia-Theme in Bombastklassik, allerdings wirklich spooky inszeniert. Und jeder, der ordentlich Wumms im niederfrequenten Bereich seiner Anlage hat, sollte das mal auf Über-Zimmerlautstärke testen. Meine Empfehlung.
~~~
So.
Die Subroutine des Tages läuft noch unter dem Namen "FischAmHaken".
Ich habe mir den Spaß gemacht, an das Ende der Subroutine zu gucken. Ich stelle eine These auf, der der geneigte, mehrerfahrene ASM-Tüftler_01 widersprechen mag oder nicht.
These: Im Zweifelsfall sollte man bei mangelndem Verständnis eines (ASM-)Programms hinten anfangen, es zu untersuchen.
Argumentation: Meist steht am Ende der direkte Verwendungszweck und vorab mag ein variablenumformendes Geplänkel in verschiedenartiger Dimensioniertheit das Verständnis des unbedarften Lesers verhüllen. (Stimmt, in der Sendung gestern war Malmsheimer wieder zu Gast...)
Also schau ich auf das Ende:
Dieser Teil nämlich stellt sich als sehr einfach dar.
Zunächst zu den aufgerufenen Subroutinen: Die "BigChain" ist eine Kette von weiteren Subroutinenaufrufen (hence the name), die allesamt sich darum kümmern, jede DMA-Subroutine aufzurufen und nachher die Bildschirm-Einstellungen zu updaten. Das bedeutet, mit "BigChain" werden alle vorherigen Änderungen "gespeichert", bzw. in die Tat umgesetzt und letztendlich sichtbar gemacht.
Das reguläre "PrepVDMA" nutzt die Inhalte der Variablen $00 bis $06 und füllt damit die DMA-Kanäle (bzw. die für dieses Programm geschriebene DMA-Warteschlange im RAM).
"PrepVDMAplus" nun ist dem regulären "PrepVDMA" als "ergänzender Intro" vorgeschaltet und speichert einfach nur X und Y in die Variablen $00 und $02 (da 16bit = $00-$03). Diese Sache mit dem "ergänzenden Intro" begegnet mir hier häufiger und ist etwas, was ich mir merken sollte - in Masse betrachtet kann man durch die ganzen dadurch wegfallenden Branch-Befehle auch Speicher sparen.
So. In jedem Fall kann ich über das Ende von "FischAmHaken" sagen: es werden zwei DMAs durchgeführt, beide übertragen $800 Byte (LDX #$0800, STX $05.b), beide haben als Bank der Quellmaterial-Adresse die obere Bank des RAM (LDA #$7F.b, STA $04.b), der Rest der Ursprungsadresse wird jeweils vor JSL PrepVDMAplus.l in Y geladen ($B000 bzw. $B800).
Soweit verständlich. Das entscheidende ist die Zieladresse. Diese wird für die erste Hälfte aus $12, für die zweite Hälfte aus $14 entnommen. Ich könnte mir durchaus vorstellen, dass sie wieder einmal direkt hintereinander in den VRAM eingepflanzt werden, aber zumindest diese Möglichkeit besteht, dass das beide Hälften an unterschiedliche Stellen gehen.
Aufgrund der bisherigen Ermangelung an Tilemaps und der Übertragungsbreite von $800 gehe ich davon aus, dass hier gleich Tilemaps aus dem ROM geladen werden und wie ein preiswerter Weihnachts-Kasslerbraten mit Prittstift aus Streifen und Endstücken zusammengepappt wird und anschließend im VRAM auf 200° erhitzt... *hust*
Schauen wir.
Den gesamten Rest von "FischAmHaken" kann/muss ich hier in einem Rutsch darbieten:
Fangen wir oben an:
Die BigChain wird aufgerufen; vermutungshalber, um die eventuellen Warteschlangen-Eintragen loszuwerden. Danach ein wenig Variablen-Vorgeplänkel, dass sich genauer zu betrachten mir verbietet, um nicht dem Wahn eines Maxwell Roivas anheim zu fallen (siehe Stunde 64).
Der Grund für den fast-Whole-In-One ist der nachfolgende größere Loop "HomeFishy". Versuch ich mich da auch mal im Rückwärtig-Auseinandernehmen.
PLA / DEC a erklärt dann damit schon einmal einen Teil des Vorgeplänkels.
Der Wert in A, der zu beginn auf den Stack gepusht wird, namentlich #$20, ist schlichtweg der Loopcounter. Also: Es wird zweiundreißig Mal, in Zahlen: $20 Mal, der Loop durchlaufen. (this joke never gets old).
Öööh... fein, ab da wirds dann doch komisch.
$10 wird geladen, 8 addiert, wieder in $10 gespeichert. Jetzt wird $0742 geladen. Glorioserweise ist das eine mir unbekannte Variable. Schlaulicherweis' schaue ich heute aber mal in meine ROM Map und stelle fest, womit ich nicht gerechnet hatte - Das wird ein Eintrag in der DMA-Pipeline sein. Um dessen Inhalt abschätzen zu können, müsste ich mich wohl wieder mit der DMA-Subroutine selbst auseinandersetzen. Hm. Also machen wir mal weiter.
Weshalb dorte in AND #$6C00 steht, kann ich mir fast schon denken. Aber machen wirs zunächst mal binär: AND #%0110.1100.0000.0000.
Hm. Das war nicht, womit ich rechnete. Aber das ist nicht schlimm. Meine Vermutung ist nicht widerlegt, aber trotzdem sollte ich sie nicht darlegen, weil sie nicht bewiesen ist.
Gut, gehen wir weiter vorwärts-rückwärts. Ab dem LDA $10.b war alles diese Aufbereitung der Adresse. Es werden $12 und $14 beschrieben, also sind das die VRAM-Zieladressen der beiden $800-Byte-Klopper von vormals. Das reicht bis zum "STA $14.b". Das anschließende LDA #$0000.w ist nur Vorarbeit für das anschließende SEP #$20.b. Beim Schrumpfen des Akkumulators will man sicherstellen, dass der unsichtbare Byte auf 00 ist, ansonsten fliegt einem das nächste TAX um die Ohren (was mich schonmal bei einem meiner Programme in den Wahnsinn getrieben hat, ikari_01 wird sich vielleicht erinnern).
Gut, damit sind wir schon bei dem nächsten Segment, ein Loop-im-Loop.
Es werden Daten übertragen, von $0D00 bis $0D3F und $0D40 bis $0D7F in die beiden $800-Byte-Puffer, die die Reise in den VRAM antreten werden. Der innere Loop überträgt bei jedem der $20 Aufrufe, die er während der $20 Durchläufe des äußeren Loops (HomeFishy) erfährt, $40 Byte in jeden der beiden Zwischenspeicher im RAM.
Kurzer Einschub: Ich gehe mal wieder davon aus, das da irgendwas mit einer neuen Tabelle gehandhabt wird, die diese $40-Blöcke hantiert.
Ich bin mir gerade nicht mehr sicher, aber ich meine, $40 Byte müssten als Tilemap-Daten doch zwei komplette Zeilen ergeben, oder? Die Sache mit den 64x64-Tilemaps o. ä. ist ja hier egal, da ja auch bei Tilemaps größer die 32x32-Tiles die Tilemap in 32x32-Tilemap-Kacheln sequentiell abgelegt werden...
...woll!?
Nun wirds im nächsten Schritt wieder knobelig. Wir nehmen mal alles nach dem "JSL SetzMalKaffeeAuf.l" unter die Loope. (Kleiner Kalauer am Rande; fehlt jetzt nur noch einen Verweis auf den Goofy-Ripoff von Fix und Foxi... ihr kennt doch Fix und Foxi, oder!?).
Die beiden STZ-Befehle müssten, wenn ich das recht in Erinnerung habe, die Pipeline-Einträge deaktivieren. Es wird in der Pipeline jeweils der Eintrag mit der Null am Ende, also $07x0, geprüft, ob er nicht-null ist. Ist er null, wird das Ge-DMA-e sofort abgebrochen, weil damit signalisiert wird, dass die Warteschlange leer ist.
Da ja auch im folgenden noch einmal aus $0742 gelesen wird, kommt mir gerade der Gedanke, dass man "der Einfachheit halber" einen DMA-Pipeline-Eintrag fingiert hat, um Footer-artig eine Information an die Subroutine auf der Meta-Ebene weiterzugeben... äh... you know what I mean!?
So. In jedem Falle wird dann weitergeschnitzelt. Besagter $0742-Wert wird geladen, die oberen Bytes werden weggeschmissen (AND #$3FF schmeißt die oberen sechs Bit weg, die -MO-ment!- weiter unten doch noch einmal für anderes genutzt werden, also enthält der Doppelbyte in $0742 scheinbar zwei unterschiedliche Informationen in einem 16-Bit-Wert...?) und anschließend erfolgt mit ASL a der Linksruck, den Wolfgang Clement vor nunmehr einem halben Jahrzehnt zum Austritt aus seiner Partei bewog (man sieht: Ich gucke zu viele alte Neues-aus-der-Anstalt-Folgen. Wobei ich nicht behaupten will, zu verstehen, worüber sie reden. Aber immerhin erkenne ich mittlerweile eine Franz-Josef-Strauß-Parodie, wenn sie gemacht wird.).
Dieser Wert (also: die untersten zehn Bit von $742 mal zwei) sind die Zielangabe für den Transfer in den RAM beim nachfolgenden ProbablyTilemapLoop. Y wird logischerweis' vorher auf null gesetzt, denn es soll bei jedem ProbablyTilemapLoop, ob Wind, ob Regen, von $0D00 und $0D40 beginnen, seine zu übertragenden Daten zu laden.
Stunde rum, Resümee:
Es fehlt noch der Kopf des Fisches am Haken (bis zum Kaffee Kochen), zwei Subroutinen, und die DMA-Klitsche sollte ich auch noch einmal inspizieren.
In dieser Stunde habe ich eine grob-schematische Richtung erkannt, wohin dieser Leviathan zu steuern meint. Mein Verständnis selbigens gleicht dem zerfetzten Stahlträger-Skelett eines halb bekleideten, halb fertiggestellten Gebäudes im Entstehen.
Aber trotz dieser "unfinished business"-Ausgangssituation werde ich mich jetzt erstmal um anderes kümmern. Vom Hörensagen erfuhr ich, es gibt ein Leben, dass man nicht mit WLA kompilieren kann.
Disassembled: 145.048 / 1.048.576 Bytes (13,833%)
Gehört: Harmony of a Hunter - 101% Run (disc 1)
Kennt jemand das Gameboy-Spiel "Mole Mania"? Ich meine, außer wrampi, der das sicherlich dreifach in seiner Sammlung hat. Ich kenne es nicht. Eigentlich nur von Screenshots aus der Club Nintendo, hah.
Wie dem auch sei, ich bin per Zufall auf ein Lied aus dem Soundtrack gestoßen. Und das ist gerade mal eins der besten Lieder für den Gameboy, die ich gehört habe. Woah. Hätte ich nie gedacht.
Ich habe vorhin zunächst einmal probeweise mir den Sourcecode angeguckt, ob ich heute für die wirre Subroutine mehr Verständnis zeigen kann; denn, wenn nicht, hätte ich mich nun zuerst um das gekümmert, was ich sowieso tun muss...
... aber es ist geglückt. Gleich dazu mehr.
Vorher noch etwas in eigener Sache:
Super-Metroid-Spielern sei dieser Remix aus "Harmony of a Hunter - 101% Run" sehr ans Herz gelegt. Die Maridia-Theme in Bombastklassik, allerdings wirklich spooky inszeniert. Und jeder, der ordentlich Wumms im niederfrequenten Bereich seiner Anlage hat, sollte das mal auf Über-Zimmerlautstärke testen. Meine Empfehlung.
~~~
So.
Die Subroutine des Tages läuft noch unter dem Namen "FischAmHaken".
Ich habe mir den Spaß gemacht, an das Ende der Subroutine zu gucken. Ich stelle eine These auf, der der geneigte, mehrerfahrene ASM-Tüftler_01 widersprechen mag oder nicht.
These: Im Zweifelsfall sollte man bei mangelndem Verständnis eines (ASM-)Programms hinten anfangen, es zu untersuchen.
Argumentation: Meist steht am Ende der direkte Verwendungszweck und vorab mag ein variablenumformendes Geplänkel in verschiedenartiger Dimensioniertheit das Verständnis des unbedarften Lesers verhüllen. (Stimmt, in der Sendung gestern war Malmsheimer wieder zu Gast...)
Also schau ich auf das Ende:
Code: Alles auswählen
LDA #$7F.b
STA $04.b
LDX #$0800.w
STX $05.b
LDX $12.b
LDY #$B000.w
JSL PrepVDMAplus.l ; $008952 = $0000:0952
LDA #$7F.b
STA $04.b
LDX #$0800.w
STX $05.b
LDX $14.b
LDY #$B800.w
JSL PrepVDMAplus.l ; $008952 = $0000:0952
JSL BigChain.l ; $00827D = $0000:027D
RTLZunächst zu den aufgerufenen Subroutinen: Die "BigChain" ist eine Kette von weiteren Subroutinenaufrufen (hence the name), die allesamt sich darum kümmern, jede DMA-Subroutine aufzurufen und nachher die Bildschirm-Einstellungen zu updaten. Das bedeutet, mit "BigChain" werden alle vorherigen Änderungen "gespeichert", bzw. in die Tat umgesetzt und letztendlich sichtbar gemacht.
Das reguläre "PrepVDMA" nutzt die Inhalte der Variablen $00 bis $06 und füllt damit die DMA-Kanäle (bzw. die für dieses Programm geschriebene DMA-Warteschlange im RAM).
"PrepVDMAplus" nun ist dem regulären "PrepVDMA" als "ergänzender Intro" vorgeschaltet und speichert einfach nur X und Y in die Variablen $00 und $02 (da 16bit = $00-$03). Diese Sache mit dem "ergänzenden Intro" begegnet mir hier häufiger und ist etwas, was ich mir merken sollte - in Masse betrachtet kann man durch die ganzen dadurch wegfallenden Branch-Befehle auch Speicher sparen.
So. In jedem Fall kann ich über das Ende von "FischAmHaken" sagen: es werden zwei DMAs durchgeführt, beide übertragen $800 Byte (LDX #$0800, STX $05.b), beide haben als Bank der Quellmaterial-Adresse die obere Bank des RAM (LDA #$7F.b, STA $04.b), der Rest der Ursprungsadresse wird jeweils vor JSL PrepVDMAplus.l in Y geladen ($B000 bzw. $B800).
Soweit verständlich. Das entscheidende ist die Zieladresse. Diese wird für die erste Hälfte aus $12, für die zweite Hälfte aus $14 entnommen. Ich könnte mir durchaus vorstellen, dass sie wieder einmal direkt hintereinander in den VRAM eingepflanzt werden, aber zumindest diese Möglichkeit besteht, dass das beide Hälften an unterschiedliche Stellen gehen.
Aufgrund der bisherigen Ermangelung an Tilemaps und der Übertragungsbreite von $800 gehe ich davon aus, dass hier gleich Tilemaps aus dem ROM geladen werden und wie ein preiswerter Weihnachts-Kasslerbraten mit Prittstift aus Streifen und Endstücken zusammengepappt wird und anschließend im VRAM auf 200° erhitzt... *hust*
Schauen wir.
Den gesamten Rest von "FischAmHaken" kann/muss ich hier in einem Rutsch darbieten:
Code: Alles auswählen
FischAmHaken:
JSL BigChain.l ; $00827D = $0000:027D
LDY $1002.w
STY $10.b
LDA #$20.b
HomeFishy:
PHA
LDA $1008.w
STA $AC.b
LDY $1000.w
STY $B1.b
LDY $10.b
STY $B3.b
JSL EinsZwoDreiCeh.l ; $00923C = $0000:123C
JSL SetzMalKaffeeAuf.l ; $009426 = $0000:1426
STZ $0740.w
STZ $0750.w
REP #$30.b
LDA $0742.w
AND #$03FF.w
ASL a
TAX
LDY #$0000.w
ProbablyTilemapLoop:
LDA $0D00.w, Y
STA $7FB000.l, X
LDA $0D40.w, Y
STA $7FB800.l, X
INX
INX
INY
INY
CPY #$0040.w
BCC ProbablyTilemapLoop
LDA $10.b
CLC
ADC #$0008.w
STA $10.b
LDA $0742.w
AND #$6C00.w
STA $12.b
EOR #$0400.w
STA $14.b
LDA #$0000.w
SEP #$20.b
PLA
DEC a
BNE HomeFishyDie BigChain wird aufgerufen; vermutungshalber, um die eventuellen Warteschlangen-Eintragen loszuwerden. Danach ein wenig Variablen-Vorgeplänkel, dass sich genauer zu betrachten mir verbietet, um nicht dem Wahn eines Maxwell Roivas anheim zu fallen (siehe Stunde 64).
Der Grund für den fast-Whole-In-One ist der nachfolgende größere Loop "HomeFishy". Versuch ich mich da auch mal im Rückwärtig-Auseinandernehmen.
PLA / DEC a erklärt dann damit schon einmal einen Teil des Vorgeplänkels.
Der Wert in A, der zu beginn auf den Stack gepusht wird, namentlich #$20, ist schlichtweg der Loopcounter. Also: Es wird zweiundreißig Mal, in Zahlen: $20 Mal, der Loop durchlaufen. (this joke never gets old).
Öööh... fein, ab da wirds dann doch komisch.
$10 wird geladen, 8 addiert, wieder in $10 gespeichert. Jetzt wird $0742 geladen. Glorioserweise ist das eine mir unbekannte Variable. Schlaulicherweis' schaue ich heute aber mal in meine ROM Map und stelle fest, womit ich nicht gerechnet hatte - Das wird ein Eintrag in der DMA-Pipeline sein. Um dessen Inhalt abschätzen zu können, müsste ich mich wohl wieder mit der DMA-Subroutine selbst auseinandersetzen. Hm. Also machen wir mal weiter.
Weshalb dorte in AND #$6C00 steht, kann ich mir fast schon denken. Aber machen wirs zunächst mal binär: AND #%0110.1100.0000.0000.
Hm. Das war nicht, womit ich rechnete. Aber das ist nicht schlimm. Meine Vermutung ist nicht widerlegt, aber trotzdem sollte ich sie nicht darlegen, weil sie nicht bewiesen ist.
Gut, gehen wir weiter vorwärts-rückwärts. Ab dem LDA $10.b war alles diese Aufbereitung der Adresse. Es werden $12 und $14 beschrieben, also sind das die VRAM-Zieladressen der beiden $800-Byte-Klopper von vormals. Das reicht bis zum "STA $14.b". Das anschließende LDA #$0000.w ist nur Vorarbeit für das anschließende SEP #$20.b. Beim Schrumpfen des Akkumulators will man sicherstellen, dass der unsichtbare Byte auf 00 ist, ansonsten fliegt einem das nächste TAX um die Ohren (was mich schonmal bei einem meiner Programme in den Wahnsinn getrieben hat, ikari_01 wird sich vielleicht erinnern).
Gut, damit sind wir schon bei dem nächsten Segment, ein Loop-im-Loop.
Es werden Daten übertragen, von $0D00 bis $0D3F und $0D40 bis $0D7F in die beiden $800-Byte-Puffer, die die Reise in den VRAM antreten werden. Der innere Loop überträgt bei jedem der $20 Aufrufe, die er während der $20 Durchläufe des äußeren Loops (HomeFishy) erfährt, $40 Byte in jeden der beiden Zwischenspeicher im RAM.
Kurzer Einschub: Ich gehe mal wieder davon aus, das da irgendwas mit einer neuen Tabelle gehandhabt wird, die diese $40-Blöcke hantiert.
Ich bin mir gerade nicht mehr sicher, aber ich meine, $40 Byte müssten als Tilemap-Daten doch zwei komplette Zeilen ergeben, oder? Die Sache mit den 64x64-Tilemaps o. ä. ist ja hier egal, da ja auch bei Tilemaps größer die 32x32-Tiles die Tilemap in 32x32-Tilemap-Kacheln sequentiell abgelegt werden...
...woll!?
Nun wirds im nächsten Schritt wieder knobelig. Wir nehmen mal alles nach dem "JSL SetzMalKaffeeAuf.l" unter die Loope. (Kleiner Kalauer am Rande; fehlt jetzt nur noch einen Verweis auf den Goofy-Ripoff von Fix und Foxi... ihr kennt doch Fix und Foxi, oder!?).
Die beiden STZ-Befehle müssten, wenn ich das recht in Erinnerung habe, die Pipeline-Einträge deaktivieren. Es wird in der Pipeline jeweils der Eintrag mit der Null am Ende, also $07x0, geprüft, ob er nicht-null ist. Ist er null, wird das Ge-DMA-e sofort abgebrochen, weil damit signalisiert wird, dass die Warteschlange leer ist.
Da ja auch im folgenden noch einmal aus $0742 gelesen wird, kommt mir gerade der Gedanke, dass man "der Einfachheit halber" einen DMA-Pipeline-Eintrag fingiert hat, um Footer-artig eine Information an die Subroutine auf der Meta-Ebene weiterzugeben... äh... you know what I mean!?
So. In jedem Falle wird dann weitergeschnitzelt. Besagter $0742-Wert wird geladen, die oberen Bytes werden weggeschmissen (AND #$3FF schmeißt die oberen sechs Bit weg, die -MO-ment!- weiter unten doch noch einmal für anderes genutzt werden, also enthält der Doppelbyte in $0742 scheinbar zwei unterschiedliche Informationen in einem 16-Bit-Wert...?) und anschließend erfolgt mit ASL a der Linksruck, den Wolfgang Clement vor nunmehr einem halben Jahrzehnt zum Austritt aus seiner Partei bewog (man sieht: Ich gucke zu viele alte Neues-aus-der-Anstalt-Folgen. Wobei ich nicht behaupten will, zu verstehen, worüber sie reden. Aber immerhin erkenne ich mittlerweile eine Franz-Josef-Strauß-Parodie, wenn sie gemacht wird.).
Dieser Wert (also: die untersten zehn Bit von $742 mal zwei) sind die Zielangabe für den Transfer in den RAM beim nachfolgenden ProbablyTilemapLoop. Y wird logischerweis' vorher auf null gesetzt, denn es soll bei jedem ProbablyTilemapLoop, ob Wind, ob Regen, von $0D00 und $0D40 beginnen, seine zu übertragenden Daten zu laden.
Stunde rum, Resümee:
Es fehlt noch der Kopf des Fisches am Haken (bis zum Kaffee Kochen), zwei Subroutinen, und die DMA-Klitsche sollte ich auch noch einmal inspizieren.
In dieser Stunde habe ich eine grob-schematische Richtung erkannt, wohin dieser Leviathan zu steuern meint. Mein Verständnis selbigens gleicht dem zerfetzten Stahlträger-Skelett eines halb bekleideten, halb fertiggestellten Gebäudes im Entstehen.
Aber trotz dieser "unfinished business"-Ausgangssituation werde ich mich jetzt erstmal um anderes kümmern. Vom Hörensagen erfuhr ich, es gibt ein Leben, dass man nicht mit WLA kompilieren kann.
pantalytron: ルトロンはくそのディスアセンブラだよ！
Perikles hat geschrieben:Man muss sich das mal reinziehen: die Idee ist scheiße, die theoretische Ausarbeitung ist scheiße, die praktische Umsetzung ist scheiße und der so entstehende Anspruch noch beschissener.
-
ChronoMoogle
- snesfreaks.com-Team
- Beiträge: 9895
- Registriert: 26. Februar 2007, 14:56
- +Positive Tradingpoints+: 98 von 98
- Wohnort: Nippon
- Kontaktdaten:
Re: Disassemble Blog: Ihatovo Monogatari
Wie immer toller Progress, auch wenn er sich in den Prozenten der Bytes nicht gross wiederspiegelt. Hier geht es schliesslich um Verstaendnis der Spielengine und die laesst sich nicht immer in Zahlen wiederspiegeln. Weiter so
Mole Mania ist eines der besten Game Boy Spiele und grausamst untergegangen, obwohl niemand anderes als Shigeru Miyamoto die Spielidee erdacht hat. Von Soundtrack bis Leveldesign stimmt da einfach alles. Ist ausserdem eine gute Entschuldigung seinen Super Game Boy mal wieder zu entstauben
https://www.youtube.com/watch?v=ZmWO-1CW5Mg ^___^
Mole Mania ist eines der besten Game Boy Spiele und grausamst untergegangen, obwohl niemand anderes als Shigeru Miyamoto die Spielidee erdacht hat. Von Soundtrack bis Leveldesign stimmt da einfach alles. Ist ausserdem eine gute Entschuldigung seinen Super Game Boy mal wieder zu entstauben
https://www.youtube.com/watch?v=ZmWO-1CW5Mg ^___^
| Mein YT Channel | Mein Twitter | Ich suche | Ich verkaufe | Foren SuFu |
...weil Terranigma einfach das Größte ist!
-
lytron
- Code Bro
- Beiträge: 2664
- Registriert: 12. August 2012, 20:18
- +Positive Tradingpoints+: 12 von 12
- Wohnort: ハノーファー区
- Kontaktdaten:
Re: Disassemble Blog: Ihatovo Monogatari
Vielen Dank, Moogle.ChronoMoogle hat geschrieben:Wie immer toller Progress, auch wenn er sich in den Prozenten der Bytes nicht gross wiederspiegelt. Hier geht es schliesslich um Verstaendnis der Spielengine und die laesst sich nicht immer in Zahlen wiederspiegeln. Weiter so
Oder, wie man in Japan sagen würde:
Katamari damashi, muugulu-kun-san-chan-sama-khan! ^.^
Cool! ^.^ Hat das wer zufällig über? (vermutlich nicht unbedingt die richtige Stelle, um zu fragen)ChronoMoogle hat geschrieben:Mole Mania ist eines der besten Game Boy Spiele und grausamst untergegangen, obwohl niemand anderes als Shigeru Miyamoto die Spielidee erdacht hat. Von Soundtrack bis Leveldesign stimmt da einfach alles. Ist ausserdem eine gute Entschuldigung seinen Super Game Boy mal wieder zu entstauben
https://www.youtube.com/watch?v=H7SNtuQ19zo ^___^
~~~
So... once again in Oxford English, to tell an anecdote not twice:
The cat's office (neko no jimosho ねこのじむしょ) is another tale by Miyazawa. The office that is run by cats delivers something like "traveling information" to the town inhabitants. Five cats work in that office, a black cat is the supervisor, a white cat, a tiger cat, a three-colo(u)red cat and a "oven cat" (German: "Herdkatze").
The last one's name comes from the fact that it can only sleep inside an warm oven. Because of this, it is dirty from the oven's smut (smut = Ruß, wie man sich denken kann
). The "oven cat" is proud of being an employee in this office, as it is an hono(u)r to work there.As the story progresses, the "oven cat" is a victim of workplace bullying (zu deutsch: Mobbing. Ja, ich finde das auch seltsam). As the other three cats lie to the black cat and make it believe that the oven cat wants to overtake its position, they all totally ignore the oven cat (which cannot bear this and starts crying).
The end of the story is: A lion sees all this and announces that this is no way to run an office and shuts it down. The German translation of this tale ends with the sentences: "Auf diese Weise wurde das Büro abgeschafft. Ich bin zur Hälfte der Meinung des Löwen." ("This way the office was closed. I am half agreeing with the lion.")
I hope you can understand why I consider this as...
... bizarre, at it's best.
It took me a whole afternoon to figure out what could be the morality of this tale: Eh... bullying could make you bite the hand that feeds... sort of... kinda...?
Anyways? Why do I tell this?
Because I found this:
versteckter Inhalt:
Thanks to MaddHatts, I know what these Japanese blogposts are. They are a broadcast description that was shown in a textmessage in the BS-menu (the no-name-town-thing).
What else-else?
I found a few arranged songs from the Ihatovo-Monogatari-OST, maybe they were broadcast?
And where did I found them? On Youtube. As it seems, on the official channel of Tsukasa Tawada. The Pokémon-OST-guy that worked on Ihatovo Monogatari, too.
Here they are:
versteckter Inhalt:
As I was talking with Kiddo, I realized that the Ihatovo Monogatari-OST that was released on CD has a 22 minute track on it. The title of the track doesn't clarify anything, as it is simply called "Original Soundtrack", written in Hiragana (sic).
Possible content of this track may be:
- An exclusive audio drama
- The arranged songs liked above
- The piano suite of Tawada with all/most melodies from the game
So far.
Oh, and by the way: If you're wondering what Mr. Black Cat is saying: He simply says the Japanese equivalent to "meow".
Who has seen that coming, huh!?
pantalytron: ルトロンはくそのディスアセンブラだよ！
Perikles hat geschrieben:Man muss sich das mal reinziehen: die Idee ist scheiße, die theoretische Ausarbeitung ist scheiße, die praktische Umsetzung ist scheiße und der so entstehende Anspruch noch beschissener.
-
ChronoMoogle
- snesfreaks.com-Team
- Beiträge: 9895
- Registriert: 26. Februar 2007, 14:56
- +Positive Tradingpoints+: 98 von 98
- Wohnort: Nippon
- Kontaktdaten:
Re: Disassemble Blog: Ihatovo Monogatari
Die Trivia und Referenzen zum Spiel und dem BS Nachfolger sind uebrigens auch hoechst interessant. Ich bin schlichtweg (auf erfreute Weise) geschockt, was du noch fuer coole Quellen und interessante Sachen an Land ziehst.
| Mein YT Channel | Mein Twitter | Ich suche | Ich verkaufe | Foren SuFu |
...weil Terranigma einfach das Größte ist!
-
lytron
- Code Bro
- Beiträge: 2664
- Registriert: 12. August 2012, 20:18
- +Positive Tradingpoints+: 12 von 12
- Wohnort: ハノーファー区
- Kontaktdaten:
Re: Disassemble Blog: Ihatovo Monogatari
Awww... :>ChronoMoogle hat geschrieben:Die Trivia und Referenzen zum Spiel und dem BS Nachfolger sind uebrigens auch hoechst interessant. Ich bin schlichtweg (auf erfreute Weise) geschockt, was du noch fuer coole Quellen und interessante Sachen an Land ziehst.
Du sollst doch nicht immer so übertreiben, du! <3
Danke für die erfreulichen Worte. Und noch einmal danke, dass du dieses Spiel (und noch viel wichtiger: Diesen Soundtrack!) in mein Leben gebracht hast.
Was mich an dem Spiel auch so fasziniert, ist exakt diese Wechselwirkung zwischen Buch und Spiel, die Möglichkeit, "Insider" einzubauen, wenn man mit dem Material gut vertraut ist und versucht, sein Bestes zu geben.
Was ich da zum Teil aus dem Internet ziehe, erfreut mich auch, weil auch dort eine Art "sportlicher Anreiz" besteht, sich hinterzuhängen und zu gucken, was man herausfinden kann, wenn man nur verbissen genug sucht.
Aber natürlich gehört eine große Menge Glück dazu, und sei es nur das Glück, dass eben überhaupt jemals eine deutsche Übersetzung von Miyazawa oder ein OST zu dem Spiel veröffentlicht wird.
Und dann braucht man natürlich auch das Glück, Kumpels in einer Community zu haben, die einem beim Disassemblen helfen, oder Bezugsquellen für seltene Fernost-Artikel eröffnen.
Summa summarum:
Luv U all, guyz.
pantalytron: ルトロンはくそのディスアセンブラだよ！
Perikles hat geschrieben:Man muss sich das mal reinziehen: die Idee ist scheiße, die theoretische Ausarbeitung ist scheiße, die praktische Umsetzung ist scheiße und der so entstehende Anspruch noch beschissener.
-
lytron
- Code Bro
- Beiträge: 2664
- Registriert: 12. August 2012, 20:18
- +Positive Tradingpoints+: 12 von 12
- Wohnort: ハノーファー区
- Kontaktdaten:
Re: Disassemble Blog: Ihatovo Monogatari
Stunde 66
Disassembled: 145.048 / 1.048.576 Bytes (13,833%)
Gehört: Neues aus der Anstalt 14
I'm a reasonable man get off get off get off my case.
Mal gucken, wie produktiv das wird...
~~~
So. Zu Beginn dieser Subroutine erkenne ich, dass ich mir diesen DMA-Schanuckel noch einmal begucken muss.
~~~
Produkt der letzten... halben Stunde. Nicht sehr produktiv, ja. Aber dann kann ich jetzt das letzte Ende des Zipfels bezipf... bearbeiten.
Zwei DMAs, beide mit $40 Byte, Quelle ist jeweils Bank 00, von $0D00 und $0D40, schreiben in $2118 (VRAM-Data), normale Adress-Inkrementierung (was ist normal? Öööh...).
Hah! Funny! Die VRAM-Adresse wird bei dem Schabernack aber nicht gesetzt!
~~~
Okay, nachdem ich nachträglich noch einmal über den nachfolgenden Code aus der letzten Stunde geschaut:
Die Adresse wird nicht *gesetzt*, sie wird ausgelesen. Und die hier gerade gesetzten On-Schalter für den DMA-Transfer werden da ausgeknipst. Weird. Ich sollte weiterarbeiten, und dann noch einmal danach mir alles "im Fluss" anschauen...
Stunde rum, Resümee:
Ich sollte morgen weiterarbeiten.
Disassembled: 145.048 / 1.048.576 Bytes (13,833%)
Gehört: Neues aus der Anstalt 14
I'm a reasonable man get off get off get off my case.
Mal gucken, wie produktiv das wird...
~~~
Code: Alles auswählen
SetzMalKaffeeAuf:
REP #$30.b
LDA $B9.b
AND #$FFE0.w
CLC
ADC #$6800.w
STA $0742.w
EOR #$0400.w
STA $0752.w
LDA $BB.b
AND #$FFE0.w
CLC
ADC #$3000.w
STA $0C.b
LDA #$007F.w
STA $0E.b
STZ $00.b
STZ $02.b
LDA #$0020.w
STA $04.b
LDA $B3.b
AND #$0008.w
LSR a
STA $08.b
LuckyLoop:
LDY $00.b
LDA [$0C.b], Y
ASL a
ASL a
ASL a
CLC
ADC $08.b
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 LuckyLoop
LDA #$0000.w
SEP #$20.b
LDA #$FF.b
STA $0740.w
STA $0750.w
LDA #$80.b
STA $0741.w
STA $0751.w
LDA #$01.b
STA $0744.w
STA $0754.w
LDA #$18.b
STA $0745.w
STA $0755.w
LDX #$0D00.w
STX $0746.w
LDX #$0D40.w
STX $0756.w
LDA #$00.b
STA $0748.w
STA $0758.w
LDX #$0040.w
STX $0749.w
STX $0759.w
RTL ~~~
Code: Alles auswählen
; Queue Slots are from $0700 to $078F
; They are handled in reverse order: $078x first, $070x last
;
; $07x0= On/Off-Switch - No DMA if it is #$00
; $07x1= Address increment mode
; $07x2/3 = VRAM Address Low Byte/High Byte
; $07x4 = Transfer Direction, Address Increment, DMA Fixed Transfer
; $07x5 = Bus B Address ($21xx)
; $07x6/7 = Source Address Low Byte/High Byte
; $07x8 = Source Bank
; $07x9/A = Data SizeCode: Alles auswählen
SEP #$20.b
LDA #$FF.b
STA $0740.w
STA $0750.w
LDA #$80.b
STA $0741.w
STA $0751.w
LDA #$01.b
STA $0744.w
STA $0754.w
LDA #$18.b
STA $0745.w
STA $0755.w
LDX #$0D00.w
STX $0746.w
LDX #$0D40.w
STX $0756.w
LDA #$00.b
STA $0748.w
STA $0758.w
LDX #$0040.w
STX $0749.w
STX $0759.wHah! Funny! Die VRAM-Adresse wird bei dem Schabernack aber nicht gesetzt!
~~~
Okay, nachdem ich nachträglich noch einmal über den nachfolgenden Code aus der letzten Stunde geschaut:
Die Adresse wird nicht *gesetzt*, sie wird ausgelesen. Und die hier gerade gesetzten On-Schalter für den DMA-Transfer werden da ausgeknipst. Weird. Ich sollte weiterarbeiten, und dann noch einmal danach mir alles "im Fluss" anschauen...
Stunde rum, Resümee:
Ich sollte morgen weiterarbeiten.
pantalytron: ルトロンはくそのディスアセンブラだよ！
Perikles hat geschrieben:Man muss sich das mal reinziehen: die Idee ist scheiße, die theoretische Ausarbeitung ist scheiße, die praktische Umsetzung ist scheiße und der so entstehende Anspruch noch beschissener.
-
lytron
- Code Bro
- Beiträge: 2664
- Registriert: 12. August 2012, 20:18
- +Positive Tradingpoints+: 12 von 12
- Wohnort: ハノーファー区
- Kontaktdaten:
Re: Disassemble Blog: Ihatovo Monogatari
Stunde 67
Disassembled: 145.048 / 1.048.576 Bytes (13,833%)
Gehört: Neues aus der Anstalt 15
Tobacco-Tabasco-Man!
~~~
Oben noch einmal die SetzMalKaffeeAuf-Subroutine. Der Untere Pinsel ist uns bereits bekannt, jetzt starten wir in den LuckyLoop:
Guuut... wann wird der Loop verlassen? Wenn $04 = #$00 ist.
Ich gucke weiter oben und sehe: $04 wird auf #$20 gesetzt. Endlich! Ein fester Wert!
O... kay... der weitere Teil macht nur als geschnürtes Bündel Sinn. Also, fangen wir bei "LDY $02.b" an.
$02 geht in das Y-Register, dann wird von $7F1000 nach $0D00 übertragen. Da der Loop pro Durchlauf 4 Byte überträgt, und $20 mal durchläuft, ergibt das 4 * $20 = $80, werden die beiden $40-Byte-Kanister gefüllt, die dann danach... du erinnerst dich...? Also: $7F1000 bis $7F107F geht zu $0D00 bis $0D7F.
Weiter gehts mit einem Doppel-Inkrement von $00, was wohl später mal relevant- also früher, weil- also... jah.
Nach dem Doppel-Inkrement geht Y in den Akkumulator, wird um vier erhöht, die Spitzen, die über $7F reichen könnten, werden gekappt, und dann wieder in $02 gespeichert. Soweit dazu.
Fangen wir also am Anfang des Loops an. $00 wird in Y geladen und mit dem Inhalt von $0C bis $0E bildet sich eine Adresse, von der aus geladen wird. $0C bis $0E werden in "SetzMalKaffeeAuf" bestimmt, vor dem LuckyLoop:
$0E ist -natürlich- $7F, $0C ist eine ganz eine doofe Wert-Umherschieberei, aus $BB entsprungen (passt ja wieder in die Jahreszeit). Der dort geladene Wert wird mit 8 multipistaziert (3x ASL a), dann wird Variable $08 addiktiert, und der ergebende Pups in X verschoben und dort als Index, Offset oder wie auch immer man diese Schlammpackung in Fachkreisen zu heißen beliebt, für das Laden aus Bank $7F genutzt.
Stunde rum, Resümee:
Es hängt jetzt an $BB, um zu erkennen, wo das alles herkommt, was am Ende in den VRAM geht.
Und, *wo* in den VRAM es exakt hingeht, wissen wir immer noch nicht, da die entsprechenden, entscheidenden Einträge immer noch nicht behandelt wurden. In meinem Weltbild sind $0742 und $0752 (und deren Nachbarn zur höherliegenden Seite) immer noch leer.
Disassembled: 145.048 / 1.048.576 Bytes (13,833%)
Gehört: Neues aus der Anstalt 15
Tobacco-Tabasco-Man!
~~~
Code: Alles auswählen
SetzMalKaffeeAuf:
REP #$30.b
LDA $B9.b
AND #$FFE0.w
CLC
ADC #$6800.w
STA $0742.w
EOR #$0400.w
STA $0752.w
LDA $BB.b
AND #$FFE0.w
CLC
ADC #$3000.w
STA $0C.b
LDA #$007F.w
STA $0E.b
STZ $00.b
STZ $02.b
LDA #$0020.w
STA $04.b
LDA $B3.b
AND #$0008.w
LSR a
STA $08.b
LuckyLoop:
LDY $00.b
LDA [$0C.b], Y
ASL a
ASL a
ASL a
CLC
ADC $08.b
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 LuckyLoop
LDA #$0000.w
SEP #$20.b
LDA #$FF.b
STA $0740.w
STA $0750.w
LDA #$80.b
STA $0741.w
STA $0751.w
LDA #$01.b
STA $0744.w
STA $0754.w
LDA #$18.b
STA $0745.w
STA $0755.w
LDX #$0D00.w
STX $0746.w
LDX #$0D40.w
STX $0756.w
LDA #$00.b
STA $0748.w
STA $0758.w
LDX #$0040.w
STX $0749.w
STX $0759.w
RTL Code: Alles auswählen
LuckyLoop:
LDY $00.b
LDA [$0C.b], Y
ASL a
ASL a
ASL a
CLC
ADC $08.b
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 LuckyLoopIch gucke weiter oben und sehe: $04 wird auf #$20 gesetzt. Endlich! Ein fester Wert!
O... kay... der weitere Teil macht nur als geschnürtes Bündel Sinn. Also, fangen wir bei "LDY $02.b" an.
$02 geht in das Y-Register, dann wird von $7F1000 nach $0D00 übertragen. Da der Loop pro Durchlauf 4 Byte überträgt, und $20 mal durchläuft, ergibt das 4 * $20 = $80, werden die beiden $40-Byte-Kanister gefüllt, die dann danach... du erinnerst dich...? Also: $7F1000 bis $7F107F geht zu $0D00 bis $0D7F.
Weiter gehts mit einem Doppel-Inkrement von $00, was wohl später mal relevant- also früher, weil- also... jah.
Nach dem Doppel-Inkrement geht Y in den Akkumulator, wird um vier erhöht, die Spitzen, die über $7F reichen könnten, werden gekappt, und dann wieder in $02 gespeichert. Soweit dazu.
Fangen wir also am Anfang des Loops an. $00 wird in Y geladen und mit dem Inhalt von $0C bis $0E bildet sich eine Adresse, von der aus geladen wird. $0C bis $0E werden in "SetzMalKaffeeAuf" bestimmt, vor dem LuckyLoop:
$0E ist -natürlich- $7F, $0C ist eine ganz eine doofe Wert-Umherschieberei, aus $BB entsprungen (passt ja wieder in die Jahreszeit). Der dort geladene Wert wird mit 8 multipistaziert (3x ASL a), dann wird Variable $08 addiktiert, und der ergebende Pups in X verschoben und dort als Index, Offset oder wie auch immer man diese Schlammpackung in Fachkreisen zu heißen beliebt, für das Laden aus Bank $7F genutzt.
Stunde rum, Resümee:
Es hängt jetzt an $BB, um zu erkennen, wo das alles herkommt, was am Ende in den VRAM geht.
Und, *wo* in den VRAM es exakt hingeht, wissen wir immer noch nicht, da die entsprechenden, entscheidenden Einträge immer noch nicht behandelt wurden. In meinem Weltbild sind $0742 und $0752 (und deren Nachbarn zur höherliegenden Seite) immer noch leer.
pantalytron: ルトロンはくそのディスアセンブラだよ！
Perikles hat geschrieben:Man muss sich das mal reinziehen: die Idee ist scheiße, die theoretische Ausarbeitung ist scheiße, die praktische Umsetzung ist scheiße und der so entstehende Anspruch noch beschissener.
-
lytron
- Code Bro
- Beiträge: 2664
- Registriert: 12. August 2012, 20:18
- +Positive Tradingpoints+: 12 von 12
- Wohnort: ハノーファー区
- Kontaktdaten:
Re: Disassemble Blog: Ihatovo Monogatari
Stunde 68
Disassembled: 145.048 / 1.048.576 Bytes (13,833%)
Gehört: Neues aus der Anstalt 16
Tabasco-Tarantino-Man!
~~~
Den LuckyLoop lassen wir hinter uns (wörtlich), und betrachten den Anfang der zweiten Subroutine.
$B9 wird seiner untersten fünf Bit beraubt, was, wenn es denn in der Tat sich um Tilemaps handelt, bedeutet: Wir springen an den Anfang einer Tilemap-Zeile. Wir addieren #$6800, das heißt: Der $074x-Eintrag ist höchstwahrscheinlich die BG1-Tilemap. Dann machen wir was Neues mit EOR, welches Endergebnis ich gerade nicht mir beisammen grübeln kann.
Gut, und wenn ich in die übergeordnete "FischAmHaken" schaue und dort feststelle, dass scheinbar nur $0742, nicht aber $0752 genutzt wird, wird das Ganze nicht unbedingt weniger mysteriös.
Also trete ich, hahaha, die Flucht nach *vorn* an, und arbeite weiter am Anfang, um am Ende dann noch einmal in Strom-Richtung mich treiben zu lassen und dann vielleicht dieses oder jenes besser verstehen zu können...
... schauen wir.
~~~
Also:
$B9 wandert nach Umwandlungen in $0742 und $0752.
$BB setzt die Adresse in $0C.
$00 und $02 wird geleert.
$04, der Counter für den LuckyLoop, wird auf #$20.
$B3 wird geladen, und abhängig vom 8er-Bit (Bit 3 bei Zählung von 0 bis 7) ist der Inhalt von $08 (was später irgendwo draufaddiert wird) entweder 4 oder 0.
Stunde rum, Resümee:
Die zweite der beiden Soubroutinen ist auseinandergenommen, fehlt nur noch die erste, und dann... muss das... verständlich sein... angeblich...
Disassembled: 145.048 / 1.048.576 Bytes (13,833%)
Gehört: Neues aus der Anstalt 16
Tabasco-Tarantino-Man!
~~~
Code: Alles auswählen
SetzMalKaffeeAuf:
REP #$30.b
LDA $B9.b
AND #$FFE0.w
CLC
ADC #$6800.w
STA $0742.w
EOR #$0400.w
STA $0752.w
LDA $BB.b
AND #$FFE0.w
CLC
ADC #$3000.w
STA $0C.b
LDA #$007F.w
STA $0E.b
STZ $00.b
STZ $02.b
LDA #$0020.w
STA $04.b
LDA $B3.b
AND #$0008.w
LSR a
STA $08.b$B9 wird seiner untersten fünf Bit beraubt, was, wenn es denn in der Tat sich um Tilemaps handelt, bedeutet: Wir springen an den Anfang einer Tilemap-Zeile. Wir addieren #$6800, das heißt: Der $074x-Eintrag ist höchstwahrscheinlich die BG1-Tilemap. Dann machen wir was Neues mit EOR, welches Endergebnis ich gerade nicht mir beisammen grübeln kann.
Gut, und wenn ich in die übergeordnete "FischAmHaken" schaue und dort feststelle, dass scheinbar nur $0742, nicht aber $0752 genutzt wird, wird das Ganze nicht unbedingt weniger mysteriös.
Also trete ich, hahaha, die Flucht nach *vorn* an, und arbeite weiter am Anfang, um am Ende dann noch einmal in Strom-Richtung mich treiben zu lassen und dann vielleicht dieses oder jenes besser verstehen zu können...
... schauen wir.
~~~
Also:
$B9 wandert nach Umwandlungen in $0742 und $0752.
$BB setzt die Adresse in $0C.
$00 und $02 wird geleert.
$04, der Counter für den LuckyLoop, wird auf #$20.
$B3 wird geladen, und abhängig vom 8er-Bit (Bit 3 bei Zählung von 0 bis 7) ist der Inhalt von $08 (was später irgendwo draufaddiert wird) entweder 4 oder 0.
Stunde rum, Resümee:
Die zweite der beiden Soubroutinen ist auseinandergenommen, fehlt nur noch die erste, und dann... muss das... verständlich sein... angeblich...
pantalytron: ルトロンはくそのディスアセンブラだよ！
Perikles hat geschrieben:Man muss sich das mal reinziehen: die Idee ist scheiße, die theoretische Ausarbeitung ist scheiße, die praktische Umsetzung ist scheiße und der so entstehende Anspruch noch beschissener.
-
LostTemplar
- SNES-Gamer
- Beiträge: 55
- Registriert: 21. Februar 2012, 09:41
- +Positive Tradingpoints+: 0 von 0
- Kontaktdaten:
Re: Disassemble Blog: Ihatovo Monogatari
Ein kleiner Tipp von mir: Wenn du mal nicht weiterkommst beim "sequentiellen" Disassemblieren (d.h. von vorne alle der Reihe nach durch), dann versuch's doch mal von hinten aufzurollen.
Du kannst zum Beispiel schauen, wo im Menü (falls das Spiel eines hat...) Text ausgegeben wird (z.B. mit Breakpoint auf die Tilemap). Wenn du die Routine hast, schaust du, wo sie aufgerufen wird und findest dann irgendwann die Routine, die das ganze Menü malt usw.
Der Sinn dahinter ist, dass es viel, viel einfacher ist, etwas zu verstehen, wenn man schon weiß, was es eigentlich tut. Aus Erfahrung weiß ich selbst, dass es ziemlich schwierig ist, ein Spiel einfach von vorne und der Reihe nach zu disassemblieren. Denn viele Sachen dienen nur zur Vorbereitung für spätere Berechnungen/Übertragungen/sonst was, und man fühlt sich schnell überwältigt.
Du kannst zum Beispiel schauen, wo im Menü (falls das Spiel eines hat...) Text ausgegeben wird (z.B. mit Breakpoint auf die Tilemap). Wenn du die Routine hast, schaust du, wo sie aufgerufen wird und findest dann irgendwann die Routine, die das ganze Menü malt usw.
Der Sinn dahinter ist, dass es viel, viel einfacher ist, etwas zu verstehen, wenn man schon weiß, was es eigentlich tut. Aus Erfahrung weiß ich selbst, dass es ziemlich schwierig ist, ein Spiel einfach von vorne und der Reihe nach zu disassemblieren. Denn viele Sachen dienen nur zur Vorbereitung für spätere Berechnungen/Übertragungen/sonst was, und man fühlt sich schnell überwältigt.