Maggi-Fix für SNES Programmierung

lytron · Beitrag von **lytron** » 25. September 2012, 18:13

Es besteht Bedarf an Artikeln zum Thema SNES-Programmierung.
Speziell an einsteigerfreundlichen.
Deswegen möchte (und darf) ich ab jetzt hier als Vorschreiberling fungieren, und bräuchte eure Mithilfe.

Es wäre schön, wenn ihr direkte Fragen äußern könntet, die ich dann beantworte. Ich möchte hier dringend drauf hinweisen, dass ich selbst noch Lernender bin. Deshalb kann es auch sein, dass meine Aussagen von einiger Seite noch einmal korrigiert werden. Aber grundsätzlich werde ich schon darauf achten, strickt Dinge zu trennen, von denen ich weiß, dass sie so sind, und wo ich davon ausgehe, dass sie so sind.

Also, stellt mir Fragen, ich beantworte sie, es wird dann und wann mal geprüft, ob dem so ist, wie ich sage, und anschließend wird das gesamte in Artikeln zusammengefasst. Dementsprechend könnt ihr dort direkt mitwirken, indem ihr nachfragt, wenn euch etwas zu schwammig oder gar zu bildhaft formuliert ist, wo Zusatzinfos angebracht wären, was gestreckt werden könnte etc.

So weit, so gut. Packen wirs an.

Svambo · Beitrag von **Svambo** » 25. September 2012, 19:38

Super Projekt von Dir! Fangen wir doch mal ganz vorne an:

1) Welche Entwicklungsumgebung braucht man? Welche Tools, Converter etc. ?

Beitrag von **Redscorpion** » 25. September 2012, 20:01

Bau das doch so hier auf.
http://www.portabledev.com/wiki/doku.ph ... llation_en

gruß

red

lytron · Beitrag von **lytron** » 25. September 2012, 20:02

Svambo hat geschrieben:Super Projekt von Dir! Fangen wir doch mal ganz vorne an:

Der Dank gilt in erster Linie Moi und seinen Kohorten, die er fürs Korrekturlesen abbestellt.

Svambo hat geschrieben:1) Welche Entwicklungsumgebung braucht man? Welche Tools, Converter etc. ?

Der d4s hat ja bereits eine gute Menge zusammengestellt, und eigentlich benutze ich einen Teil von den Programmen.
Es gibt die Möglichkeit, SNES-Programme mit Assembler oder C zu schreiben. Assembler ist grob vereinfacht gesagt "direkte Computersprache". (HALBWISSEN) Irgendwann kamen findige Hunde darauf, ein Programm zu schreiben, mit dem Sie Programme in C schreiben können, und dass den ganzen Kram in Assembler übersetzt. Hat den Vorteil, dass Leute, die C bereits beherrschen sich viele Dinge so vereinfachen können, weil sie die Befehle so schreiben können, wie sie es bereits gewöhnt sind. (/HALBWISSEN)
Es werden beide Varianten heute noch "gelebt", N-Warp Daisakusen und MegaFamilyBros sind rein in Assembler geschrieben, Classic Kong in C ((HALBWISSEN) Und wenn ich mich recht entsinne, hat d4s für Super Road Blaster auch in das C-Lager gewechselt

(/HALBWISSEN) ).

Ich persönlich nutze Assembler, weil ich bei meinen paar vorherigen halbherzigen Versuchen, C(++) zu lernen, schnell gescheitert bin und dementsprechend mich wenig dazu motivieren kann. Außerdem habe ich schon durch Excel-Spielereien großes Vergnügen gefunden, mit einer relativ begrenzten Anzahl von Befehlen kompliziertere Funktionen zusammenzupuzzlen, und das passt gut auf Assembler, weil die Befehle begrenzt sind (es sind insgesamt weniger als 256).

Daaarum... wer meint, mit mir programmieren lernen zu wollen, muss mit Assembler vorlieb nehmen.

Für das Programmieren benutze ich WLA DX. Das ist ein Kommandozeilenprogramm, das Codedateien in Dateien umwandelt, die der SNES versteht (die dann solche Endungen haben wie "SFC", oder, was wesentlich populärer ist, "SMC").

Die Codedateien erstelle ich mit Wordpad.
Testen tu ich die Programme gern mit BSNES und ZSNES, wobei ZSNES optional, BSNES aber eine definitive Empfehlung ist. Außerdem nutze ich gern mein Super Everdrive.

Also, kurz zusammengefasst:
- BSNES
- WLA DX

Es gibt dann noch allerlei kleine Helferlein, die man dann später gebrauchen kann, aber ich würde sagen, zu denen kommt man, sobald es soweit ist.

lytron · Beitrag von **lytron** » 25. September 2012, 20:07

Redscorpion hat geschrieben:Bau das doch so hier auf.
http://www.portabledev.com/wiki/doku.ph ... llation_en

Werde ich überdenken, erstmal möchte ich Content produzieren. Ich bin jemand, der sich dann zu schnell in Style over Substance verrennt.

lytron · Beitrag von **lytron** » 25. September 2012, 22:03

Ein nächster Brocken vom Basiswissen:

Von den Nullen und Einsen bis zum Dirigieren des Prozessors

Null: Strom aus, eins: Strom an.
Der Mensch "spricht" mit dem Prozessor durch Kombinationen aus "Strom aus" und "Strom an".

