DE69232865T2

DE69232865T2 - Externes Speichersystem mit programmierbaren Graphikprozessor für ein Videospielsystem oder dergleichen

Info

Publication number: DE69232865T2
Application number: DE69232865T
Authority: DE
Inventors: Ben Cheese; Carl N. Graham; Jeremy E. San; Peter R. Warnes
Original assignee: AN Inc
Current assignee: AN Inc
Priority date: 1992-01-30
Filing date: 1992-08-05
Publication date: 2003-11-20
Anticipated expiration: 2012-08-06
Also published as: US20010040577A1; EP1262921A2; ATE229197T1; EP1262921A3; EP0553532A2; EP0553532A3; JPH0689567A; AU657147B2; AU2060392A; US20040166943A1; US6646653B2; CA2074554C; CA2074554A1; US7432932B2; US20020050999A1; KR930016902A; US6895470B2; US7229355B2; KR100280939B1; DE69232865D1

Description

GEBIET DER ERFINDUNG

Die Erfindung betrifft allgemein eine Informationsverarbeitungsvorrichtung einschließlich einer einzigartigen externen Speichereinheit, die einen darin verkörperten programmierbaren Prozessor aufweist. Insbesondere betrifft die Erfindung eine entfernbare externe Speichereinheit, die einen Programmspeicher aufweist, der ein Programm speichert, das teilweise von einem Hostverarbeitungssystem, z. B. einem Videospielesystem, und teilweise durch einen programmierbaren Mikroprozessor, der dafür ausgelegt ist, um die Hochgeschwindigkeits-Grafikverarbeitungsmöglichkeiten des Hostsystems zu verbessern, ausgeführt werden soll.

HINTERGRUND UND ZUSAMMENFASSUNG DER ERFINDUNG

Herkömmliche Videospielemaschinen mit einem 8-Bit Mikroprozessor und einem dazu gehörigen Anzeigeverarbeitungs-Untersystem, die in einem Videospiele-Steuerdeck verkörpert sind, erzeugen typischerweise Grafiken durch vorheriges Speichern von Zeichen in einer Spielekassette in der Farm von 8- Bit · 8-Bit-Matrizen und durch Aufbauen einer Bildschirmanzeige unter Verwendung von verschiedenen programmierbaren Kombinationen dieser vorgespeicherten Zeichen. Derartige herkömmliche Videospielesysteme weisen typischerweise die Fähigkeit auf, den gesamten Anzeigehintergrund sowie eine Anzahl von "sich bewegenden Objekten" oder "Sprites", die von einem Spieler gesteuert werden, zu bewegen.
Derartige herkömmliche Systeme weisen nicht die Fähigkeit auf, praktisch Videospiele zu implementieren, die sich bewegende Objekte einschließen, die aus einer Kombination von Polygonen gebildet sind, die manipuliert, z. B. gedreht und für jedes Bild bzw. jeden Rahmen "neu gezeichnet", werden müssen. Der herkömmliche 8-Bit-Prozessor und die zugehörige Anzeigeverarbeitungs- Schaltungsanordnung in derartigen Systemen ist zum Beispiel nicht in der Lage, die Berechnungen auszuführen, die benötigt werden, um dreidimensionale Polygon-gestützte Objekte effektiv zu drehen oder derartige sich drehende Objekte geeignet zu skalieren, um spezielle Effekte eines 3-D Typs zu erzeugen. Die Erfinder der vorliegenden Anmeldung haben erkannt, dass ausgefeilte Grafiken das Aktualisieren des Bildschirms auf einer Pixel-für-Pixel Basis und das Ausführen von komplexen mathematischen Operationen auf einer Echtzeitbasis erfordern. Derartige herkömmliche zeichengestützte Videospielemaschinen sind nicht in der Lage, derartige Aufgaben auszuführen.
Die herkömmlichen 8-Bit-Videospielemaschinen können auch nicht andere Grafiktechniken effektiv ausführen, die ein schnelles Aktualisieren des Bildschirms auf einer Pixel-für-Pixel-Basis erfordern. Z. B. können derartige Systeme nicht effektiv ein Objekt auf ein angezeigtes Polygon abbilden, welches ein Teil eines noch anderen angezeigten Objekts (nachstehend als eine "Texturabbildung" bezeichnet) in einem dreidimensionalen Raum ist.
Im Hinblick auf eine Verbesserung der Grafikfahigkeiten gegenüber herkömmlichen 8-Bit- Maschinen sind Videospielesysteme unter Verwendung von leistungsfähigeren 16-Bit Prozessoren entwickelt worden. Derartige 16-Bit Prozessoren versehen das Videospielesystem mit einem Mechanismus zum Ausführen der mathematischen Operationen, die für ausgefeiltere Grafiken benötigt werden. Derartige Systeme erlauben zum Beispiel eine ausgefeiltere Farberzeugung und eine bessere Grafikauflösung. Derartige 16-Bit Videospielemaschinen sind zeichengestützte Systeme, die die Implementierung eines breiten Bereichs von Videospielen erlauben, die in zeichengestützte oder Sprite-Grafiken vorgezeichnet werden können. Derartige 16-Bit Videospielesysteme erlauben auch die Bewegung von mehreren farbigen Hintergrundebenen bei hohen Geschwindigkeiten mit sich bewegenden Objekten, die hinter oder vor derartigen Ebenen angeordnet sind.
Jedoch erlauben derartige herkömmliche 16-Bit Videospielemaschinen nicht die praktische Implementierung von fortgeschrittenen Videospielen mit speziellen Effekten des 3-D Typs, die ausgefeilte Objekte anzeigen, die aus Polygonen gebildet sind, die sich während jedes Rahmens bzw. jedes Bilds ändern müssen. Z. B. sind Spiele, die viele sich vollständig drehende Objekte oder sich vollständige drehende Sprites erfordern, die auf einer Rahmen-für-Rahmen Basis vergrößert und/oder verkleinert werden müssen, in derartigen herkömmlichen zeichengestützten 16-Bit Maschinen praktisch nicht realisierbar. Die Erfinder haben erkannt, dass zur effektiven Implementierung von derartigen Spielen, die sich vollständig drehende und skalierte Polygon-gestützte Objekte beinhalten, es erforderlich ist, die Kanten der Polygone zu zeichnen und derartige Polygon-gestütze Objekte mit geeigneten Daten auf einer Pixel-für-Pixel Basis zu füllen. Derartige Aufgaben, die auf einer Pixel-für-Pixel Basis durchgeführt werden müssen, verbrauchen viel Verarbeitungszeit.
In dem Stand der Technik können entfernbare Spielekassetten modifiziert werden, um eine Ausfeilung von Spielen dadurch zu verbessern, dass existierenden Prozessoren erlaubt wird, einen größeren Speicherprogramm-Adressenraum zu adressieren, als die existierende Anzahl von Adressenzeilen, die zu dem Host-Mikroprozessor gehören, ansonsten erlauben würden. Z. B. haben derartige herkömmliche 8-Bit- Systeme Spielekassetten verwendet, die Mehrfachspeicher-Controllerchips einschließen, die eine Speicherbankumschaltung und zusätzliche Funktionen ausführen. Derartige Chips, die sich auf eine Speicherbankumschaltung beziehen, sind jedoch nicht in der Lage, das Videospielesystem in die Lage zu versetzen, eine Hochgeschwindigkeits-Grafikverarbeitung der voranstehend beschriebenen Art durchzuführen.
Die EP-A 0402067 offenbart ein externes Speichersystem für entfernbare Spielekassetten, bei dem eine verbesserte Spieleausfeilung dadurch erreicht wird, dass Daten, die von der Kassette an die Konsole übertragen werden sollen, abgefangen und modifiziert werden können.
Die vorliegende Erfindung adressiert die voranstehend beschriebenen Probleme in dem Stand der Technik durch Bereitstellen eines einzigartigen, vollständig programmierbaren Grafikmikroprozessors, der dafür ausgelegt ist, um in einer entfernbaren externen Speichereinheit zur Verbindung mit einem Host- Informationsverarbeitungssystem verkörpert zu werden. In einer hier beschriebenen beispielhaften Ausführungsform wird die vorliegende Erfindung in einem Videospielesystem mit einem Host- Videospielesystem und einer VideoSpielekassette, die den Grafikmikroprozessor aufnimmt, verkörpert.
Der Grafikmikroprozessor und das Videospielesystem, die hier beschrieben werden, schließen zahlreiche einzigartige und vorteilhafte Merkmale ein, von denen einige nachstehend zusammengefasst sind.
Gemäß der vorliegenden Erfindung ist ein einzigartiger Grafikmikroprozessor einsteckbar mit einem Host-Mikroprozessor verbunden. Um die Verarbeitungsgeschwindigkeit zu maximieren, kann der Grafikprozessor parallel zu dem Host-Mikroprozessor arbeiten. In einer beispielhaften Ausführungsform schließt die Spielekassette, in der der Grafik-Coprozessor angeordnet ist, auch einen Nur-Lese-Speicher (ROM) und einen Speicher mit wahlfreiem Zugriff (RAM) ein.
Der Grafik-Coprozessor der vorliegenden Erfindung führt Entscheidungen (Arbitirierungen) zwischen Speichertransaktionen zwischen seinen eigenen Anforderungen und Datenholvorgängen von dem Host-Mikroprozessor aus. Der Prozessor ist in der Lage, Programme gleichzeitig mit dem Host- Mikroprozessor auszuführen, um eine Hochgeschwindigkeitsverarbeitung zu erlauben, die bislang in herkömmlichen Videospielesystemen nicht erreichbar war.
Der Grafik-Coprozessor der vorliegenden Erfindung arbeitet im Zusammenhang mit einer Drei- Bus-Architektur, die auf der Spielekassette verkörpert ist, die eine effektive Verwendung der RAM und ROM Kassettenspeicher erlaubt, indem die Fähigkeit sowohl des Host- als auch des Kassettenprozessors optimiert wird, derartige Speichereinrichtungen effizient zu verwenden.
Der vollständig vom Benutzer programmierbare Grafik-Coprozessor der vorliegenden Erfindung umfasst einen einzigartigen Befehlssatz, der dafür ausgelegt ist, um eine Hochgeschwindigkeitsverarbeitung zu ermöglichen. Der Befehlssatz ist dafür ausgelegt, um effizient arithmetische Operationen, die zu 3-D Grafiken gehören, zu implementieren und schließt z. B. spezielle Befehle ein, die durch speziell vorgesehene Hardware ausgeführt werden, um einzelne Pixel in der Zeichen-abgebildeten Anzeige des Host- Videospielesystems zu plotten.
Viele der Befehle in dem Befehlssatz können in einem Maschinenzyklus ausgeführt werden und sind dafür ausgelegt, um in einem Byte eines Programm-ROM gespeichert zu werden. Jedoch können die Befehle durch die Verwendung vom Spezialzweck-, Präfix-Befehle, leistungsfähiger gemacht werden.
Der Befehlssatz umfasst einzigartige pixelgestützte Befehle, die vom Standpunkt des Programmierers her ein "virtuelle" Bitkarte erzeugen, indem die Adressierung von individuellen Pixeln erlaubt wird - obwohl das Hostsystem zeichengestützt ist. Die Pixeldaten werden im Durchlauf (on the fly) durch den Grafikprozessor in Zeichendaten eines Formats umgewandelt, welches typischerweise von der zeichengestützten 16-Bit Hostmaschine verwendet wird. Obwohl der Programmierer einen einzigartigen "PLOT"-Befehl zum Plotten eines Pixels verwenden kann, wenn Daten an ein RAM gelesen werden, werden somit z. B. die Daten auf ein zeichengestütztes Format umgewandelt, welches die 16-Bit Hostmaschine verwenden kann. Spezialzweck-Pixelplothardware führt diesen Befehl aus, um effizient zu ermöglichen, dass Hochgeschwindigkeitsgrafiken des 3-D Typs implementiert werden.
Der Grafik-Coprozessor der vorliegenden Erfindung umfasst auch einen einzigartigen "CACHE"- Befehl und einen Cache-Speichermechanismus, die erlauben, dass Programmbefehle, die in dem Programm-ROM gespeichert sind, bei hoher Geschwindigkeit durch den Grafik-Coprozessor von dem CACHE-RAM ausgeführt werden. Der CACHE-Befehl erlaubt einem Programmierer die Ausführung eines Programms von dem internen Cache-RAM des Grafik-Coprozessors automatisch zu initiieren, indem der derjenige Teil des Programms abgegrenzt wird, der bei hoher Geschwindigkeit ausgeführt werden soll.
Der Befehlssatz umfasst auch Spezialzweckbefehle, die dafür ausgelegt sind, um das Programmieren der Grafiktechniken zu unterstützten, die benötigt werden, um Videospiele mit ausgefeilten 3-D Typ Merkmalen zu implementieren. Derartige Befehle umfassen die voranstehend beschriebenen Pixel PLOT Befehle und einen MERGE (ZUSAMMENFASSEN) Befehl, der dafür ausgelegt ist, um ein Zusammenfassen von Sprite-Daten, die in unterschiedlichen Registern gespeichert sind, zu erlauben, um eine Drehung von angezeigten Objekten oder eine Texturabbildung effizienter zu erlauben.
Spezialzweckbefehle erlauben die Pufferung von Daten, um eine Parallelverarbeitung durch den Host-Mikroprozessor und den Grafik-Coprozessor der vorliegenden Erfindung zu erlauben. Z. B. wird ein Spezialzweckbefehl zum Erhöhen von Verarbeitungsgeschwindigkeiten verwendet, um die relativ langsame Zugriffszeit von ROMs, die in Spielekassetten verwendet werden, zu kompensieren. Diesbezüglich verwendet der Grafikprozessor einen Befehl, in dem irgendeine Referenz auf ein vorgegebenes allgemeines Register (z. B. ein Register R14 in der beispielhaften Ausführungsform) automatisch eine Datenholoperation von dem ROM initiiert. Während derartige ROM-Zugriffe stattfinden, kann ein anderer Code ausgeführt werden. Einige Zyklen später werden die geholten Daten verfügbar sein. Jedoch musste der Prozessor in der Zwischenzeit nicht auf derartige Daten warten, sondern war anstelle davon in der Lage, andere Aufgaben durchzuführen, was erlaubt, dass ein sehr schnell ausführbarer Code geschrieben werden kann.
Um eine Unterprogrammverkettung (Subroutine linkage) effizient zu behandeln, umfasst der Grafik-Coprozessor der vorliegenden Erfindung auch einen LINK (VERKNÜPFUNGS)-Befehl, der arbeitet, um die Adresse des Befehls zu laden, der ausgeführt werden soll, nachdem das Unterprogramm in den Programmzähler R15 zur Zeit eines Abschlusses abgeschlossen worden ist.
Der Befehlssatz umfasst einen RAM-Rückspeicherbefehl. In Übereinstimmung mit diesem Befehl initiiert ein RAM-Controller innerhalb des Grafik-Coprozessors einen Rückspeicherbetrieb für aktualisierte Daten an der geeigneten zuletzt verwendeten RAM-Adresse. Dieser Einzelzyklus-Rückspeicherbefehl kann in vorteilhafter Weise verwendet werden, um effizient Blöcke von Daten zu aktualisieren.
Der Grafik-Coprozessor der vorliegenden Erfindung umfasst auch Befehle, die automatisch das Lesen oder Schreiben von dem RAM unter Verwendung des niedrigstwertigsten Bytes gefolgt von dem höchstwertigsten Byte automatisch erlauben. Dieser Mechanismus dient als eine Programmierhilfe bei der Bereitstellung einer Kompatibilität mit Daten, die in jedem Format gespeichert sind, ohne dass irgendeine Datentransponierung ausgeführt werden muss.
Der Grafikprozessor der vorliegenden Erfindung kann auf eine Anzahl von unterschiedlichen Plotmoden eingestellt werden, indem ein internes Prozessorstatusregister modifiziert wird. Derartige Moden umfassen einen Punktschattierungsmodus (Dithering-Modus), der die Erzeugung von programmierbaren Schattierungseffekten erlaubt, wobei das alternierende Pixel eine unterschiedliche Farbe enthält. Ein anderer wählbarer Modus erlaubt eine Auswahl einer hohen und niedrigen Tetrade (Nibble) für Farben, um zu ermöglichen, dass zwei Sprites in dem Speicher in einem Raum gespeichert werden, der ansonsten von einem Sprite aufgenommen werden würde.
Die vorliegende Erfindung umfasst auch viele einzigartige Hardwaremerkmale. Z. B. schließt der Grafik-Coprozessor eine Spezialzweck-Plotschaltungsanordnung ein, die eine verbesserte Pixeldatenpufferung durch die Verwendung eines On-Chip-RAMs (RAM auf einem Chip) einschließt. Eine derartige Datenpufferung minimiert die Menge von Lese- oder Schreibtransaktionen an das externe Daten- RAM und erhöht die Geschwindigkeit, mit der angezeigte Polygone mit geeigneten Daten "gefüllt" werden können.
Zusätzlich zu dem Lesepufferungsmerkmal, welches auf irgendeinen Zugriff auf das Register R14, wie voranstehend beschrieben, hin initiiert, umfasst der Grafik-Coprozessor der vorliegenden Erfindung auch Schreibpufferungsmerkmale, bei denen Daten, die an das Spielekassetten-RAM geschrieben werden sollen, gepuffert werden, um der Zentralverarbeitung des Mario Chips zu ermöglichen, andere Befehle so schnell wie möglich auszuführen.
Der Grafik-Coprozessor der vorliegenden Erfindung umfasst auch sechzehn Register, R0-R15, auf die sowohl der Grafikprozessor, als auch das Host-Verarbeitungssystem zugreifen können. Das Register R0 ist ein Voreinstellungsregister, welches nicht explizit in einem Befehl identifiziert werden muss und das als ein Akkumulator dient. Das Register R15 dient als ein Programmzähler. Das Register R14 ist das Register, auf das voranstehend Bezug genommen wurde, und das, wenn auf es zugegriffen wird, automatisch eine Datenholoperation von einem ROM initiiert. Spezielle Präfix-Befehle können verwendet werden, um die Quellen- und/oder Zielregister zu definieren. Der Grafik-Coprozessor der vorliegenden Erfindung steht in Wechselwirkung mit dem Host-Coprozessor, so dass die Register des Grafik- Coprozessors für den Host-Prozessor zugänglich sind.
Eine einzigartige Drei-Bus-Architektur, die zu dem Grafik-Coprozessor gehört, erlaubt einen hohen Grad einer Parallelität. Die 3 Busse umfassen den Host-Prozessorbus, einen ROM-Bus, und einen RAM-Bus. Diese Busse sind physikalisch getrennt und können gleichzeitig verwendet werden. Jeder Bus schließt Adressenleitungen, Datenleitungen und Steuerleitungen ein. Der Host-Prozessorbus schließt Adressenleitungen, Datenleitungen und Steuerleitungen ein, die einen breiten Bereich von Signalen zuführen, die innerhalb des Grafik-Coprozessors benötigt werden. Der Grafikprozessor der vorliegenden Erfindung, der diese Busarchitektur verwendet, kann Programme entweder von dem Programm-ROM, dem externen RAM oder von seinem eigenen internen Cache-RAM ausführen.
Der Grafik-Coprozessor koppelt mit dem Host-Mikroprozessor unter Verwendung von verschiedenen Entscheidungsmoden (Arbitrierungs-Moden). In dieser Hinsicht wird durch Laden einer logischen "Eins" in eine vorgegebene Position des Grafikprozessor-Statusregisters ein Arbitrierungsmodus durch den Host-Prozessor gesetzt, um anzuzeigen, dass der Host-Prozessor einen Zugriff auf das ROM und das RAM der Spielekassette aufgegeben hat.
Die Erfinder der vorliegenden Anmeldung haben erkannt, dass sogar bei Umständen, bei denen der Host-Prozessor einen Zugriff auf ein RAM und ein RAM durch geeignetes Setzen des Statusregisters aufgegeben hat, Unterbrechungen (Interrupts) trotzdem auftreten, wenn der Host-Prozessor einen RAM- Zugriff zum Holen einer Adresse einer Routine zum Behandeln eines derartigen Interrupts initiieren kann. Bei derartigen Umständen arbeitet der Grafikprozessor, um an dem Host-Mikroprozessor eine Arbeits- RAM-Adresse anstelle der Programm-ROM-Adresse bereitzustellen, was den Host-Prozessor veranlasst, auf sein eigenes internes Arbeits-RAM zuzugreifen. Diese Technik hält den Host-Prozessor davon ab, das Programm-ROM zu der Zeit zu adressieren, wenn der Grafik-Coprozessor eine Ausführung von dem Programm-ROM vornimmt.
Wenn der Host-Prozessor auf das Kassetten-RAM zugreifen muss, wird das Grafik-Coprozessor- Statusregister derart gesetzt, dass der Grafik-Coprozessor nicht in der Lage ist, auf das RAM zuzugreifen, wodurch dem Host-Prozessor ermöglicht wird, auf irgendeine Information zuzugreifen, die von dem RAM benötigt wird, und danach den Grafik-Coprozessor auf einen Zustand zu schalten, in dem ein Zugriff auf das RAM möglich ist. Jedoch ist es wünschenswert, dass der Coprozessor das ROM und das RAM auf der Kassette als Folge von seiner schnelleren Verarbeitungsgeschwindigkeit im maximal möglichen Ausmaß verwendet.
Der Grafik-Coprozessor der vorliegenden Erfindung ist dafür ausgelegt, um eine Pixelinformation, die in das Zeichendaten-RAM geladen ist, an das Host-Prozessor-Video-RAM für eine Anzeige effizient zu transferieren. Das Video-RAM ist jedoch nicht direkt für den Grafikprozessor durch irgendeinen Kassettenbus zugänglich. Ein derartiger Transfer muss durch die Verwendung von Schaltungen mit einem direkten Speicherzugriff (Direct Memory Access, DMA) auftreten.
Der Grafik-Coprozessor der vorliegenden Erfindung empfängt mehrere Taktsignale von dem Host- Informations-Verarbeitungssystem. Ein Timing (eine Zeitsteuerung) innerhalb des Grafik-Coprozessors wird durch einen dieser Takte gesteuert.
Als ein optionales Merkmal der vorliegenden Erfindung erlaubt eine Schaltungsanordnung innerhalb des Grafik-Coprozessors dem Prozessor, rekonfiguriert zu werden, um zukünftige Modifikationen zu berücksichtigen, und zwar in Abhängigkeit von dem Zustand von Signalen, die über Ausgangsadressenleitungen empfangen werden, die als Konfigurationseinstellungs-Eingangsleitungen unmittelbar nach der Einschaltungsrücksetzung verwendet werden. Die Werte der Optionseinstellungswiderstände, die mit diesen Adressenleitungen gekoppelt sind, werden von dem Graphik-Coprozessor gelesen. Diese Signale werden verwendet, um zum Beispiel den Typ von RAM Chip zu definieren, der gerade mit dem Graphikprozessor verwendet wird, z. B. ein statisches RAM oder ein dynamische RAM.
Diese und andere Merkmale und Vorteile der Erfindung werden sich aus der folgenden ausführlichen Beschreibung der beispielhaften Ausführungsform der vorliegenden Erfindung besser verstehen lassen, wenn sie im Zusammenhang mit den beiliegenden Zeichnungen betrachtet wird.

KURZBESCHREIBUNG DER ZEICHNUNGEN

In den Zeichnungen zeigen:

Fig. 1 ein Blockdiagramm eines beispielhaften externen Speichersystems in Übereinstimmung mit einer beispielhaften Ausführungsform der vorliegenden Erfindung;
Fig. 2 ein Blockdiagramm eins beispielhaften Host-Verarbeitungssystems zur Verwendung mit einem Grafik-Coprozessor der gegenwärtig bevorzugten beispielhaften Ausführungsform;
Fig. 3 eine perspektivische Ansicht, die eine beispielhafte mechanische Konfiguration der Spielekassette, die einen Grafik-Coprozessor aufnimmt, und einer Basiseinheit, die das Host- Verarbeitungssystem aufnimmt, zeigt;
Fig. 4A und 4B ein Blockdiagramm des Grafik-Coprozessors in Übereinstimmung mit der gegenwärtig bevorzugten beispielhaften Ausführungsform;
Fig. 5 ein Flussdiagramm, welches die Sequenz von Operationen abgrenzt, die von dem Host- Verarbeitungssystem zum Initiieren einer Grafik-Coprozessoroperation ausgeführt werden;
Fig. 6 ein ausführlicheres Blockdiagramm der Arithmetik- und Logikeinheit, die in Fig. 4A gezeigt ist;
Fig. 7 ein ausführlicheres Blockdiagramm einer beispielhaften Pixel-Plot-Schaltungsanordnung des in Fig. 4A gezeigten Typs;
Fig. 8A ein Blockdiagramm, das die Eingangssignale, die von dem Plot-Controller empfangen werden, und die Ausgangssignale, die von dem Plot-Controller erzeugt werden, zeigt;
Fig. 8B ein Farbmatrixelement, das in der Farbmatrix in der Pixel-Plot-Schaltungsanordnung enthalten ist;
Fig. 8C Timing-, Steuer- und Datensignale, die zu der Pixel-Plot-Schaltungsanordnung gehören;
I Fig. 9 ein ausführlicheres Blockdiagramm des in Fig. 4A gezeigten RAM-Controllers;
Fig. 9A beispielhafte Timing-, Steuer- und Datensignale, die zu dem in Fig. 9 gezeigten RAM- Controller gehören;
Fig. 10 ein Schaltbild, das die in Fig. 9 gezeigte Arbitrierungslogik darstellt;
Fig. 11 ein Diagramm einer Resynchronisations-Schaltungsanordnung in einer beispielhaften Ausführungsform des Grafik-Coprozessor der vorliegenden Erfindung;
Fig. 12 Timing-Signale, die zu der Resynchronisations-Schaltungsanordnung der Fig. 11 gehören;
Fig. 13 ein ausführlicheres Blockdiagramm des ROM-Controllers des Grafik-Coprozessors der vorliegenden Erfindung;
Fig. 14 ein Blockdiagramm des Cache-Controllers des Grafik-Coprozessors in Übereinstimmung mit einer beispielhaften Ausführungsform der vorliegenden Erfindung;
Fig. 15A ein Blockdiagramm, das die auf eine Befehlsdecodierung bezogene Schaltungsanordnung des Grafik-Coprozessors der vorliegenden Erfindung zeigt;
Fig. 15B beispielhafte Timing-Signale, die den Betrieb der Vorausschaulogik in Fig. 15A demonstrieren;
Fig. 16 und 17 Blockdiagramme, die die Registersteuerlogik des Grafik-Coprozessors in Übereinstimmung mit einer beispielhaften Ausführungsform der vorliegenden Erfindung zeigen,
Fig. 18 ein beispielhaftes Flussdiagramm, das die Sequenz von Operationen des Grafik- Coprozessors beim Ausführen einer Polygonerzeugungs-Task zeigt; und
Fig. 19, 20 und 21 beispielhafte Anzeigen, die von Polygon-gestützten Objekten erzeugt werden können, um Skalierungs- und Drehungsmerkmale in Übereinstimmung mit einer beispielhaften Ausführungsform der vorliegenden Erfindung zu illustrieren.

AUSFÜHRLICHE BESCHREIBUNG DER BEISPIELHAFTEN AUSFÜHRUNGSFORM DER VORLIEGENDEN ERFINDUNG

