Fragen bzgl der Funktionsweise des Super Gameboy

[lytron]

Da fehlt $00/8002 und $00/8003! Dann sind da mehrere diesee jump befehle. Unter dem ersten. Die zeigen allesamt auf adressen, die 'fehlen'.. zu guter letzt finde ich auch nirgendwo im code einen befehl der auf diesen block zeigt also aif $80B9

alles sehr mysteriös ':)

Ich weiß, wie das kommt. AAAAAAAAAALLLSOOO:

Du erinnerst dich, dass ich ganz zu Anfang meines Maggifixes sagte: Der Prozessor kann Grafikdaten nicht von Code unterscheiden, und wenn du ihn darauf steuerst, würde er das als Code interpretieren und irgendeinen Unsinn machen (z. B. eine entlegende Kommune im Uralgebirge als Stadtstaat vom Russischen Mutterland lösen, oder auch das Spiel aufhängen).

Du hast dem Dingens gesagt: Von hier bis hier möchte ich den Code disassembled haben. Also los!
Der Geiger dachte sich: Gut, fange ich an. Er hat den ersten Byte genommen, geguckt, was für ein Befehl das ist und wie viele Argument-Bytes dabei sind. Dementsprechend hat er dann den nächsten Byte danach genommen und das ganze Prozedere wiederholt.
Die Sache ist: Wenn da jetzt z. b. eine Grafik oder eine Tabelle oder sonstwelche Daten dazwischen wären, würde er die auch disassemblen. Das alleine wäre nicht schlimm. Schlimm ist, dass er verrutschen könnte. Dass er nämlich ab der Stelle, wo der Code wieder beginnt und der erste Byte einen Befehl darstellt, er diesen Byte - aufgrund des vorhergegangenen - als Argument interpretiert und die nachfolgenden Argumente wiederum als Befehl. Das ganz sich immer eine ganze Weile hinziehen, bis er sich wieder "eingerenkt" hat.

Meine Empfehlung: Arbeite erstmal mit Log-Files. Damit kriegst du den Anfangspunkt raus, siehst den "Fluss" des Programms und umgehst diese Interpretationsfehler.

Und überhaupt: Zeig doch mal her, was du schon disassembled hast. Würde mich interessieren, inwieweit mein "Schüler" Fortschritte gemacht hat.

[snoer]

Das mit den logfiles hört sich recht logisch an.. muss mal gucken wie man das bewerkstelligt.
Hatte mich eh schon gewundert, weil mir mein vorgehen nicht recht effizient vorkam ':)

Ich lade nachher mal meine txt datei hier hoch oder schick sie dir per pn
..ein bisschen beschähmt, denn so richtig viel habe ich inhaltlich noch nicht interpretiert.
aber das siehst du dann ja.. aber wie gesagt. von mir aus wär ich jetzt nicht auf die idee gekommen das ganze präsentieren wollen ':)

[lytron]

Ich lade nachher mal meine txt datei hier hoch oder schick sie dir per pn
..ein bisschen beschähmt, denn so richtig viel habe ich inhaltlich noch nicht interpretiert.
aber das siehst du dann ja.. aber wie gesagt. von mir aus wär ich jetzt nicht auf die idee gekommen das ganze präsentieren wollen ':)

Aber, aber! Rom wurde auch nicht an einem Tag mit Zitronenscheiben gepflastert! Ich bin einfach nur gespannt, inwieweit meine Tutorials Früchte getragen haben, und ob ich dir an der einen oder anderen Stelle helfen kann. Das meiste beim Wühlen im Fremdcode macht schlichtweg die Erfahrung. Das kann ich derzeit nur allzusehr bestätigen: Je mehr man sich anguckt, desto schneller findet man sich zurecht, weil doch einiges sich allzu gleich ansieht.

[snoer]

Ich bräuchte hier nochmal Hilfe, bzw einen lesetip..

Es geht um indirect adressing ..wenn ich das richtig sehe x)
Ich habe eine txt mit einer routine angehängt die ich nciht verstehe.

A ist 8bit .. dann kommt ein lda gefolgt von einer 16bit adresse, y ..
Ich hab schon das wdc65816 manual rausgekramt aber werde aus dem was ich da lese nicht schlau.

Irgendwie hab ich auch das Gefühl, dass dieser dubiose hidden vector B hier eine Rolle spielt.
..aber seht selbst ':)

