Architektur des SNES

Architektur des
Super Nintendo Entertainment Systems
(SNES)
Rechnerstruktur - Labor
Prof. Dr. Thomas Risse
Von:
André Killing
Oliver Hanslian
Roy Norbart
155033
125446
123834
Architektur des Super Nintendo Entertainment Systems
1
08. Juli 2008
Inhalt
1
Inhalt................................................................................................................................................ 2
2
Abkürzungsverzeichnis .................................................................................................................... 4
3
Fremdwörterverzeichnis ................................................................................................................. 4
4
Einleitung ......................................................................................................................................... 5
5
Computertechnik dieser Zeit ........................................................................................................... 6
6
Das System ...................................................................................................................................... 8
6.1
Das Gesamtsystem .................................................................................................................. 8
6.2
Hauptprozessor ..................................................................................................................... 10
6.3
Grafikprozessoren (Nintendo 5C77 & Nintendo 5C78) ......................................................... 12
6.4
Soundsystem ......................................................................................................................... 14
6.4.1
Speicher ......................................................................................................................... 15
6.4.2
Kommunikation mit der SNES-CPU ............................................................................... 16
6.4.3
Timer / Counter ............................................................................................................. 17
6.5
Der Kopierschutz ................................................................................................................... 18
6.6
Diverse Komponenten ........................................................................................................... 19
7
Das Modul ..................................................................................................................................... 20
8
Externe Co-Prozessoren ................................................................................................................ 23
8.1
9
Der SA-1 ................................................................................................................................. 25
8.1.1
Speicheranbindung ........................................................................................................ 25
8.1.2
Interner Aufbau ............................................................................................................. 27
8.1.3
Kommunikation mit dem SNES...................................................................................... 31
8.1.4
Operating Modes ........................................................................................................... 32
Programmierung des Systems ....................................................................................................... 35
9.1
Allgemeiner Aufbau der Instruktionen .................................................................................. 35
9.2
Initialisierungsparameter ...................................................................................................... 36
9.3
Entwickeltes Testprogramm .................................................................................................. 37
9.4
Kompilierung und Test .......................................................................................................... 38
10
Quellenverzeichnis .................................................................................................................... 39
11
Abbildungsverzeichnis ............................................................................................................... 41
12
Tabellenverzeichnis ................................................................................................................... 41
André Killing (155033)
Oliver Hanslian (125446)
Roy Norbart (123834)
Seite 2 von 53
Architektur des Super Nintendo Entertainment Systems
13
08. Juli 2008
Anhänge..................................................................................................................................... 42
13.1
Anhang A: header.inc ........................................................................................................... 42
13.2
Anhang B: Snes_Init.asm ...................................................................................................... 43
13.3
Anhang C: Soundtest.asm..................................................................................................... 45
13.4
Anhang D: Flex.asm .............................................................................................................. 52
André Killing (155033)
Oliver Hanslian (125446)
Roy Norbart (123834)
Seite 3 von 53
Architektur des Super Nintendo Entertainment Systems
08. Juli 2008
2 Abkürzungsverzeichnis
CCC
FD
GPU
IRQ
ISA
B (KB / MB)
b (Kb / Mb)
NMI
NTSC
PAL
PPU
RAM
ROM
SFR
SNES
SRAM
VDP
3
Character Conversation Circuit
Floppy Disk (Diskette)
Graphics Processing Unit
Interrupt Request
Industry Standard Architecture
Angaben in Byte (KiloByte / MegaByte)
Angaben in Bit (KiloBit / MegaBit)
Not Maskable Interrupt
National Television Systems Committee
(umgangsspr. Never The Same Color)
Phase Alternating Line
Picture Processing Unit
Random Access Memory
Read Only Memory
Special Function Register
Super Nintendo Entertainment System
Static Random Access Memory
Video Display Prozessor
Fremdwörterverzeichnis
Cartridge
Pinout
Slot
André Killing (155033)
Oliver Hanslian (125446)
Roy Norbart (123834)
Modul
Pin Layout
Steckplatz
Seite 4 von 53
Architektur des Super Nintendo Entertainment Systems
4
08. Juli 2008
Einleitung
Dieses Dokument behandelt den Aufbau des Super Nintendo Entertainment Systems (SNES). Es soll
einen Überblick darüber verschaffen, mit welchen technischen Tricks eine, für damalige Verhältnisse,
leistungsstarke und doch recht günstige Konsole für den Homeentertainment-Bereich entwickelt
wurde. Das Dokument gliedert sich dabei grob in vier Teile. Im ersten Teil, dem Kapitel 5, verschaffen
wir uns zunächst einen Überblick darüber, gegen welche Systeme der SNES konkurrieren musste. Um
dies zu veranschaulichen führen wir auch die technischen Daten der Mitbewerber auf.
Der zweite Teil (Kapitel 6) beschäftigt sich mit dem technischen Aufbau des Systems. Es werden viele
der eingebauten Elemente näher erläutert. Auf eine ausführliche Erklärung einiger Elemente wird
jedoch verzichtet, da diese Standardkomponenten der Elektronik sind und daher auch nur bekannte
Funktionen ausführen.
Im Anschluss an den Aufbau des SNES behandelt der dritte Teil des Dokuments (Kapitel 7 + 8) den
Aufbau der Module (engl. Cartridge). Zunächst soll der allgemeine Aufbau und das Pinout dieser
Module dargestellt werden. Danach werden einige der Co-Prozessoren, welche in machen Modulen
vorhanden waren, ausführlich erklärt.
Im letzten Teil der Ausarbeitung wird auf unseren praktischen Teil der Laborarbeit eingegangen. Es
soll der Aufbau eines SNES-Programms erklärt und einige einfache Programmbeispiele dargestellt
werden. Zudem wird beschrieben mit welcher Software der Quelltext kompiliert wird und welche
Testmöglichkeiten man hat.
André Killing (155033)
Oliver Hanslian (125446)
Roy Norbart (123834)
Seite 5 von 53
Architektur des Super Nintendo Entertainment Systems
5
08. Juli 2008
Computertechnik dieser Zeit
Als der SNES 1990 erstmals auf den Markt kam, musste sich dieser in direktem Konkurrenzkampf mit
dem SEGA MegaDrive und handelsüblichen PCs / Amigas begeben. Der Vorteil für die
Konsolenhersteller war jedoch, dass das Zusammenspiel der Komponenten aufeinander ausgelegt
war und auch viele spezielle Co-Prozessoren vorhanden waren, welche trotz langsamerer
Taktfrequenz zum Teil aufwändigere Spiele abarbeiten konnten als der Hauptprozessor eines PCs.
Außerdem war ein PC damals nicht als Spielesystem ausgelegt. Für damalige Verhältnisse aufwändige
Grafiken mussten alleine von der CPU errechnet werden, wohingegen der SNES 2 PPUs (Picture
Processing Units) zur Grafikdarstellung besaß. Diese Arbeitsweise ist erst Mitte der 90er mit dem
Erscheinen der ersten 3D-Grafikkarten in die PC-Welt übernommen worden. Auch waren
Soundkarten im PC eher eine Ausnahme, da selbst die günstigen Modelle noch über 150 DM
kosteten. Jedoch besaß der PC andere Vorzüge gegenüber dem SNES. Er konnte nicht nur für Spiele
sondern auch für Büroanwendungen verwendet werden. Auch war er fast beliebig erweiterbar, auch
wenn aufgrund von fehlender Standards noch vieles inkompatibel zueinander war (Beispiel: CD-ROM
Schnittstellen). Was wohl auch für den PC sprach, war die Möglichkeit, Software einfach kopieren zu
können. Diese Möglichkeit zum Kopieren der Module gab es später zwar auch für Konsolen, war aber
noch recht teuer und umständlich.
Im Vergleich zum PC war der Amiga, auch wenn Hersteller Commodore es anders sah, ein reiner
Spielecomputer und somit das Bindeglied zwischen dem PC und den Konsolen. Im Gegenteil zum PC
war dieser nicht beliebig erweiterbar, bot aber bereits eine vorinstallierte Soundeinheit. Somit war er
als Spielecomputer recht beliebt. Auch die Softwarepiraterie erlebte mit dem Amiga einen
drastischen Anstieg, da Spiele, wie beim PC auch, auf Diskette und ohne Kopierschutz-mechanismen
vertrieben wurde.
Im Konsolenlager lieferten sich lange Zeit Nintendos SNES und Segas MegaDrive einen erbitterten
Kampf. Der MegaDrive war zur Zeit der Veröffentlichung des SNES bereits zwei Jahre auf den Markt.
Da Japan jedoch eine Hochburg von Nintendo war und auch die USA von Nintendo mehr angetan
waren, konnte Sega mit dem MegaDrive hier keine großen Erfolge erzielen. Lediglich in Europa
konnte sich der MegaDrive etablieren, da diese 16 Bit Konsole hier zwei Jahre vor dem 16Bit SNES auf
den Markt kam. 1993 bzw. 1994 endete die Ära der 16Bit Konsolen, nachdem 3DO in Amerika eine,
überteuerte und daher wenig verkaufte, Konsole mit CD-ROM-Laufwerk anbot. 1994 veröffentlichte
Sony dann die PlayStation, welche den SNES weitestgehend ablöste.
Anm.: Sollten Sie mehr über eines der angesprochenen Systeme erfahren wollen, so schlagen sie
bitte in den unter Quelle 1-8 angegebenen Links nach.
André Killing (155033)
Oliver Hanslian (125446)
Roy Norbart (123834)
Seite 6 von 53
Architektur des Super Nintendo Entertainment Systems
Veröffentl.:
Preis:
CPU:
RAM:
Grafik:
Modulgr.:
SNES
MegaDrive
PC
1990
329DM
65816
3,58MHz
(16 Bit)
128KB
2 PPUs
128KB RAM
512x448Px
(15Bit)
8MB Modul
1988
295DM
MC68000
7,61MHz
(16 Bit)
64KB
VDP
64KB RAM
320x240Px
(9Bit)
4MB Modul
1989
6000DM
486DX
33MHz
(32 Bit)
4MB
ISA Karte
256-512KB
640x480Px
(8 Bit)
1,4MB FD
08. Juli 2008
Amiga
500+
1991
900DM
MC68000
7,14MHz
(16 Bit)
1MB
MOS 8362
unbek.
640x480Px
(8 Bit)
1,4MB FD
3DO
Playstation
1993
700$
ARM60
12,5MHz
(32 Bit)
2MB
unbek.
1MB
320x480Px
(24 Bit)
700MB CD
1994
599DM
R3000A
33,87MHz
(32 Bit)
1,5MB
GPU
1MB
640x480Px
(24 Bit)
700MB CD
Tabelle 1: Computersysteme um 1990 (Quellen: 1-8)
André Killing (155033)
Oliver Hanslian (125446)
Roy Norbart (123834)
Seite 7 von 53
Architektur des Super Nintendo Entertainment Systems
6
08. Juli 2008
Das System
Dieses Kapitel behandelt den Aufbau des Super Nintendo Entertainment Systems. Es werden hier die
einzelnen Bauelemente und Zusammenhänge erklärt, welche zur Erzeugung der Video- und
Audiosignale verwendet werden. Es wird jedoch darauf verzichtet, darauf einzugehen, wie Daten
genau verarbeitet werden und wie diese schließlich auf PAL bzw. NTSC umgewandelt werden.
Nachdem bereits im vorangegangenen Kapitel ein kleiner Überblick über das Gesamtsystem gegeben
wurde, steigen wir nun in die Arbeitsweise des Gerätes ein. Hierzu wird im folgenden Unterkapitel
zunächst ein Einblick in die Konsole gegeben. Die darauf folgenden Unterkapitel beschreiben
anschließend die Funktionsweise der einzelnen Bauelemente.
6.1 Das Gesamtsystem
Das Blockschaltbild des Systems sieht wie folgt aus:
Abbildung 1: Blockschaltbild des SNES (Quelle: 9 – Seite 99)
André Killing (155033)
Oliver Hanslian (125446)
Roy Norbart (123834)
Seite 8 von 53
Architektur des Super Nintendo Entertainment Systems
08. Juli 2008
Bevor wir zu den einzelnen Komponenten des Systems kommen, möchten wir auf das
Zusammenspiel der Komponenten eingehen.
Der CIC-Chip ist der Kopierschutz des Systems (siehe Kapitel 6.5). Er verfügt über eine Reset-Leitung,
mittels der er die zweite Grafikeinheit abschalten kann. Diese gibt das Reset-Signal dann weiter an
die erste Grafikeinheit, die Soundeinheiten, dem RAM und die SNES-CPU.
Die SNES-CPU ist an zwei Adressbus-Systeme angeschlossen. Zum einen der 24 Bit breite A-Bus und
zum anderen der 8 Bit breite B-Bus. Mittels des A-Busses ist es der CPU möglich, den gesamten RAM
sowie den gesamten ROM-Speicher des Moduls zu adressieren. Der B-Bus hingegen dient zur
Kommunikation mit den anderen Bauteilen. So haben die Sound- & Grafikeinheiten nur Zugriff auf
einen kleinen Teil des RAMs. Allen Einheiten gemein ist der 8 Bit breite Datenbus.
Die beiden PPUs haben zudem einen eigenen Speicher (32KB pro Einheit). Die Besonderheit bei der
Verdrahtung ist jedoch dass nur die erste Einheit in der Lage ist, den Speicher zu adressieren. Somit
ist die zweite PPU auf das Anlegen der richtigen Adresse auf dem Adressbus auf die erste PPU
angewiesen.
Die Soundeinheiten des Systems können nur über die Sound CPU mit dem Rest des Systems
kommunizieren. Auf welche Art die Soundeinheiten untereinander kommunizieren, wird im
entsprechenden Kapitel behandelt. (Quelle: 9 – Seite 98-100)
André Killing (155033)
Oliver Hanslian (125446)
Roy Norbart (123834)
Seite 9 von 53
Architektur des Super Nintendo Entertainment Systems
08. Juli 2008
6.2 Hauptprozessor
Der Hauptprozessor des Systems ist eine Spezialanfertigung für Nintendo welche mit dem Western
Design Center 65816 bzw. 65C816 kompatibel ist. Der von Nintendo verwendete Name dieses
Prozessors ist „5A22“. Technisch gesehen entspricht dieser Chip einer Weiterentwicklung des
Prozessors welcher auch im NES verbaut war (MOS Technologies 6502). Prinzipiell kann der SNES
somit den Programmcode des NES verarbeiten, jedoch scheitert die Umsetzung an den PPUs welche
nicht kompatibel zum NES-Pendant sind. (Quelle: 12)
Im Gegensatz zum 6502 besitzt dieser Prozessor auf 16Bit erweiterte Alu, X & Y, Index-Register und
Stack-Pointer. Über einen Softwareschalter lässt sich die CPU jedoch in einen 8Bit Modus
umschalten. Wie bereits zuvor angesprochen verfügt die CPU über einen Anschluss an den 24Bit
Adressbus.
Kommen wir nun zum internen Aufbau der Einheit. Zur Verständnis stellen wir nachfolgend das
Blockschaltbild des Prozessors, welches aus der offiziellen Dokumentation stammt, dar.
Abbildung 2: Blockschaltbild der SNES-CPU (Quelle: 11 – Seite 11)
Der Hauptprozessor verfügt über drei 8-Bit-Schnittstellen, über die er mit den anderen Bauteilen auf
dem Chip kommunizieren kann. Dies sind zwei reine Adress-Schnittstellen, die die Datenleitungen A0
André Killing (155033)
Oliver Hanslian (125446)
Roy Norbart (123834)
Seite 10 von 53
Architektur des Super Nintendo Entertainment Systems
08. Juli 2008
bis A15 bereitstellen, sowie eine Schnittstelle, die wahlweise für Adressen oder Daten genutzt
werden kann und bei Adressen die Leitungen A16 bis A23 bereitstellt. Somit kann parallel eine 24-BitAdresse ausgegeben werden, oder eine 16-Bit-Adresse und gleichzeitig 8 Bit Daten.
Die Datenleitungen werden in den Prozessor weitergeleitet, im Gegensatz zu den Adsressleitungen.
Bei Befehlsbytes geschieht dies über die Data Latch/Predecode-Einheit, bei Datenbytes über das
Databank-Register. Adressen werden über den Internal Adress Bus ein- und ausgelesen. Über die
Data Latch/Predecode-Einheit werden Befehle in das Instruction-Register geschrieben. Das
Databank-Register gibt Daten weiter auf den Internal Data Bus, von dem sie weitergegeben werden
können an Program Counter, Accumulator, ALU oder Direct-Register (welches bei bestimmten
Adressierungsarten benötigt wird). In die Register X und Y können die Daten nur über einen weiteren
Schritt über den Internal Special Bus geladen werden, auf den sonst nur Accumulator, ALU und StackPointer sowie die Transfer Switches Zugriff haben.
Neben den drei 8-Bit-Schnittstellen verfügt der Hauptprozessor noch über eine Reihe von
Steuerleitungen, die die System Control, Timing Control und Interrupt Logic-Einheiten sowie den
Clock Generator steuern bzw. entsprechende Befehle und Signale weitergeben. (Quelle: 11)
André Killing (155033)
Oliver Hanslian (125446)
Roy Norbart (123834)
Seite 11 von 53
Architektur des Super Nintendo Entertainment Systems
08. Juli 2008
6.3 Grafikprozessoren (Nintendo 5C77 & Nintendo 5C78)
Der SNES kann Auflösungen von 256*224 bis 512*478 Pixeln darstellen, wobei die Darstellung jeweils
unterschiedlich abläuft. Bilder mit Auflösungen von 256*224 bis 512*239 werden progressive
aufgebaut, also Zeile für Zeile von oben nach unten. Bilder mit Auflösungen von 512*448 oder
512*478 werden interlaced aufgebaut, also erst die ungeraden Zeilen, dann die geraden. Dies
geschieht, damit das Auge keine halben Bilder wahrnimmt, weil der Aufbau des ganzen Bildes zuviel
Zeit in Anspruch nimmt.
Die beiden Grafikprozessoren arbeiten als eine Einheit, können also auch als solche wahrgenommen
werden. Der erste Grafikchip ist für den Zugriff auf den internen Grafikspeicher zuständig und mit
diesem über einen Adressbus verbunden. Der zweite Chip sendet die Farbinformationen an die RGBEinheit, die diese Daten weitergibt. Der interne RAM umfasst 64 KB Speicher für Daten, 544 Byte für
Objekte (Sprites im Weiteren) und 512 Byte für Farbdaten. Die Farben setzen sich aus den RGBFarbwerten (15 Bit Farben) zusammen, was eine Bandbreite von 32.768 Farben ermöglicht.
Allerdings werden im Farbdaten-RAM nur Paletten von 4 bis 256 Farben pro Palette gespeichert, aus
denen die jeweiligen Elemente auf dem Bildschirm wählen können. 256 Farben ist gleichzeitig die
Speichergrenze des Farbdaten-RAM (Eine Farbe braucht 2 Byte Speicher), wodurch die 256-FarbenPalette auch als „full palette“ bezeichnet wird. Jede Palette enthält die Farbe „durchsichtig“,
wodurch dahinter liegende Objekte gezeigt werden.
Der SNES kann in 8 Modi Grafiken darstellen, die sich jeweils grundsätzlich unterscheiden. Allen Modi
gemeinsam ist, dass sie Layer verwenden, wobei die Anzahl der Layer je nach Modus variiert. Jeder
Layer ist aufgebaut aus Tiles, „Kacheln“, die eine Größe zwischen 32*32 und 128*128 Pixeln haben
können. Die Daten für die Tiles sind im internen Daten-RAM hinterlegt und können auch mehrfach
verwendet werden. Die möglichen Farben für die Tiles sind wiederum vom Modus abhängig. Die Tiles
können in zwei Planes, „Ebenen“, angeordnet werden, die Vordergrund und Hintergrund des Layers
darstellen. Alle Layer können unabhängig voneinander auf dem Bildschirm horizontal und vertikal
verschoben werden.
Auf jede Plane jedes Layers können sich Sprites, „Objekte“, befinden. Diese Sprites können die Größe
von 8*8 bis 64*64 Pixeln haben, sind für sich bewegbar sowie horziontal und vertikal drehbar. Die
Daten der Sprites werden im Objekt-RAM gespeichert, wobei maximal 32 Sprites gleichzeitig
dargestellt werden können. Auch
Sprites werden aus Tiles geformt, wobei diese für Sprites immer 8*8 Pixel groß sind und über eine
16-Farben-Palette verfügen.
Die Modi im Einzelnen:
Modus 0:
4 Layer stehen zur Verfügung, jeder Layer verfügt nur über eine 4-Farben-Palette.
Modus 1:
3 Layer, zwei mit jeweils 16-Farben-Paletten, einer mit einer 4-Farben-Palette.
Modus 2:
2 Layer, jeder mit einer 16-Farben-Palette. Jedes Tile kann einzeln verschoben
werden.
André Killing (155033)
Oliver Hanslian (125446)
Roy Norbart (123834)
Seite 12 von 53
Architektur des Super Nintendo Entertainment Systems
08. Juli 2008
Modus 3:
2 Layer, einer mit der „full palette“, 256 Farben, einer mit einer 16-Farben-Palette.
Zusätzlich kann der Layer mit der full palette auch Farben aus einem 11-BitFarbraum (RGB 443) direkt definieren.
Modus 4:
2 Layer, einer mit der „full palette“, einer mit einer 4-Farben-Palette. Zusätzlich
kann der Layer mit der full palette auch Farben aus dem 15-Bit-Farbraum direkt
definieren. Jedes Tile kann einzeln verschoben werden.
Modus 5:
2 Layer, einer mit einer 16-Farben-Palette, einer mit einer 4-Farben-Palette.
Veränderte Codierung der Tiles, um interlaced-Darstellung zu erleichtern.
Modus 6:
1 Layer, der eine 16-Bit-Palette verwendet. Ebenfalls veränderte Tile-Codierung zur
Erleichterung von interlaced-Darstellungen, zusätzlich kann jedes Tile einzeln
verschoben werden.
Modus 7:
Dieser Modus bildet eine große Besonderheit des SNES. Es wird nur ein Layer
verwendet, der entweder nur über eine Plane mit full palette verfügt, oder über
zwei Planes mit jeweils 128 Farben. Besonderheit ist, dass der Layer unter
Benutzung von Matrix-Transformationen gedreht, gekippt und kleiner oder größer
skaliert werden kann. Dies soll Dreidimensionalität simulieren und perspektivische
Darstellung ermöglichen.
Weitere Möglichkeiten der Farbgestaltung ergaben sich aus gröberer Pixelung der Layer oder
Farbaddition bzw. –subtraktion der Farben von Layer und Sprite, was eine wiederum größere
Farbvielfalt ermöglicht, als eigentlich vorgesehen. (Quellen: 12 & 13 – Seite 115-139)
André Killing (155033)
Oliver Hanslian (125446)
Roy Norbart (123834)
Seite 13 von 53
Architektur des Super Nintendo Entertainment Systems
08. Juli 2008
6.4 Soundsystem
Das Soundsystem des SNES besteht aus einem Sony 8 Bit Prozessor (SPC700) und einem Sony DSP
(WWW210R6X) gefolgt von einigen Filtern und D/A-Wandlern. Eingehen wollen wir in diesem Kapitel
nur auf den Prozessor, da dieser maßgeblich für die Leistung der Soundausgabe ist. (Quelle 9 – Seite
153)
Abbildung 3: Soundeinheit (Quelle: 9 – Seite 154)
Der Sony SPC700 CMOS 8 Bit Prozessor ist die Verwaltungseinheit des Soundsystems.
Taktfrequenz:
ROM:
Adressbereich:
Timer / Counter:
2,48MHz
64 Byte
64KB
(8 Bit Timer + 4 Bit Counter) x 3 im Set
Tabelle 2: Technische Daten des SPC700 (Quelle: 9 – Seite 153)
Aufgabe dieses Chips ist es, die zur Tonerzeugung benötigten Daten anzufordern und in den 64KB
großen Sound-RAM zu übertragen.
Zudem wird der SPC700 zur Steuerung des DSPs verwendet. Dieser arbeitet die Anweisungen der
Sound CPU zu entsprechender Zeit mit den Daten aus dem Sound-RAM ab und gibt die erzeugten
digitalen Daten an die D/A-Wandler & Filter weiter.
Nun soll die Funktionsweise des SPC700 genauer erläutert werden. (Quelle: 9 – Seite 154)
André Killing (155033)
Oliver Hanslian (125446)
Roy Norbart (123834)
Seite 14 von 53
Architektur des Super Nintendo Entertainment Systems
08. Juli 2008
6.4.1 Speicher
Da der SPC700 maximal 64KB Adressieren kann und dies bereits mit der Größe des RAMs ausgereizt
ist, besteht ein Konflikt mit dem 64Byte großen IPL ROM, welcher den initialen Zustand der
Soundeinheit nach dem Starten der Konsole enthält. Als Lösung wurden vom Adressbereich des
RAMs 64Byte an den ROM abgetreten.
Der verbleibende Adressbereich ist jedoch nicht vollständig für beliebige Daten verfügbar. So sind
weitere 128Byte für die Special Function Register (kurz: SFR) reserviert.
Alle noch verfügbaren Adressbereiche stehen für Sounddaten zur Verfügung. Zu beachten ist nur,
dass der Bereich von 0200H – 7FFH der Bereich ist, welcher für Datentransfers benötigt wird. So
sollten Daten, die öfter benötigt werden, aus diesem Bereich verschoben werden, um der Gefahr zu
entgehen, dass diese bei einem weiteren Datentransfer überschrieben werden. (Quellen: 12 & 9 –
Seite 154)
Abbildung 4: Adressbereich des SPC 700 (Quelle: 9 – Seite 155)
André Killing (155033)
Oliver Hanslian (125446)
Roy Norbart (123834)
Seite 15 von 53
Architektur des Super Nintendo Entertainment Systems
08. Juli 2008
6.4.2 Kommunikation mit der SNES-CPU
Die zuvor angesprochenen Datentransfers des SPC700 laufen alle über den Datenbus, den B-Bus und
der SNES-CPU ab. Hierzu stehen der SPC700 vier Ports zur Verfügung. Von jedem der vier Ports
stehen zwei Versionen zur Verfügung: jeweils ein Read- und ein Write-Register. Die Read-Register
können von der SNES-CPU beschrieben und von der Sound-CPU nur gelesen werden. Anders herum
ist es bei den Write-Registern, welche nur vom SPC700 beschrieben werden können. Aufgrund der
Tatsache, dass sich die Speicherstellen im Work-RAM (kurz: WRAM) des SNES befinden greifen, die
SNES-CPU und die Sound-CPU mit unterschiedlichen Speicheradressen auf diesen zu. Der Sound-CPU
steht nur der 8 Bit breite B-Bus zur Verfügung, die SNES-CPU kann hingegen den 24 Bit breiten A-Bus
verwenden. (Quelle: 9 – Seite 161)
Abbildung 5: Transfer-Ports des SPC700 (Quelle: 9 – Seite 161)
André Killing (155033)
Oliver Hanslian (125446)
Roy Norbart (123834)
Seite 16 von 53
Architektur des Super Nintendo Entertainment Systems
08. Juli 2008
6.4.3 Timer / Counter
Die 8 Bit Timer der Sound-CPU sind in Sets zusammen mit den 4Bit Countern geschaltet (je ein Timer
und ein Counter). Zwei der drei Sets werden mit 8KHz angesteuert, das dritte Set hingegen mit
64KHz. Die vor den Countern befindlichen Timer können dabei wie üblich mit einem max. Wert
vorbelegt werden. Sobald der Timer in Betrieb ist und den Vorgabewert erreicht, wird ein Signal an
den entsprechenden Counter im Set gesendet. Dieser wird dann um 1 inkrementiert. (Quelle: 9 –
Seite 164 / 165)
Abbildung 6: Timer / Counter des SPC700 (Quelle: 9 – Seite 164)
Auf die Vorgehensweise wie aus den Binärdaten ein Audiosignal erzeugt wird, möchten wir hier nicht
näher eingehen. Ziehen Sie bitte hierzu Kapitel 3-2-1 aus dem 1. Entwicklerhandbuch (Quelle Nr. 9)
zu Rate.
André Killing (155033)
Oliver Hanslian (125446)
Roy Norbart (123834)
Seite 17 von 53
Architektur des Super Nintendo Entertainment Systems
08. Juli 2008
6.5 Der Kopierschutz
Über den Kopierschutzchip ist wenig in Erfahrung zu bringen. Nintendo hält sich verständlicherweise
auch sehr bedeckt bei dem Thema. Die Funktionsweise des Kopierschutzes hingegen ist bekannt.
Beim Einschalten der Konsole beginnt der Chip mit einem baugleichen Chip auf dem Modul zu
kommunizieren. Stellt sich dabei heraus, dass kein Chip oder auch ein falscher Chip (die NTSC-Version
unterscheidet sich von der PAL-Version) auf dem Modul vorhanden ist, setzt der CIC-Chip im SNES
das RESET-Signal und stoppt somit alle im SNES vorhandenen Einheiten. Welche Daten zwischen den
beiden Einheiten ausgetauscht werden, ist nicht bekannt. Es ist auch nicht bekannt, ob es sich bei
jedem Startvorgang um die gleichen Daten handelt, die übermittelt werden; es ist aber davon
auszugehen, dass der CIC-Chip im SNES ein zufälliges Signal generiert, auf welches der Chip im Modul
entsprechend antwortet.
Um auf eine Frage aus unserem Vortrag zurückzukommen, möchten wir an dieser Stelle noch einmal
erläutern, warum es nicht immer möglich ist, einfach die RESET-Leitung zu durchtrennen um den
Kopierschutz unwirksam zu machen. Bei unseren Recherchen sind wir auf genau diese
Vorgehensweise gestoßen. Und dieses Vorgehen funktionierte auch bei den ersten verfügbaren
Modulen. Bei den neueren hingegen wird dieses Vorgehen vom Modul erkannt und verweigert
daraufhin den Datentransfer. Auf welche Art dies vom Modul ermittelt wird ist uns aufgrund der
unbekannten genauen Funktionsweise des Chips unbekannt. Wir vermuten jedoch, dass der CIC-Chip
im SNES beim Setzten des RESET-Signals auch alle Übertragungen zum Pendant im Modul abbricht.
Dieser könnte diesen Abbruch der Kommunikation als Indiz für das Setzten des Resets im SNES
nehmen und somit den Datenaustausch zwischen ROM und SNES unterbinden. (Quelle: 13)
André Killing (155033)
Oliver Hanslian (125446)
Roy Norbart (123834)
Seite 18 von 53
Architektur des Super Nintendo Entertainment Systems
08. Juli 2008
6.6 Diverse Komponenten
Abschließend werden wir noch einen kleinen Überblick über alle nicht angesprochenen Elemente
geben. Dies sind u.A. die I/O-Schnittstellen und die ausgebenden Bausteine.
GPK-Connector
Front Connector
Unit
OSC
Super NES WRAM
Expansion Conn
Reset IC
RGB Encoder
12P Multi Out
RF Mod
GPK steht für GamePaK. Der Gamepak-Connector sind die nach außen
geführten Pins, welche einen Slot bilden. Die Abmessungen entsprechen in
etwa denen von ISA-Slots aus der 486er-Computerzeit
Diese Einheit dient zum Anschluss der Eingabegeräte für den Benutzer. Die
Front Connector Unit bietet ohne Zuhilfenahme von spezieller Peripherie
maximal zwei Eingabegeräten eine Anschlussmöglichkeit. Mit einem Adapter
lässt sich dies auf bis zu vier Eingabegeräte erweitern.
Oszillatoren, welche die benötigten Taktfrequenzen den entsprechenden
Bauteilen zur Verfügung stellen
Dies ist der RAM des SNES. Das W im Namen steht für „Work“, also Arbeit. Er
ist der größte im SNES verbaute Speicherbaustein (128KB). Dies hat den
Grund, dass viele Programmteile, welche häufig zur Programmausführung
benötigt werden, aus dem vergleichsweise langsamen ROM-Speicher des
Moduls in den WRAM ausgelagert werden.
Gedacht war diese Schnittstelle, welche sich an der Unterseite des SNES
befindet, für diverse Erweiterungen. So sollte ein von Sony entwickeltes CDROM Laufwerk (mit dem Codenamen „Playstation“) an dieser Schnittstelle
angebracht werden. Das Projekt wurde jedoch nie, im eigentlichen Sinne,
abgeschlossen. Die einzige Erweiterung die hierfür erschien war ein Modem
für einen Satellitenanschluss. Hiermit konnten Spieldemos etc. zu
bestimmten Tageszeiten heruntergeladen werden. Erschienen ist dieses
Modem jedoch nur in Japan und Groß Britannien.
Dies ist die Reset-Taste, die dem Benutzer das Neustarten der Konsole
erlaubte.
Der RGB Encoder wandelt das von der zweiten PPU fertiggestellte Bildsignal
in ein RGB-Komponentensignal um.
Der Multi Out war die qualitativ bessere Anschlussmöglichkeit des
Fernsehers. Hier wurden die Bild und Tonkanäle über getrennte Adern
übertragen. Als Buchse wurde ein Nintendo-eigenes Format verwendet. Am
anderen Ende war das Kabel auf die drei üblichen Chinch-Stecker aufgeteilt.
Da zu damaliger Zeit noch nicht jeder Fernseher über Chinch- bzw. ScartBuchsen verfügte, bestand die Möglichkeit, über einen Antennenanschluss
den SNES am Fernseher anzuschließen. Der RF Mod moduliert dabei das Bildund Tonsignal zusammen und überträgt es über nur eine Ader. Dies führt
jedoch zu einer schlechteren Qualität des Ausgabesignals.
Tabelle 3: Diverse Komponenten des SNES (Quelle: 12)
André Killing (155033)
Oliver Hanslian (125446)
Roy Norbart (123834)
Seite 19 von 53
Architektur des Super Nintendo Entertainment Systems
7
08. Juli 2008
Das Modul
Die Spiele für den Super Nintendo wurden in den meisten Fällen auf Modulen sog. Cartridges
ausgeliefert (nur ein Bruchteil wurde über ein nur in Japan und Groß-Britannien erhältliches
Satellitenmodem veröffentlicht). Die Cartridges beinhalten immer einen ROM und einen CIC Chip.
Außerdem können diese einen SRAM und eine Batterie, einen MAD-1 und / oder einen Co-Prozessor
enthalten. Diese Komponenten sollen nachfolgend kurz erklärt werden: (Quelle: 12 & 14)
Chip
ROM
SRAM
MAD-1
CIC-Chip
Co-Prozessoren
Funktion
Der ROM wird zum Speichern des Programmcodes, der Grafiken und
der Sounds benötigt.
Der SRAM dient zum Speichern von Spielständen, Highscores etc.. Der
SRAM wird dabei von einer Knopfzelle gespeist, da die Daten auch nach
dem Abschalten der Konsole erhalten bleiben sollen.
Der MAD-1 (Memory Address Decoder Revision 1) ist ein
Adressdecoder, welcher in Spielen benötigt wird, bei dem sowohl ROM
als auch RAM im Modul vorhanden sind.
Kopierschutzchip des SNES (siehe Kapitel 6.5)
Erweiterungschips, die den Funktionsumfang erweitern und / oder die
Geschwindigkeit des SNES verbessern (siehe Kapitel 0).
Tabelle 4: Cartridge-Mikrochips (Quelle: 14)
Die Verdrahtung dieser Komponenten soll hier nicht weiter behandelt werden, da diese je nach
Ausstattung des Moduls unterschiedlich ist.
Lediglich das Pinout soll hier noch behandelt werden. Dieses können Sie der nachfolgenden
Abbildung und Tabelle entnehmen. (Quelle: 15 & 16)
André Killing (155033)
Oliver Hanslian (125446)
Roy Norbart (123834)
Seite 20 von 53
Architektur des Super Nintendo Entertainment Systems
08. Juli 2008
+-------------------------------//----------------------------+
| 32 33 34 35 | 36 37 38 39 40 //53 55 56 57 58 | 59 60 61 62 |
| 01 02 03 04 | 05 06 07 08 09// 22 24 25 26 27 | 28 29 30 31 |
+----------------------------//-------------------------------+
Pin
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
Name
Clk
EXP
PA6
/PARD
GND
A11
A10
A9
A8
A7
A6
A5
A6
A3
A2
A1
A0
/IRQ
D0
D1
D2
D3
/READ
CIC
CIC
/RAM Enable
VCC
PA0
PA2
PA4
LAI
Beschreibung
21,48MHz Clk
Expansion
Address 6 (Bus B)
Read (Bus B)
Ground
Address 11
Address 10
Address 9
Address 8
Address 7
Address 6
Address 5
Address 4
Address 3
Address 2
Address 1
Address 0
Interrupt
Data 0
Data 1
Data 2
Data 3
Read
Copy Prot.
Copy Prot.
RAM Enable
+5 VDC
Address 0 (Bus B)
Address 2 (Bus B)
Address 4 (Bus B)
Left Audio Input
Pin
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
Name
/WRAM
REFRESH
PA7
/PAWR
GND
A12
A13
A14
A15
A16
A17
A18
A19
A20
A21
A22
A23
/ROM ENABLE
D4
D5
D6
D7
/WRITE
CIC
CIC
n/c
VCC
PA1
PA3
PA5
RAI
Beschreibung
WRAM (Bus A)
MEM Refresh
Address 7 (Bus B)
Write (Bus B)
Ground
Address 12
Address 13
Address 14
Address 15
Address 16
Address 17
Address 18
Address 19
Address 20
Address 21
Address 22
Address 23
ROM Enable
Data 4
Data 5
Data 6
Data 7
Write
Copy Prot.
Copy Prot.
Not connected
+5 VDC
Address 1 (Bus B)
Address 3 (Bus B)
Address 5 (Bus B)
Right Audio Input
Tabelle 5: Cartridge Pinout (Quelle: 15 & 16)
Die Angaben stammen von zwei Internetseiten, bei denen die Autoren ausdrücklich darauf
hinweisen, dass die Angaben aus Dokumentationen übernommen wurden und nicht auf Richtigkeit
geprüft wurden. Dennoch gehen wir davon aus, dass zumindest die Pins 5-27 & 36-58 korrekt sind,
da diese auf allen von uns gefundenen Quellen identisch waren. Bei den eben nicht genannten Pins
(1-4, 28-35 & 59-62) haben wir jedoch nur eine Quelle gefunden, die diese beschreibt. Daher sind
diese mit Vorsicht zu betrachten. Die genannten Pins gehören zu den Co-Prozessoren (welche weiter
unten behandelt werden) und sind daher nicht in jedem Modul vorhanden (Siehe Abbildung 7 &
Abbildung 8).
André Killing (155033)
Oliver Hanslian (125446)
Roy Norbart (123834)
Seite 21 von 53
Architektur des Super Nintendo Entertainment Systems
08. Juli 2008
Abbildung 7: SNES-Cartridge ohne Co-Prozessor (Spiel: "Super R-Type") (Quelle: Privat)
Abbildung 8: SNES-Cartridge mit Co-Prozessor (Spiel: "Starwing") (Quelle: Privat)
Nun soll noch eine Erklärung zu den Pins 5-27 und 36-58 folgen. Die Pins A0-24 sind die
Adressleitungen. Der Super NES kann hier über seinen Bus A die gewünschte Adresse anlegen, um
den Inhalt einer Speicherstelle im ROM oder im RAM auszulesen bzw. zu schreiben. Welche
Datenquelle bzw. welches Datenziel die CPU auswählt, legt diese mit den Leitungen /RAM Enable
bzw. /ROM Enable fest. Über die Pins /READ bzw. /WRITE wird angegeben, in welche Richtung die
Daten über die Datenleitungen D0-7 übertragen werden sollen.
Der Pin /IRQ wird zum Senden bzw. Empfangen eines Interrupts verwendet. Die vier CIC-Pins
übertragen Daten zum Überprüfen des Kopierschutzes. VCC und GND ist die Spannungsversorgung
für das Modul.
Die 24 Adressleitungen unterteilen sich in zwei Bereiche. Über die Leitungen A0-15 wird der Offset
und über die Leitungen A16-23 wird die Speicherbank ausgewählt. Auffallend ist, dass über 24
Adressleitungen ein Speicher von max. 128MB bzw. 1024Mbit Byteadressierbar ist. Laut Nintendo ist
jedoch die Modulgröße auf max. 8MB bzw. 64Mbit beschränkt. Weshalb es zu einer solchen
Einschränkung kommt, ist uns nicht bekannt, soll jedoch hier auch nicht behandelt werden, da dieses
Kapitel nur einen kurzen Einblick in das Modul geben sollte. (Quelle: 14, 15, 16)
André Killing (155033)
Oliver Hanslian (125446)
Roy Norbart (123834)
Seite 22 von 53
Architektur des Super Nintendo Entertainment Systems
8
08. Juli 2008
Externe Co-Prozessoren
Da die CPU des SNES mit den max. 3,6MHz recht schwach ist, muss diese für manche Spiele
unterstützt werden. Für die ersten Spiele wie „Super Mario World“ reichte die Rechenleistung noch
aus. Bei Spielen wie „Starwing“ oder „Super Mario World 2“ welche für damalige Verhältnisse
aufwendige Grafiken besaßen, wurden Spezialchips als Co-Prozessoren benötigt. Jedoch waren
Grafikberechnungen nicht der einzige Aufgabenbereich solcher Spezialchips. So wurde auch die
Berechnung der KI, die Dekompression von Daten aus dem ROM oder auch die Systememulation
(Game Boy) auf solche Spezialchips ausgelagert. Ein Teil der möglichen SNES Co-Prozessoren wurde
von Nintendo selbst oder von einer von Nintendo beauftragten Firma entwickelt. Meist sind dies
universell einsetzbare Co-Prozessoren. Der andere Teil sind herstellerspezifische Eigenentwicklungen.
Hierbei handelt es sich meist um Prozessoren, die nur für eine bestimmte Aufgabe entwickelt
wurden. (Quelle: 17)
Nachfolgend werden die bekannten von Nintendo entwickelten Spezialchips mit deren Funktion
aufgeführt:
Chip
SA-1
Super FX 1 & 2
DSP 1-4
S-DD1
SGB CPU
MegaChips MX15001TFC
Funktion
Der vom Funktionsumfang leistungsstärkste Spezialchip. Er besitzt als
Kern die gleiche CPU wie der SNES, hat einen Memory-Controller und
zusätzliche Rechenhardware für spezielle Aufgaben. Dieser Chip wird in
Kapitel 8.1 näher erläutert.
Ein Spezialchip, der hauptsächlich zur Berechnung von 3D-Grafiken
verwendet wird. Dieser kann jedoch auch zur Berechnung von 2DGrafiken und arithmetischen Funktionen verwendet werden.
Diese Chipserie wird zum Berechnen von vektorbasierten Funktionen
verwendet. Benötigt werden diese Funktionen, um eine pseudo 3D
Umgebung zu schaffen.
Der S-DD1 wird verwendet, um Bildmaterial, welches im ROM
komprimiert gespeichert ist, zu dekomprimieren. Die SNES-CPU würde
ohne diesen Chip die Daten nicht rechtzeitig der PPU zur Verfügung
stellen können.
Wird für den „Super Game Boy“ verwendet. Dies ist ein SNES-Modul, in
dem man Game Boy Spiele einsetzten und spielen kann. Da die SNESCPU nicht genug Rechenleistung hat, um den Game Boy Code in SNESCode umzuwandeln und in Echtzeit auszuführen, führt dieser Chip das
Umwandeln durch.
Dies ist ein Exot unter den Spezialchips. Erschienen ist er nur in Japan
in sog. Nintendo Power Cartridges. Dies waren SNES Module, auf
denen man an bestimmten Automaten Spiele gegen Geld laden
konnte. Benötigt wurde der Chip zum Speichermanagement und als
Bootloader.
Tabelle 6: Nintendo's Co-Prozessoren (Quelle: 17)
André Killing (155033)
Oliver Hanslian (125446)
Roy Norbart (123834)
Seite 23 von 53
Architektur des Super Nintendo Entertainment Systems
08. Juli 2008
Separat von den „offiziellen“ Chips werden nun die herstellerspezifischen Spezialeinheiten
aufgeführt:
Chip
Cx4
SPC7110
ST010, ST011, ST018
S-RTC
OBC1
Funktion
Eigenentwicklung von „Capcom“ zum Berechnen von Wireframe
Grafiken und trigonometrischen Funktionen.
Ein von Hudson zur Datendekomprimierung verwendete Spezialeinheit.
Eine von „Seta“ entwickelte Chipserie, welche in einigen Spielen zur
Berechnung der KI verwendet wird.
Dies ist eine Echtzeit-Uhr (Real Time Clock)
Ein für ein Spiel von „Intelligent Systems“ entwickelter Chip, welcher
zur Spritemanipulation verwendet wird.
Tabelle 7: Herstellerspezifische Co-Prozessore (Quelle: 17)
Diese speziellen Einheiten ersetzen trotz ihrer hohen Leistung nicht die Haupteinheit des SNES,
sondern unterstützen diese. Somit wird durch das Einsetzen eines Spielmoduls mit einem solchen
Chip das SNES zu einer Multiprozessoreinheit. (Siehe Kapitel 8.1)
André Killing (155033)
Oliver Hanslian (125446)
Roy Norbart (123834)
Seite 24 von 53
Architektur des Super Nintendo Entertainment Systems
08. Juli 2008
8.1 Der SA-1
Der SA-1 Chip ist der leistungsstärkste Spezialchip des SNES (Quelle: 17). Als Kern dieser Einheit dient
die gleiche CPU wie im SNES (WDC65816). Dies macht es leicht, vorhandenen Programmcode auf
diesen Prozessor auszulagern. Zudem besitzt der SA-1 noch einige weitere hardwaregestützte
Funktionen, welche an entsprechender Stelle in diesem Kapitel behandelt werden.
Die Taktfrequenz dieser Einheit ist um den Faktor 4 höher als die der SNES-CPU im Standard Modus
(SNES: 2,68MHz; SA-1: 10,74MHz). Somit ist unter Verwendung dieses Prozessors eine bis zu fünffach
höhere Performance des Gesamtsystems möglich. (Quelle: 10 – Seite 9)
8.1.1 Speicheranbindung
Gegenüber einem Modul ohne Co-Prozessor bei dem die Adress- und Datenleitungen direkt am RAM
und ROM anliegen, werden in diesem Fall die Adressen und Daten an den SA-1 übergeben. Dieser
übernimmt dann die Ansteuerung des Speichers. Abbildung 9 soll diesen Aufbau veranschaulichen.
(Quelle: 10 – Seite 11)
Abbildung 9: Speicheranbindung des SA-1 (Quelle: 10 – Seite 11)
In dieser Darstellung ist nicht erkennbar, dass die SNES CPU auf fast den gesamten Speicher des
Moduls zugreifen kann. Lediglich die internen Register des im SA-1 enthaltenen WDC65816 sind der
SNES-CPU nicht zugänglich. Der SA-1 hingegen hat selbstverständlich Zugriff auf diese Register,
André Killing (155033)
Oliver Hanslian (125446)
Roy Norbart (123834)
Seite 25 von 53
Architektur des Super Nintendo Entertainment Systems
08. Juli 2008
jedoch besitzt diese Einheit keine Möglichkeit Daten, direkt aus dem WRAM des SNES zu beziehen.
(Siehe Abbildung 10) (Quelle: 10 – Seite 12)
Abbildung 10: Speicheranbindung - SA-1 (Quelle: 10 – Seite 12)
Verallgemeinert kann man sagen, dass die SA-1 Einheit auf den gesamten auf dem Modul
befindlichen Speicher zugreifen kann, jedoch keinen Zugriff auf den im SNES implementierten
Speicher bekommt. Dies ist auch sinnvoll, da die SNES-CPU die Steuereinheit des Gesamtsystems ist
und eine Umsetzung eines gemeinsamen Speichers recht aufwändig ist. Als Beispiel hierfür kann man
die Multiprozessor-Server-Systeme nennen. (Quelle: 10 – Seite 12)
André Killing (155033)
Oliver Hanslian (125446)
Roy Norbart (123834)
Seite 26 von 53
Architektur des Super Nintendo Entertainment Systems
08. Juli 2008
8.1.2 Interner Aufbau
Der interne Aufbau des SA-1 entspricht dem des nachfolgenden Blockschaltbildes. Die einzelnen dort
dargestellten Elemente werden nachfolgend erläutert.
Abbildung 11: Blockschaltbild des SA-1 (Quelle: 10 – Seite 13)
Auf die CPU soll hier nicht eingegangen werden, da diese bis auf wenige Unterschiede (Siehe
Entwicklerhandbuch 2 Kapitel 1-5-5) die gleiche wie im SNES ist. Informationen zur Arbeitsweise der
Einheit entnehmen Sie bitte Kapitel 6.2. Auch beim 2KB bzw. 16Kb großen RAM wird auf eine
Erklärung verzichtet, da davon ausgegangen wird, dass die Funktionsweise von RAM bekannt ist. Die
„Super NES CPU I/O“ (siehe Abbildung 11) ist an sich keine Einheit sondern lediglich das Pinout,
mittels welches der SNES mit dem Modul verbunden ist.
Allen einzelnen Einheiten gemein ist die Konfigurationsart. Sowohl das Einstellen der Einheiten als
auch die Kommunikation wird über SFR (Special Function Register) gesteuert. Hierzu stehen eine
Vielzahl an Registern zur Verfügung, die aufgrund des Umfangs nicht alle erläutert werden sollen.
Eine ausführliche Beschreibung ist dem Entwicklerhandbuch von Nintendo zu entnehmen. (Quelle:
10 – Seite 23 folgende)
André Killing (155033)
Oliver Hanslian (125446)
Roy Norbart (123834)
Seite 27 von 53
Architektur des Super Nintendo Entertainment Systems
08. Juli 2008
8.1.2.1 Super MMC:
Die Super MMC ist ein Speichercontroller welcher die Ansteuerung des GamePak-Roms übernimmt.
Diese Einheit ermöglicht dem SNES ein ROM mit über 32Mb Speicher zu adressieren. Hierzu wird der
sog. Map Mode 22 verwendet. Um diesen zu veranschaulichen, sollte zunächst ein Blick auf die
Memory-Map des SA-1 geworfen werden (Abbildung 12) (Quelle: 10 – Seite 14)
Abbildung 12: Memory-Map des SA-1 (Quelle: 10 – Seite 19)
Im linken Bereich der Abbildung befinden sich vier separate Bereiche, welche mit „Game Pak Rom
Select“ gekennzeichnet sind (0000H – FFFFH in den Bänken C0H – FFH). Jedes dieser Elemente hat
einen Adressbereich, der zum Adressieren von 8Mbit nötig ist. Über spezielle Register, welche
anschließend noch genauer beschrieben werden, kann nun angegeben werden, welcher Adressteil
des GamePak-Roms mit diesen Bänken dargestellt werden soll. Diese Konfigurationsregister
ermöglichen zudem die Zuweisung bestimmter ROM-Adressbereiche in die virtuellen Adressbereiche
00:8000H – 1F:FFFFH, 20:8000H – 3F:FFFFH, 80:8000H – 9F:FFFFH, A0:8000H – BF:FFFFH. Dabei
besteht eine spezielle Verknüpfung der Bänke Cx, Dx, Ex, Fx mit den zuvor genannten
Adressbereichen. Bank Cx ist dem Bereich 00:8000H – 1F:FFFFH zugewiesen, wohingegen Bank Dx
mit dem Bereich 20:8000H – 3F:FFFFH verknüpft ist. Diese Art der Verbindung besteht auch für die
übrigen beiden Bänke Ex und Fx.
Welche Adressbereiche des ROMs in diesen Adressraum gelegt werden können, hängt somit vom in
der zugehörigen Bank ausgewählten Speicherbereich ab. Entweder es wird der Adressbereich der
Bank in den Speicherbereich kopiert oder es wird der Block des ROMs abgelegt, welcher dieselbe
Nummer hat wie der Adressbereich (siehe hierzu Abbildung 13). Eine genauere Erklärung folgt weiter
André Killing (155033)
Oliver Hanslian (125446)
Roy Norbart (123834)
Seite 28 von 53
Architektur des Super Nintendo Entertainment Systems
08. Juli 2008
unten in diesem Kapitel.
Sowohl der SA-1 als auch die SuperNES CPU können über die in diesen Bereichen dargestellten
Speicherbereiche auf den Speicher des ROMs zugreifen.
Wie bereits erwähnt, wird über SFR ausgewählt, welche GamePak-ROM-Bereiche an welcher Stelle in
der Memory Map vertreten sind. Ein solches Register ist wie folgt aufgebaut:
Abbildung 13: ROM-Bank Select (Quelle: 10 – Seite 32)
Dieses Register gibt an, welche Adressen des Roms in der Bank Cx und im Bereich 00:8000H –
1F:FFFFH dargestellt werden. Die Register für die anderen Bänke besitzen den gleichen Aufbau wie
das oben dargestellte.
Die Bits CB0-CB2 geben an, welche 8Mb des ROMs mittels der Bank Cx in der Memory Map
angesprochen werden soll. Sollte z.B. der Speicherbereich 40:0000H – 4F:FFFFH in Bank Cx abgelegt
werden, so entspricht dies dem fünften Element des ROMs und somit der Bitfolge 100. Nun gibt es
noch das Bit, welches mit „CBM“ gekennzeichnet ist. Dieses gibt an, welches Element in den ersten
Game Pak ROM Image-Bereich geladen wird (für Bank Dx wäre es das zweite Game Pak ROM Image,
beim Ex das Dritte und bei Fx das Vierte). Setzt man das CBM Bit, so ist im entsprechenden Game Pak
ROM Image Bereich der gleiche ROM-Bereich abgebildet wie in Bank Cx. Ist das Bit nicht gesetzt, so
wird der erste Bereich des ROMs in den ersten Game Pak ROM Image-Bereich gelegt (bei Bank Dx der
zweite Teil in den zweiten Bereich und so fort)
Auf die Speicherbänke 40H – 6FH und die BW-RAM Image Bereiche gehen wir nicht näher ein.
Lediglich der Verwendungszweck soll hier kurz erklärt werden. Die Bänke 40H-6FH dienen zum
André Killing (155033)
Oliver Hanslian (125446)
Roy Norbart (123834)
Seite 29 von 53
Architektur des Super Nintendo Entertainment Systems
08. Juli 2008
Adressieren des Backup-RAMs. Dieser Speicherbereich kann in Blöcke à 64Kb unterteilt werden. Einer
dieser Blöcke kann in die BW-RAM Image-Bereiche projiziert werden. Hierbei ist zu beachten, dass
der BW-RAM-Image-Bereich in den Bänken 00H – 3FH den identischen Inhalt hat wie der in den
Bänken 80H - BFH.
Die weiteren noch nicht besprochenen Bereiche sind nicht im Zusammenhang mit dem Super MMC
zu sehen, da dieser nur die Speicherverwaltung zum externen ROM und RAM übernimmt. (Quelle: 10
– Seite 20 folgende)
8.1.2.2 Arithmetic Circuit
Diese Einheit dient zum schnellen Abarbeiten von arithmetischen Funktionen. Es wird die
Multiplikation, die Division und die kumulative Summe unterstützt. Alle Operanten, mit Ausnahme
des Divisors, können dabei „signed“ sein.
Gesteuert wird die Einheit durch das Register 2250H, in welchem die Bits ACM und M/D die
durchzuführende Operation angeben. Wie diese gesetzt werden können und wie viele Takte (bei
einer Taktfrequenz von 10,74MHz) für die Verarbeitung notwendig sind, entnehmen Sie der
nachfolgenden Tabelle.
Operation
Multiplikation
Division
Kumulative Summe
ACM
0
0
1
M/D
0
1
-
Takte
5
5
6
Tabelle 8: Arithmetic Circuit (Quelle: 10 – Seite 79)
Werte, die diese Einheit verarbeiten soll, müssen dazu in speziellen Registern gesichert werden.
Welcher Operand in welches Register eingetragen werden muss, entnehmen Sie bitte dem 2.
Entwicklerhandbuch Kapitel 1-7-2 folgende. (Quelle: 10 – Seite 79)
8.1.2.3 Character Conversion Circuit
Die CCC dient zum Umwandeln der im BW-RAM oder I-RAM abgelegten Bitmap-Daten in ein PPUkonformes Format. Aufgrund des Aufbaus von Bitmap-Daten können mit diesem Format z.B.
Rotationen und Größenanpassungen schneller durchgeführt werden. Jedoch ist die PPU nicht in der
Lage, Bitmap-Daten zu verarbeiten. Wie diese Umwandlung durchgeführt wird, entnehmen Sie bitte
Kapitel 1-6-1 des 2. Entwicklerhandbuchs. (Quelle: 10 – Seite 67)
8.1.2.4 Variable Length Bit Processing Unit
Diese Einheit ist in der Lage, unterschiedlich lange Datensätze aus dem GamePak ROM zu lesen. Aus
Sicht dieser Einheit besteht der gesamte ROM-Speicher aus einem Datenstring welcher an beliebiger
Stelle gelesen werden kann. So muss nicht mehr Byteweise aus dem Speicher gelesen werden, was
zu einem Geschwindigkeitsschub führt. Umgesetzt wird diese Funktion mittels eines Barrel-Shifts.
Die Arbeitsweise dieser Einheit ist in Kapitel 1-8-1 im 2. Entwicklerhandbuch beschrieben. (Quelle: 10
– Seite 82 folgende)
8.1.2.5 Timer & DMA Circuit
Aufgrund der Tatsache, dass die Funktionsweise dieser Einheiten bekannt sein sollte, verzichten wir
an dieser Stelle auf eine Beschreibung. Sollten dennoch Informationen zu diesen Einheiten erwünscht
André Killing (155033)
Oliver Hanslian (125446)
Roy Norbart (123834)
Seite 30 von 53
Architektur des Super Nintendo Entertainment Systems
08. Juli 2008
sein, so ziehen sie bitte Kapitel 1-9-1 des zweiten Entwicklerhandbuchs für den DMA-Circuit zu Rate.
Das Kapitel der Timer ist leider nicht in dieser Version des Dokuments vorhanden. (Quelle: 10)
8.1.3 Kommunikation mit dem SNES
Der SA-1 ist nicht in der Lage, der SNES-CPU Befehle aufzuzwingen, da das SA-1 System den Slave
darstellt. Dennoch muss natürlich eine Kommunikation zwischen beiden Einheiten stattfinden. Dies
geschieht über spezielle Register, welche Interrupts auslösen. Hierzu stehen zwei Arten von
Interrupts zur Verfügung. Zum einen der normale IRQ sowie der NMI (Not Maskable Interrupt).
Letzerer ist nur in eine Richtung möglich. Dem SA-1 ist es nicht möglich, einen NMI an die Konsole zu
senden.
Nach dem Empfang eines IRQs versucht der Empfänger anhand eines Registers festzustellen, von
welcher Einheit der Request gesendet wurde. Anschließend wird der Request vom Empfänger
zurückgesetzt.
Neben den eigentlichen IRQ kann noch eine zusätzliche 4Bit große Nachricht übertragen werden,
welche dem Empfänger ermöglicht, auf spezielle Weise auf den Interrupt zu reagieren. Da dies
jedoch nicht immer ausreichend ist, können zusätzliche Informationen über dem von beiden
Prozessoren erreichbaren I-Ram ausgetauscht werden. Auch der BW-RAM könnte hierfür verwendet
werden, jedoch ist dieser während einer Character Conversation nicht zugänglich.
In diesem Zusammenhang soll auch der „Internal Controller“ etwas näher erläutert werden. Aufgabe
dieses Elementes ist es, Kollisionen bei Datentransfers zu vermeiden. Dies gilt sowohl für die im SA-1
verbauten Einheiten als auch für die Transfers nach Extern. Sollte die SNES-CPU und ein Element des
SA-1 simultan auf den RAM zugreifen wollen, so wird der SNES-CPU Vorrang gewährt. (Quelle: 10 –
Seite 59)
André Killing (155033)
Oliver Hanslian (125446)
Roy Norbart (123834)
Seite 31 von 53
Architektur des Super Nintendo Entertainment Systems
08. Juli 2008
8.1.4 Operating Modes
Die SA-1 Erweiterung kann in verschiedenen Modi zusammen mit der SNES-CPU arbeiten. Diese Modi
werden nicht durch SFR eingestellt, sondern dynamisch von der SNES-CPU gewählt. Allen Modi
gemein ist, dass die SA-1 keinen Einfluss auf die Wahl hat. Dieser ist im Master-Slave-System der
Slave und führt daher nur die Operationen aus, die diesem zugewiesen wurden. (Quelle: 10 – Seite
63)
Folgende 3 Modi stehen zur Wahl:
8.1.4.1 Accelerator Mode
Dieser Modus ist aus Programmierer-Sicht der am einfachsten umzusetzende. Hierbei dient der
SNES-CPU nur zum Hochladen der auszuführenden Routinen zum SA-1. Dieser verarbeitet dann die
ihm zugeschickten Daten. Während der Verarbeitung im SA-1 wartet der SNES-CPU im Idle-Zustand.
Erst sobald die SA-1 per Interrupt an die SNES-CPU signalisiert, dass die Programmroutinen
verarbeitet wurden, beginnt die CPU weitere Routinen an den SA-1 zu senden.
Die gesamte Abarbeitung des Programmcodes wird also durch die SA-1-Einheit durchgeführt. Dass
die SNES-CPU dabei Untätig ist, macht diesen Modus zum langsamsten von allen.
Nachfolgend ist diese Verarbeitungsmethode dargestellt: (Quelle: 10 – Seite 63)
Abbildung 14: Accelerator Mode
André Killing (155033)
Oliver Hanslian (125446)
Roy Norbart (123834)
(34)
Seite 32 von 53
Architektur des Super Nintendo Entertainment Systems
08. Juli 2008
8.1.4.2 Parallel Processing Mode
Bei diesem Modus werden zuvor sequenziell abgearbeitete Programmteile parallel auf den beiden
CPUs abgearbeitet. Dieser Modus ist somit schneller als der Accelerator Mode, da auch die SNES-CPU
an der Abarbeitung des Programmcodes beteiligt ist. Es können jedoch auch hier Idle-States
entstehen, wenn Programmteile auf Ergebnisse von Routinen im anderen Prozessor warten müssen.
(Quelle: 10 – Seite 64)
Abbildung 15: Parallel Processing Mode (Quelle: 10 – Seite 64)
André Killing (155033)
Oliver Hanslian (125446)
Roy Norbart (123834)
Seite 33 von 53
Architektur des Super Nintendo Entertainment Systems
08. Juli 2008
8.1.4.3 Mixed Processing Mode
Wie der Name schon andeutet, werden hier die beiden zuvor angesprochenen Modis miteinander
verknüpft. Die SNES-CPU teilt dabei dem SA-1 Programmteile zu, die dieser abarbeiten soll.
Währenddessen verarbeitet dieser andere Subroutinen. Es ist jedoch auch möglich, dass die SNESCPU bereits angefangene Subroutinen an den wesentlich schnelleren SA-1-CPU weiterleitet und auf
ein Ergebnis wartet. (Quelle: 10 – Seite 65)
Abbildung 16: Mixed Processing Mode (Quelle: 10 – Seite 65)
André Killing (155033)
Oliver Hanslian (125446)
Roy Norbart (123834)
Seite 34 von 53
Architektur des Super Nintendo Entertainment Systems
9
Programmierung des Systems
9.1
Allgemeiner Aufbau der Instruktionen
08. Juli 2008
Der SNES wird mit einer Variante des Assembler-Befehlscodes programmiert. Diese Variante verfügt
über eine große Bandbreite von Befehlen und kann verwendet werden, um alle Bauteile des SNES zu
programmieren. Auch die allermeisten SNES-Emulatoren verwenden diesen Befehlscode, allerdings
gibt es auch eine Abwandlung von C, die zur Programmierung verwendet werden kann. Wir haben
nur die Assembler-Variante verwendet.
Die große Bandbreite von Befehlen von unterschiedlicher Länge lässt vermuten, das es sich um einen
CISC-Befehlssatz handelt, sicher lässt sich dies aber für den SNES nicht sagen, da das Produkt des
Compilers nicht bekannt ist, sondern nur der geschriebene Code, und wir ausserdem nicht alle
Befehle kennen. Der Assembler-Befehlscode verfügt über drei genutzte Register (Akkumulator, X, Y),
für die jeweils Lade- und Speicher-Befehle existieren. Weiterhin gibt es Befehle, um Daten von einem
ins andere Register zu verschieben. Ein eigener Speicherbefehl speichert den Wert null in einer
Speicherzelle. Auch gibt es einer Reihe von Sprungbefehlen, vom einfachen Sprung bis zu Varianten
wie ‚bpl „Wert“’ (Branch on Plus, Springe, wenn der Wert „Wert“ positiv ist). Daneben gibt es noch
eine ganze Reihe weiterer Befehle, deren Beschreibung hier den Rahmen sprengen würde. Zumal es
nicht sicher ist, dass uns alle Befehle bekannt sind, da es nicht möglich war, einen vollständigen
Befehlssatz zu finden.
Jeder Befehl kann maximal einen angegebenen Parameter haben, der zweite Parameter ist
grundsätzlich durch den Befehl vorgegeben, so überhaupt ein zweiter Parameter nötig ist. Als
Beispiel soll hier der Befehl ‚lda’ dienen, der einen Wert in den Akkumulator lädt. Lda lässt sich
verschiedentlich laden, so kann man einen Wert direkt angeben, der in den Akku geladen werden soll
(lda #$00 , lade den Wert(#) 00 Hex($) in den Akku), oder eine Speicherstelle angeben, deren Wert in
den Akku geladen werden soll (lda $2214 , lade den Wert der Speicherstelle 2214 Hex($) in den
Akku). Auch kann Registerindirekt adressiert werden (lda $2214,x , lade den Wert in den Akku, der
sich in der Speicherstelle befindet, die durch 2214 Hex($) plus den Inhalt des X-Registers(x) adressiert
wird). Statt einer 16 Bit-Adresse kann auch eine 24 Bit-Adresse angegeben werden, oder es kann
über das Direct-Register adressiert werden. (Quelle: 18 & 19)
André Killing (155033)
Oliver Hanslian (125446)
Roy Norbart (123834)
Seite 35 von 53
Architektur des Super Nintendo Entertainment Systems
08. Juli 2008
9.2 Initialisierungsparameter
Um einen SNES emulieren zu können, muss sich ein Emulator auch wie ein solcher verhalten. Daher
muss er auch den Initialisierungsalgorithmus abbilden, der im SNES zum Zeitpunkt des Anschaltens
abläuft. Hierzu gibt es im Netz zwei Init-Routinen, die einfach in jedes Emulator-Programm
eingebunden werden können, und den Emulator auf den Stand setzen, dass er das eigentliche
Programm genau so abarbeitet, wie ein echter SNES es tun würde. Die Routinen sind in den
Anhängen A und B zu finden, die Inhalte seien hier noch mal kurz erläutert:
header.inc (Quelle: 20)
In der header.inc werden allgemeine Dinge definiert, die teilweise beim echten SNES durch
die Hardware schon vorgegeben sind, teilweise von SNES zu SNES variieren können. Allen
gemeinsam ist aber, dass sie bei einem SNES immer gleich sind. Am wichtigsten sind hier die
Definitionen der ROM-Bänke und der ROM-Startadressen, so dass klar ist, über wie viel
Speicher der simulierte ROM verfügt und wo dieser adressiert wird. Als Zusatz lässt sich hier
der Name des zu schreibenden Programms definieren.
Snes_Init.asm (Quelle: 21)
Die Snes_Init.asm ist, entgegen der header.inc, keine Header-Datei, sondern beinhaltet ein
Makro, welches ein Unterprogramm aufruft. Somit könnte sie auch im eigentlichen
Programmcode stehen. Dass sie dennoch ausgegliedert ist, liegt einfach daran, dass der Code
sich immer wieder verwenden lässt, und als eigene Datei einfacher einzubinden ist. Der SNES
verfügt über nur wenige Register in der CPU, sondern lässt viele wichtige Werte im RAM an
eigens dafür vorgesehenen Stellen ablegen. Die Snes_Init.asm schreibt an diese Stellen die
benötigten Werte, so dass das Programm mit einem Minimum an Änderungen auskommt,
ohne irgendwo undefinierte Werte stehen zu haben. Das wiederum heisst in den meisten
Fällen, dass die entsprechenden Speicherstellen mit null initialisiert werden (stz = Store
Zero), an einigen Stellen werden aber auch andere Werte geschrieben, so wird der Bildschirm
mit „Ausgeschaltet, volle Helligkeit“ initialisiert, damit im Programm hier eine Ausgabe
definiert werden kann, und er dann angeschaltet werden kann. (Quelle: 10 – Seite 11)
André Killing (155033)
Oliver Hanslian (125446)
Roy Norbart (123834)
Seite 36 von 53
Architektur des Super Nintendo Entertainment Systems
08. Juli 2008
9.3 Entwickeltes Testprogramm
Die Programme wurden in mehreren Zyklen entwickelt, mit dem festen Ziel, am Ende etwas „zum
Zeigen“ zu haben. So wurde mit der Informationssuche begonnen, und als erstes ein einfaches
Programm entwickelt, welches den Bildschirm einfärbt. Diese Funktion ist auch noch im SoundtestProgramm zu finden. Zu diesem Zeitpunkt lagen die beiden Init-Dateien schon vor, wodurch dieser
Schritt sich recht einfach gestaltete. Das Programm tut nicht mehr, als den Bildschirm abzuschalten,
die Farbe durch Ändern der entsprechenden Parameter zu wechseln, und den Bildschirm wieder
einzuschalten. (Quelle: 22)
Da über den Soundchip und dessen Programmierung am meisten Informationen vorlagen, war das
der logische nächste Schritt. Dies gestaltete sich etwas schwieriger, da mit einem anderen Chip, dem
Soundchip, kommuniziert werden musste. Da aber der größte Teil der SNES-Programmierung auf
diesem Wege abläuft, war das unumgänglich. Der Ablauf war aus en Inormationen ersichtlich: Daten
zuerst auf dem ROM, dies sollte im Initialisierungsteil geschehen, da auf dem SNES die Daten auch
schon von Anfang an auf dem ROM sind. Dann müssen die Daten auf den RAM der CPU und von da
weiter in den RAM des Soundchips. Weiterhin müssen die Header-Informationen vom ROM auf den
RAM, und dort in ein kleines Programm verpackt werden, welches das Abspielen der Datei startet.
Dieses Programm muss ebenfalls an den Soundchip gesendet werden und dort gestartet werden. Mit
entsprechender Initialisierung wird die Musik dann als Endlosschleife abgespielt. Der Quellcode ist in
Anhang C zu finden. (Quelle: 23)
Der dritte Schritt war dann die Entwicklung eines kleinen Grafik-Programms. Hierzu lag ein
rudimentäres Beispielprogramm vor, welches entsprechend modifiziert werden musste. Die Quelle
des Beispielprogramms liegt uns leider nicht mehr vor. Ein Datensatz zum Anzeigen von Buchstaben
war ebenfalls gefunden worden. Das Programm wurde in vier einzelnen schritten entwickelt:
Anzeigen eines Buchstaben, eines Textes, eines fliessenden Textes, und als letztes, eines in einer
Sinuskurve schwingenden Textes, als optisches „Highlight“. Der Aufbau ist immer ähnlich. Zunächst
wird der SNES initialisiert, wobei hier noch zusätzliche unterprogramme hinzukommen, die den
Grafik-RAM leeren und den Buchstaben-Datensatz hineinkopieren. Dann wird der anzuzeigende Text
identifiziert und Zeilenweise angezeigt. Zuletzt wird noch der Bildschirm wieder angeschaltet, und je
nach Programm das ganze auf dem Stand angehalten oder immer wieder neu gestartet. Bei einem
einzelnen Buchstaben gestaltet sich das recht einfach: Der Buchstabe wird identifiziert und alle Pixel
desselben angezeigt. Bei der Zeile ist das schon schwieriger, da jeder Buchstabe einzeln angezeigt
werden muss. Bei dem Fliesstext wird nur ein Teil des Textes angezeigt, wobei der angezeigte Teil
jeweils nach der Anzeige geändert wird, beim schwingenden Text muss die Anzeige noch mit der
Sinuskurve verrechnet werden. Der Quelltext der letzten Variante, des schwingenden Textes, ist in
Anhang D zu finden.
André Killing (155033)
Oliver Hanslian (125446)
Roy Norbart (123834)
Seite 37 von 53
Architektur des Super Nintendo Entertainment Systems
08. Juli 2008
9.4 Kompilierung und Test
Geschrieben werden die Programme, aufgrund ihrer Assembler-ähnlichen Programmiersprache, mit
jedem denkbaren Texteditor. Es mag spezielle Programme geben, die das Schreiben eines SNESProgrammes erleichtern, doch zumindest waren solche für uns nicht auffindbar. Ein einmal
geschriebenes Programm wird dann, sobald fertig und fehlerfrei, in eine Objektdatei kompiliert. Wir
haben dazu das WLA DX Macro Assembler Package (Quelle: 24) verwendet, welches neben Compiler
und Linker noch eine Textausgabe der gefundenen Fehler anzeigt. Dies ist zum debuggen sehr
hilfreich. Wenn die Objektdatei existiert, muss eine Link-Datei erstellt werden, in der alle
Objektdateien des aktuellen ROM aufgeführt sind. Diese Datei ist, zumindest bei dem von uns
genutzten Linker, notwendig, auch wenn nur eine Objektdatei existiert. Die Objektdatei und die
Linkdatei werden dann dem Linker übergeben, der daraus eine smc-Datei macht, die von jedem
üblichen SNES-Emulator gelesen werden kann. Wir haben hier den ZSNES-Emulator (Quelle: 25)
verwendet. Im Emulator lässt sich jetzt das entsprechende simulierte ROM auswählen und starten.
Über die Ausgabe erhält man eine weitere Möglichkeit, den Code zu testen.
André Killing (155033)
Oliver Hanslian (125446)
Roy Norbart (123834)
Seite 38 von 53
Architektur des Super Nintendo Entertainment Systems
08. Juli 2008
10 Quellenverzeichnis
(1)
Technische Daten des AMIGAS (Stand: 30.06.2008):
http://www.amigafuture.de/kb.php?=&k=367&mode=article
(2)
Technische Daten des AMIGA 500 (Stand: 30.06.2008):
http://de.wikipedia.org/wiki/Amiga_500
(3)
Technische Daten des 3DO (Stand: 30:06.2008):
http://classicgaming.gamespy.com/View.php?view=ConsoleMuseum.Detail&id=39&game=12
(4)
Weitere Daten des 3DO (Stand: 30:06.2008):
http://de.wikipedia.org/wiki/3DO
(5)
Technische Daten des SEGA Mega Drives (Stand: 30.06.2008):
http://de.wikipedia.org/wiki/Megadrive
(6)
Allgemeine Daten zum SNES (Stand 30.06.2008):
http://de.wikipedia.org/wiki/SNES
(7)
Technische Daten der Sony PlayStation (Stand: 30.06.2008):
http://de.wikipedia.org/wiki/Playstation
(8)
Technische Daten des Intel 486er (Stand: 30.06.2008):
http://de.wikipedia.org/wiki/80486
(9)
SNES Development Manual Book 1 (Stand: November 2007)
http://www.romhacking.net/docs/226
(10)
SNES Development Manual Book 2 (Stand: November 2007)
http://www.romhacking.net/docs/226
(11)
Spezifikation der SNES CPU (Stand: 30.06.2008):
http://www.65c816.com/wdc/documentation/w65c816s.pdf
(12)
Technische Daten des SNES (Stand: 30.06.2008):
http://en.wikipedia.org/wiki/Snes
(13)
Kopierschutzsystem des SNES (Stand: 30.06.2008):
http://www.freepatentsonline.com/4799635.html
(14)
Allgemeiner Modulaufbau (Stand: 30.06.2008):
http://patpend.net/technical/snes/sneskart.html
(15)
Pinout des SNES-Moduls (Stand: 30.06.2008):
http://pinouts.ru/Game/CartridgeSnes_pinout.shtml
(16)
Pinout des SNES-Moduls (Stand: 30.06.2008):
http://www.allpinouts.org/index.php/SNES_Cartridge
André Killing (155033)
Oliver Hanslian (125446)
Roy Norbart (123834)
Seite 39 von 53
Architektur des Super Nintendo Entertainment Systems
(17)
08. Juli 2008
SNES Co-Prozessoren (Stand: 30.06.2008):
http://en.wikipedia.org/wiki/List_of_Super_NES_enhancement_chips
(18)
Assemblerprogrammierung des SNES (Stand: 30.06.2008):
http://en.wikibooks.org/wiki/Super_NES_Programming/Introduction_to_assembly
(19)
Register des SNES (Stand: 30.06.2008):
http://en.wikibooks.org/wiki/Super_NES_Programming/SNES_Hardware_Registers
(20)
SNES-Programmheader (Stand: 30.06.2008):
http://en.wikibooks.org/wiki/Console_Game_Programming:SNES_Initialization_Tutorial/Snes_Init
(21)
SNES-Initialisierungsprogramm: (Stand: 30.06.2008):
http://en.wikibooks.org/wiki/Console_Game_Programming:SNES_Initialization_Tutorial/header
(22)
SNES-Initialisierungs-Tutorial (Stand: 30.06.2008):
http://en.wikibooks.org/wiki/Super_NES_Programming/Initialization_Tutorial
(23)
SNES-Sound-Programme (Stand: 30.06.2008):
http://en.wikibooks.org/wiki/Super_NES_Programming/Loading_SPC700_programs
(24)
SNES-Emulator für Windows (Stand: 30.06.2008):
http://www.zsnes.com/
(25)
Compiler für SNES-Programme (Stand: 30.06.2008):
http://www.villehelin.com/wla.html
André Killing (155033)
Oliver Hanslian (125446)
Roy Norbart (123834)
Seite 40 von 53
Architektur des Super Nintendo Entertainment Systems
08. Juli 2008
11 Abbildungsverzeichnis
Abbildung 1: Blockschaltbild des SNES (Quelle: 9 – Seite 99) ................................................................. 8
Abbildung 2: Blockschaltbild der SNES-CPU (Quelle: 11 – Seite 11) ..................................................... 10
Abbildung 3: Soundeinheit (Quelle: 9 – Seite 154) ............................................................................... 14
Abbildung 4: Adressbereich des SPC 700 (Quelle: 9 – Seite 155) ......................................................... 15
Abbildung 5: Transfer-Ports des SPC700 (Quelle: 9 – Seite 161) .......................................................... 16
Abbildung 6: Timer / Counter des SPC700 (Quelle: 9 – Seite 164) ....................................................... 17
Abbildung 8: SNES-Cartridge mit Co-Prozessor (Spiel: "Starwing") (Quelle: Privat) ............................. 22
Abbildung 7: SNES-Cartridge ohne Co-Prozessor (Spiel: "Super R-Type") (Quelle: Privat) ................... 22
Abbildung 9: Speicheranbindung des SA-1 (Quelle: 10 – Seite 11) ....................................................... 25
Abbildung 10: Speicheranbindung - SA-1 (Quelle: 10 – Seite 12) ......................................................... 26
Abbildung 11: Blockschaltbild des SA-1 (Quelle: 10 – Seite 13) ............................................................ 27
Abbildung 12: Memory-Map des SA-1 (Quelle: 10 – Seite 19) ............................................................. 28
Abbildung 13: ROM-Bank Select (Quelle: 10 – Seite 32) ....................................................................... 29
Abbildung 14: Accelerator Mode (34) .................................................................................................... 32
Abbildung 15: Parallel Processing Mode (Quelle: 10 – Seite 64)........................................................... 33
Abbildung 16: Mixed Processing Mode (Quelle: 10 – Seite 65) ............................................................ 34
12 Tabellenverzeichnis
Tabelle 1: Computersysteme um 1990 (Quellen: 1-8) ............................................................................ 7
Tabelle 2: Technische Daten des SPC700 (Quelle: 9 – Seite 153) ......................................................... 14
Tabelle 3: Diverse Komponenten des SNES (Quelle: 12) ....................................................................... 19
Tabelle 4: Cartridge-Mikrochips (Quelle: 14) ........................................................................................ 20
Tabelle 5: Cartridge Pinout (Quelle: 15 & 16) ....................................................................................... 21
Tabelle 6: Nintendo's Co-Prozessoren (Quelle: 17)............................................................................... 23
Tabelle 7: Herstellerspezifische Co-Prozessore (Quelle: 17) ................................................................. 24
Tabelle 8: Arithmetic Circuit (Quelle: 10 – Seite 79) ............................................................................. 30
André Killing (155033)
Oliver Hanslian (125446)
Roy Norbart (123834)
Seite 41 von 53
Architektur des Super Nintendo Entertainment Systems
08. Juli 2008
13 Anhänge
13.1 Anhang A: header.inc
;==LoRom==
; We'll get to HiRom some other time.
.MEMORYMAP
SLOTSIZE $8000
;
;
;
;
;
;
;
DEFAULTSLOT 0
SLOT 0 $8000
.ENDME
.ROMBANKSIZE $8000
.ROMBANKS 8
.SNESHEADER
ID "SNES"
Begin describing the system architecture.
The slot is $8000 bytes in size. More
details on slots later.
There's only 1 slot in SNES, there are more
in other consoles.
Defines Slot 0's starting address.
End MemoryMap definition
; Every ROM bank is 32 KBytes in size
; 2 Mbits - Tell WLA we want to use 8 ROM
; Banks
; 1-4 letter string, just leave it as "SNES"
NAME "SNES Tile Demo
"
;
"123456789012345678901"
; Program Title - can't be over 21 bytes,
; use spaces for unused bytes of the name.
SLOWROM
LOROM
CARTRIDGETYPE $00
others
ROMSIZE $08
SRAMSIZE $00
COUNTRY $01
LICENSEECODE $00
VERSION $00
.ENDSNES
; $00 = ROM only, see WLA documentation for
.SNESNATIVEVECTOR
COP EmptyHandler
BRK EmptyHandler
ABORT EmptyHandler
NMI VBlank
IRQ EmptyHandler
.ENDNATIVEVECTOR
; Define Native Mode interrupt vector table
.SNESEMUVECTOR
COP EmptyHandler
ABORT EmptyHandler
NMI EmptyHandler
RESET Start
IRQBRK EmptyHandler
.ENDEMUVECTOR
; Define Emulation Mode interrupt vector table
;
;
;
;
;
$08 = 2 Mbits,
No SRAM
$01 = U.S. $00
Just use $00
$00 = 1.00, $01
see WLA doc for more..
see WLA doc for more..
= Japan, that's all I know
= 1.01, etc.
; where execution starts
.BANK 0 SLOT 0
; Defines the ROM bank and the slot it is
inserted in memory.
.ORG 0
; .ORG 0 is really $8000, because the slot
starts at $8000
.SECTION "EmptyVectors" SEMIFREE
André Killing (155033)
Oliver Hanslian (125446)
Roy Norbart (123834)
Seite 42 von 53
Architektur des Super Nintendo Entertainment Systems
08. Juli 2008
EmptyHandler:
rti
.ENDS
.EMPTYFILL $00
; fill unused areas with $00, opcode for BRK.
; BRK will crash the snes if executed.
13.2 Anhang B: Snes_Init.asm
.MACRO Snes_Init
sei
clc
xce
rep
#$18
ldx
#$1FFF
txs
;
;
;
;
;
Disabled interrupts
clear carry to switch to native mode
Xchange carry & emulation bit. native mode
Binary mode (decimal mode off), X/Y 16 bit
set stack to $1FFF
jsr Init
.ENDM
.bank 0
.section "Snes_Init" SEMIFREE
Init:
sep
lda
sta
stz
stz
#$30
#$8F
$2100
$2101
$2102
stz
stz
stz
stz
stz
stz
stz
stz
stz
stz
stz
stz
stz
stz
stz
stz
stz
stz
stz
stz
stz
stz
stz
stz
stz
lda
sta
$2103
$2105
$2106
$2107
$2108
$2109
$210A
$210B
$210C
$210D
$210D
$210E
$210E
$210F
$210F
$2110
$2110
$2111
$2111
$2112
$2112
$2113
$2113
$2114
$2114
#$80
$2115
André Killing (155033)
Oliver Hanslian (125446)
Roy Norbart (123834)
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
X,Y,A are 8 bit numbers
screen off, full brightness
brightness + screen enable register
Sprite register (size + address in VRAM)
Sprite registers (address of sprite
memory [OAM])
same as above
Mode 0, = Graphic mode register
noplanes, no mosaic, = Mosaic register
Plane 0 map VRAM location
Plane 1 map VRAM location
Plane 2 map VRAM location
Plane 3 map VRAM location
Plane 0+1 Tile data location
Plane 2+3 Tile data location
Plane 0 scroll x (first 8 bits)
Plane 0 scroll x (last 3 bits) #$0 - #$07ff
Plane 0 scroll y (first 8 bits)
Plane 0 scroll y (last 3 bits) #$0 - #$07ff
Plane 1 scroll x (first 8 bits)
Plane 1 scroll x (last 3 bits) #$0 - #$07ff
Plane 1 scroll y (first 8 bits)
Plane 1 scroll y (last 3 bits) #$0 - #$07ff
Plane 2 scroll x (first 8 bits)
Plane 2 scroll x (last 3 bits) #$0 - #$07ff
Plane 2 scroll y (first 8 bits)
Plane 2 scroll y (last 3 bits) #$0 - #$07ff
Plane 3 scroll x (first 8 bits)
Plane 3 scroll x (last 3 bits) #$0 - #$07ff
Plane 3 scroll y (first 8 bits)
Plane 3 scroll y (last 3 bits) #$0 - #$07ff
increase VRAM address after writing to $2119
VRAM address increment register
Seite 43 von 53
Architektur des Super Nintendo Entertainment Systems
stz
stz
stz
stz
lda
sta
stz
stz
stz
stz
stz
sta
stz
stz
stz
stz
stz
stz
stz
stz
stz
stz
stz
stz
stz
stz
$2116
$2117
$211A
$211B
#$01
$211B
$211C
$211C
$211D
$211D
$211E
$211E
$211F
$211F
$2120
$2120
$2121
$2123
$2124
$2125
$2126
$2127
$2128
$2129
$212A
$212B
sta
$212C
stz
stz
stz
lda
sta
stz
$212D
$212E
$212F
#$30
$2130
$2131
lda
sta
stz
#$E0
$2132
$2133
stz
lda
sta
stz
stz
stz
stz
stz
stz
stz
$4200
#$FF
$4201
$4202
$4203
$4204
$4205
$4206
$4207
$4208
stz
stz
stz
stz
stz
cli
rts
$4209
$420A
$420B
$420C
$420D
08. Juli 2008
;
;
;
;
VRAM address low
VRAM address high
Initial Mode 7 setting register
Mode 7 matrix parameter A register (low)
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
Mode 7 matrix parameter A register (high)
Mode 7 matrix parameter B register (low)
Mode 7 matrix parameter B register (high)
Mode 7 matrix parameter C register (low)
Mode 7 matrix parameter C register (high)
Mode 7 matrix parameter D register (low)
Mode 7 matrix parameter D register (high)
Mode 7 center position X register (low)
Mode 7 center position X register (high)
Mode 7 center position Y register (low)
Mode 7 center position Y register (high)
Color number register ($0-ff)
BG1 & BG2 Window mask setting register
BG3 & BG4 Window mask setting register
OBJ & Color Window mask setting register
Window 1 left position register
Window 2 left position register
Window 3 left position register
Window 4 left position register
BG1, BG2, BG3, BG4 Window Logic register
OBJ, Color Window Logic Register
(or,and,xor,xnor)
Main Screen designation (planes, sprites
enable)
Sub Screen designation
Window mask for Main Screen
Window mask for Sub Screen
; Color addition & screen addition init setting
; Add/Sub sub designation for screen, sprite,
; color
;
;
;
;
color data for addition/subtraction
Screen setting (interlace x,y/enable SFX
data)
Enable V-blank, interrupt, Joypad register
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
Programmable I/O port
Multiplicand A
Multiplier B
Multiplier C
Multiplicand C
Divisor B
Horizontal Count Timer
Horizontal Count Timer MSB (most significant
bit)
Vertical Count Timer
Vertical Count Timer MSB
General DMA enable (bits 0-7)
Horizontal DMA (HDMA) enable (bits 0-7)
Access cycle designation (slow/fast rom)
Enable interrupts
.ends
André Killing (155033)
Oliver Hanslian (125446)
Roy Norbart (123834)
Seite 44 von 53
Architektur des Super Nintendo Entertainment Systems
08. Juli 2008
13.3 Anhang C: Soundtest.asm
; Dieses Programm spielt eine vorher definierte Sounddatei ab.
; Die Daten der Sounddatei werden dabei so behandelt, wie sie ein SNES auch
; behandeln würde.
.include "Header.inc"
.include "Snes_Init.asm"
.define
.define
.define
.define
.define
.define
BG1MoveH
BG1MoveV
BG2MoveH
BG2MoveV
BG3MoveH
BG3MoveV
$7E1A25
$7E1A26
$7E1A27
$7E1A28
$7E1A29
$7E1A2A
VBlank:
rti
.define
.define
.define
.define
; Einbindung der Initialisierungsdateien
; Einige Definitionen von Werten, die laut
; "Snes_Init.asm" gebraucht werden
; Definition, die laut "Header.inc" gebraucht
; wird
AUDIO_R0
AUDIO_R1
AUDIO_R2
AUDIO_R3
$2140
$2141
$2142
$2143
.define XY_8BIT $10
.define A_8BIT $20
;
;
;
;
;
;
;
Definition der vier Soundports, die für die
Kommunikation der SNES-CPU mit der Sound-CPU
benötigt werden. Diese Ports sind über
Speicherstellen im SNES-RAM abgebildet, die
auch von der Sound-CPU, allerdings mit
anderen Adressen, angesprochenwerden können.
Sie Dienen als Ports in beide Richtungen.
; Einige Definitionen von Werten, die im
; Weiteren gebraucht werden
.define musicSourceAddr $00fd
;
;
;
;
Speicherplatz, der später für die
Kopiervorgänge benötigt wird.
Hier wird die Quelladresse der Musik
gespeichert und hochgezählt.
.define spcFile "OTTest.spc" ; Der Name der Musik-Quelldatei
.define spcFreeAddr $ffa0
; Adresse im RAM des Soundchips, bei der später
; die Init-Routine gespeichert wird
; Speicherbank für die erste Hälfte der Daten der Musik-Quelldatei.
; Im Zuge der Definition werden die Daten gleich aus der Musikdatei in den
; simulierten ROM geschrieben.
.bank 1
.section "musicData1"
spcMemory1: .incbin spcFile skip $00100 read $8000
; Kopiervorgang von Datei zu ROM
.ends
; Speicherbank für die zweite Hälfte der Daten der Musik-Quelldatei.
; Im Zuge der Definition werden die Daten gleich aus der Musikdatei in den
; simulierten ROM geschrieben.
.bank 2
.section "musicData2"
spcMemory2: .incbin spcFile skip $08100 read $8000
; Kopiervorgang von Datei zu ROM
André Killing (155033)
Oliver Hanslian (125446)
Roy Norbart (123834)
Seite 45 von 53
Architektur des Super Nintendo Entertainment Systems
08. Juli 2008
.ends
; Speicherbank für den Programmcode auf der SNES-CPU
.bank 0
.section "MainCode"
dspData:
.incbin spcFile skip $10100 read $0080
; DSP-Daten der Musik-Quelldatei, werden direkt
; in die "MainCode"-Sektion des ROM geschrieben
audioPC: .incbin spcFile skip $00025 read $0002
audioA:
.incbin spcFile skip $00027 read $0001
audioX:
.incbin spcFile skip $00028 read $0001
audioY:
.incbin spcFile skip $00029 read $0001
audioPSW: .incbin spcFile skip $0002a read $0001
audioSP: .incbin spcFile skip $0002b read $0001
; Headerinformationen der Musik-Quelldatei,
; werden direkt in die "MainCode"-Sektion des
; ROM geschrieben
; Hauptprogramm
; Hier wird eine Subroutine aufgerufen, die sich um die Musik kümmert.
; Danach wird der Hintergrund gefärbt und eine Endlosschleife gestartet.
Start:
Snes_Init
; Aufruf der Initialisierung des Emulators
jsr LoadSPC
; Aufruf des Musik-Unterprogramms
; Färben des Hintergrundes
sep
#$20
; Akku auf 8 Bit Breite setzen
lda
#%10000000
; Helligkeit wird auf 0% gesetzt
sta
$2100
lda
#%11100000
; Untere 8 Bit der Hintergrundfarbe laden (Hier
; grün)
sta
$2122
lda
#%00000000
; Obere 8 Bit der Hintergrundfarbe laden (Hier
; grün)
sta
$2122
lda
#%00001111
; Helligkeit wieder auf 100% setzen, damit die
; Farbe angezeigt wird
sta
$2100
Forever:
jmp Forever
; Endlosschleife
; Makro zum Kopieren eines Datenblocks
; Das Makro selbst speichert die übergebenen daten an entsprechenden
; Stellen des Speichers und ruft ein Unterprogramm auf, das den
; Kopiervorgang übernimmt.
.macro sendMusicBlockM
; Parameter: Quellsegment, Quelladresse,
; Zieladresse, Länge
sep
lda
sta
rep
lda
#A_8BIT
#\1
;
;
;
musicSourceAddr +
;
;
#A_8BIT
;
#\2
;
;
André Killing (155033)
Oliver Hanslian (125446)
Roy Norbart (123834)
Akku auf 8 Bit Breite setzen
Lade Quellsegment in den Akku (\1: Erster
Parameter)
2
Speichere Quellsegment an der vorgesehenen
Speicherstelle
Akku auf 16 Bit Breite setzen
Lade Quelladresse in den Akku (\2: Zweiter
Parameter)
Seite 46 von 53
Architektur des Super Nintendo Entertainment Systems
sta
rep
ldx
ldy
jsr
musicSourceAddr ;
;
#XY_8BIT
;
;
#\3
;
;
#\4
;
;
CopyBlockToSPC ;
;
08. Juli 2008
Speichere Quelladresse an der vorgesehenen
Speicherstelle
X-Register und Y-Register auf 16 Bit Breite
setzen
Speichere Zieladresse in X-Register (\3:
Dritter Parameter)
Speichere Länge in Y-Register (\4: Vierter
Parameter)
Aufruf des Unterprogramms für den
Kopiervorgang
.endm
; Unterprogramm, welches für das eigentliche Abspielen der Musik zuständig
; ist. Hier werden die Programme zum kopieren der Musik und zur Ausführung
; des Abspielvorgangs aufgerufen.
LoadSPC:
jsr
CopySPCMemoryToRam
; Subroutine, mittels der die Sounddaten aus
; dem ROM in den RAM kopiert werden
stz
$4200
sei
; Deaktiviert Interrupts und Controllereingaben
sendMusicBlockM $7f $0002 $0002 $ffbe
; Kopiert die Daten vom RAM in den Speicher der
; Sound-CPU
jsr
MakeSPCInitCode ; Schreibt die Initialisierungsroutine für den
; Soundchip anhand der Headerinformationen
sendMusicBlockM $7f $0000 spcFreeAddr $0016
; Speichert den Initcode des Soundprogramms an
; einer freien Speicherstelle im Soundchip-RAM
jsr
InitDSP
; Sendet die DSP-Daten der Sounddatei an die
; Sound-CPU
rep
#XY_8BIT
; X-Register und Y-Register auf 16 Bit Breite
; setzen
ldx
#spcFreeAddr
; Lade die Speicheradresse des Initcodes der
; Sounddatei im Soundchip-RAM in das X-Register
jsr
StartSPCExec
; Startet die Ausführung der Sound-Schleife
cli
sep
#A_8BIT
; Akku auf 8 Bit
lda
#$80
sta
$4200
; Reaktiviert interrupts und Controllereingaben
rts
; Subroutine, mittels der die Sounddaten aus dem ROM in den RAM kopiert
; werden, vom Datenende an Rückwärts
CopySPCMemoryToRam:
Rep
#XY_8BIT
; X,Y auf 16 Bit
ldx.w
#$7fff
; X-Register als Counter auf Anfangswert
; initialisieren (Rückwärts, also höchster Wert
; beginnt)
CopyLoop:
lda.l
spcMemory1,x
; Lade den Inhalt der ersten Speicherbank des
; ROM an der durch das X-Register vorgegebenen
; Position in den Akku
sta.l
$7f0000,x
; Speichere den Inhalt des Akku an die
; Speicherstelle 7f0000 Hex plus den Inhalt des
; X-Register
lda.l
spcMemory2,x
; Lade den Inhalt der ersten Speicherbank des
; ROM an der durch das X-Register vorgegebenen
; Position in den Akku
André Killing (155033)
Oliver Hanslian (125446)
Roy Norbart (123834)
Seite 47 von 53
Architektur des Super Nintendo Entertainment Systems
sta.l
$7f8000,x
dex
bpl
CopyLoop
;
;
;
;
;
;
08. Juli 2008
Speichere den Inhalt des Akku an die
Speicherstelle 7f8000 Hex plus den Inhalt des
X-Register
verringere den Wert im X-Register um 1
Springe zu CopyLoop, wenn der Wert im XRegister positiv ist (bpl: Branch if PLus)
rts
; Sendet die DSP-Daten der Sounddatei an die Sound-CPU
InitDSP:
rep
#XY_8BIT
; X,Y auf 16 Bit
ldx
#$0000
; X-Register auf 0 setzen
InitLoop:
sep
#A_8BIT
; Akku auf 8 Bit
txa
; Kopiere den Inhalt des X-Registers in den
; Akku (Hier: Das untere Byte von X)
sta
$7f0100
; Speichere den Inhalt des Akku an die
; Speicherstelle 7f0100 Hex
lda.l dspData,x
; Lade den Akku mit dem Wert des Bytes der DSP; Daten, der vom X-Register angegeben wird
sta
$7f0101
; Speichere den Inhalt des Akku an die
; Speicherstelle 7f0101 Hex
phx
; Rette den Inhalt des X-Registers auf den
; Stack
; Rufe das Block-Kopier-Makro auf, dass die Speicherstellen 7f0100 und
; 7f0101 in den RAM der Sound-CPU schreiben soll.
sendMusicBlockM $7f $0100 $00f2 $0002
rep
plx
inx
cpx
bne
rts
#XY_8BIT
#$0080
InitLoop
;
;
;
;
;
Schreibe den Inhalt von X vom Stack wieder in
das X-Register
Erhöhe X um 1
Vergleiche X mit 80 Hex
Wenn X geringer, springe zu InitLoop
; Schreibt die Initialisierungsroutine für den Soundchip anhand der
; Headerinformationen
MakeSPCInitCode:
; Es müssen folgende Daten geschrieben werden:
; 00-Byte nach 00.
; 01-Byte nach 01.
; Wert für s nach s.
; PSW-Wert auf den Stack.
; Wert für a nach a.
; Wert für x nach x.
; Wert für y nach y.
; Lade PSW-Wert vom Stack.
; Springe zur Position des Programm-Counters.
sep
#A_8BIT
; Push [01]-Wert auf den Stack.
lda.l
$7f0001
pha
; Push [00]-Wert auf den Stack.
lda.l
$7f0000
pha
André Killing (155033)
Oliver Hanslian (125446)
Roy Norbart (123834)
Seite 48 von 53
Architektur des Super Nintendo Entertainment Systems
08. Juli 2008
; Schreibe Code fürs setzen des [00]-Wertes.
lda
#$8f
; mov dp,#imm
sta.l
$7f0000
pla
sta.l
$7f0001
lda
#$00
sta.l
$7f0002
; Schreibe Code fürs setzen des [01]-Wertes.
lda
#$8f
; mov dp,#imm
sta.l
$7f0003
pla
sta.l
$7f0004
lda
#$01
sta.l
$7f0005
; Schreibe Code fürs setzen des s-Wertes.
lda
#$cd
; mov x,#imm
sta.l
$7f0006
lda.l
audioSP
sta.l
$7f0007
lda
#$bd
; mov sp,x
sta.l
$7f0008
; Schreibe Code fürs pushen von PSW auf den Stack.
lda
#$cd
; mov x,#imm
sta.l
$7f0009
lda.l
audioPSW
sta.l
$7f000a
lda
#$4d
; push x
sta.l
$7f000b
; Schreibe Code fürs setzen des Akku-Wertes.
lda
#$e8
; mov a,#imm
sta.l
$7f000c
lda.l
audioA
sta.l
$7f000d
; Schreibe Code fürs setzen des x-Wertes.
lda
#$cd
; mov x,#imm
sta.l
$7f000e
lda.l
audioX
sta.l
$7f000f
; Schreibe Code fürs setzen des y-Wertes.
lda
#$8d
; mov y,#imm
sta.l
$7f0010
lda.l
audioY
sta.l
$7f0011
; Schreibe Code fürs holen von PSW vom Stack.
lda
#$8e
; pop psw
sta.l
$7f0012
; Schreibe Code fürs springen.
lda
#$5f
; jmp labs
sta.l
$7f0013
rep
#A_8BIT
lda.l
audioPC
sep
#A_8BIT
André Killing (155033)
Oliver Hanslian (125446)
Roy Norbart (123834)
Seite 49 von 53
Architektur des Super Nintendo Entertainment Systems
sta.l
xba
sta.l
rts
08. Juli 2008
$7f0014
$7f0015
; Unterprogramm für den Kopiervorgang
; Dieses Unterprogramm ist für die Kommunikation mit dem Soundchip und das
; Verschieben der Daten vom SNES-RAM in den Sound-RAM zuständig.
; Es verschiebt die Daten anhand der übergebenen Adressen:
;
Die Quelladresse ist in musicSourceAddr gespeichert
;
Die Zieladresse findet sich im X-Register
;
Die Länge des zu kopierenden Blocks ist im Y-Register gespichert
CopyBlockToSPC:
; Warte darauf, dass die Sound-CPU bereit ist.
sep
#A_8BIT
; Akku auf 8 Bit
lda
#$aa
; Lade den Wert aa Hex in den Akku
WaitLoop1:
cmp
AUDIO_R0
; Vergleiche den Wert im Akku mit dem Wert am
; ersten Soundport
bne
WaitLoop1
; Sollte dieser Wert nicht anliegen, warte, bis
; er anliegt
stx
AUDIO_R2
phy
plx
; Speichere die Zieladresse im Port 3
; Schreibe den Wert von Y auf den Stack
; und lade ihn in X
; Start des Kopiervorganges durch senden eines Befehlscodes an die
; Sound-CPU.
lda
#$01
sta
AUDIO_R1
; Lade den Wert 01h in den zweiten Soundport
lda
#$cc
sta
AUDIO_R0
; Lade den Wert cch in den ersten Soundport
WaitLoop2:
cmp
AUDIO_R0
; Vergleiche den Wert im Akku mit dem Wert am
; ersten Soundport
bne
WaitLoop2
; Sollte dieser Wert nicht anliegen, warte, bis
; er anliegt
ldy
#$0000
; Initialisiere das Y-Register mit 0 als
; Counter
CopyBlockToSPC_loop:
Xba
; Tausche die Bytes des Akku
lda
[musicSourceAddr],y
; Lade den Akku mit dem y-ten zu übertragenden
; Byte
xba
; Tausche die Bytes des Akku, so dass das
; Adressbyte im High Byte des Akkus liegt
tya
; Lade den Inhalt von Y in A (das untere Byte
; von Y)
rep
sta
#A_8BIT
AUDIO_R0
sep
#A_8BIT
WaitLoop3:
cmp
AUDIO_R0
André Killing (155033)
Oliver Hanslian (125446)
Roy Norbart (123834)
;
;
;
;
Akku auf 16 Bit
Sende den Inhalt des Akku an den ersten
Soundport
Akku auf 8 Bit
; Vergleiche den Wert im Akku mit dem Wert am
; ersten Soundport
Seite 50 von 53
Architektur des Super Nintendo Entertainment Systems
08. Juli 2008
bne
WaitLoop3
iny
dex
bne
; Zähler hochzählen
; Anzahl noch zu sendender Bytes runterzählen
CopyBlockToSPC_loop
; Wenn noch Bytes zu senden, springe zu
; CopyBlockToSPC_loop
ldx
#$ffc9
stx
AUDIO_R2
; Lade den Wert der Startadresse der IPL ROM
; Routine in das X-Register
; Sende den wert an den dritten Soundport
xba
lda
xba
#0
; Lösche das High Byte des Akku
clc
adc
#$2
; Stoppe den Counter
rep
sta
#A_8BIT
AUDIO_R0
sep
#A_8BIT
;
;
;
;
Akku auf 16 Bit
Sende den Inhalt des Akku an den ersten
Soundport
Akku auf 8 Bit
;
;
;
;
Vergleiche den Wert im Akku mit dem Wert am
ersten Soundport
Sollte dieser Wert nicht anliegen, warte, bis
er anliegt
WaitLoop4:
cmp
bne
AUDIO_R0
WaitLoop4
; Sollte dieser Wert nicht anliegen, warte, bis
; er anliegt
rts
; Startet die Ausführung der Sound-Schleife
; Die Startadresse des Initcodes der Sounddatei befindet sich im X-Register
StartSPCExec:
; Warte darauf, dass die Sound-CPU bereit ist.
sep
#A_8BIT
; Akku auf 8 Bit
lda
#$aa
; Lade den Wert aa Hex in den Akku
WaitLoop5:
cmp
AUDIO_R0
; Vergleiche den Wert im Akku mit dem Wert am
; ersten Soundport
bne
WaitLoop5
; Sollte dieser Wert nicht anliegen, warte, bis
; er anliegt
stx
AUDIO_R2
; Sende die Startadresse an den dritten
; Soundport
; Start der Programmausführung durch senden eines Befehlscodes an die
; Sound-CPU.
lda
#$00
sta
AUDIO_R1
; Lade den Wert 00h in den zweiten Soundport
lda
#$cc
sta
AUDIO_R0
; Lade den Wert cch in den ersten Soundport
WaitLoop6:
cmp
AUDIO_R0
; Vergleiche den Wert im Akku mit dem Wert am
; ersten Soundport
bne
WaitLoop6
; Sollte dieser Wert nicht anliegen, warte, bis
; er anliegt
rts
André Killing (155033)
Oliver Hanslian (125446)
Roy Norbart (123834)
Seite 51 von 53
Architektur des Super Nintendo Entertainment Systems
08. Juli 2008
.ends
13.4 Anhang D: Flex.asm
; Dieses Programm zeigt einen Text auf dem Bildschirm an, der über den
; Bildschirm scrollt und sich dabei dreht. Der Text wird endlos angezeigt,
; wiederholt sich also.
.include "Header.inc"
.include "Snes_Init.asm"
VBlank:
RTI
; Einbindung der Initialisierungsdateien
; Definition, die laut "Header.inc" gebraucht
; wird
.bank 0
.section "MainCode"
; Der Code des Programms befindet sich in der
; Speicherbank 0 des ROM
; Die Startroutine schreibt einige Initialisierungen, um die Textanzeige zu
; ermöglichen. Dann werden einige Unterprogramme aufgerufen, die den RAM
; entsprechend vorbereiten und die Buchstaben und Farben kopieren.
; Gleichzeitig werden verschiedene Zähler definiert, die für die
; Textanzeige benötigt werden. Zuletzt wird eine Endlosschleife gestartet,
; die die Textanzeige am laufen hält.
Start:
Snes_Init
; Aufruf der Initialisierung des Emulators
rep
#$10
; X, Y-Register auf 16 Bite Breite
sep
#$20
; Akkumulator auf 8 Bit Breite
lda
#$00
sta
$2105
; Setze Bildschirm auf Modus 0, 8*8 Bit Tiles
lda
#$75
sta
$2107
; Hintergrund 1 Init-Einstellungen
lda
#$00
sta
$210b
; Hintergrund 1 Tile Init-Einstellungen
lda
#$01
sta
$212c
; Hintergrund 1 aktiviert
stz
$1000
; Startwert der Tile-Initialisierung
stz
$1001
; Speichervariable für Tile-Initialisierung
jsr
Copy_Gfx
; Funktion zum kopieren der Grafikdaten in RAM
jsr
Copy_colors
; Funktion zum kopieren der Farbdaten in den
; Farb-RAM
jsr
Make_tiles
; Leeren des Screens und Tile-Initialisierung
jsr
Clear_ram
; Leeren des VRAM
ldx
stx
#$0000
$1002
ldx
stx
#$0000
$1004
ldx
stx
#$0000
$1006
ldx
stx
#$0000
$1008
André Killing (155033)
Oliver Hanslian (125446)
Roy Norbart (123834)
; Counter für die Zeilen eines zu zeichnenden
; Buchtaben
; Counter für Buchstaben, die zu zeichnen sind
; Grafik-Offset eines Buchstaben. Gibt die
; Position der entsprechenden Grafik im VRAM an
; Hier wird der Text-Offset für die Flex; Funktion gespeichert
Seite 52 von 53
Architektur des Super Nintendo Entertainment Systems
08. Juli 2008
ldx
stx
#$0000
$100a
; Der aktuelle Offset der SINE-Werte
ldx
stx
#$0000
$100c
; Speicherwert für den SINE-Offset
ldx
stx
#$0000
$100e
; Speicherwert für den SINE-Offset
ldx
stx
#$0000
$1010
; Scrollposition innerhalb eines Buchstaben.
ldx
stx
#$0000
$1012
; Scrollposition in Buchstaben im Text
lda
sta
lda
sta
lda
sta
#$00
$10
#$80
$11
#$7e
$12
lda
sta
Waitloop:
jsr
#$0f
$2100
WaitVb
jsr
Routines
bra
Waitloop
; Speichert den Wert 7e8000h in 10-12h, so dass
; mit [$10] $7e8000 adressiert werden kann
; Bildschirm an, höchste Helligkeit
;
;
;
;
;
;
Starte die WaitVb-Routine, um sicher zu sein,
das neue Daten gesendet werden können
Starte die Berechnung und Übertragung neuer
Daten
Springe wieder zu Waitloop, um den Prozess
erneut zu starten
; Routines ist eine Sammelfunktion, in der der DMA-Prozess vom Speicher in
; den VRAM angestossen wird. Weiterhin werden hier die Funktionen, die für
; die Anzeige des Textes benötigt werden, aufgerufen.
Routines:
rep
#$10
; Setze X,Y-Register auf 16 Bit
sep
#$20
; Setze Akku auf 8 Bit
; Start der allgemeinen DMA Routine zum Kopieren der Grafikdaten in die
; Ausgabe. Start eines DMA-Prozesses, der die Daten, die angezeigt
; werden sollen, vom RAM des SNES in den VRAM schreibt.
lda
#$00
sta
$4330
; initialisiere Befehlsregister des vierten
; DMA-Controllers
lda
#$18
sta
$4331
; Setze Zieladresse auf VRAM
lda
#$00
sta
$4332
lda
#$80
sta
$4333
lda
#$7e
sta
$4334
; Setzt Quelladresse auf 7E8000h
ldx
#$0800
stx
$4335
; Anzahl der zu übertragenden Bytes auf 800h
lda
#$00
sta
$2115
; Setze VRAM Autoinkrement auf 0
ldx
#$0000
stx
$2116
; Setzt Zieladresse im VRAM auf 0h
André Killing (155033)
Oliver Hanslian (125446)
Roy Norbart (123834)
Seite 53 von 53
Architektur des Super Nintendo Entertainment Systems
lda
sta
#$08
$420b
lda
sta
#$80
$2115
lda
sta
stz
$1010
$210d
$210d
jsr
Scroll
jsr
Flex
08. Juli 2008
; Startet DMA-Übertragungsprozess mit dem
; vierten DMA-Controller
; Autoinkrement Adresse im Grafik-RAM um 80h
;
;
;
;
;
;
;
;
;
;
;
;
;
;
Lade aktuellen Scrolloffset im Buchstaben
Scrolle den Bildschirm um diesen Offset
Setze den Scrolloffset auf null, um flackern
zu verhindern
Die Scrollroutine setzt den Scrolloffset neu,
so das der Text weiter scrollt. Weiterhin
schreibt sie die Buchstaben, die angezeigt
werden sollen, in den Speicher.
Die Flex-Routine lässt die Buchstaben in
einer Sinuskurve schwingen und ist
gleichzeitig dafür zuständig, das die
Buchstaben zeilenweise in den Speicherbereich
kopiert werden, aus dem sie später die DMARoutine in den VRAM kopiert.
rts
; Die Scrollroutine ist dazu da, den Text in den Speicher zu schreiben, der
; aktuell angezeigt werden soll. Gleichzeitig berechnet sie, welcher Text
; angezeigt wird, wenn der Text über den Bildschirm scrollt.
Scroll:
lda
$1010
; Lade aktuellen Scrolloffset im Buchstaben
clc
adc
#$01
; Erhöhe um 1
sta
$1010
; Speichere den erhöhten Offset
cmp
#$08
; Prüfe, ob über einen Buchstaben gescrollt
; wurde
bcs
scrolltexts
; Wenn ja, springe zu scrolltexts
rts
scrolltexts:
stz
$1010
; Setze aktuellen Scrolloffset im Buchstaben
; auf null
ldy
$1012
; Lade Scrolloffset im Text ins Y-Register
ldx
#$0000
; Lade das X-Register mit null als Counter für
; den Text, der auf dem Bildschirm ausgegeben
; wird
copyscroll:
lda
TEXT,y
; Lade den ersten anzuzeigenden Buchstaben in
; den Akku
sta
$7e7000,x
; Speichere den Buchstaben im RAM an der Stelle
; 7e7000h + X
iny
; Zähle den Counter für den Text hoch
cpy #$0040
; Prüfe, ob der Text zuende ist (der Text hat
; momentan 32 Zeichen)
beq endtext
; Wenn ja, springe zu endtext
moveon:
inx
; Zähle die Counter für die Anzeige hoch
cpx
#$0020
; Prüfe, ob die Anzeige schon voll ist (der
; Bildschirm ist 16 Zeichen breit)
bne
copyscroll
; Wenn noch nicht alle Zeichen ausgegeben
; wurden, starte die Funktion neu
ldy
$1012
; Hole aktuellen Text-Offset
iny
; Erhöhe ihn um 1
cpy #$0040
; Prüfe, ob der Text zuende ist
André Killing (155033)
Oliver Hanslian (125446)
Roy Norbart (123834)
Seite 54 von 53
Architektur des Super Nintendo Entertainment Systems
beq endtext2
moveon2:
sty
$1012
rts
endtext:
ldy
#$0000
bra
moveon
endtext2:
ldy
#$0000
bra
moveon2
08. Juli 2008
; Wenn ja, springe zu endtext
; Speichere den erhöhten Offset
; Lade den Counter für den Text neu
; Lade den Counter für den Text neu
; Die Flex-Routine lässt die Buchstaben in einer Sinuskurve schwingen und
; ist gleichzeitig dafür zuständig, dass die Buchstaben zeilenweise in den
; Speicherbereich kopiert werden, aus dem sie später die DMA-Routine in den
; VRAM kopiert.
Flex:
ldy
$100a
; Lese den aktuellen Absolut-SINE-Offset in Y
; ein
sty
$100e
; Speichere ihn, zur Verwendung für die
; Erstellung aller Buchstaben
Flex1:
ldy
$100e
; Lese den SINE-Offset der Zeile in Y ein
sty
$100c
; Speichere ihn, zur Verwendung für die
; Erstellung eines Buchstaben
ldx
$1008
; Lese den aktuellen Text-Offset in X ein
rep
#$30
; Setze Akku auf 16 Bit
lda
$7e7000,x
; Lese nächsten anzuzeigenden Buchstaben
and
#$003f
; Konvertiere das Format von ASCII zu C64; Format und Lösche das High Byte
asl
a
; Nun wird der Wert vier mal mit 2 malgenommen
asl
a
; (um 1 nach links geschoben) um seine
asl
a
; Entsprechung im Charset zu finden, da jeder
asl
a
; Buchstabe im Charset 16 Byte groß ist.
sta
$1006
; Speichere den Wert
tax
; Schreibe den Wert vom Akku ins X-Register
Flexdraw:
ldy
$100c
; Lese den SINE-Offset für den aktuellen
; Buchstaben in Y ein
rep
#$30
; Setze Akku auf 16 Bit
lda
SINE,y
; Lese SINE-daten an der Stelle y in den Akku
and
#$00ff
; Lösche das High Byte
tay
; Schreibe Akku ins Y-Register
sep
#$20
; Setze Akku auf 8 Bit
lda
$7ea000,x
; Lese das aktuelle Byte der Grafik des
; aktuellen Buchstaben ein
sta
[$10],y
; Speichere es an der Stelle, die der SINE; Offset vorgibt. [$10] ist Speicherindirekt,
; gespeichert wird also an der Stelle im
; Speicher, die in der Speicherstelle 10h
; steht.
inx
; Hole das nächste Byte
inc
$100c
; Erhöhe den SINE-Offset des Zeichens
inc
$1002
; Erhöhe den Zeilencounter des aktuellen
; Buchstaben
lda
$1002
; Lade den Zeilencounter
cmp
#$10
; Prüfe, ob 16 Zeilen gezeichnet wurden
bne
Flexdraw
; Wenn nicht, springe zu Flexdraw
stz
$1002
André Killing (155033)
Oliver Hanslian (125446)
Roy Norbart (123834)
; Setze den Zeilencounter auf null
Seite 55 von 53
Architektur des Super Nintendo Entertainment Systems
inc
lda
cmp
beq
rep
lda
clc
adc
$1004
$1004
#$20
enddraw
#$30
$10
sta
sep
$10
#$20
lda
clc
adc
sta
inc
$100e
bra
enddraw:
lda
sta
lda
sta
Flex1
stz
stz
inc
inc
rts
$1008
$1004
$100a
$100a
#$0040
#$fe
$100e
$1008
#$00
$10
#$80
$11
08. Juli 2008
;
;
;
;
;
;
;
;
;
;
;
;
;
;
Erhöhe den Buchstabencounter
Lade den Buchstabencounter
Prüfe, ob 32 Buchstaben gezeichnet wurden
Wenn ja, springe zu enddraw
Setze Akku auf 16 Bit
Lade den wert der Adresse 10h
Lösche das Carry-Flag
Erhöhe die Adresse im Akku um 40h, also um
ein Zeichen. Jede Spalte ist 64 Byte hoch,
das ist aus der SINE-Tabelle ersichtlich. 64
dezimal sind 40h, und somit muss für die
nächste Spalte der Wert um 40h erhöht werden.
Speichere den Wert wieder in 10h
Setze Akku auf 8 Bit
;
;
;
;
;
;
;
Lade den SINE-Offset der Zeile in den Akku
Lösche das Carry-Flag
Verringere den SINE-Offset um 2
Speichere den Zeilenoffset wieder
Erhöhe den Text-Offset um 1, um das nächste
Zeichen zu lesen
springe zu Flex1
;
;
;
;
Lade den Wert 8000h in 10-11h. 12h ändert
sich nicht
Setze den Text-Offset auf null zurück
Setze den Buchstabencounter auf null zurück
; Erhöhe den Absolut-SINE-Offset um 2
; Die WaitVb (Virtual Blank) Routine wartet, bis der Bildschirm mit neuen
; Daten versorgt werden kann.
WaitVb:
lda
$4210
; Hier wird das NMI-Flag zurückgesetzt, indem
; es gelesen wird. Dadurch wird ein NMI-Prozess
; angestossen, an dessen Ende das Flag wieder
; gesetzt wird. Dieser Prozess ist
; erforderlich, um die Anzeige neu schreiben zu
; können.
bpl WaitVb
; Das NMI-Flag soll high sein. Sollte das nicht
; der Fall sein,
; springt bpl zu WaitVb.
rts
; Diese Funktion leert den VRAM und schreibt das Buchstaben-Charset hinein,
; damit später die Buchstaben anhand dieses Charsets auf dem Bildschim
; angezeigt werden können.
Copy_Gfx:
ldx
#$0000
Clearvr:
stx
$2116
; Wähle VRAM-Adresse durch das X-Register
stz
$2118
stz
$2119
; Lösche die Daten des VRAM an der Stelle
inx
; Erhöhe das X-Register
André Killing (155033)
Oliver Hanslian (125446)
Roy Norbart (123834)
Seite 56 von 53
Architektur des Super Nintendo Entertainment Systems
cpx
bne
ldx
txy
Chardouble:
lda
sta
08. Juli 2008
#$0000
Clearvr
; Prüfe, ob X wieder null erreicht hat
; Ist der RAM noch nicht zuende, springe zu
; Clearvr
#$0000
; Lade X mit null
; Kopiere null auch nach Y
Charset,y
$7ea000,x
;
;
;
;
;
;
;
;
;
;
;
;
;
inx
sta
$7ea000,x
inx
iny
cpy
#$0200
bne
Chardouble
Lese das Y-te Byte des Charset on den Akku
Speichere das Byte im RAM, an der Stelle
7ea000h + X
Erhöhe X um 1
Speichere dasselbe Byte im RAM um eine Stelle
im RAM weiter. Dadurch wird jeder Buchstabe
doppelt so hoch
Erhöhe X um 1
Erhöhe Y um 1
Prüfe ob alle Bytes aller Buchstaben gelesen
wurden
Wenn noch nicht alle Bytes gelesen wurden,
springe zu Chardouble
rts
; Diese Funktion kopiert die verwendeten Farben für Hintergrund und Schrift
; in den Farb-RAM Die Farben sind 16 Bit lang und im 0rrrrrgggggbbbbb; Format gespeichert (0: nicht relevant, r: rot, g: grün, b: blau)
Copy_colors:
stz
$2121
; Adresse 00h im Farb-RAM
lda
#$FD
; High Byte des Hintergrundes
sta
$2122
lda
#$FF
; Low Byte des Hintergrundes
sta
$2122
lda
#$7C
; High Byte der Textfarbe
sta
$2122
lda
#$00
; Low Byte der Textfarbe
sta
$2122
rts
; Diese Funktion löscht die genutzten Hintergründe, indem sie sie mit
; leeren Tiles füllt. Danach werden neue Tiles definiert, die später mit
; den Werten für die Buchstaben gefüllt werden sollen.
Make_tiles:
ldx
#$7400
stx
$2116
; Wähle die Adresse 7400h im VRAM aus
; (Hintergrund 1)
; Auf diesem Hintergrund wird d. Text angezeigt
ldx
#$0000
; Initialisiere X als Counter
clearscreen:
lda
#$00
sta
$2118
lda
#$01
sta
$2119
; Lösche den Hintergrund, indem leere Tiles
; genutzt werden
inx
; Erhöhe X
cpx
#$0400
; Prüfe, ob Alle Tiles des Hintergrundes
; geleert wurden
bne
clearscreen
; Wenn nicht, springe zu clearscreen
ldx
#$7800
André Killing (155033)
Oliver Hanslian (125446)
Roy Norbart (123834)
Seite 57 von 53
Architektur des Super Nintendo Entertainment Systems
stx
$2116
ldx
#$0000
clearscreen2:
lda
#$00
sta
$2118
lda
#$01
sta
$2119
inx
cpx
#$0400
bne
clearscreen2
08. Juli 2008
;
;
;
;
;
Wähle die Adresse 7800h im VRAM aus
(Hintergrund 2). Dieser Hintergrund ist nicht
zu sehen, ausser am rechten Rand, wenn der
erste Hintergrund verschoben wird.
Initialisiere X als Counter
;
;
;
;
;
;
Lösche den Hintergrund, indem leere Tiles
genutzt werden
Erhöhe X
Prüfe, ob Alle Tiles des Hintergrundes
geleert wurden
Wenn nicht, springe zu clearscreen2
; Dieser Teil initialisiert die Tiles, auf denen später der Text
; dargestellt wird. Die Tiles haben einen Inhalt, der für das weitere
; nicht relevant ist, und wie folgt aussieht:
;
00h
08h
10h ... (32 Spalten Breite)
;
01h
09h
11h ...
;
02h
0Ah
12h ...
;
03h
0Bh
13h ...
;
04h
0Ch
14h ...
;
05h
0Dh
15h ...
;
06h
0Eh
16h ...
;
07h
0Fh
17h ...
ldx
stx
ldx
drawchar:
lda
#$7540
$2116
#$0000
$1000
sta
$1001
drawflexpattern:
lda
$1001
sta
$2118
stz
$2119
lda
$1001
clc
adc
#$08
sta
inx
cpx
bne
$1001
ldx
inc
lda
#$0000
$1000
$1000
cmp
bne
rts
#$08
drawchar
#$0020
drawflexpattern
André Killing (155033)
Oliver Hanslian (125446)
Roy Norbart (123834)
; Wähle die Adresse 7540h im VRAM aus
; Initialisiere X als Spaltenzähler
; Lade den Wert des Zeilenzählers (Erste Zeile,
; erste Spalte) in den Akku
; Speichere den Akku zur späteren Verwendung
;
;
;
;
Lade das aktuelle Byte
Schreibe es in den VRAM
Keine Farbpalette dazu auswählen
Lade das aktuelle Byte nochmal
;
;
;
;
;
;
;
;
;
Erhöhe das Byte um 8, um die nächste Zeile zu
erhalten. Die Zählreihenfolge ist vertikal,
deswegen müssen 7 Byte übersprungen werden,
um bei einer Spaltenhöhe von 8 Byte in
dieselbe Zeile der nächsten Spalte zu
gelangen
Aktuelles Byte rückspeichern
Spaltenzähler erhöhen
Prüfe, ob alle 32 Spalten bearbeitet wurden
;
;
;
;
;
;
;
Wenn nicht, springe zu drawflexpattern
Setze den Spaltenzähler wieder zurück
Erhöhe den Zeilenzähler um 1
Lade aktuelles Byte (Nächste Zeile, erste
Spalte)
Prüfe, ob alle Zeilen bearbeitet wurden
Wenn nicht, springe zu drawchar
Seite 58 von 53
Architektur des Super Nintendo Entertainment Systems
08. Juli 2008
; Diese Funktion löscht alle relevanten Bereiche im RAM. Der Bereich
; 7e8000h - 7e8800h ist für die Grafikdaten des anzuzeigenden Textes,
; der Bereich 7e7000h - 7e7020h speichert die Buchstaben in Rohform.
Clear_ram:
ldx
#$0000
; Lade X mit null
clearram:
lda
#$00
; Lade Akku mit null
sta
$7e8000,x
; Speichere null an der Stelle 7e8000h + X
inx
; Erhöhe X
cpx
#$0800
; Prüfe, ob der komplette Bereich geleert wurde
bne
clearram
; Wenn nicht, springe zu clearram
ldx
#$0000
clearscrolltext:
lda
#$20
sta
inx
cpx
bne
rts
; Setze X wieder auf null
;
;
$7e7000,x
;
;
;
#$0040
;
;
clearscrolltext ;
Lade den Akku mit 20h (Der Wert steht für ein
Leerzeichen)
Schreibe den Wert in die Speicherstelle
7e7000 + X
Erhöhe X
Prüfe ob alle Werte, in denen Text
gespeichert wird, überschrieben wurden
Wenn nicht, springe zu clearscrolltext
; Dies sind die Werte, die die Sinuskurve bilden, welcher der Text folgt.
SINE:
.db 32,32,33,34,35,35,36,37,38,38,39,40,41,41,42,43,44,44,45,46
.db 46,47,48,48,49,50,50,51,51,52,53,53,54,54,55,55,56,56,57,57
.db 58,58,59,59,59,60,60,60,61,61,61,61,62,62,62,62,62,63,63,63
.db 63,63,63,63,63,63,63,63,63,63,63,63,62,62,62,62,62,61,61,61
.db 61,60,60,60,59,59,59,58,58,57,57,56,56,55,55,54,54,53,53,52
.db 51,51,50,50,49,48,48,47,46,46,45,44,44,43,42,41,41,40,39,38
.db 38,37,36,35,35,34,33,32,32,31,30,29,28,28,27,26,25,25,24,23
.db 22,22,21,20,19,19,18,17,17,16,15,15,14,13,13,12,12,11,10,10
.db
9, 9, 8, 8, 7, 7, 6, 6, 5, 5, 4, 4, 4, 3, 3, 3, 2, 2, 2, 2
.db
1, 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
.db
1, 1, 1, 1, 1, 2, 2, 2, 2, 3, 3, 3, 4, 4, 4, 5, 5, 6, 6, 7
.db
7, 8, 8, 9, 9,10,10,11,12,12,13,13,14,15,15,16,17,17,18,19
.db 19,20,21,22,22,23,24,25,25,26,27,28,28,29,30,31
; Dies sind die Buchstaben, die später auf dem Bildschirm angezeigt werden.
; Das Charset wurde mit dem Cyber Font-Editor V1.4 erstellt, das aber
; leider nicht kostenlos zu bekommen ist.
Charset:
;==========================================================================
; Cyber Font-Editor V1.4 Rel. by Frantic (c) 1991-1992 Sanity Productions
;==========================================================================
.db
$0
.db
$3c,$42,$99,$a1,$a1,$99,$42,$00
;' '
.db
$3e,$60,$c6,$fe,$c6,$c6,$66,$00
;'!'
.db
$fc,$06,$ce,$fc,$c6,$ce,$fc,$00
;'"'
.db
$3e,$60,$c0,$c0,$c0,$c6,$7c,$00
;'#'
.db
$fc,$06,$c6,$c6,$cc,$dc,$f0,$00
;'$'
.db
$fe,$00,$c0,$f8,$c0,$e6,$7c,$00
;'%'
.db
$fe,$00,$c0,$f8,$c0,$c0,$60,$00
;'&'
.db
$7c,$e6,$c0,$ce,$c6,$ce,$7c,$00
;'''
.db
$c6,$06,$c6,$fe,$c6,$c6,$66,$00
;'('
André Killing (155033)
Oliver Hanslian (125446)
Roy Norbart (123834)
Seite 59 von 53
Architektur des Super Nintendo Entertainment Systems
.db
.db
.db
.db
.db
.db
.db
.db
.db
.db
.db
.db
.db
.db
.db
.db
.db
.db
.db
.db
.db
.db
.db
.db
.db
.db
.db
.db
.db
.db
.db
.db
.db
.db
.db
.db
.db
.db
.db
.db
.db
.db
.db
.db
.db
.db
.db
.db
.db
.db
.db
.db
.db
.db
.db
$fc,$00,$30,$30,$30,$30,$7c,$00
$7e,$00,$18,$18,$98,$d8,$70,$00
$c6,$0c,$d8,$f0,$d8,$cc,$46,$00
$c0,$00,$c0,$c0,$c0,$d8,$f6,$00
$26,$70,$fe,$d6,$d6,$c6,$66,$00
$66,$e0,$f6,$fe,$ce,$c6,$66,$00
$7c,$e6,$c6,$c6,$c6,$ce,$7c,$00
$fc,$06,$c6,$fc,$c0,$c0,$60,$00
$7c,$e6,$c6,$c6,$c6,$ce,$76,$00
$fc,$06,$c6,$fc,$d8,$cc,$66,$00
$7c,$e6,$c0,$7c,$06,$ce,$7c,$00
$fc,$00,$30,$30,$30,$30,$18,$00
$c6,$c0,$c6,$c6,$c6,$6e,$3e,$00
$c6,$c0,$c6,$c6,$66,$36,$1c,$00
$66,$c0,$c6,$d6,$fe,$76,$32,$00
$66,$e0,$7c,$18,$7c,$ee,$66,$00
$c6,$c0,$c6,$6c,$38,$38,$38,$00
$7e,$46,$0c,$18,$30,$66,$7c,$00
$00,$00,$00,$00,$00,$00,$00,$00
$00,$00,$00,$00,$00,$00,$00,$00
$00,$00,$00,$00,$00,$00,$00,$00
$00,$00,$00,$00,$00,$00,$00,$00
$00,$00,$00,$00,$00,$00,$00,$00
$00,$00,$00,$00,$00,$00,$00,$00
$18,$18,$18,$18,$18,$00,$0c,$00
$6c,$6c,$36,$00,$00,$00,$00,$00
$00,$6c,$fe,$6c,$6c,$fe,$6c,$00
$00,$00,$00,$00,$00,$00,$00,$00
$00,$00,$00,$00,$00,$00,$00,$00
$00,$00,$00,$00,$00,$00,$00,$00
$0c,$0c,$18,$00,$00,$00,$00,$00
$30,$60,$60,$c0,$60,$60,$30,$00
$18,$0c,$0c,$06,$0c,$0c,$18,$00
$10,$54,$38,$fe,$38,$54,$10,$00
$00,$10,$10,$7c,$10,$10,$00,$00
$00,$00,$00,$00,$00,$18,$30,$00
$00,$00,$00,$7c,$00,$00,$00,$00
$00,$00,$00,$00,$00,$30,$30,$00
$00,$06,$0c,$18,$30,$60,$c0,$00
$7c,$e6,$c6,$c6,$c6,$ce,$7c,$00
$70,$c0,$30,$30,$30,$30,$38,$00
$3c,$60,$06,$1c,$30,$66,$7c,$00
$fc,$00,$06,$3c,$06,$c6,$7c,$00
$1c,$20,$6c,$cc,$fe,$0c,$0e,$00
$fe,$00,$c0,$fc,$06,$ce,$7c,$00
$3c,$66,$c0,$fc,$c6,$ce,$7c,$00
$7e,$00,$06,$06,$0c,$0c,$0c,$00
$7c,$e0,$c6,$7c,$c6,$ce,$7c,$00
$7c,$e0,$c6,$7e,$06,$ce,$7c,$00
$00,$00,$00,$18,$00,$18,$00,$00
$00,$00,$00,$18,$00,$18,$30,$00
$18,$30,$70,$e0,$70,$30,$18,$00
$00,$00,$3c,$00,$3c,$00,$00,$00
$30,$18,$1c,$0e,$1c,$18,$30,$00
$7c,$c6,$66,$0c,$18,$00,$18,$00
08. Juli 2008
;')'
;'*'
;'+'
;','
;'-'
;'.'
;'/'
;'0'
;'1'
;'2'
;'3'
;'4'
;'5'
;'6'
;'7'
;'8'
;'9'
;':'
;';'
;'<'
;'='
;'>'
;'?'
;'@'
;'A'
;'B'
;'C'
;'D'
;'E'
;'F'
;'G'
;'H'
;'I'
;'J'
;'K'
;'L'
;'M'
;'N'
;'O'
;'P'
;'Q'
;'R'
;'S'
;'T'
;'U'
;'V'
;'W'
;'X'
;'Y'
;'Z'
;'['
;'\'
;']'
;'^'
;'_'
; Dieser Text wird auf dem Bildschirm angezeigt. Es kann jeder beliebige
; Text angezeigt werden, solange die Zeichen im Charset vorhanden sind, und
; die Länge in der Scrollfumktion entsprechend eingetragen ist.
TEXT:
André Killing (155033)
Oliver Hanslian (125446)
Roy Norbart (123834)
Seite 60 von 53
Architektur des Super Nintendo Entertainment Systems
.db
.db
08. Juli 2008
"
DIES IST EIN SCROLLENDER TEXT"
". UND DAS TOLLSTE IST, ER DREHT "
.ends
André Killing (155033)
Oliver Hanslian (125446)
Roy Norbart (123834)
Seite 61 von 53