Gemäß der gegenwärtigen beispielhaften Ausführungsform steht der Grafik-Coprozessor der vorliegenden Erfindung in Wechselwirkung mit einem 16-Bit-Videospielesystem, welches kommerziell von Nintendo aus Amerika, Inc., als das Super-Nintendo Entertainment System (Super NES) kommerziell verkauft wird. Das Super-Nintendo Entertainment System wird teilweise in der EP-0437630, mit dem Titel "Video Processing Apparatus", und der EP-A 0473392, mit dem Titel "Direct Memory Access Apparatus and External Storage Device Used Iherein" beschrieben. Es sei darauf hingewiesen, dass die vorliegende Erfindung nicht auf Super NES bezogene Anwendungen beschränkt ist und mit anderen Videospielesystemen oder anderen Informationsverarbeitungsvorrichtungen, bei denen es sich nicht um ein Videospiel handelt, verwendet werden kann.
Lediglich zur einfacheren Referenz wird der Grafikprozessor in Übereinstimmung mit der vorliegenden beispielhaften Ausführungsform nachstehend als der "Mario Chip" bezeichnet. Der Mario Chip ist in der gegenwärtig bevorzugten beispielhaften Ausführungsform so beschrieben, dass er innerhalb einer Videospielekassette verpackt ist. Es sei darauf hingewiesen, dass es für die vorliegende Erfindung nicht wesentlich ist, dass der Mario Chip in dem gleichen Kassettengehäuse (Kartuschengehäuse) wie der Programmspeicher untergebracht ist, solange wie er in der Verwendung mit einem Programmspeicher und mit der Host-Verarbeitungseinheit verbunden ist.
Fig. 1 zeigt ein beispielhaftes System mit einer VideoSpielekassette/einem externen Speicher in Übereinstimmung mit einer beispielhaften Ausführungsform der vorliegenden Erfindung. Die Spielekassette (Spielekartusche) umfasst eine gedruckte Schaltungsplatine (die nicht gezeigt ist), auf der sämtliche Komponenten der Fig. 1 angebracht sind. Die Kassette (bzw. Kartusche) umfasst ein Feld von Verbinderelektroden 1, die an einem Einfügungsende der gedruckten Schaltungsplatine angeordnet sind, um Signale an das Super NES-Hauptsteuerdeck zu senden und davon zu empfangen. Das Feld von Verbinderelektroden 1 wird von einem passenden Verbinder aufgenommen, der in dem Super NES- Hauptsteuerdeck angeordnet ist
In Übereinstimmung mit der gegenwärtigen beispielhaften Ausführungsform ist der Mario Chip (Grafik-Coprozessor) 2, der auf der Spielekassette verkörpert ist, ein integrierter Schaltungschip mit 100 bis 128 Anschlussstiften. Der Mario Chip empfängt viele Steuer-, Adressen- und Datensignale von dem Host- Verarbeitungssystem (z. B. dem Super NES). Z. B. empfängt der Mario Chip 2 einen 21 MHz Takteingang von dem Host-Verarbeitungssystem über den Anschlussstift P 112 und einen Systemtakteingang, der 21 MHz (oder eine andere vorgegebene Frequenz) sein kann, über den Anschlussstift P117. Der Systemtakteingang kann z. B. verwendet werden, um den Mario-Prozessor mit Speicher-Timinginformation (Speicherzeitsteuerungsinformation) für Host-CPU-Speicherzugriffe zu versehen, und um Taktsignale für Timing-Operationen innerhalb des Mario Chips bereitzustellen. Der Mario Chip 2 umfasst auch einen optionalen externen Takteingang (Anschlussstift P110), der den Mario Chip mit einem externen Kristall 4 koppelt, um die Mario-CPU beispielsweise bei einer höheren Frequenztaktrate als die von dem Host- System empfangenen 21 MHz anzusteuern.
Host-CPU-Adresseneingänge (HA) sind mit dem Mario Chip 2 über Anschlussstifte P37 bis Anschlussstifte P62 von dem Adressenbus des Hosi-Verarbeitungssystems (z. B. der Super NES- CPU/Bildverarbeitungseinheit PPU) gekoppelt. In ähnlicher Weise sind Dateneingänge (HD) von dem Host-System mit dem Mario Chip 2 über Anschlussstifte P65-P72 von dem Host-CPU-Datenbus gekoppelt. Der Mario Chip 2 empfangt zusätzlich von der Host-CPU ein Speicherwiederauffrischungssignal RFSH über den Anschlussstift P119, ein Rücksetzsignal über den Anschlussstift P118, und Lese- und Schreibsteuersignale über die Anschlussstifte P104, P105. Der Mario Chip erzeugt ein Interrupt- Anforderungssignal IRQ und koppelt das Signal IRQ mit dem Super NES über den Anschlussstift P120. Andere Steuersignale werden von dem Super NES empfangen, beispielsweise ein ROMSEL-Signal über den Anschlussstift P 106, das z. B. einen Zugriff des Host-Programms ROM 10 initiieren kann. Zusätzlich umfasst die Kassette einen Authentifizierungsprozessor 3, der Daten mit einem Super NES- Authentifizierungsprozessor auf dem Eingang I, dem Ausgang O und Rücksetz-R-Leitungen austauscht. Der Authentitizierungsprozessor 3 und das Sicherheitssystem, die zum Authentifizieren von Spielekassetten verwendet werden, können von dem Typ sein, der in der EP-A-0206704 gezeigt ist.
Der Mario Chip ist mit den RAMs 6 und 8 über den RAM-Adressenbus (RAM A), und mit RAM- Adressenstiften P74-P91 und dem RAM-Datenbus (RAM D) und Datenstiften P93-P100 gekoppelt. Diese RAMs können dynamische Speichereinrichtungen sein, die teilweise unter Verwendung von Zeilenadressen- und Spaltenadressen-Hinweissignalen (RAS, CAS) gesteuert werden, die über die Anschlussstifte P90 bzw. P91 gekoppelt werden. Ein oder mehrere statische RAMs können anstelle von dynamischen RAMs verwendet werden und die Anschlussstifte P90 und P91 würden dann verwendet werden, um Adressensignale mit ihren jeweiligen RAMs ohne die Zeilenadressen- und Spaltenadressen- Hinweissignale (Strobe Signale) zu koppeln. Ein Schreibaktivierungs-Steuersignal WE ist in geeigneter Weise mit dem RAM 6 und 8 über den Anschlussstift P107 gekoppelt.
Die Lese- und Schreibsteuersignale (R, W) werden von der Host-CPU erzeugt und mit dem Mario Chip über die Anschlussstifte P104 und P105 gekoppelt. Durch Überwachung von diesen Lese- und Schreibleitungen kann der Mario Chip die Art des Speicherzugriffsbetriebs bestimmen, den die Super NES- CPU versucht auszuführen. In ähnlicher Weise werden im Grunde genommen sämtliche Adressen- und Steuerleitungen von dem Hostsystem von dem Mario Chip überwacht, um zu verfolgen, was die Host-CPU versucht zu tun. Die ROM und RAM-Adressierungssignale, die von dem Mario Chip empfangen werden, werden überwacht und an die geeignete Speichereinrichtung weitergeleitet. Diesbezüglich werden die ROM-Adressen an das Programm-ROM 10 über den ROM-Adressenbus und dem Anschlussstift P2 bis P26 gekoppelt und die RAM-Adresse wird mit den RAMs 6 und 8 über die Anschlussstifte P74 bis Anschlussstifte P91 gekoppelt. Die ROM- und RAM-Dateneingänge von der Host-CPU werden in geeigneter Weise mit dem ROM 10 über den ROM-Datenbus und Anschlussstifte P28-P35 bzw. über die Anschlussstifte P93-P100 gekoppelt.
Sollte erkannt werden, dass der Mario Chip im Zusammenhang mit einem breiten Bereich von verschiedenen Speichereinrichtungen verwendet werden kann, zusätzlich zu den ROM und RAMs, die hier beschrieben sind. Z. B. wird in Erwägung gezogen, dass der Mario Chip in vorteilhafter Weise im Zusammenhang mit Videospielesystemen verwendet wird, die CDROMs verwenden.
Z. B. kann in der Fig. 1 anstelle einer Verwendung eines ROMs 10 ein CD ROM (nicht gezeigt) verwendet werden, um Zeichendaten, Programmbefehle, Video-, Grafik- und Sounddaten (Tondaten) zu speichern. Ein CD-Abspielgerät eines herkömmlichen Typs (welches ebenfalls nicht gezeigt ist), das in geeigneter Weise mit dem Mario Chip 2 verbunden ist, um Speicheradressensignale über den Adressenbus P2-P26 zum Zugreifen von Daten und/oder Befehlen über den Datenbus P28-P35 zu empfangen. Die spezifischen strukturellen und betriebsmäßigen Einzelheiten von CD-Abspielgeräten und CD-ROM- Speichersystemen sind altbekannt für Durchschnittsfachleute in dem technischen Gebiet. Ein Vorteil, der von dem CD-ROM-Speicher bereitgestellt wird, ist eine signifikante Verringerung der Kosten für die Speicherung pro Byte der Information. Daten können bei Kosten zwischen 100 bis 1000% kleiner als eine Speicherung auf einem Halbleiter-ROM gespeichert werden. Unglücklicherweise ist die Speicherzugriffs- /Lesezeit für ein CD-ROM sogar langsamer als diejenige für ein Halbleiter-ROM.
Der Mario Chip verwendet eine Dreibusarchitektur, die erlaubt, dass Information auf wenigstens drei Bussen parallel verwendet werden. Diesbezüglich ist in der Spielekassette, die in Fig. 1 gezeigt ist, der Mario Chip 2 mit einem ROM-Bus (einschließlich von ROM-Datenleitungen, ROM-Adressenleitungen und Steuerleitungen), einem RAM-Bus (einschließlich von ROM-Adressenleitungen, Datenleitungen, und Steuerleitungen) und einem Host-Prozessorbus (einschließlich einer Host-Adresse, Daten- und Steuerleitungen) gekoppelt.
Die Architektur des Mario Chips ermöglicht, dass Pipeline-Operationen auftreten, um einen Durchsatz zu optimieren. Diesbezüglich kann der Mario Chip ein Datenbyte von dem ROM gerade lesen, während er gerade andere Daten verarbeitet, während er noch weitere Daten an das RAM schreibt, um zu ermöglichen, dass 3-D-bezogene Grafiken sehr effizient ausgeführt werden. Wie nachstehend weiter beschrieben wird, verwendet der Mario Chip 2 intern eine 16-Bit-Architektur und ist dennoch dafür ausgelegt, um mit 8-Bit-ROM 10 und RAM 6, 8 Chips eine Kopplung bereitzustellen. Intern sind sämtliche internen Datenbusse und interne Register 16-Bits. Lesevorgänge von dem ROM 10 und Schreibvorgänge an das RAM 6, 8 werden "gepuffert" und verlangsamen eine Programmausführung typischerweise nicht.
In ähnlicher Weise kann der Mario Chip 2 auf Befehle und Grafikdaten von der CD-ROM zugreifen und diese Information in das RAM 6, 8 für einen nachfolgenden DMA-Transfer in das Video- RAM des Host-Prozessors, z. B. der Super NES-Bildverarbeitungseinheit (PPU) hinein schreiben. Durchschnittsfachleute in dem technischen Gebiet weiden erkennen, dass der Mario Chip 2 programmiert werden kann, um einen Transfer von Daten von der CD-ROM direkt an das Video-RAM der PPU zu koordinieren, wobei die RAM-Speicherung und Zugriffsoperationen umgangen werden.
Die extrem schnelle Verarbeitungsgeschwindigkeit des Mario Chips 2 macht eine CD-ROM- Speicherung praktisch für Grafikanwendungen trotz der langen Lesezeit von CD-ROMs. Video- und Audiodaten werden unter Verwendung von herkömmlichen Datenkompressionstechniken vor einer Speicherung auf der CD-ROM komprimiert. Datenkompressions- und Dekompressionstechniken sind Durchschnittsfachleuten in dem technischen Gebiet altbekannt. Nach Zugreifen auf komprimierte Daten von der CD-ROM dekomprimiert der Mario Chip 2 die Daten unter Verwendung von herkömmlichen Datendekompressionsalgorithmen in sehr viel kürzeren Zeitperioden als von herkömmlichen Grafikprozessoren erzielt werden kann. Weil er mit einem 21-MHz-Takt arbeitet, beendet der Mario Chip 2 eine Dekompression innerhalb vorgeschriebener Zeitperioden für einen Datentransfer an das RAM 6, 8.
Somit wird auf große Mengen von Video- und Audiodaten in typischen CD-ROM- Zugriffszeitperioden (in komprimierter Form) zugegriffen. Jedoch wird der Effekt von diesen relativ langen Zugriffszeiten minimiert, weil nach einer Datendekompression durch den Mario Chip 2 die tatsächliche Zugriffszeit pro Datenbyte signifikant verringert wird. Wenn der Mario Chip 2 eine Dekompression ausfuhrt, ist der Host-Grafikprozessor, z. B. die Super NES-PPU, frei zum Ausführen von anderen Verarbeitungs-Tasks. Wenn natürlich die Geschwindigkeit nicht ein Aspekt für eine bestimmte Anwendung ist, kann der Mario Chip 2 auf Daten von einer CD-ROM in nicht komprimierter Form zugreifen.
Die Kassette (Kartusche) kann auch eine Batteriesicherung (ein Batterie-Backup) einschließen, wenn ein statisches RAM verwendet wird. Eine Backup-Batterie 12 ist mit einer herkömmlichen Backup- Batterieschaltung 14 über einen Widerstand R gekoppelt, um eine Backup-Spannung (RSRAM) für ein statisches RAM und ein Chip-Wählsignal RAMCS für das statische RAM für den Fall eines Energieverlusts bereitzustellen, um ein Datenspeicherungsmerkmal bereitzustellen.
Zusätzlich gekoppelt mit dem RAM-Adressenbus sind Optionseinstellungswiderstände 16. Im normalen Betrieb sind die Mario Chip Adressenleitungen mit den RAMs 6 und 8 gekoppelt. Während Rücksetz- oder Einschaltoperationen werden diese Adressenleitungen jedoch als Eingabeleitungen verwendet, um entweder ein hohes oder ein niedriges Signal in Abhängigkeit davon zu erzeugen, ob sie auf eine vorgegebene Spannung VCC oder Masse gebunden werden. In dieser Weise wird eine "1" oder "0" in geeigneter Weise in ein internes Mario Chip Register gelesen. Nach der Rücksetzung kann der Mario Chip, in Abhängigkeit von der Einstellung von diesen Widerständen, z. B. (während einer Progammausführung) die Multiplizierertaktrate, die RAM-Zugriffszeit, mit der der Mario Chip gekoppelt ist, die Taktrate, die mit anderen Operationen innerhalb des Mario Chips verwendet werden soll, etc. bestimmen. Durch die Verwendung von diesen Optionseinstellungsregistern ist der Mario Chip z. B. anpassbar, um mit einer Anzahl von unterschiedlichen Typen von Speichereinrichtungen verwendet zu werden, ohne dass irgendwelche Mario Chip Konstruktionsmodifikationen benötigt werden. Wenn eine dynamische RAM- Einstellung erfasst wird, dann werden z. B. Wiederauffrischungssignale zu geeigneten Zeiten angelegt werden. Zusätzlich können die Optionseinstellungen verwendet werden, um die Geschwindigkeit zu steuern, bei der die Prozessormultipliziererschaltungen z. B. arbeiten, und um zu ermöglichen, dass andere Befehle von dem Grafikprozessor bei einer schnelleren Rate ausgeführt werden, als es möglich ist, bestimmte Multiplizierungsbefehle auszuführen. Durch Initiieren einer verzögerten Multiplizierungsausführung können die verbleibenden Befehle somit bei einer schnelleren Taktrate als der Taktrate, die ansonsten möglich ist, laufen (z. B. kann der Prozessor bei 30 Megahertz getaktet werden, wohingegen die Optionseinstellungen effektiv bewirken würden, dass die Multiplizierungsbefehle bei 15 Megahertz ausgeführt werden).
Fig. 2 ist ein Blockdiagramm eines beispielhaften Hostvideo-Spielesystems, wobei die in Fig. 1 aufgeführte beispielhafte Spielekassette konstruiert ist, um damit gekoppelt zu werden. Fig. 2 kann z. B. das Super NES darstellen, welches gegenwärtig von Nintendo aus Amerika verkauft wird. Die vorliegende Erfindung ist jedoch nicht auf Super NES bezogene Anwendungen oder Systeme mit einem Blockdiagramm wie dasjenige, das in Fig. 2 gezeigt ist, beschränkt.
Das Super NES schließt innerhalb seines Steuerdecks 20 eine 16-Bit Host-CPU ein, die z. B. ein 6581-kompatibler Mikroprozessor sein kann. Die CPU 22 ist mit einem Arbeits-RAM 32 gekoppelt, der z. B. 128 K Bytes einer Speicherung einschließen kann. Die CPU 22 ist mit einer Bildverarbeitungseinheit (PPU) 24 gekoppelt, die wiederum mit einem Video-RAM 30 gekoppelt ist, das z. B. 32K Wörter für eine Speicherung einschließen kann. Die CPU 22 hat einen Zugriff auf das Video-RAM 30 über die PPU 24 während vertikaler oder horizontaler Austastintervalle. Somit kann die CPU 22 auf das Video-RAM 30 durch die PPU 24 nur zu anderen Zeiten als während eines aktiven Zeilenscans, wenn die PPU 24 gerade auf das Video-RAM zugreift, zugreifen. Die PPU 24 erzeugt eine Videoanzeige auf einem Fernseher 36 des Benutzers von dem Video-RAM 30. Die CPU ist auch mit einer Audioverarbeitungseinheit APU 26 gekoppelt, die mit einem Arbeits-RAM 28 gekoppelt ist. Die APU 26, die einen kommerziell erhältlichen Soundchip umfassen kann, erzeugt die Töne (Sounds), die zu dem Videospieleprogramm gehören, das auf der Spielekassette in dem ROM 10 gespeichert ist. Die CPU 22 kann nur auf das Arbeits-RAM 28 über die APU 26 zugreifen. Die PPU 24 und die APU 26 sind mit dem Privatfernsehen 36 des Benutzers über eine RF Modulatoreinheit 34 gekoppelt.
Das Video-RAM 30 in dem Super NES System muss mit geeigneten Zeichendaten geladen werden, die in dem Programm-ROM 10 in der Kassette gespeichert sind (die nicht nur das Spieleprogramm, sondern auch die Zeichendaten, die während des Spielens des Spiels verwendet werden, speichert). Irgendein sich bewegendes Objekt, z. B. eine Sprite-Information oder eine Hintergrund-Information, die angezeigt werden soll, muss in dem Video-RAM 30 vor der Verwendung vorhanden sein. Auf das Programm-ROM 10 wird durch die Hostadresse der CPU 22 und durch Datenbusse über einen zusammen passenden Verbinder 18 zugegriffen, der mit dem Kantenverbinder 1 der gedruckten Schaltungsplatine, der in Fig. 1 gezeigt ist, gekoppelt ist. Die PPU 24 ist mit der Spielekassette über gemeinsam verwendete Host-CPU-Daten und Adressenbusse und einen Verbinder 23 verbunden, um so einen Pfad für PPU-Daten und Steuersignale bereitzustellen, um mit der Kassette gekoppelt zu werden. Die APU 26 ist mit der Spielekassette über gemeinsam verwendete Host-CPU-Busse und einen Audiobus 27 verbunden. Der Adressenraum der CPU 22 wird derart abgebildet, dass Stellen des Programm-ROMs 10 an einer Stelle 0 beginnen, und ist typischerweise in 32K Byte Segmente aufgeteilt. Das Programm-ROM verwendet ungefähr eine Hälfte des CPU Adressenraums. Die oberen Stellen bzw. Orte in jedem 32K Byte Segment des CPU Adressenraums werden typischerweise für die Adressierung des Arbeits-RAMs 32 und verschiedene Register verwendet. Das Programm-ROM 10 ist typischerweise 4 Megabytes. Die CPU 22, die in dem Super NES verwendet wird, kann die Gesamtheit des Programm-ROMs 10 adressieren.
Andererseits umfasst der Mario Chip 2 nur einen 16 Bit Programmzähler und umfasst somit Bankregister zum Wählen zwischen den 32K Byte Banken in dem Programm-ROM 10.
In der vorliegenden beispielhaften Ausführungsform weist der Mario Chip einen vollständigen 24 Bit Adressenraum auf, der der Speicherkarte des Super NES entspricht. Dieser enthält das ROM 10 an der Position beginnend an der Stelle $ 00 : 8000, und der RAM Chip 6, 8 auf der Kassette startet an der Stelle $ 70 : 0000.
Da das ROM 10 und das RAM 6, 8 auf der Kassette auf getrennten Bussen sind, kann auf sie von dem Mario Chip parallel zugegriffen werden. Ferner kann auf die RAMs 6, 8 bei einer schnelleren Rate als das ROM zugegriffen werden und der Mario Chip ist dafür ausgelegt, um diesen Vorteil des Betriebsverhaltens zu verwenden. Der Mario Chip weist keinen Zugriff auf irgendeinen Speicher auf, der innerhalb des Super NES ist, d. h. keinen Zugriff auf das Arbeits-RAM 32 oder das PPU Video-RAM 30.
Damit der Mario Chip Daten verarbeitet oder in eine Bitkarte hinein zeichnet, müssen Daten innerhalb des Mario Kassetten-RAM-Chips 6, 8 enthalten sein. Somit müssen irgendwelche Variablen, die zwischen dem NES CPU-Programm und dem Mario Chip Programm gemeinsam verwendet werden, innerhalb des Mario Kassetten-RAM-Chip 6, 8 sein. Irgendwelche vorgespeicherten Daten, die das Mario Chip-Programm verwenden muss, können in dem ROM 10 sein und irgendwelche Variablen werden in dem RAM 6, 8 sein.
Irgendwelche privaten Variablen, die nur von dem Super NES-Programm benötigt werden, müssen nicht in dem Kassetten-RAM 6, 8 sein. Da in der Tat dieses RAM 6, 8 im Hinblick auf einen Speicherplatz an einer Premiumstelle ist, ist es ratsam, das Kassetten-RAM 6, 8 auf eine Hochprioritäts- Anforderungsbasis zuzuordnen. Irgendwelche nicht-wesentlichen Variablen sollten in dem Super NES internen RAM 32 gespeichert werden.
Die Bitkarte, in die der Mario Chip hineinschreibt, ist in dem Mario Kassetten-RAM 6, 8 und wird unter der Steuerung des Super NES in das Video-RAM 30 der PPU hinein DMA transferiert, wenn jeder Bitkartenrahmen vollständig bereitgestellt worden ist.
Die CPU 22 des Super NESs weist einen Zugriff auf sämtliches internes RAM innerhalb des Super NES Steuerdecks auf, genauso, wie wenn der Mario Chip nicht vorhanden wäre. Der Mario Chip weist keinen Zugriff auf dieses RAM auf, so dass sämtliche Daten, die zwischen den Mario ROM/RAM Chips und dem internen Super NES RAM transferiert werden, durch die CPU 22 selbst initiiert werden müssen. Daten können über eine CPU 22 Programmierung transferiert werden, oder über einen DMA Transferblock bewegt werden. Das Mario Kassetten-ROM 10 und das RAM 6, 8 werden herein abgebildet, so wie dies bei sämtlichen Spieleprogrammen üblich ist.
Die CPU 22 weist eine Steuerung darüber auf, welche CPU einen Zugriff auf Kassetten-ROM oder RAM-Chips aufweist. Beim Einschalten der Energieversorgung oder bei Rücksetzbedingungen wird der Mario Chip abgeschaltet und die CPU 22 weist einen vollständigen Zugriff auf die Chips des Kassetten- ROM und -RAM auf. Damit der Mario Chip ein Programm ausführt ist es erforderlich, dass das CPU 22 Programm seinen Zugriff auf entweder den ROM oder den RAM Chip, und vorzugsweise auf beide, aufgibt und entweder darauf wartet, dass der Mario Chip seine gegebene Aufgabe (Task) beendet, oder alternativ kann die CPU 22 einen bestimmten Code in ein internes Arbeits-RAM 32 kopieren und dies dort ausführen.
Der Mario Chip weist eine Anzahl von Registern auf, die von der Seite der Super NES CPU programmierbar und lesbar sind. Diese werden in die CPU 22 Speicherkarte beginnend an der Stelle $ 00 : 3000 abgebildet.
Wie in Fig. 2 angedeutet, erzeugt das Super NES eine Vielzahl von Steuersignalen und empfängt eine Vielzahl von Steuersignalen. Wenn die Super NES CPU 22 auf das Programm-ROM 10 zugreifen muss, erzeugt sie ein Steuersignal ROMSEL. Um eine Speicherwiederauffrischung zu initiieren erzeugt das Super NES ein Wiederauffrischungssignal RFSRH. Wenn der Mario Chip eine Operation beendet überträgt er ein Interruptsignal IRQ auf einer Interruptanforderungsleitung, die zu der Super NES CPU gehört. Die CPU 22 erzeugt zusätzlich Lese- und Schreibsignale.
System-Timingsignale werden von der Timingketten-Schaltungsanordnung 21 innerhalb des Steuerdecks 20 erzeugt. Ein Energieeinschaltungs/Rücksetzungssignal wird ebenfalls innerhalb des Hauptsteuerdecks 20 erzeugt und mit der Spielekassette gekoppelt.
Das Super NES umfasst auch eine Authentifizierungsverarbeitungsschaltung 25, die Daten auf Eingabe-I, Ausgabe-O, und Rücksetz-R-Leitern mit einer Authentifizierungsverarbeitungseinrichtung 3 auf der Spielekassette in Übereinstimmung mit der voranstehend angegebenen EP-A-0206704 austauscht. Die Verarbeitungseinrichtung 25, die von der EP-A-0206704 geleert, hält die CPU 22 in einem Rücksetzzustand, bis eine Authentifizierung hergestellt ist.
Die Super NES Videospielemaschine, die im Blockform in Fig. 2 dargestellt ist, ist hier nur allgemein beschrieben worden. Weitere Einzelheiten beispielsweise darüber, wie Information zwischen dem Super NES und der Spielekassette transferiert wird, können in der EP-A-0473392, mit dem Titel "Direct Memory Acess Apparatus in Image Processing System and External Storage Device used therein" und in US-A-5400052, mit dem Titel "Mosaic Picture Display Apparatus and External Storage Unit used therefor" gefunden werden.
In einigen Anwendungen haben die Erfinder erkannt, dass während einer vertikalen Austastung unter Verwendung von derartigen Hausprozessor-DMA-Schaltungen mehr Information transferiert werden muss, als tatsächlich möglich. Demzufolge kann es wünschenswert sein, die vertikale Austastzeit zu erweitern - selbst wenn dies zu einer geringfügigen Schrumpfung der Bildgröße fuhrt. Durch Verwenden dieses Ansatzes werden signifikante Vorteile im Hinblick auf die Verarbeitungsgeschwindigkeit und die Bildaktualisierungsrate realisiert.
Fig. 3 zeigt eine perspektivische Ansicht einer beispielhaften mechanischen Konstruktion für ein Spielekassettegehäuse 19 zur Aufnahme des Mario Chips und eine andere Kassettenstruktur, die in Fig. 1 gezeigt ist. In ähnlicher Weise zeigt Fig. 3 die perspektivische Ansicht eines beispielhaften äußeren Gehäuses für ein Videospiele-Steuerdeck 20 zur Aufnahme der Super NES Videospielehardware, die in Fig. 2 gezeigt ist. Die mechanische Konstruktion für ein derartiges Videospiele-Steuerdeck 20 und der zugehörigen entfernbaren Spielekassette 19 ist in den Fig. 2-9 der US Anmeldung mit der Seriennummer 07/748938, die am 23. August 1991 eingereicht wurde, mit dem Titel "TV Game Machine" beschrieben, wobei diese Anmeldung hiermit durch Bezugnahme hier eingebunden wird.
Die Fig. 4A und 4B sind ein Blockdiagramm des in Fig. 1 gezeigten Mario Chips 2. Fokussierend zunächst auf die verschiedenen Busse, die in den Fig. 4A und 4B gezeigt sind, ist der Befehlsbus INSTR ein 8-Bit Bus, der Befehlscodes mit verschiedenen Mario Chip-Komponenten koppelt. Die X, Y und Z Busse sind 16-Bit Datenbusse. Der HA Bus ist ein 24-Bit Hostsystem-Adressenbus, der in der gegenwärtig bevorzugten Ausführungsform in der Verwendung mit dem Super NES Adressenbus gekoppelt wird. Der HD Bus ist ein 8-Bit Hostdatenbus, der in der Verbindung mit dem Super NES Datenbus gekoppelt ist. Der PC Bus ist ein 16-Bit Bus, der den Ausgang des Mario Chip Programmzählers (d. h. das Register R15 in dem allgemeinen Registerblock 76) mit verschiedenen Systemkomponenten koppelt. Der ROM A Bus ist ein 20-Bit ROM Adressenbus. Der ROM D Bus ist ein 8-Bit-ROM Datenbus. Der RAM A Bus ist ein Bit-RAM Adressenbus. Der RAMD IN Bus ist ein 8-Bit RAM Lesedatenbus und der RAMD OUT ist ein 8-Bit RAM Schreibdatenbus.
Der Mario Chip und das Super NES verwenden gemeinsam das Kassetten-RAM 6, 8, das als ein Hauptmechanismus zur Übergabe von Daten zwischen dem Mario Chip und dem Super NES dient. Das Super NES greift auf den Mario Chip über die Adressen- und Datenbusse HA und HD zu. Auf die Register 76 des Mario Chips wird von dem Super NES über den Super NES Adressenbus HA zugegriffen.
Das Super NES greift auf das Kassettenprogramm-ROM 10 und das RAM 6, 8 über den Mario Chip 2 zu. Der ROM Controller 104 und der RAM Controller 88 empfangen Speicherzugriffs-bezogene Signale, die von dem Super NES erzeugt werden, um jeweils ROM und RAM Speicherzugriffe zu initiieren. Mit Hilfe eines Beispiels wird ein RAM Wählsignal RAMCS von dem Mario Chip 2 verwendet, um zu bestätigen, dass das Super NES versucht, das RAM zu adressieren.
Die X, Y und Z Busse, die in den Fig. 4A und 4B gezeigt sind, sind die internen Mario Chip Datenbusse. Die X und die Y Busse sind Quellendatenbusse und der Z Datenbus ist ein Zielstellenbus. Diese Busse führen 16 Bit von parallelen Daten.
Während Befehle ausgeführt werden kann der Mario Chip 2 die Quelle von Daten für einen Befehl auf die X und/oder Y Busse und die Zieldaten auf die Z Busse platzieren. Beim Ausführen eines Befehls, der die Inhalte von zwei Registern addiert und die Ergebnisse in einem dritten Register platziert, empfängt die Arythmetik und Logikeinheit (ALU) 50 zum Beispiel die Inhalte von zwei Quellenregistern und der X und Y Bus koppelt des Ergebnis an den Z Bus (der wiederum mit einem spezifizierten Register in dem Block 76 gekoppelt ist). Steuersignale, die sich von der Dekodierung eines Befehlsoperationscodes durch die Befehlsdekodierungs-Schaltungsanordnung 60 in dem Mario Chip 2 ergeben, werden mit der ALU 50 gekoppelt, um einen ADD Betrieb zu initiieren.
Wie im Hinblick auf die Beschreibung der Fig. 1 angegeben, ist der Mario Chip mit einem ROM Bus, einem RAM Bus und einem Super NES Hostbus gekoppelt, die in der Lage sind Signale parallel zu kommunizieren. Der Mario Chip 2 überwacht die Steuer-Adressen- und Datensignäle, die über den Host- Super-NES-Bus übertragen werden, um die Operationen zu bestimmen, die das Hostsystem gerade ausführt. Auf den Kassetten-ROM-Bus und den Kassetten-RAM-Bus kann parallel in Abhängigkeit von der Super NES Operation, die zu irgendeiner gegebenen Zeit gerade ausgeführt wird, zugegriffen werden. In herkömmlichen Super NES Spielekassetten werden die Host-CPU-Adressen- und Datenleitungen direkt mit dem RAM und ROM gekoppelt, so dass auf das RAM und das ROM nicht parallel zugegriffen werden kann.
In Übereinstimmung mit einem Aspekt der vorliegenden Erfindung trennt der Mario Chip 2 physikalisch den ROM Bus und den RAM Bus, wie in Fig. 1 gezeigt, von den Super NES Bussen. Der Mario Chip 2 überwacht die Signale, die auf den Super NES Bussen übertragen werden, und bestimmt, welche Signale an den ROM Chip und den RAM Chip über zwei getrennte ROM und RAM Busse, die zeitlich nicht gemeinsam getrennt werden, gekoppelt werden müssen. Durch Trennen der ROM und der RAM Busse ist der Mario Chip 2 in der Lage, von dem ROM zu lesen und gleichzeitig an das RAM zu schreiben. In dieser Weise kann der Mario Chip effektiv mit kostengünstigen ROM Chips arbeiten, die Zugriffszeiten aufweisen, die wesentlich langsamer als RAM Zugriffszeiten sind, ohne darauf zu warten, dass die ROM Zugriffe vor einem Zugriff auf das RAM beendet sind.
Bezugnehmend auf Fig. 4A, wie voranstehend angegeben, ist der Mario Chip 2 ein vollständig programmierbarer Prozessor und umfasst eine ALU 50. Die ALU 50 führt sämtliche arithmetischen Funktionen aus, die innerhalb des Mario Chips verkörpert sind, mit Ausnahme von Multiplizierungsoperationen, die von dem Multiplizierer 64 behandelt werden, und von bestimmten Pixelplotoperationen, die von der Plothardware 52 behandelt werden. Auf einen Empfang eines geeigneten Steuersignals von dem Befehlsdekoder 60 hin führt die ALU 50 Additions-, Subtraktions-, EXKLUSIV- ODER Verschiebungs- und andere Operationen aus. Wie in Fig. 4A gezeigt empfängt die ALU 50 Information, mit der von dem X, Y Bussen gearbeitet werden soll, führt die Operation aus, die von einem Steuersignal initiiert wird, welches von einem Befehlsdekoder 60 empfangen wird, und koppelt die Ergebnisse der Operation an den Z Bus. Die ALU wird mit näheren Einzelheiten nachstehend im Zusammenhang mit der Fig. 6 beschrieben.
Der Mario Chip 2 umfasst zusätzlich Spezialzweckhardware, um zu ermöglichen, dass spezielle Effekte des 3-D Typs und andere Grafikoperationen effizient so ausgeführt werden, dass Videospiele, die diese Merkmale verwenden, praktisch realisiert werden können. Diesbezüglich umfasst der Mario Chip 2 eine Plothardware 52, die zu einer Echtzeitumwandlung von einer Pixelkoordinaten-Adressierung auf eine Speicherkarten-Adressierung der Art, die in dem Super NES verwendet wird, einschließt. In vorteilhafter Weise kann der Mario Chip durch Spezifizieren von X und Y Koordinaten programmiert werden, die die Stelle bzw. den Ort jedes Pixels auf dem Anzeigeschirm definieren.
Somit werden Grafikoperationen auf Grundlage eines Programmierers, der Pixel spezifiziert, ausgeführt und die Plothardware-Schaltung 52 wandelt im Durchlauf (on the fly) Pixelspezifikationen in richtig formatierte Zeichendaten um. Die Zeichendaten werden dann in dem gewünschten Platz zur Anzeige in dem Super NES Video-RAM 30 abgebildet, das in Fig. 2 gezeigt ist. In dieser Weise muss der Mario Chip Programmierer nur das Super NES Video-RAM 30 als eine Bitkarte berücksichtigen, wenn es in der Realität eine Zeichenkarte ist.
Die Plothardware 52 reagiert auf verschiedene plotbezogene Befehle, um eine programmierbare Auswahl einer X und Y Koordinate auf dem Anzeigebildschirm und eine vorgegebene Farbe tUt ein bestimmtes Pixel zu ermöglichen und entsprechend Pixel derart zu plotten, dass die X und die Y Koordinate in eine Adresse umgewandelt wird, die einer Zeichendefinition der Form entspricht, die verwendet wird, um das Super-NES-Video-RAM 30 anzusteuern.
Die Plothardware 52 weist zugehörige Daten-Haltespeicher auf, die eine Pufferung von soviel Pixeldaten wie möglich vor einer Einschreibung an das Kassetten-RAM erlaubt, um. RAM Datentransaktionen zu minimieren. Nachdem die X und Y Koordinaten umgewandelt und in der Plothardware 52 gepuffert sind, werden Zeichendefinitionsdaten dann an das Kassetten-RAM transferiert.
Die Plothardware 52 empfängt X, Y Koordinatendaten über ein PLOT X Register 56 bzw. ein PLOT Y Register 58. In der gegenwärtig bevorzugten Ausführungsform sind die PLOT X und PLOT Y Register nicht getrennte Register (wie in Fig. 4A gezeigt), sondern sind anstelle davon Mario Chip allgemeine Register (z. B. Register R1 und R2 Register in dem Registerblock 76, der in Fig. 4B gezeigt ist).
Die Plothardware 52 empfängt auch Pixelfarbinformation über ein Farbregister 54. Wie nachstehend weiter beschrieben werden wird, wird die Farbe jedes Pixels, das angezeigt wird, in einer 8 · 8. Registermatrix gespeichert, wobei jede Pixelfarbspezifikation eine Spalte der Matrix belegt.
Die Plothardware 52 verarbeitet und koppelt die Zeichenadresse und Daten, die zu dem X, Y und dem Farb-Eingang gehören, mit dem Zeichen-RAM 6, 8. Die Zeichenadresse wird über Ausgangsleitungen 53 an den RAM Controller 88 und an einen RAM Adressenbus RAM A weitergeleitet. Die Zeichendaten werden an das Zeichen-RAM über die Ausgangsleitung 55, den Multiplexer 93 und den RAM Datenbus RAMD_OUT gekoppelt. Die Plothardware 52 ermöglicht, dass Pixel innerhalb eines Zeichens individuell adressiert werden, um dadurch den Programmierer mit einem "virtuellen" Bitkarten-Anzeigesystem zu versehen, während eine Kompatibilität mit dem Super NES Zeichenformat aufrecht erhalten wird. Die "virtuelle" Bitkarte wird in dem Kassetten-RAM gehalten und wird an das Super NES Video-RAM 30 beim Abschluss der Anzeige jedes Rahmens transferiert, wobei zum Beispiel die DMA Schaltungsanordnung in der voranstehend identifizierten Anmeldung EP-A-0473392 verwendet wird. Die Plothardware 52 ermöglicht eine individuelle Hochgeschwindigkeits-Pixelsteuerung, so dass bestimmte 3-D Grafikeffekte, die ein Drehen und ein Skalieren von Objekten beinhalten, praktisch realisierbar werden.
Wegen der Umwandlung von einem Pixel- in ein Zeichenformat empfängt die Plothardware 52 auch Information bezüglich anderer Pixel in der Nähe des gegenwärtigen Pixels X, Y von einem Kassetten- RAM 6, 8 über einen RAMD_IN Datenhaltespeicher 82 und eine Eingangsleitung 83. Durch Verwenden von vorangehenden Pixeldaten, die aus dem RAM 6, 8 zurückgewonnen und vorübergehend in den RAM Datenhaltespeichern gespeichert werden, kann die Anzahl von Schreibvorgängen an ein RAM minimiert werden. Die RAM Datenhaltespeicher 80, 84 und 86, die in Fig. 4A gezeigt sind, dienen ebenfalls zum Puffern von Farbdaten, die bezüglich eines Pixels empfangen wurden, welches in mehreren Bitebenen in einem Kassetten-RAM gespeichert worden ist, um eine Plothardware 52 mit derartigen Daten bereitzustellen.
Der RAM Datenhaltespeicher 80 ist mit dem Super NES Datenbus so gekoppelt, dass das Super NES die Inhalte des Datenhaltespeichers lesen kann. Die RAM Datenhaltespeicher 80, 82, 84 und 86 werden durch den RAM Controller 88 gesteuert. Die RAM Datenhaltespeicher 84 und 86 arbeiten, um Daten von dem RAM 6, 8 zu empfangen und Daten von dem RAM 6, 8 an den Ziel-Z-Bus zum Laden in ein vorgegebenes Register in dem Registerblock 76 zu koppeln. Zusätzlich mit dem RAM Controller 88 ist ein Datenhaltespeicher 90 gekoppelt, der RAM Adressen puffert. Die Adresse, die in dem Datenhaltespeicher 90 gespeichert ist, wird von dem RAM Controller-88 verwendet, um das RAM 6, 8 über den RAM A Bus zu adressieren. Auf den RAM Controller 88 kann auch von dem Super NES über den Adressenbus HA zugegriffen werden.
Die Plothardware 52 spricht auch auf einen LESE PIXEL (READ PIXEL) Befehl an, der die Pixelfarbinformation für eine horizontale Position, definiert durch die Inhalte des Registers R1, und die vertikale Position, definiert durch die Inhalte des Registers R2, liest und das Ergebnis in einem vorgegebenen Register in dem Registerblock 76 über den Ziel-Z-Bus und die Ausgangsleitung 87 speichert. Die PLOT Hardware 52 wird mit mehreren Einzelheiten in Zusammenhang mit der Beschreibung der Fig. 7, 8A und 8B beschrieben.
Ein Pipeline-Pufferregister 62 und ein ALU Controller Befehlsdekoder 60 sind mit dem Befehlsbus INSTR gekoppelt und arbeiten, um die Steuersignale CTL (überall in dem Mario Chip verwendet) zu erzeugen, um Operationen im Ansprechen auf Befehle zu initiieren, die auf dem Befehlsbus gelegt werden. Der Mario Chip 2 ist ein Pipeline-Mikroprozessor, der den nächsten auszuführenden Befehl holt, während er gerade den gegenwärtigen Befehl ausfuhrt. Das Pipeline-Register 62 speichert den nächsten Befehl (die nächsten Befehle), der (die) ausgeführt werden soll (sollen), um so eine Ausführung von Befehlen in einem Zyklus, wenn möglich, zu erlauben. Die Befehle, die auf den Befehlsbus gelegt werden, werden über die Inhalte des Programmzählers adressiert, der in einem Register gespeichert ist, welches zum Beispiel das Register R15 in dem Registerblock 76 sein kann, der in Fig. 4B gezeigt ist.
Die Befehle, die durch den Mario Chip 2 ausgeführt werden, können entweder von dem Programm-ROM 10, wie in Fig. 1 gezeigt, oder den internen Cache-RAM 94 des Mario Chips oder von dem Kassetten-RAM 6, 8 erhalten werden. Wenn das Programm gerade aus dem ROM 10 heraus ausgeführt wird, wird der ROM Controller 104 (in Fig. 4B gezeigt) den Befehl holen und diesen auf dem Mario Chip Befehlsbus INSTR platzieren. Wenn ein Programmbefehl in dem Cache-RAM 94 gespeichert wird, dann wird der Befehl auf den Befehlsbus direkt von dem Cache-RAM 94 über den Cache-RAM- Ausgabebus 95 plaziert werden.
Die Host-CPU, d. h. das Super NES, ist programmiert, um Abschnitte des Programm-ROMs 10 für Mario Chip Programmbefehle zuzuordnen. Das Super NES Programm befiehlt dem Mario Chip, eine vorgegebene Funktion auszuführen und stellt dann an dem Mario Chip die Adresse in dem ROM 10 zum Zugreifen auf den Mario Chip Programmcode bereit. Das Pipeline-Register 62 holt Befehle ein Byte vor dem Befehl, der gerade ausgeführt wird, um den Befehlsdekoder 60 mit einer befehlsbezogenen Infonnation für den Dekoder zu versehen, um in der Lage zu sein vorherzusehen, was während einer Programmausführung auftreten wird, um eine vorausschau-bezogene Verarbeitung zu ermöglichen. Die Dekodierungs- und Steuerschaltungsanordnung in Block 60 erzeugt Steuersignale zur Befehlsansteuerung der ALU 50, der Plothardware 52, der Cachesteuerung 68 etc., um die Operation auszuführen, die durch den Befehlscode angezeigt wird, der gerade ausgeführt wird.
Der Mario Chip umfasst auch einen Hochgeschwindigkeits-Parallelmultiplizierer 64, der von der ALU 50 getrennt ist. Der Multiplizierer 64 arbeitet im Ansprechen auf vorgegebene Befehle dazu, um zwei 8-Bit Zahlen, die von den X und Y Quellenbussen empfangen werden, zu multiplizieren und das 16-Bit Ergebnis auf den Ziel-Z-Bus zu laden. Diese Multiplizierungsoperation wird in einem Zyklus ausgeführt, wenn möglich. Jeder Zahleneingang an dem Multiplizierer 64 kann mit einem Vorzeichen versehen sein oder kann mit keinem Vorzeichen versehen sein. Der Multiplizierer 64 ist auch in der Lage lange Multiplizierungsoperationen auszuführen, wodurch zwei 16-Bit Zahlen multipliziert werden, um ein 32-Bit Ergebnis zu erzeugen. Der Multiplizierer 64 umfasst auch zugehörige Teilproduktregister 66, um Teilprodukte zu speichern, die während der Multiplikationsoperation erzeugt werden. Der Multiplizierer 64 wird durch ein Steuersignal von dem Befehlsdekoder 60 aktiviert, wenn ein Multiplizierungsoperationscode dekodiert wird. Der Multiplizierer 64 wird lange Multiplizierungsbefehle ausführen, die die Multiplikation von 16-Bit Wörtern in einem Minimum von vier Taktzyklen beinhalten.
Der lange Multiplizierungsbefehl weist ein folgendes Format auf:
R4 (unteres Wort), DREG (hohes Wort) ist = Sreg * R6.
Dieser Befehl wird ausgeführt, um das Quellenregister mit den Inhalten des Registers R6 zu multiplizieren und eine 32-Bit Ergebnis in den Registern R4/DREG (niedrig/hoch) zu speichern. Die Multiplikation wird mit einem Vorzeichen versehen und ersetzt Null- und Vorzeichen-Flags auf dem 32-Bit Ergebnis.
Die Operation findet in Übereinstimmung mit den folgenden sechs Schritten statt:
Schritt 1: Multiplikation ohne Vorzeichen von R4 [0...15] ist = SREG [0...7] * R6 [0...7]
Schritt 2: X mit Vorzeichen. R4 [0...15] ist = R4 [0...15] + 256 * SREG [8...15] * R6 [0...7]. Die oberen acht Bits des Produkts werden ignoriert, aber ein Übertrag von einer Addition wird aufrecht erhalten.
Schritt 3: X mit Vorzeichen. R5 [0...15] ist = CY + R6 [8...15] * SREG [0-7] ÷ 256; Vorzeichenerweitert.
Schritt 4: X ohne Vorzeichen, Y mit Vorzeichen. R4 [0...15] ist = R4 [0...15] + 256 * SREG [0...7] * R6 [8...15].
Die oberen acht Bits des Produkts werden ignoriert, aber ein Übertrag von der Addition wird beibehalten.
Schritt S: Y mit Vorzeichen. R5 [0...15] ist = R5 [0...15] + CY + SREG [0...7] * R6 [8...15] 256; Vorzeichenerweitert.
Schritt 6: X, Y mit Vorzeichen. R5 [0...15] ist = R5 [0...15] + RY [8...15] * R6 [8...15].
Der Multiplizierer 64, der in der vorliegenden beispielhaften Ausführungsform verwendet wird, kann zum Beispiel von dem Typ sein, der in Digital Computer Arithmetic, von Cavanaugh, herausgegeben von McGraw-Hill, 1984, geschrieben ist.
Bezugnehmend auf Fig. 4B erlaubt der Cache-Controller 68 (der mit näheren Einzelheiten in Fig. 14 gezeigt ist) einem Programmierer ein Laden des Abschnitts des Programms, das bei hoher Geschwindigkeit ausgeführt werden soll, in das Cache-RAM 94 hinein effizient zu initiieren. Ein derartiges "Cache-Einbinden" ("caching") wird typischerweise beim Ausführen von kleinen Programmschleifen verwendet, die häufig bei der Grafikverarbeitung auftreten. Der Mario Chip Befehlssatz umfasst einen "CACHE" Befehl. Irgendwelche Befehle, die unmittelbar dem Cache-Befehl folgen, werden in das Cache- RAM geladen, bis das Cache-RAM voll ist. Wenn der Cache-Befehl ausgeführt wird, dann wird der gegenwärtige Programmzählerzustand in das Cache-Basisregister 70 geladen. Somit definieren die Inhalte des Cache-Basisregisters 70 die Startstelle, an der eine Cache-Einbindung initiiert worden ist.
Die meisten Befehle werden in einem Zyklus ausgeführt. Befehle, die von relativ langsamen externen Speichern kommen, wie dem ROM 10 oder dem RAM 6, 8, müssen geholt werden, bevor sie ausgeführt werden. Dies wird zusätzliche sechs oder eine ähnliche Anzahl von Zyklen benötigen. Um die Programmausführungsgeschwindigkeit zu verbessern, sollte das 'Cache' RAM 94 verwendet werden, welches innerhalb des Mario Chips selbst ist.
Cache-RAM 94 kann ein 512-Byte Befehls-Cache sein. Dies ist eine relativ kleine Größe im Vergleich mit der Größe des durchschnittlichen Programms, so dass der Programmierer entscheiden muss, wie der Cache-Speicher 94 am besten zu verwenden ist. Irgendeine Programmschleife, die in die 512-Bytes Cache-Größe passen kann, kann bei voller Geschwindigkeit laufen, mit einem Zyklus sowohl zum Holen und Ausführen. Wegen der aufgesplitteten Busse kann gleichzeitig auf sowohl das ROM als auch das RAM zugegriffen werden, während ein Code von dem internen Cache 94 ausgeführt wird.
Das Cache-RAM 94 kann in vorteilhafter Weise verwendet werden, um ein Sprite zu drehen, indem eine Schleife innerhalb des Cache. 94 ablaufen gelassen wird, die die Farbe jedes Pixels aus dem ROM 10 lesen würde, während sie gerade die Drehungs- und Skalierungsberechnungen ausführt, während sie gerade den PLOT Befehl (der nachstehend noch beschrieben wird) verwendet, um das Pixel an das RAM 6, 8 zu schreiben. All dies passiert parallel, was einen sehr schnellen Durchsatz, verlangsamt durch die langsamste Operation, ergibt. Die langsamste Operation ist gewöhnlicherweise der ROM- Datenholvorgang, was der Grund ist, warum der Mario Chip konstruiert ist, um einen gepufferten Zugriff auf das ROM und das RAM zu verwenden.
Im Vergleich mit einem Ablauf von dem relativ langsamen ROM 10 wird ein Programm ungefähr sechsmal schneller von innerhalb des Cache-RAMs 94 laufen, aber es muss zunächst von dem ROM in den Cache 94 geladen werden. Dies wird durch Platzieren eines Befehls an dem Start von irgendeiner Schleife, die Cache-eingebunden werden soll, ausgeführt. Nur die ersten 512 Bytes der Schleife werden Cacheeingebunden, und zwar genommen von der Adresse CACHE-Befehls. Während der Code für die erste Iteration der Schleife ausgeführt wird, wird das Programm von dem ROM 10 kommen und in das Cache- RAM in 16-Byte Brocken kopiert. Sämtliche weitere Iterationen der Schleife werden von dem Cache-RAM 94 anstelle von dem ROM 10 kommen.
CACHE-Befehle können frei vor irgendwelchen sich wiederholenden Programmschleifen verwendet werden. Nur nachfolgende Iterationen einer Schleife werden einen Nutzen daraus ziehen, in einem Cache zu sein. Wenn eine Programmschleife größer als 512 Bytes ist und von dem Cache 94 überläuft, wird sie noch richtig arbeiten, aber nur die ersten 512 Bytes werden von dem Cache 94 laufen und der Rest wird wie gewöhnlich von dem ROM 10 laufen. Dies ergibt eine Teilgeschwindigkeitserhöhung, ist aber nicht ideal.
Ein Cache-Kennungsbit-Register 72 (ein Cache-Tagbit-Register 72), welches in der bevorzugten Ausführungsform ein Teil des Cache-Controllers 68 ist, identifiziert die Speicherstellen, die in dem Cache- RAM 94 geladen werden sollen. Die Cache-Kennungsbits ermöglichen dem Mario Chip schnell zu bestimmen, ob ein Programmbefehl von dem schnelleren Cache-RAM anstelle von dem Programm-ROM 10 ausführbar ist. Auf das Cache-RAM 94 kann durch den Cache-Controller 68 oder das Super NES über den Super NES Adressenbus HA über den Multiplexer 96 zugegriffen werden.
Der Cache-Controller 68 wird an den Programmzählerbus PC gekoppelt, um das Cache- Basisregister 70 zu laden und Überprüfungsoperationen für Cache-Speicheradressen außerhalb des Bereichs (Bereichsüberschreitung) auszuführen.
Ähnlich wie die Parallelität, die beim Lesen von dem ROM 10 erreichbar ist, stellt der Mario Chip auch eine Vorgehensweise zum parallelen Schreiben an das RAM 6, 8 bereit. Immer dann, wenn ein Mario Register an das RAM 6, 8 geschrieben wird, wird es eine getrennte RAM Schreibschaltung initiieren, z. B. in dem RAM Controller 88, um die Speichertransaktion durchzuführen. Dies wird typischerweise sechs Zyklen benötigen, aber es wird den Prozessor nicht verzögern, während er dies tut, vorausgesetzt, dass der Programmierer vermeidet eine andere RAM Transaktion für diese Zeit auszuführen. Zum Beispiel ist es schneller, eine andere Verarbeitung zwischen jedem Speicherbefehl zu verschachteln. In dieser Weise hat die RAM Schreibschaltung Zeit, ihren Job zu tun. Wenn zwei Schreibvorgänge in einer Zeile benötigt werden, würde der zweite den Prozessor verzögern, während der erste gerade geschrieben wird.
Folgendes Beispiel sei betrachtet (unter Verwendung von Befehlen mit dem Befehlssatz, der nachstehend beschrieben werden soll):
Es sei darauf hingewiesen, dass die zwei Speicherbefehle zu nahe zueinander sind. Der Zweite wird sechs Zyklen länger benötigen, weil der RAM Bus beschäftigt ist zu versuchen den ersten Speicherbefehl abzuschließen.
Eine bessere Vorgehensweise zum Schreiben des Codes, der schneller laufen wird, würde darin bestehen, die zwei Speicherbefehle mit einem anderen nützlichen Code räumlich zu trennen. Zum Beispiel:
In dieser Weise können einige wenige weitere Befehle parallel ausgeführt werden zu der gleichen Zeit, zu der der erste Speicherbefehl zu dem Schreibvorgang an das RAM führt. Dann kann die zweite Speicheroperation einige wenige Zyklen später ausgeführt werden.
Der Befehlssatz, der nachstehend beschrieben wird, umfasst einen schnellen Befehl zum Zurückschreiben eines Registers an die zuletzt verwendete RAM Adresse. Dies erlaubt eine "Massen" Verarbeitung von Daten durch, indem der Wert von einem RAM geladen wird, irgendeine Verarbeitung für ihn durchgeführt wird, und er dann wieder schnell zurückgespeichert wird.
Wiederum bezugnehmend auf Fig. 4B ist ein sofortiger Datenhaltespeicher 74 mit dem Befehlsbus gekoppelt. Dieser Datenhaltespeicher 74 ermöglicht dem Befehl selbst die Quelle von Daten bereitzustellen, so dass kein Quellenregister von einem Befehl spezifiziert werden muss. Der Ausgang des sofortigen Datenhaltespeicher 74 ist mit dem Ziel-Z-Bus gekoppelt, der wiederum mit einem Vorgegebenen der Register in dem Registerblock 76 gekoppelt ist. Die Befehlsdekodierungsschaltung 60 dekodiert einen "sofortigen" Datenbefehl und initiiert den Betrieb des geeigneten Transfers auf eine Registeroperation.
Das GET B Register 98, das in Fig. 4B gezeigt ist, wird im Zusammenhang mit der verzögerten/gepufferten Leseoperation verwendet, die voranstehend beschrieben wurde. Als Folge der weit verbreiteten Verwendung von ROMs mit relativ langsamen Zugriffszeiten mussten diesbezüglich herkömmliche Prozessoren typischerweise warten, bis ein Datenholvorgang abgeschlossen war, immer dann, wenn ein ROM ausgeführt wurde. Durch Verwenden des verzögerten/gepufferten Holmechanismus, der nachstehend beschrieben wird, können andere Operationen ausgeführt werden, während der Datenholvorgang erhalten wird. Gemäss dieses Mechanismus werden ROM oder RAM Holvorgänge automatisch an der Adresse initiiert, die durch die Inhalte von R14 identifiziert wird, wenn auf ein Register R14 in dem Registerblock 76 zugegriffen wird oder dieses in irgendeiner Weise modifiziert wird.
Wie in Fig. 4B angedeutet, ist das Register R14 mit dem ROM Controller 104 gekoppelt. Jedes Mal, wenn die Inhalte des Registers R14 in irgendeiner Weise modifiziert werden, arbeitet der ROM Controller 104, um einen ROM Zugriff zu initiieren. Die Ergebnisse eines Zugriffs auf das ROM werden in das GET B Register 98 über den Multiplizierer 102 geladen, der mit dem ROM Datenbus ROM D gekoppelt ist. Befehle, die nachstehend identifiziert werden, erlauben ein Zugreifen auf die Information, die in dem GET B Register 98 gepuffert ist. Diese Information wird auf den Ziel-Z-Bus über den Multiplexer 100 und dann in eines der Register in dem Registerblock 76 geladen.
Wenn bekannt ist, dass ein Datenholvorgang von einem ROM eine vorgegebene Anzahl von Verarbeitungszyklen erfordert, dieser Holvorgang initiiert werden kann und anstelle zu warten ohne andere Operationen auszuführen, kann der Mario Chip in dieser Weise z. B. einen nicht in Bezug stehenden Code ausführen, nachdem ein derartiger Datenholvorgang initiiert worden ist. Das GET B Register 98 kann ebenfalls verwendet werden, um Information zu speichern, die von einem RAM 6, 8 über einen Multiplexer 102 zurückgewonnen wird, wie in Fig. 4B gezeigt.
In dem Registerblock 76 sind sechzehn 16-Bit Register (R0-R15) verkörpert. Die Register R0- R13 sind Allgemeinzweckregister (obwohl einige von diesen Registern oft für spezielle Zwecke verwendet werden, die nachstehend noch beschrieben werden). Wie voranstehend beschrieben, wird das Register R14 als ein Zeiger zum Lesen des Speichers verwendet, und wenn modifiziert, wird ein Lesezyklus von einem ROM (oder RAM) initiiert. Das gelesene Byte wird in einem vorübergehenden Puffer (GET B Register 98) für einen späteren Zugriff durch einen GET L oder GET H Befehl gespeichert. Das Register R15 ist der Programmzähler. Am Start jedes. Befehls zeigt er auf den nächsten Befehl, der geholt werden soll.
Das Register R0 ist ein Allgemeinzweckregister, welches typischerweise als ein Akkumulator arbeitet. Es ist auch das Voreinstellungs-Quellen- und Zielregister für die meisten Einzelzyklusbefehle. Wenn z. B. die Inhalte von R0 und R4 zusammenaddiert werden sollen, ist es lediglich erforderlich, explizit das Register R4 zu spezifizieren.
Die Register R11, R12 und R13 werden speziell verwendet, wenn ein Schleifenbefehl ausgeführt wird. Das Register R13 speichert eine Adresse des Befehls, der oben in der Schleife ausgeführt werden soll, und das Register R12 speichert die Anzahl, wie oft die Schleife ausgeführt werden soll. Wenn die Inhalte des Registers R12 nicht-Null sind, dann wird der Befehl an der Adresse, die von den Inhalten von R13 spezifiziert wird, in den Programmzähler (R15) geladen und ausgeführt. Das Register R11 speichert die Adresse, die zurückgegeben werden soll, nachdem die Schleife abgeschlossen ist.
Die Registersteuerlogik 78 ist mit dem Registerblock 76 gekoppelt und steuert einen Zugriff auf die allgemeinen Register R0 bis R15. In Abhängigkeit von dem Format des bestimmten Befehls, der gerade ausgeführt wird, wird die Befehlsdecodierungslogik 60 ein oder mehrere Register R0-R15 spezifizieren. Die Registersteuerlogik 78 spezifiziert, weiches Register der nächste auszuführende Befehl verwenden muss. Die Registersteuerlogik 78 koppelt die Ausgänge des geeigneten Registers mit dem X- und Y-Bus. Zusätzlich, wie mit Fig. 4B angedeutet, empfängt das geeignete Register R0-R15 die Information von dem Z-Bus unter der Steuerung der Registersteuerung 78.
Der ROM-Controller 104 wird auf einen Empfang einer Adresse entweder von dem Super NES- Adressenbus HA oder dem Mario Chip auf diese Adresse zugreifen. Der ROM-Controller 104 ist mit näheren Einzelheiten in Fig. 13 gezeigt. Information, auf die von dem ROM 10 zugegriffen wird, kann in das Cache-ROM 94 für eine schnelle Befehlsausführung geladen werden. Die ROM- und RAM-Controller 104, 108 weisen beide Busarbitrierungseinheiten auf, die zwischen Zugriffsversuchen von dem Super NES und dem Mario Chip arbitrieren (entscheiden).
Wie nachstehend mit näheren Einzelheiten beschrieben wird, verwendet der Mario Chip ebenfalls Statusregister (z. B. innerhalb des Registerblocks 76 oder in dem RAM 6, 8), auf die die Super NES CPU zugreifen kann, und die Flags (Kennungen) zum Identifizieren von Statusbedingungen speichern, beispielsweise ein Null Flag, ein Übertrags-Flag, ein Vorzeichen-Flag, ein Überlauf-Flag, ein "GO"-Flag (wobei Eins anzeigt, dass der Mario Chip gerade läuft und Null anzeigt, dass der Mario Chip gestoppt ist); ein ROM Byte Holvorgang-wird-ausgeführt (Fetch-In-Progress) Flag (welches anzeigt, dass auf das Register R14 zugegriffen worden ist); verschiedene Modus-Anzeigeflags einschließlich eines ALT1-Flags, eines ALT2-Flags, Sofort-Byte-Niedrig und Sofort-Byte-Hoch Flags, und Flags, die anzeigen, dass sowohl ein Quellen- als auch ein Zielregister durch einen "WITH" Präfix-Befehl eingerichtet worden sind, und ein Interrupt-Flag (Unterbrechungs-Flag).
Der Mario Chip, der in Blockdiagrammform in den Fig. 4A und 4B dargestellt ist, wird von dem Super NES verwendet, das den Mario Chip ein- und ausschaltet, um Tasks (Aufgaben) viele Male pro Sekunde auszuführen. Zu Anfang, wenn das Super NES eingeschaltet wird, wird das Spieleprogramm, das in dem ROM 10 gespeichert ist, hochgefahren. Es sei darauf hingewiesen, dass vor der Ausführung des Spieleprogramms durch das Super NES und die Mario Chip-Prozessoren die Spielekassette zunächst authentifiziert wird. Beispielsweise kann eine derartige Authentifizierung stattfinden, indem die Super NES CPU in einen Rücksetzzustand gebracht wird und Authentifizierungsprogmme in Authentifizierungsprozessoren, die zu der Spielekassette und dem Super NES Hauptsteuerdeck gehören, stattfinden körnen, beispielsweise in Übereinstimmung mit den Lehren in der EP-A-0206704.
Der Mario Chip ist zu Anfang in einem ausgeschalteten Zustand. Zu diesem Zeitpunkt hat das Super NES einen unbeschränkten Zugriff auf das Spielekassetten-Programm-ROM und das Spielekassetten- RAM. Wenn das Super NES die Mario Chip Verarbeitungsleistung benutzen muss, um entweder Grafikoperationen oder mathematische Berechnungen auszuführen, speichert das Super NES die geeigneten Daten, die der Mario Chip in dem Kassetten-RAM (oder in vorgegebenen Mario Registern) ausführen soll, und lädt den Mario Chip Programmzähler mit der Adresse des Mario Programms, die ausgeführt werden soll. Die von dem Mario Chip zu verarbeitenden Daten können vorgegebene X, Y-Koordinatendaten von Objekten sein, die gedreht und vergrößert oder verkleinert werden müssen. Der Mario Chip kann Programme ausführen, die Algorithmen implementieren, um den Hintergrund und Vordergrund von Sprites oder sich bewegenden Objekten einer sich verändernden Anzahl zu manipulieren. Die Verwendung der Mario Chip Geschwindigkeitserhöhungshardware und -software führt zu einem Hochgeschwindigkeits- Betriebsverhalten von derartigen Operationen.
Die Verwendung des Mario Chips zum Verarbeiten von Sprites kann die Fähigkeiten des gesamten Videospielesystems beträchtlich erweitern. Z. B. ist das Super NES auf die Anzeige von 128 Sprites pro Rahmen beschränkt. Mit der Verwendung des Super Mario Chips können im Grunde genommen Hunderte von Sprites angezeigt werden und z. B. gedreht werden.
Wenn der Mario Chip die Funktion beendet hat, die von dem Super NES angefordert wird, wird ein Stop Befehl ausgeführt und ein Interruptsignal wird erzeugt und an den Super NES übertragen, um anzuzeigen, dass der Mario Chip seine Operation beendet hat - was wiederum anzeigt, dass er bereit ist, um die nächste Task auszuführen.
Der Mario Chip kann verwendet werden, um kleine Tasks durchzuführen, beispielsweise eine Hochgeschwindigkeits-Multiplikationstask, oder er kann verwendet werden, um einen Bildschirm voll mit Sprites zu zeichnen. In jedem Fall ist das Super NES frei, eine Verarbeitung parallel mit dem Mario Chip durchzuführen, vorausgesetzt, dass das Super NES weg von den RAM- oder ROM-Bussen bleibt, wenn derartige Busse gerade von dem Mario Chip verwendet werden. Es sei darauf hingewiesen, dass dann, wenn das Super NES dem Mario Chip eine Steuerung sowohl über die RAM- als auch ROM-Busse auf der Spielekassette gibt, das Super NES trotzdem in der Lage ist, Programme von seinem Arbeits-RAM 32 heraus, wie es in Fig. 2 gezeigt ist, auszuführen. Somit kann der Durchsatz des gesamten Systems erhöht werden, indem ein Super NES-Programm, welches aus dem Programm-ROM ausgeführt werden soll, an sein Arbeits-RAM kopiert wird, während gleichzeitig ein Programm von dem Mario Chip ausgeführt wird.
Ein Flussdiagramm ist in Fig. 5 gezeigt, das die Sequenz von Operationen zeigt, die von einem "RUN MARIO" Programm ausgeführt werden, welches von der Host-CPU (z. B. der Super NES CPU) ausgeführt wird, um den Mario Chip zu starten, um einen Code von einem ROM an der benötigten Adresse zu holen und auszuführen. Die Routine, die in Fig. 5 dargestellt ist, wird typischerweise von der Super NES CPU nach Kopieren der Routine von dem Programm-ROM 10 an sein Arbeits-RAM 32, das in Fig. 2 gezeigt ist, ausgeführt werden. Diese Routine wird von der Host-CPU jedes Mal ausgeführt, wenn der Mario Chip eine Operation ausführen soll.
Wie im Block 125 angedeutet, wenn die RUN MARIO Host-CPU-Routine ausgeführt wird, werden Initialisierungsoperationen ausgeführt, einschließlich einer Erhaltung der Super NES Register. Während des Initialisierungsschritts wird diese Routine von dem Programm-ROM 10 an das Arbeits-RAM 32 der Host-CPU kopiert.
Wie im Block 127 angedeutet, wird die ROM 10 Codebank, die den Mario Programmcode speichert, der ausgeführt werden soll, in das Mario Chip Register geladen. Zusätzlich wird die tatsächliche Adresse innerhalb der Codebank in einem Mario Chip Bildschirmbasisregister gespeichert, wie im Block 129 angedeutet.
Danach, wie im Block 131 angedeutet, werden die I/O Eingabe/Ausgabe-Moden in dem Mario Chip dadurch gesetzt, dass identifiziert wird, ob 4, 16 oder 256 Farbmoden verwendet werden müssen. Diese Moden entsprechen den Farbmoden, mit denen die Host-CPU arbeitet. Zusätzlich wird ein Modus gesetzt, der die Höhe des Bildschirms in Einheiten einer Anzahl von Zeichen definiert, die angezeigt werden können.
Zusätzlich werden Modus-Bits gesetzt, die die Steuerung der ROM- und RAM-Busse an den Mario Chip geben. Eine Steuerung der ROM- und RAM-Busse sind getrennt wählbar, so dass der Mario Chip auf einen Modus gesetzt werden kann, wo er einen Zugriff auf den ROM-Bus, den RAM-Bus, oder beide aufweist. Wenn der "Mario Eigentümer" Modus ("Mario Owner" Modus) sowohl für das ROM als auch das RAM gesetzt wird, dann kann die Host-CPU somit von dem ROM oder dem RAM nicht lesen oder nicht an diese schreiben. Es sei darauf hingewiesen, dass dann, wenn die Host-CPU versucht, auf das Programm-ROM zuzugreifen, während der Mario Chip gerade den Programm-ROM-Bus verwendet, ein Mechanismus bereitgestellt wird, mit dem der Mario Chip Blindadressen (Dummy-Adressen) an das Super NES zurückgibt. Die Verzweigung an derartige Adressen wird das Super NES beschäftigt halten, bis der Mario Chip nicht mehr auf den Kassetten-ROM-Bus zugreifen muss.
Wie im Block 133 angedeutet, beginnt der Mario Chip eine Operation, nachdem der Mario Chip Programmzähler mit einer Adresse geladen ist, die den ersten Befehl speichert, die die Mario Routine ausführen muss.
Die Host-CPU wartet dann auf ein Interruptsignal von dem Mario Chip (Block 135). Wenn ein Interruptsignal empfangen wird, wird das Super NES informiert, dass der Mario Chip seine Operation beendet hat und gestoppt hat (Block 137). Wenn kein derartiges Interruptsignal empfangen wird, dann setzt die Host-CPU einen Wartevorgang auf einen Interrupt fort (Block 135). Das Super NES kann während dieser Zeitperiode einen Programmcode parallel zu Mario Chip Operationen ausführen, indem es von seinem Arbeits-RAM 32, das in Fig. 2 gezeigt ist, heraus arbeitet.
Das Super NES überprüft dann das Statusregister (z. B. in dem Mario Chip Registerblock 76), um zu bestimmen, ob das Mario Chip "GO" Flag gesetzt worden ist, welches anzeigt, dass der Mario Chip gerade in Operation ist (137). Zusätzlich wird ein Interrupt-Flag in den Mario Chip Statusregistern gesetzt, um anzuzeigen, dass der Mario Chip die Quelle des Interruptsignals ist, das von der Host-CPU empfangen wird. Nachdem ein Interruptsignal von der Host-CPU empfangen wird (135), wird somit das geeignete Mario Statusregister getestet, um zu bestimmen, ob der Mario Chip die Quelle des Interrupts ist (im Gegensatz dazu, dass das Interruptsignal z. B. gerade ein vertikales Austastungsintervall anzeigt). Wenn der Mario Chip gestoppt hat (137), dann werden die Mario Eigentümer-Modusbits für das RAM und das ROM gelöscht und das Super NES weist einen vollständigen Zugriff auf das ROM und das RAM auf. Das Super NES beendet die Routine (141) und kehrt zu dem Punkt in seinem Programm zurück, den es gerade ausführte, bevor es in die Run Mario Routine übergegangen ist.
Wenn das Spieleprogramm der CPU 22 den Mario Chip in den ROM Mario Eigentümer-Modus gebracht hat, muss es freiwillig einen Zugriff auf das ROM stoppen. Immer dann, wenn die CPU 22 auf das ROM wegen irgendwelcher Gründe zugreifen muss, schaltet sie einfach den ROM Mario Eigentümer- Modus aus. Der Mario Chip wird automatisch dabeibleiben, wenn er als nächstes auf das ROM zugreifen muss, bis ihm wieder ein ROM Mario Eigentümer-Modus zurückgegeben wird. Wenn er von einem internen Cache-RAM gerade lief, kann dies überhaupt nicht benötigt werden.
Wenn der Mario Chip in dem Mario Eigentümer-Modus von einem ROM ist, ist es wichtig, dass das Spieleprogramm der CPU 22 noch nicht einmal versucht, irgendetwas von dem ROM zu lesen. Wenn irgendein Interrupt auftritt, z. B. als Folge einer vertikalen Austastung, verursacht dies einen NMI, und dann versucht die CPU 22 automatisch ihre Interruptvektoren von dem ROM zu holen. Dies ist nicht wünschenswert, weil die CPU 22 dem Mario Chip explizit mitgeteilt hat, dass sie von dem ROM wegbleiben wird, und dann tritt ein Interrupt auf und sie führt einen Holvorgang von dem ROM sowieso aus. D. h., in dieser Situation wird ein ROM-Zugriff von der CPU 22, obwohl sie in dem Mario Eigentümer- Modus gerade ist, den Mario Chip veranlassen anzunehmen, dass dies eine Interruptvektoraufforderung war.
Während eines Interruptvektor-Holvorganges in dem ROM Mario Eigentümer-Modus wird der Mario Chip die Interruptvektoren in das Super NES interne Arbeits-RAM 32 unten in dem Stapelgebiet neu anordnen. Wenn der gewöhnliche Interruptvektor $00:FFEC war, dann wird er z. B. einen JUMP (SPRUNG) an die Stelle $00:010c verursachen. In ähnlicher Weise verursachen sämtliche Interruptvektoren von $00:ffeX die CPU 22 an ihre entsprechenden Stellen an $00:010X zu SPRINGEN (JUMP). Diese Technik vermeidet, dass die CPU 22 auf das ROM 10 zugreift, wenn sie dies nicht tun soll, und leitet sie anstelle dessen an das On-Board (auf der Platine angeordnete) Super NES RAM 32. Es sei darauf hingewiesen, dass die RAM-gestützten Interruptvektoren Sprünge (jumps) oder Verzweigungen (branches) an Interruptbehandler enthalten müssen, d. h. ein tatsächlicher Code sollte dort vorhanden sein, nicht lediglich Vektoradressen. Wenn der Mario Chip nicht in dem Mario Eigentümer-Modus-ROM ist, sind die normalen ROM-Interruptvektoren in Verwendung, so dass es ratsam ist, die gleichen Adressen, die an diesen Stellen ausgewiesen sind, zu halten, um an den gleichen Platz wie die RAM-gestützten Interruptvektoren zu gehen.