Beim Super Nintendo zum Beispiel ist es so, dass der Prozessor weiß, dass acht solcher Kombinationsfolgen einen Befehl ergeben.
Abhängig davon, welcher Befehl es ist, weiß der Prozessor dann das, was danach kommt zu interpretieren. Soll heißen: Wenn ich dem Computer sage: "Addiere!", wird er logischerweise sagen: "Gerne, aber was?". Dementsprechend, wenn er acht Nullen und/oder Einsen als "Addiere"-Befehl erkennt, weiß er, dass danach eine Zahl kommen muss. Ein anderer Befehl hat keine solchen zusätzlichen Angaben. Das bedeutet, er weiß, wenn er in den 8 Nullen oder Einsen (eine "Null oder Eins" ist ein Bit, acht Bit sind ein Byte) einen solchen Befehl erkennt, weiß er automatisch, dass der nächste Wert ein Befehl ist.

Es wird einem immer wieder beim Thema "Super Nintendo Programmieren" begegnen, dass viele Dinge eigentlich vieldeutig sind, aber da das SNES immer nach festen Prinzipien vorgeht, "weiß" es "aus dem Zusammenhang heraus", wie es die Daten zu deuten hat. Zum Beispiel kann "00001010" kann ein Befehl sein, eine Zahl, ein Teil einer Farbe, ein Teil einer Grafik, eine Adresse oder etwas ganz anderes. Kommt auf den Zusammenhang an.
Übrigens, kleiner Nebengedanke: Natürlich ist das logischerweise auch eine gute Möglichkeit, einen totalen Super-GAU anzurichten, wenn man den Prozessor mitten in eine Grafik schickt und ihm sagt: "Diese Grafikdaten sind alles Befehle". Der Prozessor hat keine Möglichkeit, das zu erkennen und von selbst soweit zurückzurudern, und dann das Programm "richtig" auszuführen. Das bedeutet: Der Prozessor vertraut blind deinem Programm. Schreib ordentlich!

Gesteuert wird der Prozessor. Der Prozessor besteht im Großen und Ganzen aus zwei Sachen: Der ALU und den Registern.
Die Register sind das Kurzzeitgedächtnis des SNES. Die Register sind beim SNES 16-Bit groß. Übrigens spricht man deshalb auch von einer 16-Bit-Konsole. Du kennst den Kram mit 32-Bit- und 64-Bit-Architektur beim Computer? Der Prozessor deines Computers hat dementsprechend 32-Bit- oder 64-Bit große Register.
Beim SNES sind Sie 16-Bit-groß, lassen sich aber auf 8-Bit-Größe runterschalten. Dazu später mehr.
Der SNES hat drei Register, den Akkumulator (abgekürzt mit A) und zwei Indexregister (abgekürzt mit X und Y). Der Akkumulator ist sozusagen das "zentrale Kurzzeitgedächtnis", X und Y sind Hilfsregister. Es gibt mehr Befehle, wo man den Inhalt von A bearbeiten kann, als X und Y.
SNES-Programmierung hat häufig auch etwas von Schieberätseln, weil du dir gut überlegen musst, welchen Wert du in welches Register ziehen musst, welchen Wert du wie bearbeiten musst, und wie du transferieren oder eventuell auslagern musst, damit du im Akkumulator genau den Wert hast, mit dem du gerade die Funktion ausführst, die du nur mit dem Akkumulator machen kannst.

Die ALU ist die "Arithmetic-Logical Unit", die Arithmetisch-logische Einheit.
Arithmetik sind die Grundrechenarten, mit Logik sind hier Befehle gemeint wie "Vergleiche zwei Bits, und wenn die beiden Bits beide 0/nur einer 1/beide 1/mindestens einer 1 ist, dann gib im Ergebnis an der Stelle den Bit 1 aus, ansonsten 0".
Die ALU verändert gegebenenfalls die Werte in den Prozessor-Registern, je nachdem welcher Befehl gegeben wird.

Was der Prozessor maßgeblich macht, ist: Werte in seine Register laden, diese Werte vergleichen oder verarbeiten (das heißt: Mit ihnen rechnen), und diese Werte aus seinem Register an eine andere Stelle speichern. Man schreibt kein gesondertes Programm für, zum Beispiel, den Grafikchip, sondern steuert den indirekt; gibt dem Prozessor die Befehle, durch deren Ausführung er dem Grafikchip Befehle gibt. Das heißt faktisch: Man lädt bestimmte Werte in die Register und speichert sie an ganz bestimmten Stellen, und der Grafikchip weiß dann, was er zu machen hat.

Mein YT Channel · Beitrag von **ChronoMoogle** » 27. September 2012, 16:28

Da dies ja eine Art FAQ werden soll, stellt sich vor allem eine Frage, die gerne von Unwissenden gestellt wird. Kann man gut als Einleitung nehmen.

Ich habe heute XY gespielt und finde es sauklasse!!1 Ich moechte jetzt auch ein Spiel fuer das SNES programmieren und habe ganze vier Wochen Schulferien! Wie krieg ich das jetzt schnell hin? Ich habe schon alle Ideen beisammen!

Gibt es halt immer wieder. ;)

lytron · Beitrag von **lytron** » 27. September 2012, 21:05

So. Ich hoffe, das ist ausführlich und abschreckend genug geschrieben.

Auch das hier ist wieder nur eine Rohfassung, falls wirklich mal das in Artikel/FAQ-Fassung benutzt wird, kann das ja prägnanter und gebündelter formuliert werden.

Ich habe heute XY gespielt und finde es sauklasse!!1 Ich moechte jetzt auch ein Spiel fuer das SNES programmieren und habe ganze vier Wochen Schulferien! Wie krieg ich das jetzt schnell hin? Ich habe schon alle Ideen beisammen!