wie gesagt wäre ich sehr dankbar für ne kurze erläuterung, einen erklärenden link oder sonst irgendwas, was meiner konfusion entgegenwirken könnte

Edit: und um nal wenigstens eine konkrete frage zu stellen:
Wenn A 8bit ist, speichert STA dann nur A oder C? Weil.. für etwas muss B ja gut sein

[lytron]

Wenn A 8bit ist, speichert STA nur A.

B ist nur für eine Sache gut: Sachen konservieren.

LDA #$13 ; A = #$13, B = ?
XBA ; A ist B und B ist A
LDA #$14 ; A= #$14, B= #$13
...
STA $00 ; $00 = A = #$14
XBA ; eXchange B and A
STA $01 ; $01 = A = altes B = #$13


Die Funktion, die du gegeben hast, transferiert einen Datensatz in Register. Der Datensatz besteht aus einer Sequenz von Einstellungen für den Bildschirm. LDA $E6E9,y geht zu $E6E9, addiert da Y drauf (am Anfang 0, dann 1, dann 2...) und lädt von dort einen (8-bit-)Wert und speichert den in eins der Screensetting-Register. $E6E9 und soweiter sind Werte, was in der ROM festgesetzt sind.

Hilft dir das weiter, oder habe ich was vergessen?

[snoer]

..also ..sixher!? Wieso ist a dann nach dem ersten lda E702 (bei Y=0), beim zweiten lda e706 (Y=1) dann e707(Y=2) usw? ..dann plötzlich e738 und e73c
Das macht doch irgendwie keinen sinn! Oder was ist e6e9 für ein sonderbares register in dem sich der wert von selbst ändert. Grml.. ich hasse es wenn ich etwas nicht verstehe ':)

Ahh ich sehe grad.. er liest immer aus einem anderen register! Check
Dachte er liest immer aus dem gleichen, und addiert y aif den wert.

Aber.. was sind das für werte? Irgendwelche hart eingecodeten werte?

[lytron]

..also ..sixher!? Wieso ist a dann nach dem ersten lda E702 (bei Y=0), beim zweiten lda e706 (Y=1) dann e707(Y=2) usw? ..dann plötzlich e738 und e73c
Das macht doch irgendwie keinen sinn! Oder was ist e6e9 für ein sonderbares register in dem sich der wert von selbst ändert. Grml.. ich hasse es wenn ich etwas nicht verstehe ':)

Ahh ich sehe grad.. er liest immer aus einem anderen register! Check
Dachte er liest immer aus dem gleichen, und addiert y aif den wert.

Aber.. was sind das für werte? Irgendwelche hart eingecodeten werte?

Du guckst falsch.

Code: Alles auswählen

$00/8394 B9 E9 E6    LDA $E6E9,y[$01:E6E9]   A:E755 X:0020 Y:0000 P:envMXdIZC

Was in den eckigen Klammern steht, ist die Adresse, von wo geladen wird.
Was bei A steht, ist der Inhalt von C - unabhängig von SEP/REP #$20. Hier ist A (noch) #$55 (ist in der nächsten Zeile #$02, weil $E6E9 #$02 ist), B ist #$E7 und wird nicht verändert. B ist #$E7, weil offensichtlich irgendein 16-bit-Wert mal #$E7 als high byte hatte und die danach C nicht gecleart haben, bevor sie den Akku auf 8-bit geschraubt haben.

Japp, die sind hart eingecodet. Liegen auf Bank $01 bei E6E9, da ich davon ausgehe, dass das LoROM ist, müsstest du sie im Hexeditor auch genau bei 0000:E6E9 finden. +200, wenn du eine geheaderte ROM hast.

[snoer]

aber was soll das denn?
An anderer stelle kommt ein sta $bb

Wie soll ich denn herausfinden, was die sich dabei gedacht haben, einen anscheinend beliebigen wert in ein beliebiges register zu schreiben. Es wird da irgendwie auch nie wieder rausgelesen.

Sollte vlt schluss machen für heute.. ich reg mich grad voll auf. x]

[lytron]

aber was soll das denn?
An anderer stelle kommt ein sta $bb

Wie soll ich denn herausfinden, was die sich dabei gedacht haben, einen anscheinend beliebigen wert in ein beliebiges register zu schreiben.

