Maggi-Fix für SNES Programmierung

Es werden stets neue Spieletests, Berichte und Artikel für die Homepage gesucht. Beweist hier Euer Schreibtalent.

Moderator: Perikles

Benutzeravatar
lytron
Code Bro
Code Bro
Beiträge: 2664
Registriert: 12. August 2012, 20:18
+Positive Tradingpoints+: 12 von 12
Wohnort: ハノーファー区
Kontaktdaten:

Re: Maggi-Fix für SNES Programmierung

Beitrag von lytron » 19. Dezember 2012, 06:35

Für den nächsten Beitrag hätte ich gern ein Foto des Inneren eines PCs, von einem Bus-Kabel, bei dem man am besten auch erkennt, wie es an verschiedene Sachen angeschlossen ist.

Kann mich wer da unterstützen, wenn er gerade sowieso an seinem PC rumschrauben sollte?

Danke 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.

Benutzeravatar
lytron
Code Bro
Code Bro
Beiträge: 2664
Registriert: 12. August 2012, 20:18
+Positive Tradingpoints+: 12 von 12
Wohnort: ハノーファー区
Kontaktdaten:

Re: Maggi-Fix für SNES Programmierung

Beitrag von lytron » 10. Januar 2013, 19:49

Kategorie: Hardware- und/oder Computer-Know-How allgemein



DMA - Was ist das?
In diesem Artikel geht es nur darum, was DMA ist. Wenn du das schon weißt, kannst du gleich den nächsten Artikel lesen. Ich werde es hier allgemein halten - SNES-spezifisches werde ich im nachfolgenden Artikel erklären. Man verpasst also keine Informationen zum SNES-DMA, wenn man das hier auslässt.

Vorteilhaft für mögliche Höchstgeschwindigkeiten auf Autobahnen ist es, wenn davon ausgehen kann, dass alle Autos in eine Richtung fahren.
Der Computer kennt übrigens auch Autobahnen. Die heißen da wirrerweise nicht "Autobahn", sondern "Bus", in diesem Falle, um genau zu sein, "Datenbus". Glücklicherweise sehen sie aber aus wie Autobahnen.

(Denk dir hier ein Bild mit einem Computer und einem "Datenbus"; vielleicht macht irgendwer mal ein schniekes Foto von sowas und stellt mir das hierfür zur Verfügung).

Der Datenbus hat noch mehr Ähnlichkeiten mit Autobahnen außer verhältnismäßig lang, verhältnismäßig breit und verhältnismäßig grau.
Er hat z. B. Auf- und Abfahrten. Ein Datenbus verbindet beim Computer zum Beispiel ein DVD- oder Disketten-Laufwerk* mit dem Einflussbereich des Prozessors.

Kommen wir zurück zum eingangs erwähnten Axiom deutschen Verkehrswesens und damit zum Unterschied zwischen den Asphalttrassen und der Kabelage:
Autobahnen haben normalerweise zwei Richtungen. Ein Bus kennt nur eine.
Bevor das jetzt missverständlich ist - es kann der Datenbus in beide Richtungen genutzt werden. Aber nicht gleichzeitig. Folglich ist die Entscheidung, welche er haben soll - vom Prozessor weg oder zum Prozessor hin. Und wer fällt die Entscheidung?
Erstmal (soll heißen: "In diesem Falle vorerst") der Prozessor. Der Prozessor schickt ein Auto auf die Autobahn, das nimmt die Ausfahrt zum DVD-Laufwerk und gibt dem Befehle, etwas von der eingelegten DVD zu lesen.

So weit, so gut.
Doof ist nur, wenn ich zum Beispiel Grafikdaten im Speicher habe, und die an die Grafikkarte weitergeben will. Wenn es so mache, alles bröckchenweise in den Prozessor zu laden und dann von da aus an die Grafikkarte weiterzugeben, ist das für niemanden sehr sinnvoll. Ich verliere Zeit, weil der Prozessor dazwischenhängt und es nicht direkt geht. Und der Prozessor vergniedelt seine kostbaren Arbeitstakte für Sachen, von denen er nichts hat, nichts an Arithmetisch-Logischem geleistet hat, und die ihm auch nicht helfen, seine eigentliche Arbeit zu erledigen.
Das beste wäre, gäbe es einen direkten Speicherzugriff zu machen, quasi einen Direct Memory Access.