Es ist erfreulich, dass du das SNES für dich entdeckt hast und das du deiner Begeisterung so Ausdruck verleihen möchtest. Und deshalb sei dir wärmstens empfohlen, ein Spiel in SNES-Optik mit Game Maker für den PC zu machen.

SNES-Programmierung ist selbst heutzutage nicht einfach. Auch wenn es für einzelne Spiele wie Super Mario World oder Super Metroid Editoren gibt, heißt das nicht, dass man sich mittlerweile alles aus den Ärmeln schütteln kann. Nach gut zwanzig Jahren, die es das SNES gibt, gibt es immer noch keine Masse an selbstgemachten, abendfüllenden Spielen für die Konsole. Bitte bedenke das und bitte bedenke, dass es nicht daran liegen kann, dass keiner die Konsole mag und das vorher kein ambitionierter Hobbyentwickler auf dieselbe Idee gekommen ist.
Wenn du dir die besagten Editoren anschaust, wirst du auch feststellen, dass sie nicht unbedingt so bedienerfreundlich sind, wie man es sich wünschen würde, sondern dass sie auch in vielen Dingen nach ganz eigenen Spielregeln spielen, sodass das Erlernen des gekonnten Umgangs mit ihnen auch ein zeitintensiveres Unterfangen ist.

Was macht das Thema SNES-Programmierung so schwierig? Da es keinen alles vereinfachenden Editor gibt, muss man ganz an die Basis. Das bedeutet, in der Art zu Programmieren lernen, wie man es vor zwanzig Jahren getan hat, und um das zu können, muss man auch bereit sein, sich ein grundlegendes technisches Verständnis anzueignen. So simpel manche Spiele für das SNES auch sind oder erscheinen mögen, sollte man immer bedenken, dass sie von einer Vielzahl von Menschen geschrieben wurden, die langjährige berufliche Erfahrung mit Programmieren haben - was überzeugt dich, alleine und ohne derartige Vorbildung in deinen Sommerferien schnellere Ergebnisse zu Tage zu fördern?
Außerdem musst du dich damit abfinden, dass du alleine arbeiten musst. Es gibt einige Leute, die einen gehörigen Fundus an Informationen haben. Diese Leute sind gern bereit, dir bei gezielten Fragen unter die Arme zu greifen. ABER: Da diesen Leuten bewusst ist, wie viel Zeit dabei draufgeht, jemandem dieses Thema zu erklären, solltest du verstehen, dass sie dir nicht alles vorkauen werden. Wenn du bereit wärst, wochenlang von diesen Leuten darin "unterwiesen" zu werden, wenn sie sich dafür bereit erklären würden, bist du dann auch bereit, dir die Wikipedia-Artikel und Dokumentationen zu erarbeiten, auf die sie dich hinweisen? Bist du bereit, auch alleine weiterzuforschen, wenn du von ihnen keine Antwort erhälst?
An dieser Stelle ist es leider nötig, auf etwas hinzuweisen:
Du wirst niemanden finden, der dir einen Editor für Spiel xy schreiben wird. Auch nicht für Geld. Die Idee, dass das jemand für Geld tun könnte, kann nur von jemandem stammen, der nicht abschätzen kann, was für ein Aufwand es ist, das zu tun. Deswegen: Vertraue auf den Verstand anderer Menschen. Wenn es "eben mal so einfach möglich wäre", dann wäre es schon geschehen.

Nächster Punkt:
Weshalb soll dein Spiel unbedingt für das SNES sein? Nur, weil das SNES-Programmieren kompliziert ist, heißt das nicht, dass du damit Anerkennung ernten kannst. Rechne von der Vielzahl der Menschen aus deinem Freundes- und Bekanntenkreis mit Reaktionen zwischen Desinteresse und Stirnrunzeln. Du hast es hier mit einer Videospielkonsole aus dem Anfang der Neunziger zu tun, die einige noch kennen, ein paar gut finden, noch ein paar weniger die eine oder andere nette Erinnerung daran haben, aber selbst von diesen Personen der geringste Teil ernsthaft daran Interesse hat, auch nur hinter seinen Fernseher zu kriechen, um dieses Ding nochmal anzuschließen und losspielen zu können, geschweige denn sich damit zu befassen, weshalb es so eine Mammutarbeit ist, das Ding zu programmieren und weshalb du über Jahre(!) bereit bist(?), deine Freizeit dafür zu verbrennen, und weshalb du dich über das neugewonnene Verständnis eines winzigen technischen Details in Freudentänzen ergehst.
Ferner, als kleiner Schwank nebenbei, kann eine kleine, dumme Unachtsamkeit beim Programmieren dich für Tage und Wochen auf Fehlersuche schicken, ohne dass dir etwas auffallen wird. Das heißt, auch wenn du dich mühevoll vorwärtsgekämpft hast, stehst du oft genug ratlos da und beginnst, an deinen eigenen Fähigkeiten zu zweifeln.
Wenn du das SNES-Programmieren lernen willst, weil du davon ausgehst, in absehbarer Zeit vorzeigbare Ergebnisse zu haben, weil du meinst, die Nische gefunden zu haben, in der du dich profilieren kannst - geh davon aus, dass du eher das Gegenteil erreichen wirst.