BEFEHLSSATZ

Der Mario Chip Befehlssatz stellt eine effiziente Vorgehensweise zum Programmieren von Hochgeschwindigkeitsgrafiken und anderen Verarbeitungsalgorithmen bereit. Eine kurze Beschreibung von bestimmten Befehlen wird nachstehend gefolgt von einer Beschreibung von bestimmten Registern, die von verschiedenen Befehlen verwendet werden, aufgeführt. Eine ausführliche Auflistung des Befehls in dem Befehlssatz ist ebenfalls enthalten.
Befehle sind 8-Bit-Befehle und werden typischerweise in einem Einzeltaktzyklus ausgeführt. Jedoch können die Befehle durch 8-Bit Präfix-Befehle modifiziert werden. Der Mario Chip Befehlssatz umfasst ein einzigartiges Register-Außerkraftsetzungssystem (Register-Overwrite-System), welches dem Programmierer erlaubt, die Zielstellen- und beide Quellenregister vor irgendeinem Befehl zu spezifizieren. Ohne derartige "Präfix" Außerkraftsetzungen (Overwrites mit einem Präfix) würden Befehle nur auf dem Akkumulator arbeiten. Somit ist der Befehlssatz ein Befehlssatz mit variabler Länge mit einer Vielzahl von Kombinationen. Es gibt einige grundlegende Befehle, die 1 Byte lang sind, die in einem Zyklus arbeiten.
Durch Bereitstellen von Befehlen mit Präfix, kann ein Programmierer die Leistung der Befehle erweitern. Ein Befehl kann 8, 16 oder 24 Bits sein, in Abhängigkeit von dem Wunsch des Programmierers.
Der Mario Prozessor verwendet Befehle, um eine Programmausführung des On-Board Cache- RAM mit hoher Geschwindigkeit und eine verzögerte/gepufferte Eingabe/Ausgabe (I/O) an dem Speicher zu initiieren. Eine Grafikverarbeitung wird effizient durch die Verwendung eines Einzelzyklus-Pixelplot- Befehls aktiviert, der eine Operation unter Verwendung der Pixelplothardware initiiert, die voranstehend beschrieben wurde.
Vor der Identifikation des Mario Befehlssatzes werden verschiedene Speicher-abgebildete Register, die durch den Prozessor beim Ausführen von Befehlen gesetzt werden oder auf die von dem Prozessor bei der Ausfführung von derartigen Befehlen zugegriffen wird, nachstehend beschrieben. Zu Anfang wird das Statusflag-Register identifiziert. Das Statusregister ist ein 16-Bit Register und die Flags, die zu jedem der 16 Bits in dem Register gehören, werden nachstehend identifiziert. STATUS FLAGS REGISTER 16 BIT
Das "GO" Flag (Bit 5) ist ein Flag, welches auf einen "1" Zustand gesetzt wird, um anzuzeigen, dass der Mario Chip gerade läuft, und es wird auf einen "0" Zustand gesetzt, um anzuzeigen, dass der Mario Chip gestoppt hat (was zu der Erzeugung eines Interruptsignals führt, welches an das Super NES gekoppelt wird). Dieses Flagbit wird von dem Super NES Prozessor geprüft. Das Bit 6 wird gesetzt, um anzuzeigen, dass ein ROM Byte-Halvorgang gegenwärtig gerade ausgeführt wird. Der GET Byte-Befehl, der nachstehend aufgelistet ist, kann nicht ausgeführt werden, bis dieses Flag gelöscht wird, was anzeigt, dass der Datenholvorgang beendet worden ist. Diese niedrigstwertigsten Bits des Statusregisters können unabhängig oder in Kombination mit den übrigen 8 Bits von entweder dem Mario Chip Prozessor oder der Host-CPU gelesen werden. Die höchstwertigsten Bits des Statusflag-Registers werden durch geeignete Präfix-Befehle gesetzt und definieren verschieden Moden einer Befehlsinterpretation.
In dem ALT 1 Modus, der voranstehend identifiziert wurde, wird ein ADD-Befehl als ein ADD WITH CARRY (ADDITION MIT ÜBERTRAG) interpretiert und ein SUBSTRACT (SUBSTRAHIEREN) Befehl wird als ein SUBTRACT WITH CARRY (SUBTRAHIEREN MIT ÜBERTRAG) interpretiert. Ein Befehl ALT 1 initiiert diesen Modus.
Ein ALT 2 Befehl modifiziert die Interpretation des ADD-Befehls auf ADD WITH IMMEDIATE DATA (ADDIEREN MIT SOFORTDATEN) und modifiziert SUBSTRACT (SUBTRAHIEREN) auf SUBTRACT IMMEDIATE DATA (SUBTRAHIEREN VON SOFORTDATEN). Die "sofortigen" Daten ("Sofortdaten") sind in dem Byte aufgeführt, die dem Befehl sofort bzw. unmittelbar folgen. Es sei darauf hingewiesen, dass der Befehl ALT 3 beide Bits 8 und 9 auf den logischen "1" Pegel setzen wird. Die Bits 10 und 11 werden in Abhängigkeit davon gesetzt, ob der Sofortdaten-Wert ein Sofort-Hoch-Byte oder Sofort- Niedrig-Byte sind. Das Bit 12 des Statusregisters definiert einen "b" Modus, in dem beide Quellen- und Zielregister von "WITH" ("MIT") gesetzt wird.
Der Mario Chip umfasst viele Register zusätzlich zu dem voranstehend beschriebenen Statusregister. Wie voranstehend beschrieben, umfasst der Mario Chip 16 Register, die 16 Bit breit sind, wie in der Diskussion des Registerblocks 76 in den Fig. 4A und 4B angedeutet. Die meisten dieser Register sind Allzweckregister und können für eine Daten- oder Adressenspeicherung verwendet werden. Wie voranstehend angegeben, wird das Register R15 jedoch zu sämtlichen Zeiten als der Programmzähler verwendet. Typischerweise dienen Register zweierlei Zwecke und werden für eine Kommunikation mit der Host-CPU und zum Steuern des ausführenden Programms verwendet. Zusätzlich werden andere Register in dem Mario Chip verwendet, wobei die Funktionen davon in der nachstehenden Tabelle aufgeführt sind.
Register Spezialfunktion
r0 Voreinstellungs-DReg und SReg
r1 X-Koordinate für einen PLOT Befehl
r2 Y-Koordinate für einen PLOT Befehl
r3 Keine
r4 Unteres Wort des LMULT Befehlsergebnisses
r5 Keine
r6 Wortmultiplizierer für FRMULT und LMULT Befehle
r7 Quelle 1 für einen MERGE (ZUSAMMENFASSUNGS) Befehl
r8 Quelle 2 für einen MERGE (ZUSAMMENFASSUNGS) Befehl
r9 Keine
r10 Keine
rl1 Link-Register (Verbindungs-Register) für Unterprogrammaufrufe (Subroutine Calls)
r12 Zählwert für einen LOOP (SCHLEIFEN) Befehl
r13 Adresse für einen LOOP (SCHLEIFEN) Befehl zur Verzweigung nach
r14 ROM-Adresse, wenn modifiziert, startet das Lesen eines Bytes von einem ROM
r15 Programmzähler

ANDERE REGISTER

8 Bit PCBANK Programmcode-Bankregister
8 Bit ROMBANK Programmdaten-ROM-Bankregister 64 kbank
8 Bit RAMBANK Programmdaten-ROM-Bankregister 64 kbank
16 Bit SCB Bildschirmbasis
8 Bit NBP Anzahl von Bitebenen
8 Bit SCS Bildschirmspaltengrößen-Auswahl:
256, 320, 512, 640, 1024, 1280 (Bildschirme 16 & 20 Zeichen hoch, in 2, 4 & 8 Bit Ebenen)
Der Mario Chip umfasst auch ein Farbmodus-CMODE Register. Vier der Bits in diesen Registern werden in der beispielhaften Ausführungsform verwendet, um die Spezialeffekte zu erzeugen, die nachstehend beschrieben werden. Der Effekt, der durch Setzen eines CMODE Register-Bits erzeugt wird, verändert sich in Abhängigkeit davon, ob der 16 oder 256 Farbauflösungsmodus gesetzt worden ist, wie in den nachstehenden Beispielen demonstriert.
Nur Verwendung für Transparenz AUS ist zum Füllen eines Gebiets mit 0 (zum Löschen des Bildschirms verwendet)

CMODE Bit 1

Schattierungs = Bit
Schattierung in einem Modus mit 16 Farben (hoch/niedrig-Nibble ergibt zwei Farben)
Lo Nibble gewählt, wenn (xpos XOR ypos UND 1) = 0
Hi Nibble gewählt, wenn (xpos XOR ypos UND 1) = 1
Wenn Transparenz ein ist und gewählter Farb-Nibble null ist, dann nicht plotten. Schattierung in einem Modus mit 256 Farben sollte keinen Effekt aufweisen.

CMODE Bit 2

Hoch-Nibble-Farbbit
In dem Modus mit 16 Farben oder in dem Modus mit 256 Farben mit CMODE Bit 3 gesetzt.
Wenn dieses Bit gesetzt ist; setzt ein COLOUR (FARBE) Befehl 10 Nibble des Farbregisters auf ein hl Nibble des Sourcebytes
(Verwendet zum Entpacken von 16 farbigen Sprites gespeichert als hi Nibble des anderen Sprites). Wenn das 10 Nibble des Farbregisters null ist, dann nicht plotten.
Wenn Transparenz ein.

CMODE Bit 3

Kompliziertes Bit
Nur in dem Modus mit 256 Farben. Wenn dieses Bit gesetzt ist, wird das hi Nibble der Farbe gesperrt und COLOUR Befehle ändern nur das Io Nibble. Transparenz wird nur aus unterem Nibble (low_nibble) berechnet.
In dem normalen Modus mit 256 Farben wird die Transparenz von sämtlichen Bits berechnet, wenn ein.
Viele der Mario Chip Register haben zugeordnete Spezialfunktionen. Wie in der obigen Tabelle angedeutet und wenn nicht anders spezifiziert, führt das System eine Voreinstellung des Registers R0 als das Zielregister oder das Quellenregister, welches von einem bestimmten Befehl benötigt wird, aus. Das Register R0 wird auch als der ALU-Akkumulator verwendet. Der Multiplizierungsbefehl, wie voranstehend angegeben, gibt ein 32-Bit-Ergebnis zurück. Die niedrigswertigsten 16 Bits werden in dem Register in R4 gespeichert. Das Register R6 wird im Zusammenhang mit einem bruchteilsartigen mit einem Vorzeichen versehenden Multiplizierungsbefehl (Fractional Signed Multiply Befehl, FRMULT) und einem Langmultiplizierungsbefehl (LMULT) verwendet.
Die Register R7 und R8 werden beim Ausführen eines MERGE (ZUSAMMENFASSUNGS) Befehls verwendet. Der Befehl nimmt zwei vorgegebene Register (d. h. Register R7, R8) und fasst sie zusammen, um Sprite-Koordinatendaten zu bilden. Derartige Koordinatendaten werden beim Zugreifen auf eine RAM-Tabelle für eine Abbildung eines vorgegebenen Sprites auf ein vorgegebenes Polygon verwendet. Dieser Befehl ist eine Hilfe zum effizienten Ausführen von Texturabbildungsoperationen durch Kombinieren von Abschnitten von zwei Registern zum Defmieren der Adresse der Farbe des nächsten Pixels, welches zu dem enthaltenen innerhalb eines Sprites, welches auf ein Polygon hin abgebildet wird, ist.
Die Register R11 bis R13 werden zum Steuern einer Unterprogrammausführung verwendet. Das Register R11 wird als ein Verbindungs-Register (Link-Register) für Unterprogrammaufrufe verwendet und speichert die Inhalte des Programmzählers plus eins. Der Inhalt des Registers R11 definiert die Adresse, auf die zugegriffen werden muss, nachdem eine Schleife beendet worden ist. Das Register R12 wird verwendet, um einen Zählwert zu speichern, der die Anzahl von Malen definiert, wie oft die Schleife ausgeführt werden soll. Die Adresse der Schleife wird in dem Register R13 gespeichert.
Wie voranstehend angegeben, immer dann, wenn die Inhalte des Registers R14 modifiziert werden, wird ein Byte aus dem ROM 10 an der Adresse gelesen, die in dem Register R14 gespeichert ist. In dieser Weise wird eine verzögerte oder gepufferte READ (LESE) Operation im Zusammenhang mit den GET (HOLEN) Byte Befehlen, die nachstehend identifiziert werden, implementiert.
Wenn man die "anderen Register" in der obigen Tabelle betrachtet, wird auf die Programm-ROM- Stelle, von der das Programm gerade ausgeführt wird, unter Verwendung einer 24 Bit Adresse zugegriffen. Die niedrigswertigsten 16 Bits dieser Adresse werden in dem Programmzähler gefunden. Die höchstwertigsten Bits, die die Programmbank definieren, sind in einem. Programmcodebank (PC Bank) Register gespeichert.
Das ROM Bankregister (ROMBANK) speichert die höchstwertigsten Bits, um dem Mario Chip Prozessor zu erlauben, Programmdaten zu adressieren, die in dem ROM 10 gespeichert sind, und ist an die 16 Bit ROM Adresse angehängt, die in dem Register R14 gespeichert ist. In ähnlicher Weise speichert das RAM Bankregister (RAMBANK) die Adressenbits höchster Ordnung, um dem Mario Chip Prozessor zu erlauben, auf Programmdaten in dem RAM zuzugreifen. Die Inhalte des RAM und ROM Bankregisters werden im Zusammenhang mit Mario Chip ROM und RAM Zugriffsbefehlen zum effizienten Erweitern des Adressierungsbereichs des Mario Prozessors verwendet.
Das Bildschirmbasisregister (Screen Base Register, SCB) wird verwendet, um die Adresse der virtuellen Bitkarte von Sprites oder Objekten, die gerade erzeugt, und gedreht, vergrößert oder verkleinert werden, zu speichern. Wenn ein PLOT Pixelbefehl ausgeführt wird, speichert das Bildschirmbasisregister SCB die Adresse in dem RAM, auf das zugegriffen wird und an das Information geschrieben wird.
Das Register NBP wird verwendet, um die Anzahl von Bitebenen zu speichern, die gerade verwendet werden. Es zeigt typischerweise entweder die Verwendung von 2, 4 oder 8 Bit Ebenen an. Zusätzlich wird ein Bildschirmspaltengrößenregister SCS verwendet, um Information bezüglich der virtuellen Bitkarte im Hinblick auf die Anzahl von Zeichen, die in einer Spalte darin enthalten sind, zu spezifizieren.
Der Mario Chip Befehlssatz ist nachstehend aufgelistet, wobei die Befehls-Mnomo-Technik und die zugehörige Funktion, die auf ein Decodieren des zugehörigen Befehls hin ausgeführt wird, spezifiziert wird. Zu Anfang werden kurze Kommentare nachstehend für bestimmte Funktionen eines zugehörigen Befehls aufgeführt, von dem angenommen wird, dass er nicht selbsterklärend ist.
Der STOP Befehl wird ausgeführt, wenn der Mario Chip seine Operation beendet hat und arbeitet, um das "GO" Flag auf Null zu setzen, während auch irgendein Interruptsignal an der Host-CPU erzeugt wird.
Der CACHE-Befehl arbeitet, um den Abschnitt eines Programm-ROMs zu definieren, der in das Mario Chip Cache-RAM kopiert und davon ausgeführt werden soll. Wenn der CACHE Befehl ausgeführt wird, werden die Inhalte des Programmzählers in das Cache-Basisregister geladen und Cache-Tags (Cache- Kennungen), die nachstehend noch beschrieben werden, werden zurückgesetzt.
Der Mario Chip umfasst eine Reihe von verzögerten Verzweigungsbefehlen, wobei der Befehl, der der Verzweigung folgt, ausgeführt wird, wie in der nachstehenden Tabelle angegeben. Die Adresse, an die eine Verzweigung auftritt, ist relativ zu den Inhalten des Programmzählers. Der Befehlssatz umfasst eine breite Vielfalt von verzögerten Verzweigungen auf Grundlage der Bedingungen, die in der nachstehenden Tabelle aufgeführt sind.
Der Mario Chip umfasst eine Anzahl von "Präfix"-Befehlen, d. h. zu/mit/von. Diese Präfix-Befehle implizieren eine Datenverteilung für nachfolgende Befehle. Z. B. setzt das "TO" ("NACH") Präfix das Zielregister DReg für den nächsten Befehl. Der 'FROM' ('VON') Präfix setzt das Quellenregister (SReg) für den nächsten Befehl. Das 'WITH' ('MIT') Präfix setzt beide.
Die meisten Befehle benennen ein zweites Quellenregister in dem Operationscode (Opcode).
Wenn SReg und DReg nicht von Präfix-Befehlen gesetzt sind, sollten sie per Voreinstellung auf R0 sein. Sowohl SReg & DReg werden auf R0 nach jedem Befehl gesetzt, der nicht ein Präfix-Befehl ist. Wenn das DReg auf R15, den Programmzähler, gesetzt wird, wodurch bewirkt wird, dass der nächste Befehl seine Inhalte in R15 speichert, dann wird eine um einen Zyklus verzögerte Verzweigung initiiert.
Andere Präfix-Befehle setzen Flags in dem hohen Byte des Statusregisters, um den Betrieb (die Operation) eines folgenden Befehls zu ändern. Sämtliche Nicht-Präfix-Befehle löschen das hohe Byte des Statusworts. Die folgenden Beispiele dienen dazu, zu erläutern, wie nachfolgende Befehle durch Präfix- Befehle modifiziert werden können.
Wenn das "b" Flag in dem Statusregister gesetzt ist, wird der "TO" Befehl modifiziert, um als ein "MOVE" ("BEWEGEN") Befehl zu arbeiten. Der TO-Befehl spezifiziert das Register, an das die Information bewegt wird und der FROM (VON) Befehl spezifiziert die Informationsquelle.
Der STW-Befehl speichert ein bestimmtes Wort in einem Puffer, so dass es nicht erforderlich ist, zu warten, bis eine Speicheroperation beendet ist, bevor die nachfolgenden Befehle ausgeführt werden. In dieser Weise verlangsamt die Verwendung eines RAMs, welches langsamer als der Prozessor ist, nicht notwendigerweise den Prozessor herunter.
Die Ausführung des LOOP-Befehls arbeitet zum Dekrementieren der Inhalte des allgemeinen Registers R12. Wenn die Inhalte von R12 nicht-Null sind, dann wird ein Sprung an die Adresse initiiert, die in R13 spezifiziert wird.
Alt 1, alt 2 und alt 3 sind Präfix-Befehle, die die voranstehend erwähnten Flags in dem Statusregister setzen, um so zu bewirken, dass ausgeführte Befehle in unterschiedlichen Weisen interpretiert werden, wie in der nachstehenden Tabelle angegeben.
Der PLOT-Befehl identifiziert die X- und Y-Bildschirmkoordinaten des zu plottenden Pixels und plottet die Farbe, die von dem COLOUR (FARBE) Befehl spezifiziert wird, an einem Bildschirmort, der den X- und Y-Koordinaten entspricht (wie in den Registers R1 und R2 angegeben). Der PLOT = Pixelbefehl umfasst eine automatische Inkrementierung der Inhalte von R1, was zum Plotten von horizontalen Zeilen bei hoher Geschwindigkeit beiträgt und den Einbau eines zusätzlichen Inkrementierungsbefehls beseitigt.
Wenn das alt 1 Flag gesetzt ist, dann wird der Plotbefehl als ein READ PIXEL (PIXEL LESEN) Befehl (RPIX) interpretiert. Durch Ausführen des Pixellesebefehls RPIX wird die Farbe des Pixels an der spezifizierten Bildschirmstelle gelesen, was auch verwendet werden kann, um unerwünschte Pixelinformation aus der Plothardware zu räumen.
Der Pixellesebefehl RPIX verwendet im Grunde genommen die Plothardware umgekehrt, um aus einer Matrix eines Zeichens zu lesen, um die Farbe eines bestimmten Pixels zu bestimmen, die in dem Befehl spezifiziert ist. Der COLOR Befehl stellt an der Farbhardware die Farbe des nächsten Pixels bereit, das durch die Inhalte eines spezifischen Quellenregisters definiert werden kann.
Der "CMODE"-Befehl setzt den Farbmodus und kann verwendet werden, um die unterschiedlichen Spezialeffekte zu erzeugen, wie in den voranstehend angegebenen Beispielen demonstriert. Z. B. kann ein Schattierungseffekt unter Verwendung des CMODE-Befehls erzeugt werden, der unterschiedliche Farben in alternierenden Pixeln abwechselnd verwendet, um einen Schattierungseffekt zu erzeugen. Der CMODE-Befehl kann auch verwendet werden, um eine Transparenz zu steuern; so dass die Anzeige eines Sprites dann die Hintergrundanzeige ausblocken wird. Die Transparenz wird durch das Einstellen eines Farbmodus-bezogenen Flags bestimmt, wie in den obigen Beispielen gezeigt.
Der Befehlssatz umfasst auch eine bruchteilsartige Multiplizierung mit Vorzeichen, die bei Berechnungen zum Drehen von Polygonen verwendet wird, um Gradienten oder Steigungen von Objekten, die angezeigt werden sollen, zu bestimmen.
Der Inkrementierungsbefehl wird, wenn er im Zusammenhang mit dem Register R14 verwendet wird, einen Lesevorgang von dem ROM initiieren. Der GETC-Befehl wird das Byte, auf das von dem ROM zugegriffen wird, nehmen und es in das Farbregister laden.
Die folgende Tabelle spezifiziert einen beispielhaften Mario Chip Befehlssatz in Übereinstimmung mit der gegenwärtig bevorzugten. Ausführungsform einschließlich von denjenigen Befehlen, die voranstehend diskutiert worden sind. BEFEHLSSATZ
Die Fig. 6 bis 17 zeigen das Blockdiagramm von dargestellten Komponententeilen der Fig. 4A und 4B mit näheren Einzelheiten. Um die einzigartigen Merkmale der vorliegenden Erfindung deutlicher zu präsentieren, sind Schaltungseinzelheiten, von denen angenommen wird, dass sie Durchschnittsfachleuten ersichtlich oder herkömmlich sind und die dazu neigen, diese einzigartigen Merkmale zu verdeutlichen, in den Figuren, die folgen, nicht gezeigt.
Eine beispielhafte Arithmetik- und Logikeinheit, die als eine ALU-Einheit 50 verwendet werden kann, ist in Fig. 6 gezeigt. Die ALU 50 ist, wie in Fig. 4A und Fig. 6 gezeigt, mit X, Y und Z Bussen gekoppelt. Somit sind die Mario Chip Allgemeinregister R0 bis R15 mit der ALU gekoppelt.
Die ALU 50 führt Additions- und Subtraktionsfunktionen über einen 16 Bit Addierer/Subtrahierer 152 aus. Die ALU 50 umfasst auch eine herkömmliche "AND" ("UND") Logik-Schaltungsanordnung 154, "OR" ("ODER") Logik-Schaltungsanordnung 156 und "EXCLUSIVE OR" ("EXKLUSIV ODER") Logik- Schaltungsanordnung 158.
Die ALU umfasst auch eine herkömmliche Verschiebefunktions-Schaltungsanordnung, in der irgendein Übertragsbit in die höchstwertigste Bitposition verschoben und das Ergebnis mit einem Eingang des Multiplexers 164 über die Leitung 160 gekoppelt wird. Zusätzlich fährt die ALU 50 herkömmliche Byte-Swap-Operationen aus, durch die das niedrigstwertigste Byte und das höchstwertigste Byte, die auf dem Bus transportiert werden, geswappt werden können und das Ergebnis an den Multiplexer 164 auf der Leitung 162 gekoppelt werden kann. Die X- und Y-Busse sind mit den Schaltungen 152, 154, 156 und 158 gekoppelt, wie in Fig. 6 gezeigt.
Der Ausgang von jedem der Addierer/Subtrahierer 152, Schaltungen 154, 156, 158, des Verschiebeausgangs und der Swap-Funktionsausgang ist mit dem 16 Bit Multiplexer 164 mit sechs Eingängen auf ein "Ergebnis" gekoppelt. In Abhängigkeit von dem Befehl, der decodiert wird, wird das geeignete Ergebnis an den Zielbus Z ausgegeben.
Der Addierer/Subtrahierer 152 empfängt auch, zusätzlich zu dem Empfang der 16 Bits von dem X- Bus, Information, die auf den Y-Bus weitergeleitet wird, oder die Infomation in dem Befehl selbst, in Abhängigkeit von dem Befehlsdecodereingang an dem Multiplexer 150.
Die ALU 50 umfasst ferner eine CPU-Flag-Erzeugungsschaltung 166. Die CPU-Flag-Schaltung 168 erzeugt Nullüberlauf-, Vorzeichen- und Übertragssignale zum Laden in wenigstens ein Flag-Register hinein innerhalb der Schaltung 166. Die CPU-Flags können von der Befehlsdecodierungsschaltung 60 gesetzt werden, die die Übertragsaktivierungs-, Nullaktivierungs-, Vorzeichenaktivierungs- und Überlaufaktivierungs-Signale decodiert, die von Befehlen erzeugt werden, die bewirken, dass Flags in Abhängigkeit von der entsprechenden Bedingung gesetzt werden, wie durch den Addierer/Subtrahierer 152 bestimmt. Die Flags müssen auch auf Grundlage der Inhalte des Ziel-(oder Ergebnis)-Busses Z gesetzt werden, die der Flag-Schaltung 166 eingegeben werden. Flags werden z. B. verwendet, um bedingte Verzweigungsoperationen auf Grundlage eines breiten Bereichs von Bedingungen zu triggern.
Die Fig. 7, 8A und 8B zeigen die Pixelplot-Schaltungsanordnung (52, 54, 56 und 58), die in Fig. 4A gezeigt ist, mit näheren Einzelheiten. Diese Schaltungsanordnung führt den PLOT Befehl aus, der eine spezifizierte X-Koordinate und Y-Koordinate nimmt und ein Pixel an diesen Bildschirmkoordinaten in der Farbe plottet, die von den Inhalten des Farbregisters 54 spezifiziert wird, welches durch einen COLOUR Befehl geladen wird.
Wie voranstehend angegeben, verwendet das Super NES einen Zeichen-abgebildeten Anzeigeschirm. Die Plothardware arbeitet, um Pixelkoordinaten-Adressendaten in Zeichen-abgebildete Adressendaten umzuwandeln.
Die Super NES Zeichen werden in Bitebenen definiert. Zeichen können entweder 2, 4 oder 8 Bitebenen zum Definieren von 4, 16 oder 256 Farben aufweisen. Jedes Byte der Zeichendefinition umfasst eine Bitebene von einer Pixelzeile des Zeichens. Die Pixel werden links nach rechts, hohes Bit nach niedrigem Bit definiert. Für einen Betriebsmodus mit 256 Farben gibt es 8 RAM-Stellen, die aktualisiert werden müssen.
Die Pixelplot-Hardware umfasst einen lokalen Puffermechanismus einschließlich einer Farbmatrix 206, die sämtliche Bits in einem bestimmten anzuzeigenden Byte speichert, da sämtliche derartigen Bytes ultimativ aktualisiert werden müssen. Ein Bitebenenzähler 208 ist mit der Farbmatrixschaltung 208 gekoppelt. Die Pixelkoordinaten werden in Plot X und Plot Y Register 202, 204 von den X- und Y-Bussen geladen. In der gegenwärtigen beispielhaften Ausführungsform werden allgemeine Register R1 und R2 für das Plot X Register 202 und das Plot Y Register 204 verwendet, die in Fig. 7 gezeigt sind. Diese Register empfangen die X- und Y-Koordinaten des zu plottenden Pixels wie von dem PLOT Befehl spezifiziert.
Die Plot X und Plot Y Register 202, 204 sind mit einem Voll- und Halbaddierer-gestützten Zeichenadressen-Berechnungsschaltungsanordnung gekoppelt, die eine Adresse an eine zwei Positions- Tonnenverschiebeschaltung 214 (2 Positions-Barrel-Verschiebeschaltung) ausgibt, die wiederum mit einem Plotadressenregister 216 und einem Adressenvergleicher 218 gekoppelt ist. Die drei niedrigswertigsten Bits des Plot X Registers werden mit dem Demultiplexer 212 gekoppelt, der wiederum mit einem Bitanstehungsregister 210 gekoppelt ist.
Der Plotcontroller 200, der in Fig. 8A gezeigt ist, empfängt Signale, die anzeigen, dass ein PLOT Pixel (PLOT) oder READ Pixel (RPIX) Befehl decodiert worden ist, sowie andere Steuersignale, die nachstehend beschrieben werden. Der Plotcontroller 200 erzeugt Plotschaltungssteuersignale, die in der nachstehend aufgeführten Weise verwendet werden.
Wie voranstehend angegeben, erzeugt die Plotsteuerschaltung 200 Steuersignale, die innerhalb der Pixelplot-Hardware 52 verwendet werden. Wie in Fig. 8A angedeutet, empfängt die Pixelsteuerschaltung 200 den Ausgang von dem Bitanhängigkeitsregister 210, dessen Ausgang mit der Pixelsteuerschaltung 200 über ein AND (UND) Gatter 201 gekoppelt ist. Wenn sämtliche 8 Bits des Bitanhängigkeitsregisters 210' gesetzt sind, wird die Pixelsteuerlogik 200 darüber informiert, dass ein Lesezyklus übersprungen werden kann und die Informationen der Farbmatrix 206 an das RAM heraus geschrieben werden kann.
Die Pixelsteuerschaltung 200 spricht ebenfalls auf den PLOT Befehl an, um dessen Operation zu initiieren. Die Pixelsteuerlogik 200 spricht auch auf den READ Pixelbefehl RPIX an, um im Grunde genommen identische Operationen zu initiieren, mit Ausnahme davon, dass der neue Befehl nicht in die Farbmatrix 206 zur Ausgabe an ein RAM geschrieben wird. Wie voranstehend angegeben, wird der READ Pixelbefehl ausgeführt, wenn eine Notwendigkeit besteht, die Farbe eines bestimmten Pixels auf dem Bildschirm zu kennen, und wird auch verwendet, um die existierende Information in der Farbmatrix 206 herauszuräumen.
Der Controller 200 empfängt auch ein RAM-durchgeführt-Steuersignal RAM dann, was anzeigt, dass der RAM-Zugriff durchgeführt worden ist. Das RAM-durchgeführt-Signal, wie voranstehend angegeben, wird auch verwendet, um den Bitebenenzähler 208 zu inkrementieren, der eine Bitebene in der Farbmatrix 206 identifiziert. Der Plotcontroller 200 empfängt auch das PLEQ Signal von dem Adressenvergleicher 218, welches anzeigt, dass eine Adressenübereinstimmung vorhanden gewesen ist und dass keine Notwendigkeit besteht, die Inhalte der Farbmatrix 206 an das RAM herauszuschreiben, um dadurch anzuzeigen, dass eine Aktualisierung in Bezug auf die gegenwärtigen Farbmatrixinhalte fortgesetzt werden sollte. Der Plotcontroller 200 empfängt auch das Steuersignal für den Schirmmodus SCR.MD, das den Plotcontroller 200 darüber informiert, wie viele Bytes gelesen und geschrieben werden müssen.
Die Plotsteuerschaltung 200 erzeugt ein Dump-Steuersignal (Ablegen-Steuersignal) DUMP (ABLEGEN), auf das im Zusammenhang mit den Fig. 7 und 8B Bezug genommen wird und das bewirkt, dass die Inhalte der Farbmatrix 206 in ihrem zweiten Pufferabschnitt gepuffert werden. Der Controller 200 erzeugt zusätzlich ein Bitlöschungs-Anstehungsregistersignal CLRPND und ein Ladebit- Anstehungsregister-Steuersignal LDPND und koppelt derartige Signale an das Bitanstehungsregister (Register, an dem ein Bit ansteht; bit pending register) 210. Zusätzlich erzeugt der Controller 200 die LDPIX und BPR-Steuersignale, die zu den Farbmatrixelementen gehören, die im Zusammenhang mit Fig. 8B beschrieben wurden.
Die Decodierung des PLOT Befehls durch den Befehlsdecoder und des PLOT Signals, das dem Plotcontroller 200 eingegeben wird, initiiert die Erzeugung des Ladeanstehungssignals LDPND, unter der Annahme, dass die Pixelplot-Hardware ansonsten nicht beschäftigt ist. Das LDPND Signal wird an das Bitansteheungsregister 210 gekoppelt, um das Laden der Daten in das Bitanstehungsregister 210 von dem Demultiplexer 212 zu aktivieren. Das Löschen-Anstehungssignal CLRPND wird im Ansprechen auf das RAM-durchgeführt-Signal RAM dann erzeugt, welches anzeigt, dass die anstehenden Daten an das RAM herausgeschrieben worden sind. Danach wird das Bitanstehungsregister für die nächste Pixelplot- Information freigesetzt.
Ein Timing-Diagramm (Zeitsteuerungsdiagramm), das die Beziehung zwischen den Signalen, die von dem Plotcontroller 200 empfangen werden, verschiedenen Adressen- und Datensignalen, anderen in Beziehung stehenden Steuersignalen und den von dem Plotcontroller erzeugten Ausgangssteuersignalen, die voranstehend beschrieben wurden, darstellt, ist in Fig. 8C gezeigt. Beispielhafte Adressenwerte, Datenwerte etc. sind nur für Illustrationszwecke gezeigt.
Die Plothardware 52 arbeitet wie folgt. Wenn der Plotcontroller 200 bestimmt, dass die Plothardware 52 nicht beschäftigt ist, dann wird der Inhalt des Farbregisters 54, das in Fig. 4A gezeigt ist, in eine horizontale Zeile der 8 mal 8 Farbmatrixschaltung 206 geladen. Die Farbmatrix 200 wird zeilenweise geladen und spaltenweise ausgelesen. Die Inhalte des Farbregisters 54 werden durch einen COLOUR Befehl aktualisiert. Das Farbregister 54 ist das Register, durch das irgendein nachfolgender PLOT Befehl Farbdaten in die Farbmatrix hineinladen wird.
Die vertikale Position in der Farbmatrix 206, an die die Farbregisterbits geladen wird, wird durch die drei niedrigstwertigsten Bits bestimmt, die in dem PLOT X Register 202 gespeichert sind. Somit definieren die drei niedrigstwertigsten Bits der Plotadresse eine Zeile von Bits, die in der Farbmatrix 206 aktualisiert werden soll.
Das Bitanstehungsregister 210 wird verwendet, um aufzuzeichnen, welche bestimmten Bits des Abschnitts des Bildschirmzeichens gerade aktualisiert werden. Das Register 210 umfasst 16 Registerflags, die anzeigen, dass Bits in den zugehörigen Abschnitt des Bildschirms geschrieben worden sind. Das Bitanstehungsregister 210 wird im Ansprechen auf ein Signal LDPND geladen und durch ein Signal CLRPND, das von dem Plotcontroller 210 erzeugt wird, gelöscht.
Wenn ein nachfolgender Plotbefehl zum Aktualisieren der Bildschirmkarte in dem gleichen Gebiet ausgeführt werden soll, dann wird die Operation für ein gegebenes Bit zusammen mit zusätzlichen Farbdaten wiederholt, die einem Pixel entsprechen, welches in die 8 mal 8 Farbmatrix 206 hinein geladen ist. Ein anderes Bit wird dann in das Bitanstehungsregister 210 über die niedrigstwertigen Bits der Plotadresse gesetzt, die in dem Plot X Register 202 gespeichert ist. Ein bestimmtes Bit wird in das Bitanstehungsregister 210 über einen 3 zu 8 Demultiplexer 212 geladen, der mit dem Plot X Register 202 gekoppelt ist. Wenn das zu aktualisierende Pixel mehr als 8 Pixel horizontal weg ist oder wenn es eine unterschiedliche vertikale Position belegt, dann müssen die Daten, die in die Matrix 206 hineingeschrieben worden sind, an das RAM 6 (oder 8) ausgelesen werden. Die Farbmatrix 206 ist danach frei zum Empfangen von neuen Farbdaten. Bis ein nachfolgender Plotbefehl empfangen wird, der ein Schreiben an ein RAM erfordert, wird der gegenwärtige Inhalt der Farbmatrix 206 innerhalb der Pixelplotter-Hardware, z. B. innerhalb der Farbmatrix 206, gepuffert.
Wenn Daten von der Farbmatrix 206 an das RAM 6 oder 8 geschrieben werden, werden Adressentransformationsberechnungen durchgeführt, um die X-, Y-Koordinate in eine RAM-Adresse umzuwandeln, und zwar unter Verwendung der Logikgatter, der Voll- und Halbaddiererschaltungen des in Fig. 7 gezeigten Typs. Die tatsächliche Adressenberechnung soll in Übereinstimmung mit dem Erläuterungs- und Beispielcode, der nachstehend aufgeführt ist, durchgeführt werden. Derartige Berechnungen werden davon abhängen, ob ein 4, 16 oder 256-Farbmodus gerade verwendet wird. Beispielhafte Berechnungen werden für den Modus mit 256 Farben angegeben.
Diese 256 Farbzeichen weisen 4 Blöcke mit 16 Bytes auf, die jeweils Paare von Bitebenen für insgesamt 64 Bytes definieren.
Eine Bitkarte wird konstruiert, indem ein einzigartiges Zeichen auf jede Position des benötigten Bildschirmgebiets platziert wird. Wenn im Zusammenhang mit dem Super NES geplottet wird, ist es am besten, die Zeichen in Spalten zu organisieren.
Z. B. (128 Pixel-Hochbildschirm) Zeichennummern
Das Super NES ist nicht auf 256 Zeichen beschränkt, so dass eine Bitkartengröße hauptsächlich durch den Speicher und die DMA-Transferzeit beschränkt ist. Der Mario Chip ist in der Lage z. B. auf 128 und 160 Pixel hochauflösenden Bildschirmen zu plotten. Die maximale Bildschirmbreite beträgt 32 Zeichen oder 256 Pixel.
Der folgende Algorithmus stellt beispielhaft dar, wie in Pixelplot-Vorgang unter Verwendung einer virtuellen Bitkarte gesteuert wird, die in Spalten organisiert ist.
Zunächst wird eine Pixelmaske für sämtliche Bitebenen aus den niedrigswertigen 3 Bits der x- Koordinate berechnet.
Als nächstes wird eine Versatz-Abwärtsspalte (Offset down colnmn) unter Verwendung einer y- Koordinate mit 3 unteren Bits entfernt berechnet, um eine Zeichen-Abwärtsspalte zu ergeben, und dann wird mit der Größe des Zeichens multipliziert.
Als nächstes wird ein Versatz von oben der Zeichenspalte von einer x-Koordinate mit 3 unteren Bits entfernt, multipliziert mit der Spaltengröße, berechnet. Die Spaltengröße ist die Anzahl von Zeichen in der Spalte multipliziert mit der Zeichengröße. Normale Spaltengröße
Die unteren 3 Bits der y-Koordinate ergeben einen Byte-Versatz abwärts von dem Zeichen. Die Gesamtheit von sämtlichen Versätzen plus einem Zeiger auf die gegenwärtige Bitkarte ergibt die Adresse eines Bytes, welches eine erste Bitebene von Pixeln hält. Folgende Bitebenen sind alternierend 1 Byte weiter, dann 15 Bytes weiter von dem der letzten. Pixelbits können dann unter Verwendung der Pixelmaske gesetzt oder gelöscht werden. Das Bit in jeder Bitebene wird auf den Zustand des entsprechenden Bits in der Farbzahl, die in dem Farbregister 54 gespeichert und für das Pixel benötigt wird, gesetzt oder gelöscht. BEISPIELCODE
Zurückkommend zur Fig. 7 mit näheren Einzelheiten werden die X- und Y-Koordinaten des Bildschirms, die die Position des zu plottenden Pixels definieren, in PLOT X und Y Register 202 und 204 geladen (wobei diese Register tatsächlich die R1 und R2 Register in dem Registerblock 76 sein können). Die niedrigstwertigen drei Bits der Plotadresse, die in das PLOT X Register 202 geladen werden, definieren, an welches Bit innerhalb eines Bitebenenbytes durch die spezifizierte X- und Y-Koordinate geschrieben werden soll. Die Inhalte des Akkumulators R0 werden an die Spalte der Farbmatrix 206 geladen, und zwar gewählt durch die niedrigstwertigen Bits des Plot X Registers 202.
Wenn das Plot X Register 202 0 ist, dann wird das niedrigstwertige Bit in jedem der 8 Bits, die das Pixel definieren, aktualisiert werden. Wenn das Plot X Register 202 0 ist, wird der 3 zu 8 Demultiplexer 212 das niedrigstwertige Bit und in dem Bitanstehungsregister 210 auf eine logische "1" setzen.
Das Bitanstehungsregistec 210 wird von dem RAM-Controller 88 verwendet, um Spalten anzuzeigen, die aus dem RAM heraus nicht beschrieben werden müssen, da die entsprechenden Bits in dem Bitanstehungsregister 210 anzeigen, dass keine Modifikation benötigt wird.
Das Bitanstehungsregister 210 arbeitet als ein Pixelmaskenpuffer, um ein Überschreiben von neuen Daten von dem RAM zu verhindern, wenn derartige neue Daten nicht gewünscht sind. Um diese Funktion auszuführen, werden die Inhalte des Bitanstehungsregisters 210, wie in Fig. 7 angezeigt, als ein Eingang an die Farbmatrixschaltung 206 gekoppelt.
Wenn das BIT_PENDING (BIT STEHT AN) Register 210 null ist, dann wird die Bildschirmadresse des Pixels berechnet und in ein Plotadressenregister 216 geladen und die Pixelposition innerhalb des Bytes wird verwendet, um das gleiche Byte in dem BIT_PENDING Register 210 zu setzen. Wenn das BIT_PENDING Register 210 nicht null ist, dann wird das BUSY (BESCHÄFTIGT) Flag gesetzt.
Wenn die neu berechnete Adresse den Inhalten des PLOT_ADDR Registers 210 gleicht, dann wird die neue Pixelbitposition innerhalb des BIT_PENDING Registers 210 gesetzt und das BUSY Flag wird zurückgesetzt.
Wenn sich die neue Adresse von den Inhalten des PLOT_ADDR Registers unterscheidet, dann werden die folgenden Schritte vorgenommen:
Schritt 1. Wenn das BIT_PENDING Register 210 FFh enthält, wird direkt zum Schritt 3 gegangen.
Schritt 2. Lesen eines Bytes von dem RAM an der PLOT_ ADDR + scr. Basis in einen vorübergehenden Datenpuffer PLOT_BUFF.
Schritt 3. Wenn die Bits in dem Datenpuffer, maskiert von dem BIT_PENd Register 210, alle gleich zur Zeile 0 des PLOT COLOR Registerfelds sind, dann wird unmittelbar zum Schritt 5 gegangen.
Schritt 4. Schreiben der Zeile 0 des PLOT_COLOR Registerfelds in sämtliche Bits in PLOT_BUEF aktiviert durch das BIT_PENDING Registers. Schreiben von DATA_BUFF zurück an das RAM an der PLOT_ADDR.
Schritt S. Durchführen der gleichen Operation (PLOT_ADDR + 1) und Zeile eins des PLOT_COLOR Registerfelds.
Schritt 6. Bei Vorhandensein eines 8 oder 256 Farbmodus, Durchführen der gleichen Operation für (PLOT_ADDR + 16) und Zeile 2 des PLOT_COLOR Registerfelds.
Dies wird fortgesetzt, bis sämtliche Farbbits aktualisiert sind.
Die Inhalte des Plot X und Plot Y Registers 202, 204 werden durch die Volladdierer- und Halbaddierer-Schaltungsanordnung, die in Fig. 7 dargestellt ist, verarbeitet. Die Konfiguration der Voll- und Halbaddierer FA und HA und der zugehörigen Logik-Schaltungsanordnung sind für die Zwecke des Blockdiagramms der Fig. 7 vereinfacht worden. Die Adressenberechnung kann wie folgt erzielt werden:
Der mittlere Term ist:
um dadurch ein 10 Bit, Teilergebnis px[0..9], unter Verwendung von beispielsweise 6 Volladdierern und 4 Halbaddierern zu erzeugen.
Dieses Ergebnis wird in einen 12 · 3 Weg Multiplexer geführt, der von dem char_size (Zeichen_Größe) Wert gesteuert wird, um das Teilergebnis in die richtige Genauigkeit für den gewählten Bildschirmmodus zu verschieben. Dies kombiniert mit den y unteren Bits y[0..2] bildet eine 16 Bit Bildschirmadresse. Zum Abschließen der Adressenberechnung wird dies dann zu dem Screen Base (Bildschirm_Basis) Wert scr[9..22] addiert, was ermöglicht, dass der Bildschirm auf 1 k Grenzen platziert wird.
Diese Adresse wird dann an einen Zweipositions-Tonnenverschieber (214) (Zweipositions-Barrel- Verschieber) gekoppelt, der arbeitet, um die dorthin eingegebene Adresseninformation mit 1 oder 2 oder 4 zu multiplizieren, um eine Entsprechung dafür herzustellen, ob eine 4, 16 oder 256 Farb-Auflösung gewählt worden ist.
Der Ausgang der Verschiebeschaltung 214 wird an ein Plotadressenregister 216 gekoppelt, welches als ein Pufferspeicher für die RAM-Adresse dient. Die Adresse muss gepuffert werden, da sich die Inhalte der Register R1 und R2, d. h. der Plot X und Plot Y Register verändern können, nachdem der Plotbefehl ausgeführt ist.
Der Adressenvergleicher 218 vergleicht die neue Adresse, die von der Plothardware als Ausgang von der Verschiebeschaltung 214 bestimmt wird, mit der alten Adresse, die in dem Plotadressenregister 216 gespeichert ist. Wenn die Adresse anders ist, dann muss die Adresse an das RAM ausgeschrieben werden. Der Adressenvergleicher 218 erzeugt ein Steuersignal PLEQ (welches an den Plotcontroller 200 gekoppelt wird), wenn die Plotadresse, die in dem Adressenregister 216 gespeichert ist) gleich zu dem Ausgang der Verschiebeschaltung 214 ist.
Zurückkommend zu der Farbmatrix 206, wie voranstehend bemerkt, wird die Farbmatrix 206 spaltenweise ausgelesen. Ein Bitebenenzähler 208 ist mit der Farbmatrix 206 gekoppelt und definiert, welche Spalte ausgelesen werden soll. Der Bitebenenzähler 208 wird an den RAM-Controller 88 gekoppelt und, wenn ein RAM-Betrieb abgeschlossen ist, dann erzeugt der RAM-Controller 88 ein Signal, welches den Bitebenenzähler 208 inkrementiert.
Die Farbmatrix 206 umfasst ein Feld von Elementen, beispielsweise dasjenige, das in Fig. 8B gezeigt ist. Es gibt 64 derartige Elemente in einem Matrixelement der 8 mal 8 Matrix 206. Wenn der Plotbefehl decodiert wird, koppelt der Controller 200 ein Befehlssteuersignal LDPEX an den Haltespeicher 220, um den Haltespeicher zu aktivieren, um mit Farbdaten COL von dem Farbregister 54 geladen zu werden. Die Erzeugung des Steuersignals DUMP von dem Controller 200 zeigt an, dass die erste Stufe einer Pufferung innerhalb der Farbmatrix 206 abgeschlossen ist und die Daten an den Bildschirm ausgegeben werden müssen. Sobald das DUMP Signal erzeugt ist, werden die Daten, die in dem Haltespeicher 220 gespeichert sind, an eine Durchschalt-Schaltungsanordnung 226 und an den Haltespeicher 228 gekoppelt. Wenn das DUMP Signal aktiv mit der Durchschalt-Schaltungsanordnung 226 gekoppelt ist, koppelt die Durchschalt-Schaltungsanordnung die Daten an den Haltespeicher 228.
Gleichzeitig wird das Gatter 224 deaktiviert, was wiederum verhindert, dass die Rückkopplungsschleife von dem nicht-invertierenden Ausgang des Haltespeichers 228 eine Speicherung der vorangehend gespeicherten Daten aufrechterhält.
Wenn Daten von dem RAM eingelesen werden, um Datenspalten zu füllen, stellt ein Steuersignal BPR einen Null-Eingang an dem Gatter 222 bereit und das LDRAM Signal wird in einem Null-Zustand sein. Unter diesen Bedingungen werden Daten, die von dem RAMD-Eingang eingegeben werden, durch die Durchschalt-Schaltungsanordnung 226 in den Haltespeicher 228 hineinlaufen. Die Daten in dem Haltespeicher 228 sind dann zum Auslesen an den RAM-Datenbus über den RAM-Controller 88, wie in Fig. 7 gezeigt, verfügbar. Andere derartige Elemente werden kombiniert, um die Pixeldaten, wie mit der X-, Y-Pixelidentifikation angezeigt, in Zeichendaten umzuwandeln, die kompatibel mit dem Super NES. Zeichenformat sind.
Der RAM-Controller 88, der ausführlich in Fig. 9 gezeigt ist, erzeugt verschiedene Steuersignale, die zu dem (den) Spielekassetten-RAM(RAMs) gehören. Das Kassetten-RAM (die Kassetten-RAMs) müssen zwischen dem Super NES, in der Plothardware 52 innerhalb des Mario Chips, und den Datenholvorgängen von den Mario Chip Programmen, die gerade ausgeführt werden, gemeinsam verwendet werden. Der RAM-Controller 88 dient dazu, sicherzustellen, dass die richtige Adresse an den RAM-Adressenbus zu den geeigneten Zeiten gesendet wird. Die Erzeugung von RAM-Zugriffssignalen zu der geeigneten Zeit wird teilweise durch die Arbitrierungslogik 310 gesteuert, die mit näheren Einzelheiten 1 in Fig. 10 gezeigt ist.
Der RAM-Controller 88 umfasst einen Multiplexer 304, der zwischen einem Eingang von den RAM-Datenstiften über den RAM D Datenbus und den Befehlsbus multiplexiert. Der Befehlsbus oder der RAM-Datenbus wird im Ansprechen auf ein Signal gewählt, welches von dem Befehlsdecoder 60 empfangen wird, und der geeignete RAM-Ausgang wird auf den Ziel-Z-Bus gelegt.
Der RAM-Controller 88 umfasst auch ein 16 Bit Datenregister 300, welches für Datenschreibvorgänge an ein RAM, die entweder von dem 16 Bit X-Bus oder dem 16 Bit Y-Bus unter der Steuerung von Signalen empfangen werden, die von dem Befehlsdecoder 60 empfangen werden, reserviert ist. Die Daten, die in das Datenregister 300 hineingeladen werden, werden in ein niedriges Byte und ein hohes Byte aufgeteilt und an die RAM-Datenstifte über den Multiplexer 302 gekoppelt, der das untere oder obere Byte im Ansprechen auf ein Signal ausgibt, das von dem Befehlsdecoder 60 empfangen wird.
Der RAM-Controller 88 umfasst auch einen 20-Bit-Adressenmultiplexer 308. Der Multiplexer 308 wählt einen Adresseneingang im Ansprechen auf ein Steuersignal, welches von der Arbitrierungsschaltung 310 empfangen wird, das von den Codebestätigungs-CACK, Datenbestätigungs-DACK, oder Plotbestätigungs-PACK-Signalen, die in der Arbitrierungsschaltung 310 erzeugt werden, abgeleitet wird. Adressensignale von dem Super NES Adressenbus HA werden von dem Multiplexer 308 empfangen und an den RAM-Adressenbus, über den Speichertiming-Signalgenerator 312, gekoppelt, und zwar immer dann, wenn das Maiio "Eigentümer" Statusbit auf eine Null gesetzt ist. Die Arbitrierungsschaltung 310 wird über den Status der Mario Chip RAM Eigentümerschaft über das Signal RAN informiert, welches an die Arbitrierungsschaltung 310 gekoppelt wird, die auch ein RAM-Wiederauffrischungssteuersignal RFSH empfängt. Die RAN und RFSH-Signale werden zusammen "ODER" ("OR") verknüpft, um das "SUSPEND" ("ANHALTEN") Signal zu bilden, das in Fig. 10 gezeigt ist.
Der Adressenmultiplexer 308 empfängt auch einen Adresseneingang von dem 16-Bit- Multiplexerregister 306. Das Multiplexerregister 306 empfängt entweder die Inhalte des Y-Busses oder die Inhalte des Befehlsbusses in Abhängigkeit von einem Wählsignal, das von dem Befehlsdecoder 60 erzeugt wird. Der Multiplexer 308 empfängt auch den Ausgang des Datenbankregisters 314 als ein Adresseneingang zusammen mit den Inhalten des Programmzählers PC, wie in Fig. 9 gezeigt. Der Ausgang des Bildschirmbankregisters 316 wird verwendet, um die höchstwertigsten Bits der Plotadresse, die dem Multiplexer 308 eingegeben wird, die niedrigstwertigen Bits, die von der Plotschaltungsanordnung der Fig. 7 eingegeben werden, zu bilden. Sowohl das Bildschirmbankregister 316 als auch das Datenbankregister 314 werden mit Daten von dem Host-Datenbus HD geladen und die Host-CPU kann auf diese zugreifen. Obwohl dies in Fig. 9 gezeigt ist, sind diese Register nicht notwendigerweise in dem RAM-Controller 88 selbst verkörpert, sondern anstelle davon werden deren Inhalte an den RAM-Controller gekoppelt. Das Datenbankregister 314 kann z. B. in dem ROM-Controller 104 sein, der nachstehend beschrieben wird, und das Bildschirmbankregister kann z. B. in der Plothardware 52 verkörpert sein.
Das Eingangssignal des Multiplexers 308, welches ausgegeben werden soll, wird wie folgt gewählt. Wenn das Codebestätigungssignal CACK erzeugt wird, dann wird die Codebank und der Eingang des Programmzählers PC gewählt. Wenn das Datenbestätigungssignal DACK erzeugt wird, dann wird die Datenbank plus der Multiplexerregistereingang gewählt. Wenn das Plotbestätigungssignal PACK vorhanden ist, dann wird die Plotadresse gewählt. Wenn schließlich keines der CACK-, DACK- oder PACK-Signale vorhanden sind, dann wird der Adresseneingang des Hosts (z. B. SNES) gewählt.
Die 20 Bit Adresse, die von dem Multiplexer 308 ausgegeben wird, wird an den Speichertimingsignalgenerator 312 gekoppelt, der diese Adressensignale an das RAM 6, 8 zu der geeigneten Zeit koppelt. Der Speichertimingsignalgenerator 312 empfängt den Ausgang von einem Gray- Zähler in dem Arbitrierungsblock 310. Der Speichertimingsignalgenerator 312 decodiert den Ausgang von dem Gray-Zähler und erzeugt Ausgangssignale zur Adressierung des RAMs 6, 8, das in Fig. 1 gezeigt ist, über den RAM-Adressenbus RAMA. Alternativ wird der Timingsignalgenerator 312 Steuersignale zum Zugreifen auf das RAM 6, 8 einschließlich eines Zeilenadressenhinweises (Zeilenadressen-Strobes) RAS, eines Spaltenadressenhinweises (Spaltenadressen-Strobes) CAS und Schreibaktivierungs-WE-Signale erzeugen, wie in Fig. 1 gezeigt.
Der Speichertimingsignalgenerator 312 erzeugt ein DONE-Signal, welches an die Arbitrierungslogik 316 zurückgeführt wird, um anzuzeigen, dass der RAM-Zyklus beendet worden ist. Der Speichertimingsignalgenerator 312 erzeugt auch ein Datenhaltesignal DATLAT, welches zum Halten von Daten arbeitet, die von dem externen RAM in Datenhaltespeicher (nicht gezeigt) in dem RAM-Controller 88 kommen. Daten von dem RAM werden dann an die Mario Chip Schaltungsanordnung über z. B. den RAM-Datenbus RAMD_IN gekoppelt. Das RAM A Adressensignal, welches von dem Timingsignalgenerator 312 ausgegeben wird, wird an irgendein statisches RAM auf der Spielekassette gekoppelt. Die Steuersignale CES, RAS und WE werden erzeugt, wenn ein dynamisches RAM in der Spielekassette verwendet wird. Die statischen oder dynamischen RAM-Signale werden in geeigneter Weise in Abhängigkeit von der Konfiguration des Mario Chips erzeugt, wie mit den voranstehend beschriebenen Optionswiderstandseinstellungen angezeigt. Beispielhafte Timingsignale, die von dem Timingsignalgenerator 312 und anderen diesbezüglichen Signalen erzeugt werden, sind in Fig. 9A gezeigt. Die beispielhaften Adressen- und Datenwerte, die gezeigt sind, sind nur für Illustrationszwecke aufgeführt. Das RAM DONE Signal ist in Fig. 8C gezeigt.
Die Erzeugung von RAM-Zugriffssignalen zu der geeigneten Zeit wird teilweise durch die Arbitrierungslogik 310 gesteuert. Wie in Fig. 10 gezeigt, empfängt die Arbitrierungslogik 310 für einen Speicherzugriff vorgesehene eingangsbezogene Signale CACHE Anforderung CACHERQ, Datenanforderung DATRQ und Plotanforderung PLTRQ. Jedes von diesen Eingangssignalen wird vorübergehend in den Haltespeichern 325, 327, 329 gespeichert. Wenn ein Mario Befehl aus einem RAM oder ROM ausgeführt werden soll, wird der Prozess durch den Empfang CACHE Anforderungssignals CACHERQ initiiert, welches im Hinblick auf Fig. 10 verwendet wird, um zu bestätigen, dass der Befehl nicht aus dem CACHE RAM heraus ausgeführt wird und deshalb von dem RAM oder dem ROM ausgef"uhrt werden muss. Somit zeigt das GACHE Anforderung CACHERQ-Signal an, dass der Befehl von dem CACHE 94 heraus nicht ausgeführt werden kann. Das Datenanforderungssignal DATARQ wird als ein Ergebnis einer Decodierung eines Befehls, der einen RAM-Zugriff erfordert (z. B. die Byte-Lade-, Wort- Lade-Befehle) erzeugt. Zusätzlich empfängt die Arbitrierungslogik 310 ein Plotaufforderungssignal PLTRQ, welches von dem Plot-Controller 200 im Ansprechen auf die Decodierung eines Plotbefehls erzeugt wird.
Die Arbitrierungslogik 310 wird nur aktiviert (wie mit einem Statusregister-SUSPEND-Modusbit angezeigt, welches in einem "0"-Zustand ist), wenn der Mario Chip gerade läuft und wenn das Mario Eigentümerbit gesetzt ist. Nach einem Empfang und einer Speicherung der CACHE-Aufforderung erzeugen Datenanforderungs- und Plotanforderungssignale, Haltespeicher 325, 327 bzw. 329 CRQ-, DRQ- und PRQ- Signale. Gatter 331, 333 und 335 empfangen diese Signale von dem jeweiligen nicht-invertierenden Ausgang des Haltespeichers und richten die Priorität für diese Signale ein. Diesbezüglich weist das "CACHE"-Anforderungssignal die höchste Priorität auf, die Datenanforderung die zweithöchste Priorität, und das Plotanforderungssignal weist die niedrigste Priorität auf. Dem CACHE-Anforderungssignal wird die höchste Priorität zugewiesen, da es anzeigt, dass ein Versuch durchgeführt worden ist, um einen Befehl heraus aus dem GACHE auszuführen und, dass es erforderlich ist, auf den Befehl von dem RAM zuzugreifen. Die Durchschalt-Schaltungsanordnungen 333 und 335 arbeiten, um sicherzustellen, dass die Anforderung mit der niedrigsten Priorität nicht arbeitet, um die Haltespeicher 339 und 341 zu setzen, wenn eine Anforderung mit höherer Priorität bereits seinen jeweiligen Haltespeicher gesetzt hat. Die Haltespeicher 337, 339, 341 können nur gesetzt werden, wenn das System sich nicht in einem "SUSPEND"- Modus befindet, da das SUSPEND-Modussignal jedem der Gatter 331, 333, 335 eingegeben wird. Das SUSPEND-Modussignal wird auf einem niedrigen Logikpegelzustand sein, wenn der Mario Chip das RAM besitzt, d. h. er einen freien Zugriff darauf aufweist. Die Haltespeicher 337, 339 und 341 können nicht gesetzt werden, wenn SUSPEND auf "1" gesetzt ist und auch nicht, wenn irgendwelche der Bestätigungs- Haltespeicher 337, 339 und 341 bereits auf "1" sind (d. h. ein Zyklus bereits in Ausführung ist). Die Gatter 331, 333 und 335 richten die Priorität eines RAM-Zugriffs ein. Der Datenbestätigungs-Haltespeicher 339 wird nicht gesetzt werden, wenn der CACHE REQUEST Haltespeicher 337 gesetzt ist, und genauso wird der Plot Bestätigungshaltespeicher 341 nicht gesetzt werden, wenn entweder die CACHE oder DATEN Anforderungs-Haltespeicher gesetzt sind.
Das Cache-Bestätigungssignal CACK wird sofort erzeugt, wenn der Haltespeicher 337 von dem Cache-Anförderungssignal gesetzt wird und sofort, wenn von der Logik-Schaltungsanordnung in Fig. 10 festgestellt wird, dass der Cache 94 (oder das RAM) verfügbar ist. Das Datenbestätigungssignal DACK und das Plotanforderungs-Bestätigungssignal PACK werden genauso erzeugt, um die Datenaufforderungs- und Plotaufforderungssignale zu bestätigen, wenn die Logik-Schaltungsanordnung in Fig. 10 bestimmt, dass das RAM ansonsten nicht beschäftigt ist.
Der nicht-invertierende Ausgang der Haltespeicher 337, 339 und 341 wird an die Durchschalt- Schaltungsanordnung 343 gekoppelt, die wiederum über das NOR-Gatter 344 den Gray-Zähler 345 zurücksetzt, der Timingsignale für RAM-Zugriffe erzeugt. Von Durchschnittsfachleuten in dem technischen Gebiet wird erkannt werden, dass ein Gray-Zähler ein Zähler ist, bei dem sich nur ein Ausgangsbit zu einer Zeit ändert, was zweckdienlicherweise verwendet werden kann, um eine RAM-Zugriffszeit zu steuern.
Ein DONE-Signal, welches von dem Timingsignalgenerator 312 erzeugt wird, wird von dem NOR-Gatter 344 und den Haltespeichern 337, 339, 341 empfangen. Das DURCHGEFÜHRT-(DONE)- Signal zeigt an, dass ein RAM-Zyklus beendet worden ist. Die Erzeugung des DONE-Signals triggert das Löschen des geeigneten Haltespeichers in der Arbitrierungslogik 310, um die Aufforderung zu löschen, die gehalten worden ist. Das DONE-Signal wird auch an die Ursprungs-Schaltung gekoppelt, z. B. den Cache- Controller 68 oder den Plot-Controller 52, um anzuzeigen, dass der RAM-Zugriff beendet worden ist.
In Übereinstimmung mit einer alternativen Ausführungsform der vorliegenden Erfindung kann der Mario Chip ein duales Taktungssystem verwenden. Somit muss der Mario Chip Prozessor nicht von dem gleichen Takt angesteuert werden, der z. B. die RAM-Controller-Schaltungsanordnung ansteuert, die voranstehend identifiziert wurde. Der RAM-Controller 88 kann z. B. von dem 21 MHz Taktsignal angesteuert werden, welches von dem Super NES empfangen wird, und der Mario Chip Prozessor kann auf einem anderen variablen Frequenztakt angesteuert werden. In dieser Weise wird der Mario Chip Prozessor nicht darauf beschränkt sein, bei einer Taktrate von 21 MHz zu arbeiten.
Der Mario Chip in Übereinstimmung mit dieser beispielhaften Ausführungsform kann eine asynchrone Zustandsmaschinen-Steuerschaltung wie diejenige, die in Fig. 11 gezeigt ist, verwenden, um eine resynchronisierende Dualtakt-Kopplungsfunktion auszuführen. Die Schaltungsanordnung der Fig. 11 kann verwendet werden, um eine Kopplung mit dem Mario Chip Prozessor herzustellen, wenn sie unter Verwendung eines unterschiedlichen Taktungssystems als ein Speicher-Controller, der bei einer anderen Taktrate arbeitet, implementiert wird.
Die in Fig. 11 gezeigte Resynchronisationsschaltung empfangt ein ankommendes Taktsignal DIN, welches nicht synchron zu einem Taktsignal CK ist. Die Resynchronisations-Schaltungsanordnung erzeugt ein Signal von DIN, das synchron mit CK ist, und zwar unabhängig davon, ob DIN eine höhere oder niedrigere Frequenz aufweist als die Taktrate CK.
Wie in Fig. 12 beispielhaft dargestellt, geht die in Fig. 11 gezeigte Schaltungsanordnung im Ansprechen auf das Signal DIN durch Zustände 010, 110, 100, 101, 111 und zurück auf den anfänglichen Zustand 010. Die Resynchronisations-Schaltungsanordnung der Fig. 11 kann in irgendeiner Schnittstellenschaltung verwendet werden, die duale Taktsignale empfängt, beispielsweise dem ROM- Controller 104 und dem RAM-Controller 88.
Die in Fig. 11 gezeigte Schaltung spricht auf das ankommende Signal DIN an, indem sie von ihrem Ruhe- oder Rücksetzzustand "010" auf den Formzustand "110" umschaltet, und zwar als Folge davon, dass der Haltespeicher A durch das Gatter F gesetzt ist. Sobald der Resynchronisationstakt CK auf niedrig geht (was bereits wahr sein kann), wird der Haltespeicher B durch den Gatter E bildenden Zustand "100" zurückgesetzt. Wenn der Takt wieder nach oben geht, wird der Haltespeicher C in den Formungszustand "101" durch das Gatter A gesetzt.
Der Haltespeicher C erzeugt den Ausgang von der Schaltung, wie bei Q in Fig. 11 angedeutet. Wenn das Eingangssignal wieder nach unten geht wird der Haltespeicher B wieder durch den Gatter C Bildungszustand "111" gesetzt. Wenn der Takt CK wiederum nach Erreichen eines Zustands "111" auf niedrig geht, dann wird der Haltespeicher A durch den Gatter G Bildungszustand 011 zurückgesetzt. Danach geht der Takt CK wieder hoch und der Haltespeicher C wird durch das Gatter B zurückgesetzt, wobei die Zustandsmaschine auf ihren Ruhezustand zurückgeführt wird, und dann wird der Ausgang inaktiv.
Fig. 13 zeigt den ROM-Controller 104 der Fig. 4B mit näheren Einzelheiten. Der ROM-Controller 104 umfasst einen Cache-Lader 400, der teilweise das Laden des Mario Chip Cache-RAM 94 mit gegenwärtig ausführenden Programmbefehlen steuert, die in dem ROM 10 oder in dem Cassetten-ROM gespeichert sind. Befehle werden in das Cache-RAM 94 in Gruppierungen von 16-Bytes geladen. Wenn ein Sprungbefehl angetroffen wird, in der Mitte eines 16 Byte Segments, muss trotzdem ein vollständiges 16- Byte Segment weiter aufgefüllt werden, bevor ein Sprung ausgeführt werden kann. Die CACHE- Ladeschaltung 400 umfasst eine 2-Bit Zustandsmaschine, die auf das Decodieren des Sprungbefehls dadurch reagiert, dass sichergestellt wird, dass die übrigen Bytes des 16 Byte CACHE Segments in das Cache-RAM 94 hineingeladen wird. Der erste Zustand der den Cache ladenden Logik-Zustandsmaschine ist der Ruhezustand, der wahr ist, wenn entweder eine Programmausführung außerhalb des Bereichs des Caches ist oder wenn die Programmdaten bereits in den Cache geladen worden sind. Der zweite Zustand zeigt an, dass das Laden des Caches und das Ausführen der Befehle von dem Cassetten-ROM oder RAM gerade gleichzeitig auftreten. Der dritte Zustand wird durch die Decodierung des Sprungbefehls getriggert, wobei dieser Zustand im Endeffekt bleibt, bis sämtliche Bytes in dem 16 Byte Cachesegment geladen worden sind. Der vierte Zustand wird angetroffen, wenn der Sprung ausgeführt wird und der Sprung auf eine Adresse fällt, die nicht genau einer Cache-16-Byte-Grenze entspricht, wobei in diesem Fall der Cache von dem Beginn der Grenze zu dem Teil des 16 Byte Segments entsprechend zu der Adresse, an die sich das Programm verzweigt hat, gefüllt wird.
Der Cache-Controller 68, der in Fig. 4B gezeigt ist, erzeugt ein CACHE-Signal, welches dem Cache-Lader 400 eingegeben wird und welches anzeigt, dass der angeforderte Befehl gegenwärtig nicht in dem Gache-RAM 94 verfügbar ist. Demzufolge muss der Befehl aus dem ROM geholt werden. Das Code- Banksignal identifiziert die höchstwertigen drei Bits der Adresse, auf die zugegriffen werden soll, und zeigt an, ob auf das Programm-ROM oder das RAM zugegriffen werden soll. Der Cache-Lader 400 umfasst auch einen Zähler (nicht gezeigt), der während einer Programmausführung einen Zählwert aufrechterhält, der den niedrigstwertigsten Bits des Programmzählers PC entspricht. Dieser Zähler wird über den PC-Eingang des Cache-Laders 400 geladen.
Die Cache-Lade-Schaltungsanordnung 400 in dem ROM-Controller 104 empfängt auch WAIT (WARTEN und GO (GEHEN) Steuersignale, die anzeigen, dass der Mario Prozessor gerade nicht in dem WAIT-Zustand wegen irgendwelcher Gründe gehalten wird und, dass der Mario Chip in dem "GO"- oder "LAUFENDEN" Modus ist. Bei der derartigen Fällen erzeugt die Cache-Ladeschaltung 400 ein "CODEFETCH" (CODE HOLEN) Steuersignal, welches an das NOR-Gatter 408 gekoppelt wird, das in Fig. 13 gezeigt ist und wiederum mit dem Löscheingang des ROM-Timingzählers 406 gekoppelt ist. Wenn die Cache-Ladeschaltung 400 ein Codehol-Signal CODE FETCH (CODE HOLEN) erzeugt, initiiert die Logik-Schaltungsanordnung innerhalb des ROM-Controllers 104 einen Code-Holvorgang bei einer höheren Priorität als der Datenholvorgang, da dieser Code-Holvorgang vor dem Datenholvorgang initiiert werden muss. Die Arbitrierungs-Schaltungsanordnung, die die Prioritätslogik beinhaltet, wie diejenige, die im Zusammenhang mit Fig. 10 gezeigt ist, kann verwendet werden, um zu ermöglichen, dass dem erzeugten Signal eine höhere Priorität als dem DATA FETCH (DATEN-HOLEN-VORGANG) gegeben wird.
Wenn das Löschsignal von dem ROM-Timingzähler 406 entfernt wird, wird ein Zählzugriff initiiert. Der ROM-Timingzähler 406 wird verwendet, um das ROMRDY-Timingsignal zu erzeugen, welches anzeigt; dass ROM-Daten an ROM-Datenstiften vorhanden sind, wobei dieses Signal von der Durchschalt-Schaltungsanordnung 410 ausgegeben wird.
Die Durchschaltung des ROM-Daten-Bereit-Signals ROMRDY wird an die Resynchronisationsschaltung 402 gekoppelt, die z. B. die Resynchronisations-Schaltungsanordnung umfassen kann, die voranstehend in Fig. 11 beschrieben wurde. Nachdem eine Synchronisation mit dem Prozessortakt erhalten ist, wird ein Signal ROM DCK erzeugt, um einen Haltespeicher 404 zurückzusetzen und ein DATAFETCH-Signal zu erzeugen, welches einen Datenholvorgang anzeigt, der durch den Zugriff von dem Register R14 getriggert wird, was zu dem EN R14-Signal führt. Das DATAFETCH-Signal wird erzeugt, wenn ein ROM-Timingzähler 406 einen vorgegebenen Zählwert erreicht hat, um sicherzustellen, dass Daten an den ROM-Datenstiften vorhanden sind.
Der in Fig. 13 gezeigte ROM-Controller erzeugt eine ROM-Adresse an dem Ausgang von dem Multiplexer 414, der eine Adresseninformation von einem der folgenden Eingänge wählt. Das Code- Bankregister 4I2 wird von dem Super NES Datenbus HD geladen, um zu definieren, welcher ROM- Programmbank der Mario Code ausgeführt werden soll. Das Code-Bankregister 412 stellt 8 Bits einer 23 Bit ROM-Adresse an dem Multiplexer 414 bereit. Die niedrigswertigen Bits der ROM-Adresse werden von den Inhalten des Programmzählers PC erhalten. Wenn Daten gerade in das Cache-RAM hinein geschrieben werden, werden die niedrigstwertigsten 4 Bits von dem CACHE LOAD (CACHE LADEN) Signal von dem Cache-Lader 400 erzeugt. Ein zusätzlicher Adresseneingang des Multiplexers 414 wird aus den Inhalten des Mario Allgemeinregisters R14 immer dann erzeugt, wenn auf das Register R14 zugegriffen wird.
Das Zugreifen auf das Register R14 führt dazu, dass der Datenhol-Haltespeicher 404 ein DATAFETCH-Signal erzeugt, welches als ein Steuereingang verwendet wird, um den Multiplexer 414 zu veranlassen; seinen R14-Eingang (und die Inhalte des Datenbankregisters 416, die von dem Super NES Datenbus HD geladen werden) zu wählen. Das Datenbankregister 416 erhält die höchstwertigsten Bits der Datenbank, die zu der R14-Holoperation gehören.
Das DATA FETCH-Signal wird zusätzlich an ein Gatter 408 gekoppelt, was ein Zählen von dem ROM-Timingzähler 406 initiieren wird, was wiederum ein ROM-Fertig-Signal ROMRDY über das Gatter 410 erzeugt. Wenn das ROMRDY-Signal erzeugt wird, sind Daten von dem ROM-Datenbus ROM D[7 : 0] verfüghar.
Der Adressenmultiplexer 414 erzeugt auch eine ROM-Adresse von dem Super NES Adressenbus.
HA. Der Super NES Adressenbus wird in Abhängigkeit von dem Zustand des Signals "ROM" gewählt werden, welches die Steuereingänge des Multiplexers 414 gekoppelt wird. Das "ROM"-Steuersignal zeigt an dem Mario ROM-Controller an, dass das Super NES eine Steuerung von dem ROM-Adressenbus aufweist.
Nachdem ein Sprungbefehl decodiert ist, werden an den Adressenmultiplexer 414 die Inhalte des Programmzählers plus die vier niedrigswertigsten Bits, die von dem Zähler innerhalb des Cache-Laders 400 erzeugt werden, geführt. Dies erlaubt, dass das Cache-Segment mit dem Rest der 16 Bytes geladen wird, die gerade geladen wurden, bevor der Sprung gerade decodiert wurde.
Der Multiplexer 422 stellt den Datenpfad innerhalb des ROM-Controllers 104 von den ROM- Datenstiften ROMD zu dem Zielbus Z des Mario Chips bereit. Das DATAFETCH-Signal, welches durch den Haltespeicher 404 erzeugt worden ist, und das ROMRDY-Signal, welches von dem ROM- Timingzähler 406 erzeugt wurde, werden an das Gatter 418 gekoppelt, um das Laden des ROM-Puffers 420 zu aktivieren. ROM-Daten von dem ROM-Datenbus ROMD[7..0] werden in den ROM-Puffer 420 hinein geladen.
Der Multiplexer 422 wählt einen Eingang im Ansprechen auf die Decodierung eines Befehlscodes (wie GET B, was der automatische Datenholvorgang ist, der durch das Zugreifen auf das Register RI4 getriggert wird). Wenn eine Code-Holoperation decodiert wird, wird der ROM-Controller 104 Befehle an den Befehlsbus in dem Mario Chip koppeln, wie in Fig. 15A gezeigt. Wenn ein GET B-Befehl decodiert wird, dann wird das gepufferte Byte, das in dem Register 420 gespeichert ist, auf den Z-Bus gebracht. Bestimmte GET B-Befehlsoperationen beinhalten Daten über den X-Bus, wie mit den entsprechenden Eingängen an dem Multiplexer 422 angezeigt, der in Fig. 13 gezeigt ist. Die Daten, die an den Ziel-Z-Bus gekoppelt werden, können dann in eines der Mario Allgemeinregister 76 geladen werden.
Der Cache-Controller 68 ist mit näheren Einzelheiten in Fig. 14 gezeigt. Der Cache-Controller 68 umfasst einen Tag-Haltespeicher (Kennungs-Haltespeicher) 506. Der Tag-Haltespeicher 506 umfasst z. B. 64 Haltespeicher, die anzeigen, ob Befehle in dem Cache-RAM 94 (das für Illustrationszwecke so gezeigt ist, dass es in dem Cache-Controller verkörpert ist) gespeichert werden.
Jedes der 64 Flags in den Tag-Haltespeichern 506 entspricht 16 Bits einer Information, die in dem Cache-RAM 94 gespeichert ist. Das Cache-RAM 94 wird mit Befehlen zur gleichen Zeit geladen, wenn Befehle gerade von dem ROM oder RAM ausgeführt werden. Wenn ein Sprungbefehl ausgeführt wird, wie voranstehend angegeben, wird das RAM 94 mit den übrigen Bytes des 16 Byte Segments über den Cache- Lader 400 geladen, der im Zusammenhang mit dem ROM-Controller 104 beschrieben wurde, der in Fig. 13 gezeigt ist. Bis diese übrigen Bytes geladen sind, kann das gesamte 16 Byte Segment über den Tag- Haltespeicher 506 nicht als geladen angezeigt werden.
Wenn man die Aufmerksamkeit auf die Durchschalt-Schaltungsanordnung 510 richtet und der Programmzähler von 0 nach 15 gezählt hat, hat der 14 Bit Subtrahierer 502 ein Bereichsüberschreitungssignal (Out-of-range-Signal) (welches invertiert ist) ausgegeben und wenn der ROM-Controller sein ROM-Daten-Fertig-Signal ROMRDY ausgegeben hat (was anzeigt, dass ein Byte fertig ist, um ausgegeben zu werden), setzt die Durchschalt-Schaltungsanordnung 510 den Tag- Haltespeicher 506 an der Stelle, die von dem Multiplexer 504 adressiert wird.
Wenn ein Cache-Befehl decodiert wird, wird ein Steuersignal auf dem Bus 501 erzeugt, welches anzeigt, dass nachfolgende Befehle für den Cache-RAM-Speicher 94 ausgeführt werden sollen. Das Steuersignal auf dem Bus 501 wird mit dem Ladeeingang des Cache-Basisregisters 500 gekoppelt und dient dazu, das Cache-Basisregister 500 mit den 13 höchstwertigsten Bits des Programmzählers PC zu laden. Gleichzeitig werden, wie in Fig. 14 angedeutet, die Tag-Haltespeicher 506 gelöscht.
Der Ausgang des Cache-Basisregisters 500 und die höchstwertigsten Bits des Programmzählers (z. B. Bits 3-15) werden an einen Subtrahierer 502 gekoppelt, der bestimmt, ob die von dem Programmzähler PC eingegebene Adresse innerhalb des Bereichs des Cache-RAMs 94 ist. Der Subtrahierer 502 gibt z. B. seine sechs niedrigswertigsten Bits, als die höchstwertigsten Bits der Cache-RAM-Adresse aus, wobei die drei niedrigstwertigsten Adressenbits von dem Programmzähler PC gekoppelt werden.
Das Bereichsüberschreitungssignal O/Range wird von dem Übertragsausgangssignal von dem Subtrahierer 502 erzeugt und wird invertiert. Das invertierte Bereichsüberschreitungssignal dient, wenn es hoch ist, dazu, einen Haltespeicher in dem Haltespeicherfeld 506 zu setzen. Das Setzen des Haltespeichers wird von der Cache-Adresse abhängen, das von dem Subtrahierer 502 über den Demultiplexer 504 ausgegeben wird, und entspricht einem 16-Byte Segment in dem Cache-RAM 94, um anzuzeigen, dass ein Befehl in einem Cache gespeichert wird, der der ausgegebenen Cache-RAM-Adresse entspricht. Die Ausgänge der Tag-Haltespeicher 506 werden an einen Multiplexer 512 gekoppelt, der eines der 64 Tag- Haltesignale an ein NOR-Gatter 514 auf Grundlage des Multiplexer-Wähleingangs koppelt, der ein auszugebendes Haltesignal entsprechend zu einer der 64 Wählleitungen wählt, die von dem DMOX 504 ausgegeben werden. Der andere Eingang zu dem NOR-Gatter 514 ist das Bereichsüberschreitungssignal, welches anzeigt, dass ein externer Holvorgang benötigt wird, da der gewünschte Befehl in dem Cache- RAM 94 nicht gefunden werden kann.
Fig. 15A zeigt ein Blockdiagramm des ALU-Controllers/Befehlsdecoders 60, der in Fig. 4A gezeigt ist. Wie in Fig. 15 gezeigt, empfängt der ALU-Controller/Befehlsdecoder 60 Befehle von dem Cache-RAM 94, dem ROM-Controller 104, und dem RAM-Controller 88. Diese Mario Chip Komponenten sind nicht Teil des ALU-Befehlsdecoders 60, sind aber in Fig. 15 nur für Illustrationszwecke dargestellt.
Der Multiplexer 525 wählt einen Befehlsausgang von entweder dem Cache-RAM 94, dem ROM- Controller 104 oder dem RAM-Controller 88 und gibt den gewählten Befehl dem Pipeline-Haltespeicher 527 ein. Eine Auswahl durch den Multiplexer 525 zwischen dem RAM oder dem ROM auf Grundlage von Befehlen hängt von dem Zustand eines vorgegebenen Bits in dem Code-Bankregister, z. B. von dem Bit 4, ab. In Abhängigkeit von der Adresseninformation, die in das Code-Bankregister hinein geladen ist, wird ein Befehl von dem ROM oder dem RAM decodiert. Alternativ wählt der Multiplexer 525 einen Befehl von dem Cache-RAM 94 in Abhängigkeit von dem Zustand eines Steuersignals CACHE CTL von dem Cache- Controller 68, der anzeigt, dass ein auszuführender Befehl innerhalb des Bereiches des Cache-RAMs 94 ist und dass ein geeignetes Tag-Bit gesetzt worden ist, wie im Zusammenhang mit dem Cache-Controller 68 beschrieben wurde.
Der Pipeline-Haltespeicher 527 empfängt einen 8-Bit Befehl von dem Multiplexer 525, wenn er durch ein Programmzähler-Aktivierungssignal PCEN.IL.IH aktiviert ist, welches z. B. durch den ROM- Controller 104 (oder dem RAM-Controller 88) erzeugt wird, wenn ein Befehl gerade von dem ROM (oder dem RAM) geholt wird. Da mehr als ein Verarbeitungszyklus zum Holen eines Befehls von dem RAM oder dem ROM benötigt wird, werden die Befehlsdecodierungsoperationen durch das Programmzähler- Aktivierungssignal PCEN getriggert, das durch die jeweiligen ROM- oder RAM-Controller 104, 88 erzeugt wird.
Wenn der Befehl andererseits von einem Cache-RAM 94 ausgeführt wird, ist das Programmzähler- Aktivierungssignal PCEN zu sämtlichen Zeiten aktiv und die. Befehlsausführung wird bei der vollen Prozessortaktrate ausgeführt. Da die ROM 10 Zugriffszeit viel langsamer als Zugriffszeiten für das Cache- RAM 94 oder das Kassetten-RAM ist, ist es erforderlich, dass das PCEN-Signal bei weniger häufigen Intervallen für ROM-Zugriffe als das Decodierungs-Aktivierungssignal für entweder das entsprechende Cache-RAM oder das dynamische oder statische RAM erzeugt wird.
Der Befehl, der vorübergehend in dem Pipeline-Haltespeicher 527 gespeichert wird, wird an eine herkömmliche Befehlsdecodierungs-Schaltungsanordnung ausgegeben, wie schematisch durch die Durchschalt-Schaltungsanordnung 537, 539 und 541 dargestellt, um die Signale zu erzeugen, die Operationscodes 1, 2, ... N anzeigen.
Der Befehl, der in den Pipeline-Haltespeicher 527 geladen wird, wird auch an die Vorausschaulogik (Look-ahead Logik) 551 gekoppelt. Die Vorausschaulogik 551 dient zur Bereitstellung einer Vordecodierungsanzeige des Operationscodes, der dazu dienen wird, um geeignete Register in dem Mario Chip Registerblock 76 zu wählen. Um die Geschwindigkeit einer Ausführung vor einer Decodierung des Operationscodes zu optimieren, wird das Register, auf das zugegriffen werden soll, schnell bestimmt, um einen Hochgeschwindigkeitszugriff von Daten zu aktivieren, die von dem Befehl benötigt werden.
Die Vorausschaulogik 551 reagiert auf die Befehlsoperationscodebits sowie verschiedene Programmdecodierungs-Steuerflags. Die Befehlsdecodierungsschaltung 60 umfasst eine Programmsteuerungs-Flagdetektor-Logik 543, die auf vorher decodierte Operationscodes anspricht, um ALT 1 und ALT 2 Signale zu erzeugen, die anzeigen, dass die entsprechenden Präfix-Befehle, wie voranstehend beschrieben, decodiert worden sind. Ein verwandtes ALT 1 PRE Signal, welches nachstehend beschrieben wird, wird ebenfalls von der Flagdetektorlogik 543 erzeugt. Zusätzlich werden IL und III Signale erzeugt, um anzuzeigen, dass die Befehle, die sofortige Daten erfordern, decodiert worden sind (wobei L und H sich auf ein niedriges Byte bzw. hohes Byte bezieht). Die IH und IL Flags arbeiten, um auszuschließen, dass die sofortigen Daten, die sich auf Befehle beziehen, als Operationscodes decodiert werden. Demzufolge müssen nicht-IL (IL) und nicht-IH (IH) Signale ebenfalls den Pipeline-Haltespeicher 527 aktivieren. Die ALT 1 und ALT 2 Signale, wie voranstehend beschrieben, dienen dazu, um einen danach erzeugten Operationscode zu modifizieren, und Werten der Decodierungslogik 537, 539, 541 etc., wie z. B. an der Durchschalt-Schaltung 541 gezeigt, eingegeben, um den Operationscode in Übereinstimmung mit der voranstehenden Diskussion dieser Signale zu modifizieren.
Die Vorausschaulogik 551 erzeugt Registerwählsignale auf Grundlage der vordecodierten Operationscodes und von Signalen, die erzeugt werden, wenn frühere Operationscodes (z. B. Präfix-Codes ALT 1 oder ALT 2) decodiert werden. Z. B. wird, wie innerhalb der Programmsteuerungs- Flagdetektionslogik 543 gezeigt, dann, wenn ein ALT 1 Signal durch die Decodierungslogik 545 decodiert wird, ein ALT 1 PRE Signal erzeugt, wobei dieses Signal von der Programmsteuerungs-Flagdetektorlogik 543 ausgegeben wird und wobei dieses Signal wiederum an die Vorausschaulogik 531 über das ODER- Gatter 549 gekoppelt wird. Das ALT 1 PRE Signal setzt auch den ALT 1 Haltespeicher 547. Das ODER- Gatter 549 gibt auch das ALT 1 Signal von dem Haltespeicher 547 aus und koppelt das ALT 1 Signal an die Decodierungslogik 537, 539, 541 etc.
Die Vorausschau-Logik, die schematisch in Fig. 15 dargestellt ist, illustriert, wie 4 Registerwähl- Steuerbits XSEL0, XSEL1, XSEL2 und XSEL3 erzeugt werden. Diese 4 Steuerbits werden dann an die Multiplexer 620 und 622 gekoppelt, die im Zusammenhang mit der Registersteuerlogik 76 in Fig. 17 beschrieben wurden, die die Inhalte von einem der 16 Register wählt, um an den X-Bus zur Verwendung durch einen Befehl, der gerade ausgeführt wird, ausgegeben zu werden.
Somit wird ein Befehl, bevor er in den Pipeline-Haltespeicher 527 geladen wird, an das Vorausschau-Decodierungslogikelement 527 gekoppelt, das ein Registerwählbit XSEL-U0 erzeugt, welches wiederum in dem Haltespeicher 535 gehalten und dann als Signal XSEL0 ausgegeben wird. Der Haltespeicher 535 wird durch das Programmzählersignal PCEN aktiviert. In ähnlicher Weise erzeugt die Logikschaltung 531 XSEL_U1, welches in dem Haltespeicher 533 gehalten wird, das als Signal XSEL1 ausgegeben wird. Das ALT 1 PRE Signal wird an die verschiedenen Decodierungslogikschaltungen 529, 531 etc. in der Vorausschaulogik S51 gekoppelt und wird verwendet, um das geeignete Register zu definieren, das durch die Registersteuerlogik 76 gewählt wird. Z. B. ist das ALT 1 PRE Signal, wie in der Vorausschauschaltung 551 gezeigt, eines der Signale, die an die Logikschaltung 531 gekoppelt werden, die XSEL-U1 erzeugt, das in dem Haltespeicher 533 gehalten wird, der wiederum das Signal XSEL1 ausgibt.
Fig. 15B zeigt beispielhafte Timingsignale zum Demonstrieren des Betriebs der Vorausschaulogik 551. Die Fig. 15B zeigt ein Taktsignal CK und einen beispielhaften Befehlsoperationscode, der sich auf einen Datenzugriff des Cache-RAMs bezieht. Timingsignale sind ebenfalls gezeigt, die anzeigen, wann ein Pipeline-Haltespeicher 527 geladen wird, wenn eine Befehlsdecodierungsoperation ausgeführt werden soll, wenn Registerwählsignale erzeugt werden, und wenn eine Information von den Registern auf den Ziel-Z- Bus geladen werden.
Wie in Fig. 15B gezeigt, wird der Cache-RAM-Datenoperationscode (Operationscode 1) an irgendeinem Punkt zeitlich nach der Anstiegsflanke des Taktimpulses CK gültig. Der Operationscode (opcode) wird in dem Pipeline-Haltespeicher 527 bis beispielsweise zu der Anstiegsflanke des zweiten Taktimpulses gespeichert, wobei zu dieser Zeit der Operationscode 2 (opcode 2) in den Haltespeicher 527 hinein geladen wird. Der Befehlsdecoder 60 beginnt eine Decodierung des Befehls entsprechend zu dem Operationscode 1 unmittelbar nach Empfangen des Ausgangs von dem Haltespeicher 227 an einem Zeitpunkt, der schematisch in Fig. 18 dargestellt ist. Das Ergebnis der Befehlsdecodierung wird, wie voranstehend beschrieben, in geeigneter Weise Steuersignale an die Mario Chip Komponenten koppeln, beispielsweise an die ALU 50, den Cache-Controller 68 und die Plothardware 52 etc.
Die Vorausschauschaltung 551, die in Fig. 15 gezeigt ist, beginnt den Registerwähl- Decodierungsprozess durch Erzeugen eines Signals XSEL-U an einem Zeitpunkt vor der Decodierung des Operationscodes 2. Das XSEL-U0 Signal stellt den Ausgang der Decodierungslogik 529 dar, bevor er in dem Haltespeicher 535 gerade gehalten wird. Das XSEL-0-Signal wird beispielsweise von dem Haltespeicher 535 zu einem Zeitpunkt ausgegeben, so dass die Daten, die von dem Befehl benötigt werden, so früh wie möglich in dem Befehlsausführungszyklus zur Kopplung mit dem geeigneten Bus so schnell wie möglich erhältlich sind.
Ein Abschnitt der Registersteuerlogik 78 ist in Fig. 16 zum Erzeugen von Y- und Z-Bus-bezogene Registerwählsignale gezeigt. Der Multiplexer 604 wählt, welches der 16 Register von dem Z-Bus geschrieben werden. Der Multiplexer 606 wählt, welches Register eine Zuführung an den Y-Bus vornimmt.
Die Multiplexer 604 und 606 empfangen Eingänge von 4-Bit Registern 600 bzw. 602. Die Register 600 und 602 werden beim Implementieren der "FROM" und "TO" Präfix-Befehlen, die voranstehend beschrieben wurden, verwendet. Die Register 600 und 602 werden jeweils durch die Decodierung von "TO" und "FROM" Präfixen aktiviert, die arbeiten, um die niedrigstwertigsten Bits des Befehlsbusses an Register 600 und 602 zu koppeln. Die Register 600 und 602 werden im Ansprechen auf einen Befehl gelöscht, der dazu dient, um die voranstehend beschriebenen Steuerflags zurückzusetzen.
Die Multiplexer 604 und 606 empfangen zusätzlich Eingänge von verschiedenen Registern in dem Registerblock 76. Zusätzlich empfangen die Multiplexer 604, 606 einen Ausgang von den niedrigstwertigsten Bits auf dem Befehlsbus, um Befehle zu implementieren, deren niedrigstwertigste vier Bits das Befehlsziel- oder Quellenregister definieren. Zusätzlich werden vorgegebene niedrigstwertigste Bits von dem Super NES Adressenbus an die Multiplexer 604 und 606 gekoppelt, um das Super NES mit einem Zugriff auf den Registersatz zu versehen. Die Multiplexer 604 und 606 wählen das Register, das den Z- bzw. Y-Bus füttert.
Fig. 17 zeigt einen Registerblock 76 und eine zusätzliche Registerwähl-Steuerlogik, die innerhalb der Registersteuerlogik 78 der Fig. 4B verkörpert ist. Ein FROMX Register 618 wird durch ein FROMSET Signal, welches auf die Decodierung eines FROM-Befehls hin erzeugt wird, gesetzt. Auf einen Empfang des FROMSET-Signals hin werden die Inhalte des Y-Busses in das Register 618 hinein geladen. Die Daten, die in das Register 618 geladen werden, werden dann die Daten, die bei der nachfolgenden Befehlsausführung verwendet werden. Die Inhalte des Registers 618 werden als einer der Eingänge an den Multiplexer 622 gekoppelt. Der Multiplexer 622 empfängt auch die Inhalte des Registers R0 (welches als ein Voreinstellungsregister verwendet wird) als einen seiner Eingänge.
Ein anderer Eingang zu dem Multiplexer 622 ist der Ausgang des Multiplexers 620. Der Multiplexer 620 empfängt als Eingang die Inhalte des Programmzählers (d. h. des Registers R15), Eingänge von den Registern, die beim Ausführen des MERGE-Befehls verwendet werden, und des Registers R1 (das z. B. beim Ausführen des Plotbefehls verwendet wird). Der Multiplexer 620 wählt einen von diesen Eingängen auf Grundlage des Zustands der XSEL2 und XSEL3 Bits, die von der Vorausschaulogik 551 erzeugt werden, die in Fig. 15A gezeigt ist.
Ein zusätzlicher Eingang zu dem Multiplexer 622 ist mit den Inhalten des Y-Busses gekoppelt, um die gleichen Daten auf den X-Bus zu bringen, wie auf dem Y-Bus sind. Wie voranstehend angegeben, ist ein anderer Eingang zu dem Multiplexer 622 der Ausgang des FROM X Registers 618, welches voranstehend beschrieben wurde. Der Ausgang des Multiplexers 622 wird auf Grundlage des Zustands der XSEL0 und XSEL1 Bits gewählt, die in Fig. 15A erzeugt werden, und wird an den X-Bus gekoppelt.
Die Spezialzweckfunktionen, die zu vielen der Register R0-R15 gehören, sind ausführlich voranstehend beschrieben worden und werden hier nicht wiederholt. Die Ausgänge der Register R0-R3 werden an den Multiplexer 608 gekoppelt, die Ausgänge der Register R4-R7 werden an den Multiplexer 610 gekoppelt, die Ausgänge der Register R8-R11 werden an den Multiplexer 612 gekoppelt und die Ausgänge der Register R12-R15 werden an den Multiplexer 614 gekoppelt. Einer der vier jeweiligen Eingänge zu den Multiplexem 608, 610, 612 und 614 werden von den Y SEL 1 und Y SEL 0 Bits gewählt, die von dem Multiplexer 606 ausgegeben werden, der in Fig. 16 gezeigt ist. Die Ausgänge von dem Multiplexer 608, 610, 612 und 614 werden wiederum dem Multiplexer 616 eingegeben. Einer der vier Eingänge an dem Multiplexer 616 wird auf Grundlage des Zustands der Y SEL 2 und Y SEL 3 Bits gewählt, die von dem Multiplexer 606 in Fig. 16 ausgegeben werden. Der Ausgang des Multiplexers 616 ist mit dem Pufferregister 617 gekoppelt, dessen Ausgang wiederum mit dem Y-Bus gekoppelt ist.
Bezug nehmend auf die Eingänge zu den Registern R0 bis R15 weist jedes Register einen Aktivierungseingang auf, der durch ZSEL Bits 0 bis 3 gewählt wird, die wie voranstehend im. Zusammenhang mit Fig. 16 beschrieben, erzeugt werden. Jedes Register weist auch einen Takteingang CK und einen Dateneingang DATA IN auf, über den Daten von dem Z-Bus empfangen werden, nachdem sie geeignet gepuffert sind.
Das Register R4, welches im Zusammenhang mit verschiedenen Multiplizierungsoperationen verwendet wird, umfasst auch Niedrig-Deaktivierungs- und Hoch-Deaktivierungs-Biteingänge und Niedrig- Aktivierungs- und Hoch-Aktivierungs-Biteingänge auf. Das Register R15, der Programmzähler PC, empfängt ein Signal CCHLD von dem Cache-Lader 400 in dem ROM-Controller der Fig. 13, der eine Sprungoperation sperrt, bis das gegenwärtige 16-Byte Cache-Segment in das Cache-RAM geladen ist. Der Programmzähler empfängt zusätzlich ein. Programmschleifen-Anstehungssignal LOOPEN von dem Befehlsdecoder, das anzeigt, dass eine Verzweigungsoperation stattfinden sollte, und aktiviert das Laden des PC mit den Inhalten des Registers R13. Das Register R15 empfängt zusätzlich ein Einschalt- Rücksetzsignal RESET und einen Eingang RN, der den Programmzähler mit den Inhalten des Registers R13 lädt, wenn ein Schleifenbefehl gerade ausgeführt, wird.
Wie voranstehend angezeigt, kann der Grafikcodeprozessor der vorliegenden Erfindung in Kombination mit dem Host-Videospielesystem in vorteilhafter Weise verwendet werden, um eine Vielfalt von Spezialeffekten zu erzeugen, die z. B. die Drehung, Vergrößerung und/oder Verkleinerung von Polygon-gestützten Objekten beinhalten. Fig. 18 ist ein Flussdiagramm eines beispielhaften Mario Chip Programms zum Zeichnen eines Trapezoids, um darzustellen, wie der Mario Chip programmiert werden kann, um einen Abschnitt eines Polygon-gestützten Objekts, welches angezeigt werden soll, zu erzeugen. Ein Mario Programm zum Erzeugen eines derartigen Polygons wird nachstehend zusammen mit einer ausführlichen Erläuterung davon, wie die Mario Hardware das Programm ausführt, aufgeführt.
Zunächst Bezug nehmend auf das Hochebenen-Flussdiagramm (High Level Flussdiagramm), welches in Fig. 18 gezeigt ist, werden zu Anfang bestimmte Register in dem Registerblock R1 bis R15 mit Variablen assoziiert, die bei der Erzeugung des Trapezoids verwendet werden (z. B. ein Register R1 speichert die Pixel-X-Position, ein Register R2 speichert die Pixel-Y-Positionslinie, und ein Register R7 speichert die Trapezoidhöhe, etc.). Danach, wie im Block 650 angezeigt, wird ein Schleifenzähler eingerichtet und anfängliche Pixelwerte werden berechnet.
Wie in Block 652 angezeigt, wird dann eine Überprüfung durchgeführt, um die Länge von einer der Trapezoid-Horizontallinien zu bestimmen. Wenn das Ergebnis einer Subtraktion des Startpunkts der Linie von dem Endpunkt der Linien ein negativer Wert (-VE) ist, dann verzweigt sich die Routine zum Block 660. Wenn das Ergebnis einer Subtraktion des Startpunkts der Linie von dem Endpunkt der Linie ein positiver Wert ist, was anzeigt, dass die Länge der Linie nicht überschritten worden ist, dann wird ein Schleifenzähler dekrementiert (654) und ein Plotpixelbefehl wird ausgeführt, um zu dem Plotten des geeigneten Pixels zu führen (656).
Wie im Block 658 angezeigt, wird dann eine Überprüfung durchgeführt, um zu bestimmen, ob die Inhalte des Schleifenzählers null sind. Wenn der Schleifenzähler nicht null ist, dann wird ein Sprung bewirkt, um eine Verzweigung zurück zu dem Block 654 auszuführen, um den Schleifenzähler zu dekrementieren (654) und ein anderes Pixel zu plotten (656).
Wenn der Schleifenzähler gleich zu null ist, dann werden die X-Koordinate der linken Polygonseite und die X-Koordinate der rechten Polygonseite aktualisiert (660). Danach wird die Y HEIGHT (HÖHE) des Trapezoids (662) dekrementiert (662) und wenn das Ergebnis nicht null ist, dann wird die Routine erneut ausgeführt, indem eine Verzweigung zurück zu einem Block 650 durchgeführt wird (664) und die Y-Koordinate inkrementiert wird, um so eine Bewegung zu der nächsten Scanlinie vorzunehmen (665). Wenn die Y HEIGHT gleich zu null ist, dann wird die Routine vollständig ausgeführt worden sein und das Trapezoid wird fertig gestellt sein (666).
Um die Verwendung des Mario Chip Befehlssatzes zum Erzeugen von Grafiken darzustellen, wird ein beispielhaftes Programm zum Zeichnen eines Trapezoids zur Implementierung des Flussdiagramms der Fig. 1B nachstehend aufgeführt.
Um zu demonstrieren, wie die Mario Chip Hardware arbeitet, um ein Programm auszuführen, richtet sich die folgende Erläuterung auf das voranstehend aufgeführte Trapezoid-Erzeugungsprogramm. Vor der Ausführung des Trapezoid-Erzeugungsprogramms schreibt das Host-Computersystem, z. B. das Super NES, direkt an das Gode-Bankregister und in das Bildschirm-Basisregister hinein, wie im Zusammenhang mit der Beschreibung des Flussdiagramms der Fig. 5 voranstehend erläutert wurde. Zusätzlich schreibt das Super NES das untere Byte der XEQ-Adresse an ein lokales Register in dem ROM- Controller 104, die von dem Adressenbus HA des Super NES decodiert wird. Das Super NES schreibt dann ein hohes Byte an den ROM-Controller 104, welches mit den Inhalten des lokalen Registers kombiniert und an den Z-Bus gekoppelt wird. Danach ist das Register R15, welches als der Mario Chip Programmzähler arbeitet, aktiviert.
Auf ein Erfassen der hinteren Kante des voranstehenden Super NES Schreibbetriebs an den ROM- Controller 104 wird das Mario "GO" Flag gesetzt. Wenn der Programmzähler minus dem Cache- Basisregister größer als die Cache-Größe ist oder wenn das Cache-Flag mal dem Programmzähler minus dem Cache-Basisregister geteilt durch 16 gleich zu null ist, dann werden die Programmzählerinhalte an das ROM 10 übergeben und der ROM-Timingzähler (Fig. 13, Block 406) wird gestartet.
Zu Anfang, vor der Ausführung des Trapezoid-Zeichenunterprogramms, werden die Variablen, die mit dem Trapezoid-Schleifenprogramm verwendet werden, mit Super Mario Registern assoziiert, wie in dem anfänglichen Abschnitt der Trapezoid-Programmauflistung angezeigt, z. B. "rx", die die "Plot-X- Position" ist, soll mit dem Register R1 assoziiert werden und die Variable "rloop" wird mit dem Register R13 assoziiert.
Nachdem diese Registerzuweisungen durchgeführt sind, beginnt die Ausführung des Trapezoidprogramms wie folgt. Wenn der ROM-Timingzähler 406 in dem ROM-Controller 104 einen Zählwert von 5 (ungefähr 200 Nanosekunden) erreicht, wird der erste auszuführende Befehl ("IWT rloop, hlines 2" in das Pipeline-Register 62, welches in Fig. 4A gezeigt ist, hinein verriegelt, und zwar von dem ROM-Datenbus. Die Daten werden gleichzeitig in das Cache-RAM 94 geschrieben. Beim Ausführen des Befehls "IWT rloop, hlines", wird der Programmzähler inkrementiert. Die "IL" und "IM" Flags werden gesetzt, um anzuzeigen, dass die folgenden zwei Bytes in dem Befehlsstrom sofortige Daten (Sofortdaten) sind. Wenn der ROM-Timingzähler 406 5 erreicht, dann werden die sofortigen Daten (unteres Byte) an das Cache-RAM 94 geschrieben und in einem vorübergehenden Register in dem ROM-Controller 104 gehalten. Der ROM-Holmechanismus wird wiederholt und das hohe Byte der sofortigen Daten wird mit dem unteren Byte kombiniert und an den Z-Bus geleitet. Das Register R13 wird aktiviert und die Z-Bus-Inhalte werden darin gespeichert, um den Schleifenzähler zu setzen. Von diesem Punkt an in der Routine wird jeder Befehl aus dem Speicher geholt, bis der Schleifenbefehl angetroffen wird.
Beim Ausführen des Befehls FROM RX1 ", werden die untersten vier Bits des Befehlscodes in das vier Bit "FROM Y" Register 602 in dem Register-Controller (siehe Fig. 16) geladen. Zusätzlich werden die Daten von RX1 (dem Register R3) auf dem Y-Bus aktiviert und in dem 16-Bit "FROM X"-Register 618 gespeichert. Beim Ausführen des "TO RX"-Befehls, werden die untersten vier Bits des Befehlscodes in das vier Bit "Enable Z" ("Z Aktivieren") Register 600 in dem Registercontroller geladen (siehe Fig. 16).
Der "HIB"-Befehl wird ausgeführt, indem die sechzehn Bit Inhalte des "FROM X"-Registers auf den X-Bus gelegt werden. Die ALU platziert das obere Byte des X-Busses auf das untere Byte des Z- Busses und setzt das obere Byte des Z-Busses auf null. Dies entfernt den bruchteilsartigen Teil der X- Position und belässt den Startpunkt für die erste horizontale Linie in dem Register RX (Register R1).
Beim Ausführen des Befehls "FROM RX2" werden ähnliche Operationen ausgeführt, wie voranstehend beim Ausführen des "FROM RX1"-Befehls angedeutet. Der "HIB"-Befehl verursacht Operationen (ähnlich wie die voranstehend beschriebenen) in Bezug auf die obere rechte X-Koordinate des Trapezoids, wobei der Endpunkt der ersten horizontalen Linie in dem Register R0 (dem Voreinstellungs- Register, welches als der Akkumulator arbeitet) belassen wird.
Der "RLEN"-Befehl und der "SUB RX"-Befehl werden durch Subtrahieren des Starts der Linie von dem Ende der Linie RLEN (R12) = R0 - Rx ausgeführt. Das Vorzeichen-Flag wird gesetzt werden, wenn ein negatives Ergebnis vorhanden ist, um eine Fehlerbedingung anzuzeigen.
Der "BMI HLINES 3"-Befehl ist ein Befehl mit zwei Bytes, wobei das erste Byte ein Flag setzt, wenn das Vorzeichen-Flag gesetzt ist. Das zweite Byte ist der Verzweigungs-Versatz (wobei R15 R15 plus dem Befehl gleicht), wenn das konditionale Flag gesetzt ist. Wenn nicht, bleibt R15 unverändert und die normale Programmausführung wird fortgesetzt.
Der "INC RLEN"-Befehl wird ausgeführt, so dass das Linienlängenregister eins dazu addiert hat, um sicherzustellen, dass wenigstens ein Pixel geplottet wird. Der "LOOP" ("SCHLEIFEN") Befehl arbeitet, um die Berechnung von R12 = R12 - 1 zu verursachen. Wenn R12 nicht null ist, dann wird R15 (der Programmzähler) mit den Inhalten von R13 geladen, um dadurch einen Sprung zu bewirken.
Wenn das Programm an diesem Punkt in dem Bereich des Cache-RAM 94 ist, dann wird die Cache-Ladeschaltung 400 den Sprung erfassen und wird das Laden des Cache-RAM 94 fortsetzen, wobei eine Ausführung aufgehoben wird, wenn sie dies so tut. Wenn dies abgeschlossen ist, ist der Programmzähler mit seinem neuen Wert geladen und des folgende Befehl wird aus dem Cache-RAM 94 geholt.
Um den "PLOT"-Befehl auszuführen, bildet das Schleifen/Plot-Befehlspaar einen Zeichenalgorithmus für die horizontale Linie. Der "PLOT"-Befehl wird den Bildschirmpixel, der von R1, R2 (als X- und Y-Koordinaten) adressiert wird, auf die Farbe setzen, die in dem "COLOR-Register" 54 gesetzt ist, die in Fig. 4A gezeigt ist. Die Adresse des Zeichens, das den Pixel enthält, wird von der Plot- Hardware 52 berechnet. Die neuen Pixeldaten werden in einem Zeichenlinienpuffer (der Farbmatrix) gehalten, bis sich der Mario Chip auf ein Plotten an einer anderen Zeichenposition bewegt. Wenn sämtliche Farbinformation in die zweite Ebene des Doppelpuffermechanismus innerhalb der Farbmatrix kopiert ist, dann wird die Information an das externe RAM geschrieben.
Die "WITH RX1" und "ADD RX1 INC" Befehle werden ausgeführt, um die linksseitige X- Koordinate des Trapezoids zu aktualisieren. In ähnlicher Weise arbeitet der "WITH RX2" und der "ADD RX2 INC" zum Aktualisieren der rechten Seite des Trapezoids. Die "DEC RDY, BNE, Hlines 1" und "INC RY" Befehle arbeiten, um sich weiter zu der nächsten Y-Position (der nächsten Scanlinie) zu bewegen, bis das Trapezoid fertig gestellt ist.
Die folgende Programmauflistung stellt beispielhaft dar, wie der Mario Chip programmiert werden kann, um ein Feld aus 8-Bit X, Y und Z Punkten zu drehen. Diese Routine stellt eine Programmierung für den Grafikprozessor in Übereinstimmung mit einer beispielhaften Ausführungsform der vorliegenden Erfindung zum Ausführen von Drehoperationen dar. Die Auflistung für diese Routine wird nachstehend aufgeführt. AUFLISTUNG DREHEN:
Die Fig. 19, 20 und 21 stellen beispielhaft einige der Spezialeffekte dar, die erzeugt werden können, während der programmierbare Grafik-Coprozessor der vorliegenden Erfindung in Kombination mit

Claims

1. Externes Speichersystem für ein Informationsverarbeitungssystem mit einer Host- Verarbeitungssystemeinheit zum Ausführen eines Videografikprogramms, das wenigstens teilweise in dem externen Speichersystem gespeichert ist, wobei das externe Speichersystem wenigstens einen Verbinder (1) zum Koppeln des externen Speichersystems mit dem Host-Verarbeitungssystem, einem Programmspeicher (10), der einen ersten Satz von Programmbefehlen des Videografikprogramms für eine Ausführung durch das Host-Verarbeitungssystems und einen zweiten Satz von Befehlen des Videografikprogramms speichert; und einen Grafikprozessor (2), der mit dem externen Programmspeicher (IO) gekoppelt und bei der Verwendung mit dem Host-Verarbeitungssystem (20) über den wenigstens einen Verbindet (1) gekoppelt ist, zum Ausführen des zweiten Satzes von Befehlen.

2. Externes Speichersystem nach Anspruch 1, wobei die Host-Verarbeitungseinheit (20) eine Videospielesystem-Hauptverarbeitungseinheit ist und das externe Speichersystem innerhalb einer Videospielekartusche (19) verkörpert wird.

3. Externes Speichersystem nach Anspruch 1 oder 2, ferner umfassend einen externen Speicherbus, der mit dem externen Programmspeicher (10) und dem Grafikprozessor (2) zum Übertragen einer Adressen- Daten- und Steuerinformation gekoppelt ist; eine Speichereinheit (6, 8) mit wahlfreiem Zugriff, einen Bus für die Speichereinheit mit wahlfreiem Zugriff, der mit der Speichereinheit (6, 8) mit wahlfreiem Zugriff und dem Grafikprozessor (2) gekoppelt ist, zum Übertragen von Adressen-, Daten- und Steuerinformation; und einen Host-Verarbeitungseinheit-Bus zum Übertragen von Adressen-, Daten- und Steuerinformation zwischen dem Grafikprozessor und der Host-Verarbeitungseinheit.

4. Externes Speichersystem nach Anspruch 3, wobei der Grafikprozessor eine Einrichtung zum Steuern eines Zugriffs auf den Bus des externen Speichers und/oder den Bus (131) der Speichereinheit mit wahlfreiem Zugriff

5. Externes Speichersystem nach irgendeinem vorangehenden Anspruch, wobei der Grafikprozessor (2) eine Einrichtung zum Empfangen von Adresseninformation (HA, 133) von der Host- Verarbeitungseinheit zum Identifizieren des externen Speicherorts, der einen Befehl speichert, der von dem Grafikprozessor ausgeführt werden soll, einschließt.

6. Externe Speichereinheit nach Anspruch 5, wobei die Einrichtung zum Empfangen von Adresseninformation ein externes Speicherbankregister zum Empfangen von Adresseninformation, die eine externe Speicherbank identifiziert, und einen Programmzähler zum Identifizieren eines Orts innerhalb der Speicherbank einschließt.

7. Externes Speichersystem nach irgendeinem vorangehenden Anspruch, wobei der Grafikprozessor eine Arithmetik- und Logikeinheit (50) zum Ausführen von wenigstens einigen des zweiten Satzes von Befehlen, die in dem externen Speicher gespeichert sind, und eine Plot-Schaltung (52) zum Ausführen wenigstens eines anzeigebezogenen Befehls, der in dem externen Speicher gespeichert ist, einschließt.

8. Externes Speichersystem nach Anspruch 7, ferner einschließend einen ersten Datenquellenbus (X), einen zweiten Datenquellenbus (Y) und einen Datenzielstellenbus (Z), wobei jeder der Busse mit der Arithmetik- und Logikeinheit (50) und der Plot-Schaltung (52) gekoppelt sind.

9. Externes Speichersystem nach irgendeinem vorangehenden Anspruch, wobei der Grafikprozessor ferner einen Cache-Controller (68) und einen Cache-Speicher (94), der mit dem Cache-Controller (68) gekoppelt ist, einschließt, wobei der Grafikprozessor eine Einrichtung zum Ausfuhren von Befehlen, die in dem Cache-Speicher (95, 60, 50) gespeichert sind, einschließt.

10. Externes Speichersystem nach irgendeinem vorangehenden Anspruch, wobei der Grafikprozessor eine Vielzahl von Registern (76) einschließt, wobei der Grafikprozessor ferner eine Einrichtung, die auf den Zugriff auf ein vorgegebenes der Vielzahl von Registern (R14) anspricht, zum automatischen Initiieren eines Hohlbetriebs (104) des externen Speichers einschließt:

11. Externes Speichersystem nach irgendeinem vorangehenden Anspruch, wobei der externe Programmspeicher (10) ein Programm-Nur-Lese-Speicher (ROM) ist und ferner einschließend einen Speicher (RAM) mit wahlfreiem Zugriff, der mit dem Grafikprozessor gekoppelt ist.

12. Externes Speichersystem nach irgendeinem vorangehenden Anspruch, wobei der Grafikprozessor und die Host-Verarbeitungseinheit betreibbar sind, um Befehle parallel auszuführen.

13. Externes Speichersystem nach irgendeinem vorangehenden Anspruch, wobei der Grafikprozessor eine Einrichtung für eine Pipeline-Verarbeitung von Befehlen, die gerade ausgeführt werden (62, 60), einschließt.

14. Externes Speichersystem nach irgendeinem vorangehenden Anspruch, wobei der Grafikprozessor eine Einrichtung zum Dekodieren (60) des zweiten Satzes von Befehlen und eine Vorausschaueinrichtung (551) zum Verarbeiten von Betriebscodes, bevor der zugehörige Befehl decodiert wird, einschließt.

15. Externes Speichersystem nach irgendeinem vorangehenden Anspruch, wobei das Informationsverarbeitungssystem (20) eine Anzeige (36) zum Anzeigen eines Objekts einschließt und wobei der zweite Satz von Befehlen Befehle zum Drehen des Objekts einschließt, wobei der Grafikprozessor eine Einrichtung zum Ausführen der Befehle zum Drehen des Objekts einschließt.

16. Externes Speichersystem nach Anspruch 15, wobei die Einrichtung zum Ausführen der Befehle eine Plot-Schaltungsanordnung (52) zum Umwandeln von Pixel-gestützten Formatdaten in Zeichengestützte Formatdaten einschließt.

17. Externes Speichersystem nach irgendeinem vorangehenden Anspruch, wobei der Grafikprozessor eine Statusregistereinrichtung zum Speichern einer Vielzahl von Grafikprozessor-Statusanzeigen einschließlich einer Anzeige, dass der Grafikprozessor gegenwärtig in Betrieb ist, und einer Anzeige, dass der Grafikprozessor ein Unterbrechungssignal an die erste Verarbeitungseinheit gesendet hat, einschließt.

18. Externes Speichersystem nach Anspruch 17, ferner umfassend eine Einrichtung zum Ausführen wenigstens eines Befehls (50); einen Befehlsdecoder (62), der auf den Zustand von wenigstens einer der Statusanzeigen anspricht, um zu bewirken, dass der wenigstens eine vorgegebene Befehl die Einrichtung zum Ausführen steuert, um einen ersten Betrieb zu initiieren, wenn das Statusregister ein Zustand ist, und um zu bewirken, dass die. Einrichtung zum Ausführen einen zweiten Betrieb initiiert, wenn das Statusregister in einem zweiten Zustand ist.

19. Externes Speichersystem nach irgendeinem vorangehenden Anspruch, umfassend einen zusätzlichen Speicher (6, 8), der mit dem Grafikprozessor (2) gekoppelt ist, wobei der Grafikprozessor einschließt: einen Programmspeicher-Controller (104) zum Steuern eines Zugriffs auf den Programmspeicher; und einen zusätzlichen Speicher-Controller (88) zum Steuern eines Zugriffs auf den zusätzlichen Speicher.

20. Externes Speichersystem nach Anspruch 19, wobei der zusätzliche Controller (88) eine Einrichtung zum Bestimmen einer Priorität zwischen einer Vielzahl von empfangenen Aufforderungen für einen Zugriff auf den zusätzlichen Speicher einschließt.

21. Externes Speichersystem nach Anspruch 20, ferner umfassend eine Plot-Schaltungsanordnung (52), und wobei der zusätzliche Speicher-Controller (88) ein Plot-Aufforderungssignal, das anzeigt, das ein Speicherzugriff für einen Plot-Betrieb, der gerade ausgeführt wird, benötigt wird, empfängt.

22. Videospielesystem (19, 20) zur Verwendung mit einer Anzeige (36) eines Fernsehtyps, umfassend:

einen Spiele-Mikroprozessor (22) zum Ausführen von Befehlen eines Videospieleprogramms, und eine Bildverarbeitungseinheit (24), die mit dem Spiele-Mikroprozessor zum Ausführen von Bildverarbeitungsaufgaben unter der Steuerung des Spiele-Mikroprozessors (22) gekoppelt ist; und ein

externes Speichersystem in Übereinstimmung mit irgendeinem vorangehenden Anspruch zum Speichern des Videospieleprogramms und zum Ausführen von wenigstens einigen der Videospiele-Programmbefehle;

und einen programmierbaren Grafikprozessor (2), der mit dem externen Programmspeicher gekoppelt und in der Verwendung mit dem Spiele-Mikroprozessor (22) verbunden ist.