Voila, DMA!

DMA ist genau das. Der Datenbus wird für die Kommunikation zwischen zwei "Anhängseln" des Datenbusses genutzt. Dazu muss aber der Prozessor aber sein Königszepter ablegen. Es kann immer nur einen "Sender" geben, quasi eine Auffahrt auf die Autobahn, und die restlichen Teilnehmer des Datenbusses sind potentielle Empfänger.

Damit das ganze koordiniert wird, bedarf es eines Arbiters, eines "Richters", der richterlich entscheidet, wer senden darf. Da gibt es verschiedene Ansätze, wie man das entscheiden kann, z. B. nach Bedarf oder je nach bestimmten Zeitpunkten. Wie dass das SNES macht, kommt im nächsten Artikel.

DMA hat seine Vorteile für beide Seiten: Die Daten kommen direkt von A nach B und der Prozessor bleibt unbehelligt, außerdem geht es auch ansich schneller, als wenn es über den Prozessor liefe, und außer-außerdem kann der Prozessor nebenbei sich zumindest im sich selbst kümmern und, wenn auch in begrenztem Maße, weiter arbeiten ("In begrenztem Maße" logischerweise, da er ja nicht auf das zugreifen kann, was am Datenbus hängt; WICHTIG: Das ist leider beim SNES nicht der Fall; hier wird die CPU quasi "abgeschaltet", solange der DMA läuft).

Folglich ist DMA eine super Möglichkeit, viele Daten übertragen zu lassen...

... wie zum Beispiel die Grafikdaten für unsere SNES-Demo.

* Für SNES-Programmierung ist es von Vorteil zu wissen, was eine Diskette ist; allerdings ist dieses Wissen in jedem Fall nicht erforderlich für Spieleprogrammierung mit dem Game Maker.
Zuletzt geändert von lytron am 27. Januar 2013, 10:46, insgesamt 1-mal geändert.
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.

Benutzeravatar
lytron
Code Bro
Code Bro
Beiträge: 2664
Registriert: 12. August 2012, 20:18
+Positive Tradingpoints+: 12 von 12
Wohnort: ハノーファー区
Kontaktdaten:

Re: Maggi-Fix für SNES Programmierung

Beitrag von lytron » 27. Januar 2013, 10:44

Kategorie: SNES-Technisches, oder so

DMA - Wie geht das?
Beim SNES gibt es bestimmte Zeitpunkte, an denen geprüft wird, ob ein DMA durchgeführt wird. Am Anfang jedes VBLANKs, HBLANKs oder FBLANKs* wird geprüft, ob DMAs durchgeführt werden müssen oder nicht. Wenn ja, arbeitet der Prozessor in der Zeit nicht, in der der DMA durchgeführt wird.
Ein Unterschied wird zwischen dem DMA und HDMA gemacht. Der HDMA ist regulär derjenige, der während eines HBLANKs durchgeführt wird, DMA derjenige für den VBLANK. Wir betrachten hier nur den DMA, der HDMA läuft ein wenig anders ab, der könnte später gesondert erklärt werden.

Um DMA durchzuführen, gibt es beim SNES die Register $4300 bis $4376. In diese Register werden die Eckdaten des DMA eingetragen: Übertragungsart, Urpsrung, Ziel, Datenmenge. Es gibt jeweils acht DMA-Channels (Channel 0 bis Channel 7). Channel 0 nutzt die Register $4300 bis $4306, Channel 1 nutzt die Register $4310 bis $4316 usw. Die Channels sind alle "baugleich", es gibt nichts, was der eine Channel kann, was der andere nicht beherrscht (ich denke, beim SNES ist das schon recht relevant, darauf hinzuweisen). Folglich schreibe ich ab jetzt für die Register nur noch $43x0 usw., wobei die Aussagen allgemeingültig für x = {0...7 | x e N} ist.

$43x0 DMA Control for Channel x (define.asm: DMAPx)
Die untersten drei Bit (Bit 0 bis Bit 2) steuern den Transfer-Modus. Die beiden vorerst relevanten sind %000 und %001.
Bei %000 werden alle zu übertragenden Daten in das Zielregister geschrieben. Bei %001 wird abwechselnd in das angegebene Zielregister und in dessen höheren Nachbarn geschrieben. Das macht bei Übertragungen mit Low-Byte-/High-Byte-Eingaberegistern Sinn. Zum Beispiel Register $2118 (VMDATAL) und $2119 (VMDATAH), die für den Transfer in den VRAM gut sind.
Bit 3 ist für einen "fixed Transfer" zuständig. Das heißt, wenn dieser Bit gesetzt ist (das heißt: =1), wird nach dem Schreiben in das Zielregister die Adresse, aus der der nächste Byte zum Transfer geladen wird, nicht verändert. Das heißt: Es wird über den ganzen DMA hinweg nur ein einziger Byte in alle Register geschrieben. Bei dem SNES-Spiel "Ihatovo Monogatari" wird das z. B. dazu genutzt, um den kompletten VRAM per DMA zu clearen, da als zu übertragender Byte "$00" gewählt wird.
Bit 4 entscheidet über die Veränderung der Ursprungsadresse nach einer Byte-Übertragung. Ist Bit 4 gecleart, wird die Adresse inkrementiert, ist Bit 4 gesetzt, wird die Adresse dekrementiert. Das heißt, man setzt Bit 4, wenn die Ursprungsdaten genau in umgekehrter Reihenfolge am Zielort ankommen sollen. Der Effekt von Bit 4 wird von Bit 3 außer Kraft gesetzt, natürlich.
Bit 5 ist ungenutzt.
Bit 6 ist nur für HDMA relevant.
Bit 7 ist für die Transferrichtung zuständig. Ist Bit 7 gecleart, wird vom Speicher in das Zielregister ($21xx, gleich dazu mehr) geschrieben. Wenn Bit 7 gesetzt ist, liest man aus Register $21xx und schreibt in den Speicher.

$43x1 DMA Destination Register for Channel x (define.asm: BBADx)
Setzt das Zielregister (im Normalfall, das heißt, wenn Bit 7 in Register $43x0 = #%0 ist). Das Zielregister muss im Raum zwischen Register $2100 und $21FF liegen. Das ist nur bedingt eine Einengung, da alle für den DMA relevanten Register hier liegen (die CGRAM-Register, die VRAM-Register, die Soundchip-Register, und mit einem Trick kann man sogar mit bestimmten Hilfsregistern ($2180-$2183) in den Arbeitsspeicher schreiben).
Dieses Register ist nur bytegroß. Da aber von vornherein der Adress-Spielraum auf alles, was mit "$21" anfängt, eingeengt ist, muss man folglich auch kein "$21" mehr schreiben. Das heißt: Speichere ich ein #$18 in $43x1, geht der nächste DMA in das Register $2118.

$43x2 bis $43x4 DMA Source Address for Channel x low byte/high byte/bank byte (define.asm: A1TxL, A1HxL, A1Bx)
Die Adresse der Daten, die zu übertragen sind (bzw., in die übertragen wird, falls Bit 7 in Register $43x0 gesetzt sein sollte, was nicht der Normalfall ist).
Die Reihenfolge ist Low Byte, High Byte, Bank Byte, das heißt:

Code: Alles auswählen

LDA #$00.b
STA $4302.w
LDA #$B8.b
STA $4303.w
LDA #$7F.b
STA $4304.w
Führt zu einem DMA, der bei Adresse $7FB800 anfängt, die Daten zu laden.

$43x5 und $43x6 DMA Size low byte/high byte (define.asm: DASxL, DASxH)
Setzt die Menge der Bytes, die übertragen werden.

Code: Alles auswählen

LDA #$00.b
STA $4305.b
LDA #$08.b
STA $4306.b
Das wiederum setzt, dass $800 Byte übertragen werden. Alternativ könnte man natürlich auch mit einem 16-Bit-Register schreiben:

Code: Alles auswählen

LDX #$0800.w
STA $4305.w
Der Effekt ist derselbe.
Es sei noch darauf hingewiesen, dass, wenn man $0000 als Data Size einträgt, nicht null, sondern $10000 Byte übertragen werden. Obacht! Kann aber auch nützlich sein.

Abschließend muss man noch auf ein Register eingehen:
$420B DMA Enable (define.asm: MDMAEN)
Dieses Register ist die Zündschnur der DMAs. Nachdem man alle Werte in die DMA-Channel-Register eingetragen hat, kann man hier signalisieren, dass der DMA ab jetzt durchgeführt werden kann. Dabei ist die Reihenfolge: Bit 0 für Channel 0, Bit 1 für Channel 1 usw.
Heißt also: $01 aktiviert Channel 0, $04 aktiviert Channel 2, $80 aktiviert Channel 7.

Und fertig. Damit haben wir's.
Beim nächsten Mal gehen wir noch einmal zurück zu unserem ersten Programm und werden dort mit DMA arbeiten, um es einmal in Aktion zu sehen. Nähere Informationen zu den einzelnen Registern kann man bis dahin auch hier nachlesen.

* Wir erinnern uns: VBLANK war die vertikale Austastlücke, HBLANK war die horizontale Austastlücke, FBLANK war das manuelle Abschalten des Bildschirms.
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.

snoer
SNES-Programmer
SNES-Programmer
Beiträge: 249
Registriert: 27. Januar 2013, 13:10
+Positive Tradingpoints+: 5 von 5

Re: Maggi-Fix für SNES Programmierung

Beitrag von snoer » 27. Januar 2013, 19:30

Moin!
Also erstmal super was du hier machst!
das ein oder andere hab ich mir zwar auch schon von anderen seiten angelesen, aber in der muttersprache und mit sowas wie einer reihenfolge fällt es dann doch leichter sich in die materie reinzuarbeiten. Vielen Dank!!

so und jetzt meine Fragen

was bedeutet das .w und das .b hinter deinen anweisungen?

Code: Alles auswählen

    LDA #$10.b
    STA BG1SC.w
    STZ BG12NBA.w
ich hatte bisher einige der bazz tutorials durchgearbeitet und stellenweise quertys und joshis docs gelesen, aber da ist das nie vorgekommen.

dann würd ich gerne wissen ob es irgendeinen vorteil bringt seine tiles als binär daten einzubinden. ich habe nach den bazz tutorials meine tiles mit pcx2snesWIN v1.1 von eKid convertiert (der läuft einwandfrei unter windows7 64bit.. ich packe ihn mal in den anhang) und der spuckt eine normale asci .inc aus (in der ich dann nachträglich die sektionen umbenannt habe) aus.
das sieht dann so aus:

Code: Alles auswählen

; Created with eKid's pcx2snes converter ;

Tiles:
    .db $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF
    .db $00, $00, $00, $00, $00, $00, $00, $00, $00, $00, $00, $00, $00, $00, $00, $00, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF
    .db $EF, $2F, $0F, $FF, $FF, $7F, $3F, $3F, $FF, $FF, $F0, $F0, $EA, $EA, $DA, $D0, $7F, $8F, $AF, $CF, $3F, $3F, $7F, $7F, $FF, $FF, $F0, $FF, $E0, $FF, $CA, $FF
    .db $F7, $F4, $F0, $FF, $CF, $CE, $B4, $B4, $B7, $87, $37, $07, $B7, $87, $B7, $07, $FE, $F1, $F5, $F3, $CC, $FC, $86, $FE, $B7, $FF, $37, $FF, $37, $FF, $B7, $FF
    .db $FF, $00, $FF, $00, $FF, $00, $FF, $00, $FF, $00, $FF, $00, $FF, $00, $FF, $00, $00, $00, $00, $00, $00, $00, $00, $00, $00, $00, $00, $00, $00, $00, $00, $00
    .db $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $00, $00, $00, $00, $00, $00, $00, $00, $00, $00, $00, $00, $00, $00, $00, $00
    .db $DA, $C0, $DF, $C5, $DF, $C0, $DF, $D0, $2F, $28, $F0, $70, $0F, $FF, $EF, $2F, $DA, $FF, $DA, $FF, $DF, $FF, $CF, $FF, $67, $7F, $30, $3F, $AF, $CF, $7F, $8F
    .db $F7, $47, $F7, $07, $F7, $07, $F7, $17, $CC, $4C, $3F, $3E, $F0, $FF, $F7, $F4, $B7, $FF, $F7, $FF, $F7, $FF, $E7, $FF, $8E, $FE, $3C, $FC, $F5, $F3, $FE, $F1
    .db $00, $FF, $00, $FF, $00, $FF, $00, $FF, $00, $FF, $00, $FF, $00, $FF, $00, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF
    .db $00, $FF, $00, $FF, $00, $FF, $00, $FF, $00, $FF, $00, $FF, $00, $FF, $00, $FF, $00, $FF, $00, $FF, $00, $FF, $00, $FF, $00, $FF, $00, $FF, $00, $FF, $00, $FF
    .db $00, $FF, $00, $FF, $00, $FF, $00, $FF, $00, $FF, $00, $FF, $00, $FF, $00, $FF, $FF, $00, $FF, $00, $FF, $00, $FF, $00, $FF, $00, $FF, $00, $FF, $00, $FF, $00
    .db $00, $FF, $00, $FF, $00, $FF, $00, $FF, $00, $FF, $00, $FF, $00, $FF, $00, $FF, $00, $00, $00, $00, $00, $00, $00, $00, $00, $00, $00, $00, $00, $00, $00, $00
    .db $FF, $00, $FF, $00, $FF, $00, $FF, $00, $FF, $00, $FF, $00, $FF, $00, $FF, $00, $00, $FF, $00, $FF, $00, $FF, $00, $FF, $00, $FF, $00, $FF, $00, $FF, $00, $FF
    .db $FF, $00, $FF, $00, $FF, $00, $FF, $00, $FF, $00, $FF, $00, $FF, $00, $FF, $00, $FF, $00, $FF, $00, $FF, $00, $FF, $00, $FF, $00, $FF, $00, $FF, $00, $FF, $00
    .db $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $00, $FF, $00, $FF, $00, $FF, $00, $FF, $00, $FF, $00, $FF, $00, $FF, $00
    .db $00, $00, $00, $00, $00, $00, $00, $00, $00, $00, $00, $00, $00, $00, $00, $00, $FF, $00, $FF, $00, $FF, $00, $FF, $00, $FF, $00, $FF, $00, $FF, $00, $FF, $00

Palette:
    .db $6C, $40, $93, $4C, $5F, $08, $5F, $78, $64, $4D, $44, $1E, $5F, $09, $44, $4E
    .db $D7, $39, $C4, $1E, $71, $12, $1B, $42, $58, $6E, $7F, $4E, $BF, $0A, $F3, $67

; 16 tiles (0 spaces)
; 512 bytes
..das kam mir jetzt erstmal irgendwie vorteilhaft vor, weil man sehen kann was drin steht.


öhh ja.. also vor allem die erste frage ist mir wichtig, weil es mir wiederstrebt dinge zu schreiben von denen ich nicht schnalle wozu sie gut sind ;)