Darum, such dir einen guten Editor zum Spiele erstellen oder lern eine Programmiersprache, um ein Spiel für den Computer zu schreiben. Da es mittlerweile auch schicke Gamepads für den Computer gibt, es genug Grafiksets mit 16-Bit-Knuddelfiguren über Google aufzuspüren sind und die Grenze zwischen Fernseher und PC-Monitor seit einigen Jahren praktisch inexistent ist, gibt es keinen rationalen Grund mehr, sich mit dem SNES als Programmierplattform zu beschäftigen. Das steht hier nicht, weil wir nicht wollen, dass es neue Spiele gibt - ganz im Gegenteil: Damit deine Ideen, die sicherlich besser sind als die große Masse, nicht wegen zickiger, antiquierter Hardware versanden, solltest du wirklich ein System nehmen, dass wesentlich besser darauf zugeschnitten ist, dir schnell nützliche und nutzbare Ergebnisse zu liefern. Und das ist nicht das SNES. Das ist der Computer, an dem du gerade sitzt.

Mein YT Channel · Beitrag von **ChronoMoogle** » 28. September 2012, 07:39

Sorry, ich hatte in den falschen Thread gepostet, habe es noch kurz verschoben. Danke fuer die klasse FAQ-Antwort!

blackerking · Beitrag von **blackerking** » 3. Oktober 2012, 10:45

Wo finde ich eine Liste mit Assemblerbefehlen und kannst du mir ein paar einfache Funktionen wie IF/THEN/ELSE als Assembler Code zeigen? Sozusagen Eine Assembler-Befehlskette die eben zusammen einen C-Befehl ergeben?

lytron · Beitrag von **lytron** » 3. Oktober 2012, 11:28

blackerking hat geschrieben:Wo finde ich eine Liste mit Assemblerbefehlen und kannst du mir ein paar einfache Funktionen wie IF/THEN/ELSE als Assembler Code zeigen?

Eine alphabetische Liste der Befehle findest du im offiziellen Handbuch zum SNES-Prozessor. Der SNES-Prozessor ist der Ricoh 5A22, der wiederum annähernd dasselbe wie der WDC 65C816 ist, der kurz 65816 genannt werden kann. Die Unterschiede sind in dem Wikipedia-Artikel aufgelistet, und (HALBWISSEN) liegen maßgeblich darin, dass der 5A22 darauf ausgerichtet ist, dass Controller und keine Tastatur die Eingabegeräte sind, dass er es mit einem Fernseher als Ausgabegerät zu tun hat u. ä. (/HALBWISSEN)

