Fragen bzgl der Funktionsweise des Super Gameboy

[snoer]

Hallo allerseits.

Ich interessiere mich für die genauere Funktionsweise des Supergameboys.

Es ist ja offenbar so, dass ein kompletter Gameboy in der Karte steckt, und vom Snes lediglich die Energieversorgung sowie der Controller Input und Video ausgang genutzt wird.

Soweit so gut, aber da muss ja noch mehr passieren. Schließlich laufen die Gameboy Spiele ja in einer Art Wrapper (Rahmen und Paletten Optionen). Ist das ROM das das bewerkstelligt irgendwo verfügbar? Ggf sogar dokumentiert?


Ich frage unter anderem auch, weil es ja offenbar bisweilen nicht möglich ist GBC Spiele am Snes zu spielen.
Wäre es nicht möglich die Hardware des Supergameboys durch die eines GBC auszutauschen? Welcge weiteren anpassungen wären nötig damit das Ganze funktionieren würde? Sicherlich müsste der Wrapper modifiziert werden..

Najo also wenn ihr Dokumentatioenen oder ähnliches habt, lasst es mich wissen

[lytron]

Würde mich auch interessieren, wie das geht. Ich nehme an, dass die ROM des SGB die Grafiken des "Game Boy Chips" abgreift und das ganze Rahmen-Handling selbst übernimmt. Ebenso die Farben, die man dafür auswählt: Die Auswahl etc. läuft alles über die ROM, und die Grafikdaten, die vom GB übernommen werden, haben keine festgesetzte Palette.
Mit den Spezialrahmen: Ich schätze, die ROM fragt den GB-Chip an: "Ist dieses und jenes vereinbarte Kennzeichen da?" Wenn ja, dann lässt die SNES-ROM bestimmte Daten aus dem GB-Modul (also dessen ROM) auslesen und interpretiert die als Rahmen.

Vielleicht steht hier was?
http://problemkaputt.de/fullsnes.htm#sn ... pergameboy

[snoer]

Habs grad mal überflogen.. da steht dass das snes code von der gb cart aisführen kann. Das erklärt wohl, wie die speziellen rahmen realisiert werden. Trotzdem muss ja ein rom auf dem sgb sein, in dem diese paletten geschichte und die standart rahmen stecken. sotze grad im Bus, aber werd da mal in ruhe recherchieren.

Edit:
Hab grad mal geguckt und recht schnell ein sgb (world) rom gefunfen..

[lytron]

Habs grad mal überflogen.. da steht dass das snes code von der gb cart aisführen kann. Das erklärt wohl, wie die speziellen rahmen realisiert werden. Trotzdem muss ja ein rom auf dem sgb sein, in dem diese paletten geschichte und die standart rahmen stecken. sotze grad im Bus, aber werd da mal in ruhe recherchieren.

Edit:
Hab grad mal geguckt und recht schnell ein sgb (world) rom gefunfen..

Japp, grundsätzlich gehe ich von diesem Aufbau aus:

Ricoh 5A22/Peripherie (SNES) <--> SGB ROM (SBG-Modul) <--> GB Chip (SBG-Modul) <--> GB ROM (auf GB-Modul)

Die SGB-ROM macht das ganze mit den Rahmen und Paletten, und macht schlussendlich auch "die Dame vom Amt", indem es einfach nur den Input vom Controller an den GB-Chip weiterleitet und im Gegenzug Sound-/Grafikdaten zur Ausgabe zurückbekommt.

Hmmmmmmmmm...

Das SPC-Programm müsste sehr interessant sein, weil es ja für GB-Sound-Emulation auf dem SNES ausgelegt ist... aber nein, dafür habe ich keine Zeit.

[snoer]

Sound wird wenn ich das richtig aufgeschnappt hab (wie gesagt, bisher nur überflogen) direkt durchgeschleift. Also keine emulation -> weniger interessant für dich -> erleichtert die potentielle Möglichkeit die gb komponenten durch gbc komponenten zu ersetzen.

Edit:
Schon verrückt was man selbst für einen defekten gbc noch bezahlt.. dagegen krigt man den gba fast hinterhergeworfen

[lytron]

Sound wird wenn ich das richtig aufgeschnappt hab (wie gesagt, bisher nur überflogen) direkt durchgeschleift. Also keine emulation -> weniger interessant für dich -> erleichtert die potentielle Möglichkeit die gb komponenten durch gbc komponenten zu ersetzen.

Joa, gucken schadet ja trotzdem nix.

Edit:
Schon verrückt was man selbst für einen defekten gbc noch bezahlt.. dagegen krigt man den gba fast hinterhergeworfen

Oh, da bahnt sich was interessantes an.
Gerade geguckt, bei Amazon sinds wohl so zwansch/fuffnzwansch Maak, die du dafür zahlen musst. Mach doch einen "Suche"-Thread auf, vielleicht hat hier wer was auf der Resterampe.

[snoer]

Hab einen mit defeltem display defekter laustsprecher und fehlender batteriedeckel für 15 bei amazon geordert vorhin.
Vermutlich bevor du geguckt hast

[lytron]

Na, dann is' doch alles in Butter!

[Ramsis]

Offtopic (sorry): Warum sagen manche von euch eigentlich immer "DIE" ROM? Das "M" am Ende von "ROM" steht für "Memory". Wie in "das" RAM, "das" SRAM, "das" VRAM, "das" WRAM, "das" NVRAM, "das" BIOS-ROM, "das" Boot-ROM, "das" Flash-ROM ... also auch "das" SNES-ROM!

@Topic: Ich denke mal, wenn das SNES die Bandbreite hätte, Gameboy-Color-Spiele (mit der Hardware vergleichbar dem Super Gameboy) abzuspielen, dann hätte Nintendo damals auch einen entsprechenden "Super Gameboy Color" rausgebracht. Haben sie aber nicht.

Der Gameboy-Sound wird übrigens tatäschlich von der Gameboy-Hardware in der SGB-Cartridge erzeugt und über die "äußeren" Cart-Pins zum SNES durchgeschleift -- auf ähnliche Weise leitet z. B. auch das sd2snes PCM weiter, wenn MSU-1 verwendet wird. Die Gameboy-Grafik wird meines Wissens direkt ins (! ... also nicht: in "die"!) SNES-VRAM gestreamt -- hat also mit dem (!) Gameboy-ROM nix zu tun.

d4s hat übrigens vor geraumer Zeit sein Ultra16 um ein paar nette SGB-Features erweitert. Hier findet ihr seine SGB-Hardware-Docs von damals.

Lieben Gruß,
Ramsis

[snoer]

Puh, da bin ich ja erleichtert, dass dieses mal nicht ich in rechtfertigungsnot wegen meimer grammatikaliischen unzulänglichkeiten komme

Die docs werd ich gleich mal sichten.

Kann mir einer von euch grad nochmal grundsätzlich mit der syntax weiterhelfen?

Wenn da zb steht
STZ $00, x
Oder
LDY $F3, x
Was genau passiert dann?

[lytron]

Offtopic (sorry): Warum sagen manche von euch eigentlich immer "DIE" ROM?

Weil es richtig ist.
In deiner Argumentation ist nämlich auch schon wieder ein ganz dicker Fehler:

Das "M" am Ende von "ROM" steht für "Memory". Wie in "das" RAM, "das" SRAM, "das" VRAM, "das" WRAM, "das" NVRAM, "das" BIOS-ROM, "das" Boot-ROM, "das" Flash-ROM ... also auch "das" SNES-ROM!

Es heißt nämlich nicht "das" RAM, sonder der RAM.
DER RAM arbeitet. Folglich ist er männlich. Die ROM ist nicht flexibel, also nicht beweglich, sondern sitzt nur daheim vorm Herd. Und liest. Höchstwahrscheinlich Rosamunde Pilcher oder Bis(s)s-Zeugs. Außerdem verfügt sie über viel Wissen. Was sie auf Anforderung weitergibt. Genauso wie Frauen die Kinder erziehen. Darum der RAM und die ROM. Basta.

Ich hoffe, ich konnte mit meiner Erklärung Programmierer, Sprachwissenschaftler und vor allen Dingen Gender-Study-Sektierer in gehörigem Maße anpissen.

~~~

Ich gehe mal davon aus, dass das "der" von der deutschen Bedeutung herrührt: DER Arbeitsspeicher. Im Sinne von: "Der Arbeitsspeicher wird R. A. M. abgekürzt. Is' doch klar. Sieht man doch." Die ROM wird wahrscheinlich von der CD-ROM kommen.

Wenn da zb steht
STZ $00, x
Oder
LDY $F3, x
Was genau passiert dann?

Gehe zu $00, gehe X Register weiter, speicher da null rein. Beispiel:

LDX #$0000
LDY #$0000
Loop:
LDA $0100, X
STA $0200, Y
INX
INX
INY
INY
INY
INY
CPY #$0020
BNE Loop

Im ersten Schritt lädt er aus $0100 und speichert in $0200, dann wird X zweimal und Y viermal inkrementiert, das heißt, der zweite Schritt ist dann Lade von $0102 und Speichere in $0204, dann Lade $0104 und Speicher in $0208 usw.

[snoer]

Interessanterweise würde bei einem Bauteil wohl tatsächlich jeder den masculinum wählen..
ansonsten bevorzuge ich den Neutrum.. voelleicht weil es physisch gegenstandslos ist... so wie das Licht
...so! Genug getrollt
Is doch wurst. DIE Wurst

[Ramsis]

Es heißt nämlich nicht "das" RAM, sonder der RAM.

In deiner Welt vielleicht. In meiner nicht.

Wenn da zb steht
STZ $00, x
Oder
LDY $F3, x
Was genau passiert dann?

Dann wird der aktuelle Wert in Register X/Y zum Direct-Page-Offset von $00 bzw. $F3 hinzugezählt und die sich daraus ergebende Speicherstelle entweder genullt (stz) oder ins Y-Register geladen (ldy). Achtung: Der Zustand des DP-Registers (= Direct Page Register) wird berücksichtigt!

Beispiele:

• Wenn DP = $0000 und X = $2116 (und A = 16 bit), wird mit stz $00, x die VRAM-Adresse auf Null gesetzt ($00:2116/2117 = VRAM-Adressregister).
• Wenn DP = $0100 und X = $0001 (und Y = 8 bit), wird mit ldy $F3, x der Wert der DP-Variable $00:01F4 ins Y-Register geladen.

Lieben Gruß,
Ramsis

[snoer]

beim zweiten mal lesen, erkenne ich, dass sich eure erklärungen inhaltlich decken

Danke euch beiden!

Noch eine Frage:
Ich bin grad dabei den code des sgb zu disassemblieren. Dafür hab ich mit dem geiger debugger den bereich $8000 bis $ffff disassembliert. Jetzt hab ich da einen haufen code den ich sogar an macher stelle ein bisschem verstehe. (An dieser Stelle.Ein weiteres Danke an Lytron, für deinen Maggifix workshop)

da stehen, dann ja so zeilen wie:
$00/8152 DO F8 BNE $F8 [814C] A:0000 X:0000 Y:0000 P:EnvvMXdizc

1. Mir ist nicht ganz klar was das DO F8 bedeutet
2. Warum steht da BNW F8 und die Zieladresse dahinter in Klammern? An anderer Stelle steht die korrekte Zieladresse direkt hinter dem BNE.
3. Warum steht bei A X und Y stets 0000.. sollte da nicht der aktuelle wert odersowas drin stehen?
4. Gehe ich recht in der Annahme dass bei P die bits mit großbuchstaben gesetzt sind und die mit kleinem nicht?
5. Selten, aber manchmal 'fehlt' einfach eine Zeile!
Zb ist da folgender code block:

Code: Alles auswählen

$00/80B9 20 03 81 JSR $8103 [$00:8103] A:0000 X:0000 Y:0000 P: EnvMxdiszc
[...]
$00/80D1 A0 00 20 LDY #$2000 [...]
$00/80D4 F8 81 A9 01 ADC $01A981, x [01:A981] [...]

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 ':)

Jo für jegliche erläuterung aber auch für heisse tips zum disassemblieren allgemein wäre ich sehr dankbar!

Beste Grüße

Ps.: verzeiht die inkonsistente Groß-Kleinschreibing; ich habe zzt nur Internet über mein smartphone (für dieses Post habe ich geschlagene 25 minuten gebraucht *sigh)

[lytron]

1) D0 F8 ist der Code, der "BNE $F8" bedeutet. "D0" ist der Hexcode, der als "BNE" interpretiert wird.
2) Das liegt am BNE-Befehl. BNE hat relative Adressierung. Beispiel:

In Zeile $00/0300 steht: BNE $08. Dann geht er zu der festgesetzen Adresse, ab der er das errechnet (das ist immer der erste Byte *nach* dem BNE $xx-Befehl, also hier $00/0302), und rechnet den Argument-Byte drauf. $00/0302 + $08 = $00/030A. Folglich springt der BNE-Befehl, wenn der Branch denn genommen wird, nach $00/030A. Wichtige Sache: $00 bis $7F springt vorwärts, $80 bis $FF springt rückwärts. Für größere Sprünge musst du andere Befehle nehmen.
Bei deinem Codeauszug ist der BNE-Befehl bei $00/8152, also fängt die Errechnung bei $00/8154 an. Dort von dort aus geht er rückwärts, und zwar ($100 - $F8 =) $08 Bytes rückwärts. $8154 - $08 = $814C.
3) Das steht da, weil anscheinend in dem Fall da nix drin war. SOnst steht da immer der Inhalt von A, X und Y, ja. Zumindest, wenn du loggst; hier hast du ja anscheinend direkt disassembled, ohne dass der SNES das "in Sequenz" durchgegangen ist. Deshalb wird da wohl nix drin sein.
4) Richtig.
5) Meinst du zwischen $80D1 und $80D4? Da fehlt nichts. Der Byte an Adresse $80D1 ist $A0, der Byte an Adresse $80D2 ist $00, $80D3 ist $20 und $80D4 ist $F8. Und so weiter. Die Adressen sind nicht wirklich "Codezeilen", sondern die Adressen von einzelnen Bytes.