jo, also wie gesagt! vielen Dank für deine bisherigen Anstrengungen das Thema zu beleuchten!

ps (spekulativ&etwas offTopic).:
achja, du hast dich eingangs gefragt warum man um ein tile jeweils einen 1px rand lassen sollte. mir fallen da spontan ninepatch grafiken ein wobei ich nicht zu sagen verman ob es möglich ist sowas auf dem snes zu implementieren. wenns aber ginge, dann wäre das ziemlich sexy! in diesem artikel gehts eigentlich darum wie man sowas in libgdx einbindet, aber was ein ninepatch ist und wie er funktioniert wird gut erklärt
Dateianhänge
pcx2snesWIN.zip
pcx2snes converter v1.1 - by eKid
(23.12 KiB) 893-mal heruntergeladen

Benutzeravatar
lytron
Code Bro
Code Bro
Beiträge: 2664
Registriert: 12. August 2012, 20:18
+Positive Tradingpoints+: 12 von 12
Wohnort: ハノーファー区
Kontaktdaten:

Re: Maggi-Fix für SNES Programmierung

Beitrag von lytron » 27. Januar 2013, 19:53

Moin,

danke für die Resonanz, es ist schön, das alles nicht umsonst zu schreiben! :D

Die Erweiterung mit ".b" und ".w" steht jeweils für "Byte" und "Word", es gibt dann noch ".l" für Long.

Hängt mit WLA DX zusammen, denn das schnallt manchmal nicht, ob es jetzt einen oder zwei Byte als Argumente zu dem Befehl zupacken soll, und demnach können Fehler entstehen.

Ville Helin beschrieb es in der WLA DX Doc so:

Code: Alles auswählen

14.2. 6502

For example mnemonics ADC, AND, ASL, etc... cause problems to WLA, because
they take different sized arguments. Take a look at this:

LSR 11       ; $46 $0B
LSR $A000    ; $4E $00 $A0

The first one could also be

LSR 11       ; $4E $0B $00

To really get what you want, use .8BIT, .16BIT and .24BIT directives. Or
even better, supply WLA the size of the argument:

LSR 11.W     ; $4E $0B $00


Zum zweiten: Das ist Geschmackssache, denke ich. Bei der Variante, die du gewählt hast, werden die Sachen beim Kompilieren von WLA DX in Bytes umgewandelt und in die Datei eingefügt, bei "meiner" Variante sind die Sachen schon umgewandelt. Ich mache das lieber so, weil bei mir die Windows-Variante von PCX2SNES zumindest bisher nicht lief und ich bei der Kommandozeilen-Version mir nicht rausgesucht habe, wie das geht, es in diese Programm-Dateien ausspucken zu lassen. Außerdem macht es für mich keinen Unterschied, weil ich mir die Binärdateien genauso gut im Hexeditor anschauen kann, und da muss nicht auf Zeilenumbrüche oder ähnliches achten. Geschmackssache, wie gesagt.

Bei weiteren Fragen stehe ich dir gern zur Verfügung. ;)
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.

snoer
SNES-Programmer
SNES-Programmer
Beiträge: 249
Registriert: 27. Januar 2013, 13:10
+Positive Tradingpoints+: 5 von 5

Re: Maggi-Fix für SNES Programmierung

Beitrag von snoer » 28. Januar 2013, 01:49

jagut Sir..
also es geht direkt los mit einer Frage ob ich das jetzt richtig verstehe:

Code: Alles auswählen

LDA #INIDSP_FORCE_BLANK.b
STA INIDSP.w
erste Zeile:
schnappt sich eine 1, also %0000.0001 und verschiebt sie um 7 stellen nach links
-> A = #%1000.0000 (also ist der Wert von A 1byte lang)

zweite Zeile:
kippt A in $2100 rein allerdings als WORD aka 2byte lang (?)
..aber A ist doch nur 1byte lang!
schmeisst er dann nicht folgerichtig in $2101 den Wert #%00000000 rein?

warum soll er das denn machen? oder liege ich da schon falsch? *grübel

..und A ist doch eh nur 1byte groß weil wir im emulation mode sind.. ahh :) *rubberduck
grad nachgeguckt. wir sind im native mode laut InitSNES.asm
also ist A doch 2byte groß.. aber was steht da jetzt drin?
guess1: #%00000000 #%10000000
guess2: #%10000000 #%00000000

..*kratz
..und passiert dann nicht eh wieder genau das was ich am anfang vermutet habe?
wir überladen einen 8bit register ($2100) mit 16bit, also schreibt er lustig in $2101 weiter
oder bin ich jetzt total blöd? *grübel
versteckter Inhalt:

Code: Alles auswählen

|     |       |                                                              |
| w   |$2100  |Screen display register [INIDISP]                             |
|     |       |x000bbbb              x: 0 = Screen on.                       |
|     |       |                         1 = Screen off.                      |
|     |       |                   bbbb: Brightness ($0-$F).                  |
|     |       |                                                              |
|     |       |                                                              |
| w   |$2101  |OAM size register [OBSEL]                                     |
|     |       |sssnnbbb              s: 000 =  8x8  or 16x16.                |
|     |       |                         001 =  8x8  or 32x32.                |
|     |       |                         010 =  8x8  or 64x64.                |
|     |       |                         011 = 16x16 or 32x32.                |
|     |       |                         100 = 16x16 or 64x64.                |
|     |       |                         101 = 32x32 or 64x64.                |
|     |       |                      n: Name selection (upper 4k word addr). |
|     |       |                      b: Base selection (8k word seg. addr).  |
|     |       |                                                              |