Das offizielle Handbuch zum 65816 findest du hier (aus d4s' Development Resources), ab Seite 327 ist jedem Befehl eine Seite gewidmet. Oben rechts steht jeweils der Befehl (z. B. "ADC"), darunter steht, was er macht und wie sich dieser Befehl auf das Statusregister* auswirkt.

Für IF/THEN/ELSE gibt es z. B. keine eigenen Befehle, sondern man muss es sich aus einigen Rechen-, Vergleichs- und Sprungbefehlen zusammenbauen.

Ein Beispiel:

Code: Alles auswählen

LDA meineVariable
CMP #$FF
BNE NichtGleich
LDA #$01
STA ErgebnisVariable
NichtGleich:
LDA #$00
STA ErgebnisVariable

Erklärung im Schnelldurchgang:
"LDA meineVariable" --- Der Inhalt von meineVariable wird in den Akkumulator geladen
"CMP #$FF" --- Vergleiche (compare), ob im Akkumulator die Zahl "$FF" befindet. Das ist eine hexadezimale Zahl*; hexadezimale Zahlen werden in Assembler mit einem $-Zeichen gekennzeichnet. Das #-Zeichen zeigt an, dass es sich um eine Zahl handelt, und nicht um eine Speicheradresse**.
"BNE NichtGleich" --- Zweige hier ab, wenn das Ergebnis nicht gleich ist (branch not equal). Ist das Ergebnis gleich, macht er direkt bei der nächsten Zeile weiter; ist es nicht gleich, sucht er nach der Stelle im Quelltext, wo "NichtGleich:" steht, und macht dann da weiter.
"LDA #$01" --- Lade die Zahl $01 (= dezimal: 1) in den Akkumulator
"STA ErgebnisVariable" --- Speichere den Inhalt des Akkumulators in die Variable "ErgebnisVariable"
"NichtGleich:" --- Ein Label, eine Markierung für Sprung- oder Abzweigungsbefehle.
"LDA #$00" --- Lade die Zahl $00 (= dezimal: 0) in den Akkumulator
"STA ErgebnisVariable" --- Speichere den Inhalt des Akkumulators in die Variable

Was macht dieses bisschen Text?
Wenn "meineVariable" 255 ist, dann setzt es "ErgebnisVariable" auf 1, sonst setzt es sie auf 0.
Wenn, dann, sonst.
If, then, else.

blackerking hat geschrieben:Sozusagen Eine Assembler-Befehlskette die eben zusammen einen C-Befehl ergeben?

Ich weiß leider nicht, welche Befehle es alles gibt, bei der C-Entwicklungsumgebung integriert sind; am besten, du fragst nach konkreten Beispielen wie oben mit IF/THEN/ELSE.

*Für die absoluten Quereinsteiger sollte ich noch schreiben, was das ist. Wenns wer wissen will, nur bescheid sagen, dann hänge ich mich da eher hinter.

** Also, dass der Vergleichswert die Zahl $FF - dezimal: 255 - ist, und er nicht in Adresse $FF nachgucken muss, was dort für eine Zahl liegt, um das als Vergleichswert zu nehmen.

lytron · Beitrag von **lytron** » 3. Oktober 2012, 14:24

Zahlensysteme, Bits und Bytes (und Nybbles, und Words)

Im normalen Alltag benutzen wir das dezimale Zahlensystem, also das Zehnersystem. Wir benutzen zehn Ziffern, nämlich 0 und 1 bis 9. Sobald eine Zahl zu groß ist, um sie als einzelne Ziffer darzustellen, nehmen wir zwei Ziffern und setzen die zusammen. Das ist der Fall bei der Zehn, die stellen wir dann so dar: 10.
Ich rede deshalb über soetwas banales, da wir häufig beim Programmieren im Allgemeinen und definitiv beim SNES Programmieren im Speziellen auf zwei andere Zahlenformate stoßen.

Das erste ist das binäre Zahlensystem, das Zweier-Zahlensystem. Das besteht nur aus 0 und 1, und wie man sich denken kann, ist es gut, um ein einzelnes elektronisches Signal, ein Bit, darzustellen, ein "Strom an" oder "Strom aus". Logischerweise fängt man hier schon wesentlich früher an, Ziffern zusammenzusetzen, um Zahlen darstellen zu können. Namentlich beginnt das schon bei der Zwei, da nach der Eins ja das komplette Reportoire an Ziffern erschöpft ist. Soll heißen: Als Binärzahl sieht die Zwei so aus: 10. Binär zählt man 0, 1, 10, 11, 100, 101 usw.

Das zweite System ist das hexadezimale Zahlensystem, das Sechzehner-System. Hier nimmt man dann noch die Buchstaben A bis F hinzu und stellt sich vor, es wären eigenständige Ziffern, die einfach nach bzw. "über" der 9 kommen. Also: 1, 2, 3 ... 8, 9, A, B, C, D, E, F, 10, 11... usw. Folglich wird die Zehn in diesem Zahlensystem nicht als Kombination der Ziffern Eins und Null dargestellt, sondern als A. Die Ziffernfolge 10 wiederum bedeutet als Hexadezimalzahl (oder "Hexzahl", wenn's schnell gehen soll): Sechzehn.

Das ist natürlich irritierend, da demnach z. B. "1101", je nach Zusammenhang, etwas ganz anderes bedeuten kann: Dreizehn (= binäre 1101), Tausendeinhunderteins (= dezimale 1101) oder Viertausenddreihundertdreiundfünfzig (= hexadezimale 1101). Deshalb gibt es unterschiedliche Symbole, um deutlich zu machen, was man meint. Bei Assemblercode, der mittels WLA DX in SNES-Maschinencode umgewandelt wird, wird folgende Kennzeichnung verwandt:

Zahlen mit $-Zeichen vorweg sind Hexadezimalzahlen. ($1101)
Zahlen mit %-Zeichen vorweg sind Binärzahlen. (%1101)
Zahlen ohne Kennzeichnungen sind Dezimalzahlen. (1101)

Eine andere Schreibweise, die trotzdem nützlich zu wissen ist, ist diese:

Eine Null und ein kleines b für Binärzahlen (0b1101)
Eine Null und ein kleines x für Hexadezimalzahlen (0x1101)

Noch eine Kleinigkeit, die gut zu wissen ist: Im Dezimalsystem kennen wir ja den Tausender-Punkt, der uns hilft, Zahlen übersichtlicher zu gliedern. Im Binärsystem wird dieser Punkt immer nach vier statt nach drei Ziffern gesetzt, z. B.: 0b1100.1010. Das muss/darf beim Programmcode nicht verwandt werden.

Soweit zu den Zahlensystemen, kommen wir zu den Nullen und Einsen:

Wie bereits erwähnt ist ein "Strom an"- oder "Strom aus"-Signal ein Bit.
Acht Bit sind ein Byte.
Vier Bit werden manchmal als Nybble* beizeichnet.
In Bezug auf den Super Nintendo wird auch gern von einem Word geredet, wenn man zwei Byte meint. Alternativ kann man auch Doppelbyte sagen, was ich empfehlen würde, weil Word zu Verwirrungen führen kann, weil man bei ganz vielen anderen Computern und Videospielkonsolen unter einem Word etwas anderes versteht.*

Mit diesem Wissen lässt sich jetzt auch abschließend erklären, warum man das Hexadezimalsystem so gern beim (SNES-)Programmieren verwendet: Es passt exakt ein Nybble in eine Hexzahl. Der größte halbe Bytewert, das heißt die größte vierstellige Binärzahl, ist 0b1111. Und das ist =0xF. Das bedeutet wiederum, der größte Wert, den ein Byte darstellen kann, ist:

0b1111.1111 = 0xFF = 255.

Soweit klar?

Als letzter Tipp: Bei deinem Betriebssystem ist ein Taschenrechner-Programm dabei. Bei Windows Vista/7 findest du es unter dem Namen "Rechner" bzw. "calc.exe", bei älteren Windows-Versionen liegt es im Startmenü "Zubehör" (falls deine Windowsversion noch mit Arbeitsgruppen arbeitet, musst du die leider alle durchsuchen, da weiß ich nicht, wo der Rechner abgelegt ist), andere Betriebssysteme werden definitiv auch ein Taschenrechner-Programm haben.
Bei den Windowstaschenrechnern kann man zwischen diesen Zahlensystemen wechseln, wenn man den Rechner umstellt, um die Zusatzfunktionen zu bekommen. Bei Windows 7 tut man dies unter Ansicht --> Programmierer (Alt+3), bei älteren Windows-Versionen (98 und Konsorten) lief das noch über den "Wissenschaftlich"-Modus. Hier hat man nun links eine Schaltfläche, wo man zwischen "Hex", "Dez" und "Bin" wechseln kann. Wenn bereits eine Zahl im "Display" steht, wird diese entsprechend dem neuausgewählten Zahlensystem angepasst.

* Fußnote mit optionalem Zusatzwissen:
Schlaumeierei: Warum man sein Kind Nybble nennt und warum Words totale Opportunisten sind
Das Wort "Byte" klingt genauso wie das Englische "bite", was man als "Bissen" übersetzen kann. Mit diesem Hintergrund kam dann jemand auf die Idee, einen halben Byte einen "Nybble" oder "Nibble" zu nennen, da "nibble" ein kleiner Bissen, ein Happs bedeutet. Lustig, nicht? ... Nicht? ... Gut, dann nicht.
Im Bezug auf das SNES versteht man unter einem "Word" einen Doppelbyte. Allerdings ist es Prozessor-abhängig, welche Größe ein Word hat. Du weißt, dass der SNES eine 16-Bit-Konsole ist. Was hat denn 16 Bit, das dieser Konsole und quasi der gesamten Ära diesen Namen gegeben hat?
Der Akkumulator.
Im Normalfall hat der SNES-Akkumulator eine Größe von 16 Bit, also zwei Byte. Es sei der Vollständigkeit halber erwähnt, dass er sich auf 8 Bit runterstellen lässt, aber dazu an anderer Stelle mehr. Also, der SNES-Akkumulator, also das Ultrakurzzeitgedächtnis des SNES, das Ding, mit dem am meisten gerechnet, verglichen, und hin- und hergeschoben wird, ist 16 Bit groß. Darum 16-Bit-Konsole, darum 16-Bit-Ära. Der Akkumulator des NES-Prozessors war wie groß? Korrekt! 8 Bit!
Du lädst dir gerade ein Programm runter, und stehst vor der Wahl x86 oder x64. Was sollst du nehmen? Na, ist doch klar! Nimm x86, wenn dein PC eine 32-Bit-Architektur hat, und nimm x64, wenn du eine 64-Bit-Architektur hat! Nur... was heißt das jetzt? Das heißt, dass die Computerwelt zurzeit den Sprung macht, dass die Akkumulatoren in den Prozessoren der PCs neuerdings 8 Byte fassen können statt 4 Byte. Und deshalb muss jedes Programm da von Grund auf anders mit umgehen; das Schöne beim SNES ist, da man da regelmäßiger zwischen einem 8-Bit- und einem 16-Bit-Akkumulator wechselt, versteht man auch, warum.

Jedenfalls, das Problem mit dem Wort "word" ist, dass es auf jedem Prozessor eine andere Bedeutung hat; auf dem NES ist ein Word gleichzusetzen mit einem Byte, beim SNES nicht und bei deinem und meinem PC schon gar nicht. Darum ist das Treffendste, beim SNES von einem Doppelbyte zu reden, weil der überall gleichgroß ist.

lytron · Beitrag von **lytron** » 3. Oktober 2012, 15:20

Adressen: Banks, Pages, Memory-Mapped Input/Output

Das SNES benutzt Memory-Mapped Input/Output.

Aaalso.
Ich habe im vorherigen / in einem der vorherigen Klumpen Basiswissen gesagt, dass man beim Programmieren direkt mit dem Prozessor redet, und der maßgeblich Zahlenwerte in seine drei Register (den Akkumulator, das X- und Y-Register) zieht, sie prüft und eventuell umändert, und dann wieder ablegt.

Dazu benutzt man zum Beispiel den Speicher (engl. Memory).

Stell dir den Speicher als ein ganz ein hässliches, großes, graues Betongebäude ohne Fenster vor, in dem viele, viele Karteischränke stehen. Das ist der Speicher. Du bist jetzt der Akkumulator, und du hast für deinen heutigen Arbeitstag (d. h. Arbeitstakt) den Auftrag bekommen, etwas aus dem Speicher zu holen.
Da dummerweise alles in dem Gebäude gleichaussieht, gibt es keine optischen Orientierungspunkte, nach denen man dir eine Wegbeschreibung hätte geben können, sondern du kannst dich nur nach dem Zettel orientieren, den du dabei hast, auf dem steht, wo du gucken musst.
Also guckst du auf den Zettel und siehst: "Hol den Inhalt aus dem Karteikasten in der 200. Etage, 148. Regal, dritte Reihe, erste Spalte". Und dann machst du dich auf den Weg. Du stellst fest: Das Haus hat exakt 256 Stockwerke** (da es aufgrund der Brandschutzverordnung Probleme gab, die alle nach oben zu bauen, hat man die meisten unter Tage untergebracht; der Fahrstuhl ist temporarily out of order), pro Stockwerk stehen dort 256 Regalreihen mit Karteikästen, wobei in einer Regalreihe sechzehn mal sechzehn Karteikästen stehen. Mit der knappen Anweisung auf dem Zettel weißt du, der Laufbursche namens Akkumulator, aber dennoch ganz genau, wo du hinmusst.
Du suchst läufst die Treppen, du findest die Regalreihe, du findest den richtigen Karteikasten, du öffnest... und, äh, findest da dann 8 Bit.

Genug von diesem Mumpitz.

Dieses Bild hilft aber in etwa zu verstehen, wie man beim SNES-Programmieren spricht.
Obenbesagter Zettel, den man dem Laufburschen gibt, heißt in Assembler z. B.

Code: Alles auswählen

LDA $C89420

"LDA" heißt: "Load Accumulator", Lade in den Akkumulator. Danach folgt die Angabe, von wo er laden soll. Diese Angabe heißt (auch hier): Adresse. Diese Adressen können sechs-, vier- oder zweistellig sein (in diesem Zusammenhang ist es normal, Hexzahlen zu gebrauchen). Dabei stehen, bei oben genanntem Beispiel, die linken beiden Stellen für die sogenannte "Bank" ($C8 in diesem Beispiel, die 200. Etage in meinem Bild), die mittleren beiden Stellen stehen für die "Page" ($94 bzw. das 148. Regal), die letzten sind dann die genaue Angabe des bytegroßen Speicherorts ($20 bzw. die exakte Reihen- und Spaltenangabe im Regal). In jedem dieser "Speicherorte" oder Register, wie sie heißen, findest du dort dann einen Byte.
Ich habe erwähnt, dass die Ladebefehle auch nur z.B. vierstellige Speicheradressen bekommen können. Für den Fall kann man beim Programmieren vermerken, welche Bank (welche Etage) man meint, wenn man keine Angabe zur Bank macht.

Also, wie man sieht, ist der Speicher mit Adressen versehen, sodass man einzelne Bytes direkt ansprechen kann.
Der Speicher ist kartographiert.
Englisch: The memory is mapped.

Kommen wir wieder zum Anfang:
Das SNES benutzt Memory-Mapped Input/Output.

Was ist Input? Was ist Output? Eingabe und Ausgabe. Ja, richtig. Was ist beim SNES Eingabe? Z. B. ein Tastendruck auf dem Controller. Was ist Ausgabe? Zum Beispiel ein Bild auf dem Fernseher. Korrekt.
Bringen wir dieses Wissen jetzt mit obigem zusammen, erklärt sich, was mit "Memory-Mapped Input/Output" gemeint ist:
Die Eingabe- und Ausgabegeräte vom SNES haben Adressen, die so aussehen, als wären sie Speicher. Mit Speicher meine ich ROM, der Platz, wo bei einem Spiel die Grafikdaten liegen oder Programmcode oder dergleichen.
Das heißt: Die Befehle, wo ich etwas aus dem Speicher lade, oder Daten von einem Controller abfrage, sehen komplett gleich aus.

Ich hatte oben bereits als Beispiel mit der fiktiven Speicheradresse $C89420 gebracht. Um den Byte daraus zu lesen, schreibe ich den Befehl

Code: Alles auswählen

LDA $C89420

Wenn ich jetzt z. B. prüfen möchte, welche Buttons auf dem Controller 1 gedrückt werden, gucke ich nach, welche Adresse das Register hat (es sind übrigens zwei Register: $4218 und $4219, ich nehme nur mal eins), und sage dann:

Code: Alles auswählen

LDA $4218

Jetzt habe ich die Rohdaten im Akkumulator, und kann sie weiterverarbeiten.*

*Nur als Nebeninformation, was jetzt nicht relevant für das System der Adressen ist:
In den Registern $4218 und $4219 sind jeweils ein Byte, und je nach dem, welcher Button auf dem Controller gedrückt wird, wird ein unterschiedlicher Bit in den Bytes dann auf 1 gesetzt.

** Unsere Leser fragen:

hubbi2 hat geschrieben:... und warum hat das Haus exakt 256 Stockwerke?

Lieber hubbi2,

die Adressen können nicht länger als 24 Bit (also 3 Byte) sein; das hat was mit der Hardware zu tun: Das entsprechende Gerät hat nur für 24 Bit Plätze. Folglich ist der höchste Adressenwert, die jemals angesprochen werden kann, wenn alls Bits auf 1 stehen, das ist $FFFFFF. Die Stockwerke sind eine Verbildlichung für den höchsten Byte dieser Adresse, also die $FFxxxx. Und dieser Byte kann, wie jeder Byte, zwischen 0 und 255 liegen. Das wiederum macht 256 Varianten. Und da ich diesen Byte, wie gesagt, mit einer Stockwerk-Angabe verglichen habe, kann es also nur 256 Stockwerke geben.

Soweit dazu. Ist das verständlich? Habe ich irgendwas vergessen? Irgendwas vollends falsch erklärt? Alles chic? Alles nich-so-chic?

lytron · Beitrag von **lytron** » 7. Oktober 2012, 13:09

Ich fange mal mit dem Programmieren an, dann wird mir einfallen, was noch alles an Vorwissen da sein muss. Also, ab jetzt fängt der Spaß an. Oder so.

Ich hab deinen ganzen Kram gelesen, aber ich will jetzt aber endlich anfangen zu programmieren!!1

Ist ja gut, ist ja gut... >_>

Lad dir das hier runter (all der Spaß ab hier ist exklusiv für Windowsnutzer):

Blanko.zip: (116.04 KiB) 797-mal heruntergeladen

Das sind die Dateien, die ich mal für einen guten Anfang bereitgestellt habe.*
Der gezippte Ordner enthält sieben Dateien:

"Blanko.asm", "define.asm", "header.inc" und "InitSNES.asm" sind die Bausteine für das tatsächliche spätere Programm/Spiel, "Blanko.prj", "wla-65816.exe" und "wlalink.exe"** sind Dateien, die nötig sind für die Umwandlung.

Am besten, du erstellst an dieser Stelle eine Verknüpfung zur Eingabeaufforderung.

versteckter Inhalt:

Wie man ein Projekt kompiliert
Auch wenn es vorerst keinen Sinn macht, weil das Projekt eine komplett leere Hülse ist, erstellen wir jetzt unsere erste ROM.
Öffne die Eingabeaufforderung. Gib diesen Text ein und drückst dann Enter:

Code: Alles auswählen

wla-65816.exe -vo Blanko.asm Blanko.o

(Es wird auch reichen, wenn du z. B. nur "wla-" eingibst und dann die Tab-Taste zur Auto-Vervollständigung drückst)
Du hast das Programm wla-65816.exe aufgerufen, ihm die Befehle gegeben ("-vo"), eine Objektdatei zu erstellen (dafür das "o") und die Arbeit zu visualisieren ("v"). Des weiteren hast du den Namen der Input-File gegeben ("Blanko.asm") und den Namen der Outputfile festgelegt ("Blanko.o").
Die "Visualisierung" sieht man in Form der vielen Textzeilen, die ausgeworfen wurden, ehe wieder die Befehlszeile erschien. Das ist sehr hilfreich, da andernfalls man nicht sieht, wenn WLA DX eine Datei nicht erstellt, weil es eine Zeile nicht versteht (aufgrund eines Fehlers). In einem solchen Falle würde man sich immer nur wundern, weshalb die letzten Änderungen im Sourcecode nicht übernommen werden...
Jedenfalls, jetzt hast du eine Objektdatei.

Der Sinn der Objektdatei ist, dass man bei größeren Projekten nicht konstant das gesamte Projekt kompilieren muss, sondern es gegebenenfalls in mehrere Objektdateien aufteilen kann, die dann nur einzeln kompiliert werden müssen. Am Ende werden die einzelnen Objektdateien dann in mit wlalink.exe zusammengeführt. Auch wenn wir nur eine Objektdatei haben, müssen wir dennoch als zweiten Arbeitsschritt wlalink.exe aufrufen.

Code: Alles auswählen

wlalink.exe -vr Blanko.prj Blanko.sfc

Hier wird wieder der Befehl zur Visualisierung gegeben, außerdem der Befehl, eine ROM-Datei zu erstellen (das "r" in "-vr"). Als Input-File wird die Projektdatei gewählt, ich hab da mal was vorbereitet...
Guck dir mal die Blanko.prj im Texteditor an. Der Inhalt besagt, welche Dateien zu diesem Projekt gehören. Und die "gesamte Liste" besteht aus einer Datei: Blanko.o. Das heißt, wenn du die Dateien, die zu diesem Projekt gehören, irgendwann mal umbenennen willst, was ich dir dringend raten möchte, musst du dann entweder konstant im ersten Befehl eine Blanko.o-Datei erstellen, oder, wenn du deine o-Datei anders benennen möchtest, es entsprechend in der prj-Datei anpassen. Wobei die o-Datei vollkommen egal ist, da sie ja nur ein "Zwischenergebnis" ist und ihr Dateiname keine Auswirkung auf die entgültige ROM hat.
Auswirkung auf die entgültige ROM hat dann das letzte Argument, in diesem Fall "Blanko.sfc". Das ist der Name der ROM-Datei; diese Datei kannst du jetzt nehmen und mit dem Emulator deiner Wahl öffnen. Wenn du sie startest, nichts passiert und alles schwarz bleibt - Gratulation! Alles hat richtig funktioniert!

Es wäre theoretisch auch möglich, die Output-Datei auf "smc" enden zu lassen. Das mag einem SNES-Emulationen-Spieler eher bekannt sein, ist aber totaler Schwachsinn. "sfc" ist die Abkürzung für Super Famicom, und dafür schreibst gerade ein Programm. Mehr oder weniger. "smc" steht für Super Magicom.
Weißt du, was das ist?
- Wenn Nein: Gut, also kann es auch nicht das sein, wofür du ein Programm schreiben willst.
- Wenn Ja: Gut, dann weißt du ja, dass dein Programm damit nichts zu tun hat. Und bestenfalls wirst du auch verstehen, weshalb du willst, dass dein Programm nichts damit zu tun hat.

Und als nächstes gucken wir uns dann die anderen vier Dateien dieser Zipfile an.

* Diese Zusammenstellung ist eine Verschlankung und Erweiterung des First SNES Program von bazz, bereitgestellt auf http://wiki.superfamicom.org von Matthew Callis.
** Der Vollständigkeit halber: Die beiden exe-Dateien sind aus der Version 9.4a vom 06.11.2006 von WLA DX, die man auf der offiziellen Homepage herunterladen kann: Diese Seite hier aufrufen, den Link unter "Binaries (UNSUPPORTED)" anklicken, dort den vierten Link von oben, das heißt den zweiten von unten, anklicken.

KANN JEMAND BITTE PRÜFEN,
ob die beiden Exe-Files auch auf anderen Computern außer meinem laufen? Ansonsten muss ich den Kram oben umschreiben.

~~~

TO DO: (Das sollte bestenfalls vorher noch erklärt werden:
- Vektoren
- NMI/VBLANK
- Statusregister
- Native Mode / Emulation Mode

lytron · Beitrag von **lytron** » 8. Oktober 2012, 09:09

File Dump, File Dump...!

Als Vorbereitung für das Statusregister und den Grafik-Teil, die beide dringend noch erklärt werden müssen, bis ich ins Programmieren kommen kann, habe ich mal einige Bilder vorbereitet. Erst habe ich mit Paint herumgemalt, habe aber ledier festgestellt, dass das wesentlich enervierender und zeitraubender ist, als tatsächlich "per Hand" zu arbeiten, also habe ich alsbald die Filz- und Bundstifte wieder herausgeholt. ^.^

Es handelt sich hierbei um Skizzen, also bevor ihr fragt: Nein, es ist nicht mein voller Ernst!

Damit diejenigen, die den Kram hier lesen, nicht komplett verwirrt sind wegen der vielen thematischen Sprünge, nur eine kurze Erklärung, worum es dabei geht.

versteckter Inhalt: