Architektur des SNES
Transcrição
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 61 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 61 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 61 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 61 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 61 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 61 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 61 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 61 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 61 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 61 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 61 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 61 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 61 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 61 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 61 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 61 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 61 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 61 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 61 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 61 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 61 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 61 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 61 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 61 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 61 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 61 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 61 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 61 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 61 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 61 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 61 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 61 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 61 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 61 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 61 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 61 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 61 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 61 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 61 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 61 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 61 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 61 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 61 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 61 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 61 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 61 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 61 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 61 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 61 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 61 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 61 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 61 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 61 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 61 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 61 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 61 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 61 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 61 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 61 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 61