Benutzeravatar
lytron
Code Bro
Code Bro
Beiträge: 2664
Registriert: 12. August 2012, 20:18
+Positive Tradingpoints+: 12 von 12
Wohnort: ハノーファー区
Kontaktdaten:

Re: Maggi-Fix für SNES Programmierung

Beitrag von lytron » 28. Januar 2013, 06:04

Es wäre in sich schlüssig, was du schreibst, also "blöd" bist du nicht! ;)

Das ".w" und ".b" bezieht sich allerdings auf die Größe des Arguments, nicht auf die Größe des Registers.

Heißt: Bei einem 8-Bit-Akkumulator würde man trotzdem dashier schreiben:

LDA #$00.b ; Absoluter Wert
LDA $10.b ; Direct Page Register
LDA $2143.w ; Address
LDA $7F0000.l ; Long Address

Und er würde jeweils nur einen Byte laden. Weil die Adresse $2143 hexadezimal vierstellig ist, muss da ein ".w" hin. Weil die Adresse $7F0000 hexadezimal sechsstellig ist, muss da ein ".l" hin.

Folglich wird, bei deinem Beispiel, wirklich nur #$80 (#%1000.0000) in Register $2100 gespeichert, $2101 wird nicht verändert. :)
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.

snoer
SNES-Programmer
SNES-Programmer
Beiträge: 249
Registriert: 27. Januar 2013, 13:10
+Positive Tradingpoints+: 5 von 5

Re: Maggi-Fix für SNES Programmierung

Beitrag von snoer » 31. Januar 2013, 01:48

in einem der bass tutorials geht es um das Register $2107..
da steht:
Since there is only 64K of VRAM, the Most Significant Bit (bit 7) must be ZERO.

Ich habe nachgelesen was ein msb ist, aber irgendwie wird mir der Zusammenhang trotzdem nicht so wirklich klar..

Register $2107 sieht ja so aus

Code: Alles auswählen

aaaaaass
^
bit7
okay.. also.. %100.000 = decimal 64
damit wird das was zu tun haben vermute ich. aber irgendwo fehlen mir da trotzdem noch ein paar groschen zur mark.

Benutzeravatar
lytron
Code Bro
Code Bro
Beiträge: 2664
Registriert: 12. August 2012, 20:18
+Positive Tradingpoints+: 12 von 12
Wohnort: ハノーファー区
Kontaktdaten:

Re: Maggi-Fix für SNES Programmierung

Beitrag von lytron » 31. Januar 2013, 06:31

Ich verstehe das selbst nicht.

bazz schrob im Ganzen über das Register $2107:
Register $2107

BG1 Tile Map Location (1B/W)

aaaaaass a: Tile map address s: Screen size: 00=32x32 01=64x32 10=32x64 11=64x64

The a bits set the starting tilemap address. This can be set in intervals of $0400 words. So setting the a bits to 1 sets the address to $0400, incrementing that would set it to $0800, etc. If you want to convert the bits into the address itself to see, shift them left by 10. (1 left shift 10 = $0400) Since there is only 64K of VRAM, the Most Significant Bit (bit 7) must be ZERO. $2108-$210A are the same exact thing as $2107, only for BG2-BG4, respectively.
Vermutlich ist das ein Fehler im Tutorial. Denn:
Man kann im VRAM von $0000 bis $FFFF adressieren, und $2107 funktioniert in #$400er-Schritten folglich wäre der höchstmögliche Schritt ein Abzielen auf $FC00, und das wäre ein Wert von #$FC (=#%11111.1100) in $2107 (die Spiegelungsbits habe ich mal außen vor gelassen. Und holerö, da ist er, der Most Significant Bit! ;) Folglich denke ich, dass bazz' Tutorial da falsch liegt.
(Das Register habe ich in diesem Tutorial erklärt. Wenn du zu der Erklärung noch Fragen hast, stell sie, dann kann ich mein Tutorial verbessern)
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.