Normalerweise ist der Trick, natürlich danach zu suchen, wo diese Register ausgelesen und in I/O Register gespeichert werden. Hättest du z. B. eine Subroutine, die Werte aus WRAM-Registern in $210D und Kollegen überträgt und danach sich selbst beendet, wüsstest du: Das ist eine Subroutine, die die BG-Scroll-Werte updatet, und die entsprechenden WRAM-Register sind die Zwischenspeicher dafür.
Ebenfalls hilfreich am Anfang sind DMAs. Aufgrund von deren Bestimmung (Der Wert, der in $43x1 gespeichert wird) und Ursprung kann man dann immer Rückschlüsse ziehen, wo z. B. der OAM oder die Paletten gebuffert werden. Das ist, wie ich das meist mache. Man hat dann immer schonmal einen guten Grundstock, und kann dann immer schon aufgrund der genutzten Register zumindest eingrenzen, worum es in den Subroutinen geht.

An sich hast du dir aber schon ein ambitioniertes Projekt vorgenommen. Denn der SGB wird viele dieser "Conveniences" nicht haben, weil der ja nix buffern muss, weil er alles vom GB-Chip durchreicht.

Es wird da irgendwie auch nie wieder rausgelesen.

Das kann übrigens auch sein. Aber deine Frustration kann ich verstehen. Als ich neulich die SPC-Engine von Bounty Sword auseinandergenommen habe (und da den Vorsatz hatte, wirklich alles zu disassemblen und zu verstehen), saß ich auch vor einem absoluten Schwachsinn, der für mich keinen Sinn ergab. Irgendeine seltsame Zahl wurde konstant mit einem schiefen Wert aufaddiert. Und diese Zahlenwerte wurden niemals benutzt.
Schlussendlich habe ich das als eine Art ge-fake-ten Zufallszahlengenerator abgetan. Und, es sei mal dahin gestellt, wofür man bei einer Soundengine einen Zufallszahlengenerator braucht. Den Nutzen kann man aus der oben genannten Anzahl der Nutzungen ableiten:

= 0

Sollte vlt schluss machen für heute.. ich reg mich grad voll auf. x]

Das gehört dazu.

[snoer]

Danke für die guten Worte.
ich hab mich heite wieder ran gesetzt und erstmal versucht strukturell etwas locht ins dunkel zu bringen.
Mit partiellem erfolg! Ich habe einige subroutinen die zirkulär durchlaufen werden gefunden. Dabei nimmt der code unterschiedliche 'weichen', landet zuletzt aber stets wieder am anfang (bis jetzt).

Nun versuche ich den unterschied der jeweiligen routen zu ergründen, was mich zu meiner frage führt:

wie genau funktioniert inc? Ich gebe zu, ich habe das manual noch nicht dazu befragt, mache ich aber solange ich auf antwort warte, versprochen!

wenn da steht

Code: Alles auswählen

Inc $0c08 (a:ffff p:envmdIzC)

Was genau wird dann incrementiert? Also mit A passier offenbar nichts.. der würde bei incrementierung ja auf 0000 springen.
Wird also der wert im zielregister um ffff erhöht? Oder um 1?

Edit:
So abdi ins betti!
Direct Page indirect long indexed with Y.. genau x)
da muss ich erstmal ne nacht drüber schlafen, glaub ich

[lytron]

$0C08 = $0C08 + 1

Inkrementieren heißt immer: Plus eins.

[snoer]

Kurz und knapp :]

Ich bin gestern dann doch noch viel zu lange wach gewesen weil mir eines keine ruhe gelassen hat.
Habs letztlich auch nicht geblickt.

Da ist ein loop der tausendfach wiederholt wird.
er besteht lediglich aus 2 ops:

$00/8289 Lda 4210
$00/828c Bpl $fb

P: envMXdIzc
dass er das branched verstehe ich ohne weiteres. meinetwegen akzeptiere ich auch, dass er genau eine Zeile weiter oben landet (obwohl ffff-828c+8286=fffc) aber da fehlt mir wahrscheinlich nur ein steo zur mark.

Was sich mir absolut nicht erschließt, ist die tatsache, dass nach gefühlten 100000 durchläufen plötzlich die negative flag gesetzt wird! Einfach so! Ich hab schon mit bsnes debugger ne gute halbe stunde den loop durchgestept, in der annahme es könnte mit vblank oder hblank in verbindung stehen, aber nixda.. ich kann mir das nicht erklären.