Benutzeravatar
ikari_01
snesfreaks.com-Team
snesfreaks.com-Team
Beiträge: 441
Registriert: 15. Juni 2010, 23:19
+Positive Tradingpoints+: 6 von 6
Wohnort: Wunstorf

Re: Maggi-Fix für SNES Programmierung

Beitrag von ikari_01 » 31. Januar 2013, 07:14

This can be set in intervals of $0400 words.
Das könnte man auch schreiben als:
This can be set in intervals of $0800 bytes.
Das VRAM ist 16 Bit breit und wird in diesem Fall in Words adressiert. Folglich ist der sinnvolle Adressbereich 0000-7FFF und somit der höchste sinnvolle Wert %011111 (=$7C00, bzw. $F800 in Bytes).
Die PPUs können theoretisch 128kB VRAM bedienen, im SNES ist aber nur die Hälfte verbaut.
sd2snes news: https://sd2snes.de

Benutzeravatar
lytron
Code Bro
Code Bro
Beiträge: 2664
Registriert: 12. August 2012, 20:18
+Positive Tradingpoints+: 12 von 12
Wohnort: ハノーファー区
Kontaktdaten:

Re: Maggi-Fix für SNES Programmierung

Beitrag von lytron » 31. Januar 2013, 07:43

Wie, was? Im VRAM kann man nur von $0000 bis $7FFF adressieren? War mir nie aufgefallen... :shock:
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.

Benutzeravatar
ikari_01
snesfreaks.com-Team
snesfreaks.com-Team
Beiträge: 441
Registriert: 15. Juni 2010, 23:19
+Positive Tradingpoints+: 6 von 6
Wohnort: Wunstorf

Re: Maggi-Fix für SNES Programmierung

Beitrag von ikari_01 » 31. Januar 2013, 07:51

Kommt drauf an, wie man es sich zurechtlegt. :D
Du kannst von $0000-$7FFF adressieren, oder aber von $0000-$FFFE in Zweierschritten. ;)
Die Adresse, die man in den VRAM-Adressport schreibt (für DMA-Krams u.a.), ist aber auch in Words.
sd2snes news: https://sd2snes.de

Benutzeravatar
lytron
Code Bro
Code Bro
Beiträge: 2664
Registriert: 12. August 2012, 20:18
+Positive Tradingpoints+: 12 von 12
Wohnort: ハノーファー区
Kontaktdaten:

Re: Maggi-Fix für SNES Programmierung

Beitrag von lytron » 31. Januar 2013, 08:27

Moment, lass mich rekapitulieren.

Wir haben $10000 (= 65536) Byte Speicher, und wenn ich über $2116/7 arbeite, ist die Adressierungsart folgendermaßen:

$0000 - 2 Byte
$0001 - nicht existent
$0002 - 2 Byte
$0003 - nicht existent
usw.

Während Register $2107-A es so betrachten:
$0000 - 2 Byte
$0001 - 2 Byte (= vormaliges $0002)
usw.

Aye?
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.

Benutzeravatar
ikari_01
snesfreaks.com-Team
snesfreaks.com-Team
Beiträge: 441
Registriert: 15. Juni 2010, 23:19
+Positive Tradingpoints+: 6 von 6
Wohnort: Wunstorf

Re: Maggi-Fix für SNES Programmierung

Beitrag von ikari_01 » 31. Januar 2013, 09:22

Bei 2116/7 ist die Adressierungsart:
$0000 - 2 Byte
$0001 - 2 Byte
etc.
Bei 2107-A hast du ja eh nur eine Handvoll Bits, da ist es dir überlassen, wie du das in eine Adresse überträgst. ;)
sd2snes news: https://sd2snes.de

Benutzeravatar
lytron
Code Bro
Code Bro
Beiträge: 2664
Registriert: 12. August 2012, 20:18
+Positive Tradingpoints+: 12 von 12
Wohnort: ハノーファー区
Kontaktdaten:

Re: Maggi-Fix für SNES Programmierung

Beitrag von lytron » 31. Januar 2013, 09:27

Das hieße, ab #$7F ist bei $2117 Schluss? o_O Ich hätte schwören können, dass ich da auch mal ohne größere Probleme bis $FF schreiben konnte... Oder wird $00 bis $7F auf $80 bis $FF gespiegelt?
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.

Antworten