Es muss ja so sein, dass das N flag durch irgendwelche äusseren Einflüsse gesetzt wird (was beim.sgb nicht vollkommen unwahrscheinlich ist) aber da ich nicht an echter hardware arbeite sehe ich keine möglichkeit irgendwelche etwaigen impulse die vom sgb kommen abzufangen.

Darum grundsätzlich die frage: gibt es einen pin an der sgn cart der, wenn er befeuert wird , die N flag toggelt?

Sträinz bihayvia (== strange behavior)

[lytron]

meinetwegen akzeptiere ich auch, dass er genau eine Zeile weiter oben landet (obwohl ffff-828c+8286=fffc)

Die Adressen werden, wie ich irgendwo schonmal schrob, ausgehend vom ersten Byte der nächsten "Zeile" berechnet, also 828e

...aber da fehlt mir wahrscheinlich nur ein steo zur mark.

Hui, was ist denn das für eine Redewendung? Die kenn ich noch gar nicht. Ist da ein Tippfehler drin, oder heißt es wirklich "ein Steo zur Mark"?

Was sich mir absolut nicht erschließt, ist die tatsache, dass nach gefühlten 100000 durchläufen plötzlich die negative flag gesetzt wird! Einfach so! Ich hab schon mit bsnes debugger ne gute halbe stunde den loop durchgestept, in der annahme es könnte mit vblank oder hblank in verbindung stehen, aber nixda.. ich kann mir das nicht erklären.

Öhm, arbeitest du mit Fullsnes im Hintergrund offen? Wenn nicht, würde ich es dir empfehlen. Mache ich beim Disassemblen auch immer. (Ist für dich nur doof, weil du ja IIRC kein Internet am PC hast)

In $4210 wird Bit 7 gesetzt, sobald der VBLANK beginnt. Das ist ganz normales Prozedere, da werden wohl danach irgendwelche Transfers gemacht, die nur während des VBLANKs gehen, z. B. die Paletten geupdatet o. ä. Solche Sachen kannst du immer ganz gut im Fullsnes nachschlagen.
Auch beliebt: Ewig in einem Loop zu hängen, bei dem gewartet wird, dass $2140 geändert wird. Das ist eins der APU-Register, da wird dann auf eine Reaktion des SPC700 gewartet.

Es kann auch mal sein, dass bei einem WRAM-Register drauf gewartet wird, dass sich dessen Inhalt von ganz allein ändert. Das hatte ich auch schon mal, ich glaube sogar, dass das bei Ihatovo Monogatari war. Der Grund dafür war, dass der Inhalt in dem WRAM-Register immer während des NMI-Handlers (also: Während des VBLANKs) geändert wurde. Verrückt, geht aber alles.

[snoer]

Hr.. ne das war tatsächlich ein Schreibfehler .. ein step wollte ich schreiben. schon.blöd, wenn man ein lustiges wortspiel machen will und sich dann dabei verschreibt

Das mit dem apu register behalte ich mal.im hinterkopf. Die ganze geschichte kommt mir auch deswegen komisch vor weil, was ich vergessen habe zu sagen, wenn die N Flag gesetzt wird auch der wert im Akkumulator verändert wird. Es muss also irgendwas im hintergrund passieren, was den wert im accumulator verändert und die n flag setzt.

Nun werde ich. Das erstmal dezent ignorieren

[ikari_01]

Ah, der Super Gameboy
Ja, also da gibt es ein Kommandoregister, mit dem das GB-ROM dem SGB-BIOS diverse Befehle senden kann, z.B. "setze Rahmengrafik". Die Rahmengrafik selbst liegt natürlich auch im GB-ROM - die Übertragung selbiger erfolgt über die Gameboy-Grafikausgabe! Auf dem SGB2 sitzt neben dem BIOS und dem Gameboy ja noch ein Konverterchip, der den 2-Bit-Video-Ausgabestrom vom Gameboy (der normalerweise zum LCD gehen würde) puffert und dem SNES im CHR-Format zur Verfügung stellt.
Außerhalb des sichtbaren Bildbereichs werden Bitmaps erzeugt, die vom ICD2 konvertiert werden und vom BIOS aus dessen Tilepuffer wieder ausgelesen werden. Das funktioniert also tatsächlich ganz ähnlich wie der gute alte Videotext