DE3718501A1 - Videoanzeigegeraet - Google Patents

Description

Die Erfindung bezieht sich auf Videoanzeigegerät und insbeson­ dere auf die Verarbeitung von Daten zur Erzeugung von Videosi­ gnalen.

Es gibt zahlreiche kommerzielle Systeme und viele andere, in Druckschriften beschriebene Systeme zur Bildung einer Schnitt­ stelle zwischen einem digitalen Computer und einer Videoanzei­ ge mit Rasterabtastung. Die Umsetzung von digitalen Computer­ informationen in die von einer konventionellen CRT mit Raster­ abtastung benutzten Pixeldaten bedingt erhebliche Datenverar­ beitung, insbesondere für eine komplexe Farbgraphik. Bei vie­ len Personalcomputern wird ein beträchtlicher Teil der Zeit des Mikroprozessors für die Verarbeitung von Daten gerade für diesen Zweck aufgewandt, da typischerweise eine enorme Daten­ menge zur Erzeugung jedes Rahmens bewegt wird. Der Umfang dieses Problems läßt sich durch die Tatsache verständlich machen, daß mit derzeitigen Methoden zur Erzeugung einer Gra­ phikanzeige mit der Qualität von beispielsweise einem 35-mm- Film eine Rechenleistung nötig ist, die weit über diejenige derzeitiger Mikroprozessoren und tatsächlich über diejenige vieler Minicomputer und mittleren EDVA′s bei sinnvoller Dia­ logdarstellung hinausgeht.

Es wurden erhebliche Anstrengungen auf die Entwicklung von Schaltungen gerichtet, die unter Verwendung von Spezialschal­ tungen, "Graphikmaschinen" o.dgl. ohne zusätzliche Belastungen der Computer-Zentraleinheit zu verbesserten Anzeigen führen. Die Erfindung fällt in diese Kategorie, indem sie eine Gra­ phikmaschine schafft, welche, wenn auch unter der allgemeinen Kontrolle einer CPU, die Pixeldaten im wesentlichen unabhängig von der CPU erzeugt.

In vielen derzeitigen Graphiksystemen wird ein Bit-Abbildungs­ speicher (z.B. ein Rahmenpuffer) zur Speicherung der Pixelda­ ten vor deren Wiedergabe verwendet. Die Daten innerhalb dieser Speicher werden für jeden Rahmen häufig unter Steuerung der CPU bewegt. In einigen Fällen werden die Pixeldaten innerhalb des Rahmenpuffers zusammengesetzt, und die Daten können bei­ spielsweise einige Male in dieselben Plätze eingeschrieben werden, um die endgültigen Pixeldaten zu gewinnen. Ein typi­ scher Rahmenpuffer wird in Verbindung mit Fig. 2b beschrie­ ben, und der Unterschied zwischen dieser bekannten Speicher­ technik und der Erfindung wird anhand der Fig. 2c erläutert.

Generell stellt die Erfindung eine verbesserte Graphikanzeige zur Verfügung, indem sie von einer zusätzlichen Speicherkapa­ zität statt einer Verarbeitungsgeschwindigkeit Gebrauch macht. Es kann davon ausgegangen werden, daß diese Lösung mit zuneh­ mender Verringerung der Speicherkosten wesentlich ökonomischer als eine Erhöhung der Prozeßgeschwindigkeit ist. Tatsächlich haben die Kosten der Speicherkapazität, ausgedrückt in Wäh­ rungseinheiten pro Bit, in den letzten Jahren wesentlich stär­ ker und mit einer wesentlich stärkeren Rate abgenommen als die Geschwindigkeit von Mikroprozessoren oder die Kosten zur Er­ zielung einer rascheren Verarbeitung.

Die Erfindung bezieht sich auf eine Videoanzeigeeinrichtung zur Gewinnung von Pixeldaten für eine CRT-Anzeige o.dgl. Ein erster Speicher dient zur Speicherung derjenigen Daten, die für eine Vielzahl von anzuzeigenden Objekten repräsentativ sind. Die Daten für jedes Objekt werden in zusammenhängend zugreifbaren Plätzen in diesen ersten Speicher gespeichert. Es gibt eine willkürliche Beantragung (petitioning) in diesem ersten Speicher für jedes der Objekte, d.h. ein Objekt kann in einer anderen Anzahl von Plätzen als ein anderes Objekt ge­ speichert werden. Ein zweiter Speicher, der in den ersten Speicher einbezogen sein kann, dient zur Speicherung von At­ tributen für jedes der Objekte. Diese Attribute können Infor­ mationen wie die Bildschirmlage, die Objektpriorität (vom Hintergrund zum Vordergrund), die Objektlage in dem ersten Speicher, die Darstellungsfeld-Begrenzung und einen Befehl für die erste Anzeigezeile dieses Objekts enthalten. In der der­ zeit bevorzugten Ausführungsform sind die ersten und zweiten Speicher in einem Speicher vereinigt. Dieser Einzelspeicher hat duale Datenports, von denen einer serielle Wörter an den Puffer liefert und der andere Daten aus einer CPU aufnimmt.

Ein Zeilenpuffer dient zum Zusammensetzen jeder Zeile von Videodaten. In der bevorzugten Ausführungsform werden Doppel­ zeilenpuffer zur Erzeugung eines kontinuierlichen Stroms von Videopixeldaten verwendet.

Eine erste Steuereinrichtung (Verteiler-dispatcher) erhält die Attribute aus dem zweiten Speicher und steuert den Zugriff zu den Daten im ersten Speicher. Eine zweite Steuereinrichtung (Zeilenpuffersteuergerät) steuert das Laden der Daten in den Zeilenpuffer. In einigen Fällen werden Befehle in den ersten Speicher zusammen mit den Daten gespeichert, und sowohl das erste als auch das zweite Steuergerät sprechen auf diese Be­ fehle an.

Generell wird im Betrieb eine Datenzeile für jedes Bit in den Zeilenpuffer zur Entwicklung einer Zeile von Pixeldaten für die Anzeige eingelesen.

Der Puffer selbst ist in eine Vielzahl von Zellen in solcher Weise organisitiert, daß Daten mit einer höheren Geschwindig­ keit beispielsweise bei einem Bit pro Pixel übertragen werden können, im Vergleich zu einem Fall, wo mehrere Bits zur Defi­ nition eines einzelnen Pixels verwendet werden. Die Daten im Zeilenpuffer können für jedes Pixel unterschiedliche Typen von Pixeldaten darstellen, beispielsweise RGB-Daten oder einen Index in einer Farb-Nachschlagetabelle. Darüber hinaus sorgt der Zeilenpuffer für eine Maskierung, wobei die Anzeige will­ kürlich geformter Objekte ermöglicht wird.

Andere Aspekte der Erfindung und ihre Operationsweise werden im folgenden anhand der Zeichnung näher erläutert. In der Zeichnung zeigen:

Fig. 1a eine perspektivische Schemadarstellung eini­ ger für die Anzeige vorgesehener Objekte und deren relative Priorität, d.h. deren Lage vom Hintergrund zum Vordergrund;

Fig. 1b eine CRT-Bildschirmanzeige der Objekte gemäß Fig. 1a;

Fig. 2a einige Objekte auf einer CRT-Anzeige, für die vorliegende Beschreibung verwendet in Verbindung mit den Fig. 2b und 2c;

Fig. 2b ein Diagramm zur Veranschaulichung der Art und Weise, in der die auf dem Display gemäß Fig. 2a gezeigten Objekte in einem bekann­ ten Rahmenpuffer gespeichert werden;

Fig. 2c ein Diagramm zur Beschreibung derjenigen Art, in der die zur Anzeige der Objekte gemäß Fig. 2a benötigten Daten erfindungs­ gemäß im Speicher gespeichert werden; diese Figur zeigt auch den Inhalt einer typischen Objekt-Abfertigungstabelle;

Fig. 3 ein Diagramm zur Darstellung der Speicherung von Konfigurationsdaten, Abfertigungstabel­ lendaten und Objektdaten;

Fig. 4 ein Diagramm zur Veranschaulichung der Be­ ziehung im Speicher zwischen der Objekt-Ab­ fertigungstabelle und Objektdaten für die Objekte gemäß Fig. 3;

Fig. 5 ein Blockdiagramm der erfindungsgemäßen Einrichtung, einschließlich eines optionel­ len Video-RAM-Puffers;

Fig. 6 ein Diagramm zur Darstellung der Zeilenpuf­ ferkonfiguration und typischer Zeileninhal­ te;

Fig. 7 ein Diagramm, das die Zellenarchitektur in dem Zeilenpuffer veranschaulicht;

Fig. 8 ein Diagramm, daß das Layout einer Einzel­ zelle und insbesondere für eine Speicherzel­ le Gruppen-Null veranschaulicht;

Fig. 9 ein Blockdiagramm des Zeilenpuffer-Steuerge­ räts;

Fig. 10 das bevorzugte Abfertigungstabellenformat;

Fig. 11 ein Blockdiagramm des Verteilers;

Fig. 12a eine Anzeige, die zum Beschreiben der Ar­ beitsweise der Erfindung beim Anzeigen einer rechteckigen Bit-Abbildung verwendet wird;

Fig. 12b ein Diagramm, das zur Darstellung der bei der Gewinnung der Anzeige gemäß Fig. 12a verwendeten Speicherung verwendet wird;

Fig. 13a stellt eine Anzeige dar und wird zum Be­ schreiben der Operationsweise der Erfindung für horizontales Positionieren verwendet;

Fig. 13b ist ein Diagramm, das zur Darstellung der für die Gewinnung der Anzeige gemäß Fig. 13a verwendeten Speicherung benutzt wird;

Fig. 14a eine Anzeige, die zur Beschreibung der Operationsweise der Erfindung für vertikales Positionieren benutzt wird;

Fig. 14b ein Diagram, das zur Darstellung der zur Gewinnung der Anzeige gemäß Fig. 14a ver­ wendeten Speicherung benutzt wird;

Fig. 15a eine Anzeige, die zur Beschreibung der Operationsweise der Erfindung für ein hori­ zontales Darstellungsfeld verwendet wird;

Fig. 15b ein Diagramm zur Darstellung der bei der Gewinnung der Anzeige gemäß Fig. 15a be­ nutzten Speicherung;

Fig. 16a eine Anzeige, die zur Beschreibung der Operationsweise der vorliegenden Erfindung bei der horizontalen Bildverschiebung be­ nutzt wird;

Fig. 16b ein Diagramm zur Darstellung der bei der Gewinnung der Anzeige gemäß Fig. 16a be­ nutzten Speicherung;

Fig. 17a eine Anzeige, die zur Beschreibung der Operationsweise der Erfindung für ein verti­ kales Darstellungsfeld benutzt wird;

Fig. 17b ein Diagramm zur Darstellung der bei der Anzeige gemäß Fig. 17a benutzten Speiche­ rung.

Fig. 18a eine Anzeige, die zur Beschreibung der Operationsweise der Erfindung für vertikale Bildverschiebung benutzt wird;

Fig. 18b ein Diagramm zur Darstellung der bei der Gewinnung der Anzeige gemäß Fig. 18a ver­ wendeten Speicherung;

Fig. 19a eine Anzeige zur Beschreibung der Opera­ tionsweise der Erfindung für ein abgegrenz­ tes Darstellungsfeld;

Fig. 19b ein Diagramm zur Darstellung der bei der Gewinnung der Anzeige gemäß Fig. 19a ver­ wendeten Speicherung;

Fig. 19c eine zusätzliche Darstellung einer Anzeige zur Beschreibung des abgegrenzten Darstel­ lungsfeldes gemäß Fig. 19a;

Fig. 20a eine Darstellung zur Beschreibung der Ope­ rationsweise der Erfindung für eine Maske innerhalb eines Feldes;

Fig. 20b ein Diagramm, das zur Darstellung der bei der Gewinnung der Anzeige gemäß Fig. 20a verwendeten Speicherung benutzt wird;

Fig. 20c ein zusätzliches Diagramm zur Beschreibung des eingebetteten Feldes gemäß Fig. 20a;

Fig. 21a eine Anzeige zur Beschreibung der Opera­ tionsweise der Erfindung für ein komplexes Objekt;

Fig. 21b ein Diagramm zur Darstellung der bei der Gewinnung der Anzeige gemäß Fig. 21a be­ nutzten Speicherung;

Fig. 21c ein zusätzliches Diagramm zur Beschreibung des komplexen Objekts gemäß Fig. 21a;

Fig. 21d ein Diagramm, das in Verbindung mit der Beschreibung der Speicherung des komplexen Objekts gemäß Fig. 21a, 21b und 21c be­ nutzt wird;

Fig. 22 ein Diagramm, das das bevorzugte Befehls­ wortformat zeigt;

Fig. 23 ein Diagramm, das die bevorzugte Bitabbil­ dung und sequentielle Datenwortdurchlauffor­ mate zeigt; und

Fig. 24 ein Zeitfolgediagramm, das zur Beschreibung der Operationsweise der Erfindung benutzt wird.

Beschrieben wird ein Videoanzeigegerät zur Lieferung von Pi­ xeldaten für eine Rasterabtastanzeige. In der folgenden Be­ schreibung werden zahlreiche besondere Einzelheiten, bei­ spielsweise spezielle Zahlen von Bits usw., angegeben, um das Verständnis für die Erfindung zu vertiefen. Es ist jedoch für den Fachmann klar, daß die Erfindung ohne diese besonderen Einzelheiten realisiert werden kann. In anderen Fälle werden bekannte Strukturen, z. B. Register, Prozessoren usw., nicht im einzelnen gezeigt, um die Erfindung nicht unnötig zu bela­ sten.

Überblick über den Display-Datenspeicher Organisation der Erfindung und Vergleich mit dem Stande der Technik

In Fig. 1b ist eine rasterabgetastete Kathodenstrahlröhrenan­ zeige 25 gezeigt, die mehrere Objekte oder Fenster, insbeson­ dere die Objekte 26, 27, 28 und 29 enthält. Jedes Objekt bringt verschiedene Daten zur Anzeige, beispielsweise Text, Farbe usw. Die Anzeige 25, die im folgenden "Display" genannt wird, ist mit ihren überlappenden Fenstern typisch für Dis­ plays, wie sie beispielsweise in einigen Personalcomputern, z.B. im MACINTOSH-Computer der Firma Apple Computer, Inc., benutzt werden. Das Display 25 stellt tatsächlich das dar, was ein Betrachter sehen würde, wenn jedes der Objekte aus der Ansicht des Benutzers eine Priorität (vom Vordergrund zum Hintergrund) erhält. Dies ist in Fig. 1a für die Objekte 26 . . . 29 gezeigt, die in unterschiedlichen und in der Z-Richtung beabstandeten Ebenen angeordnet sind. Das Display 25 kann daher so betrachtet werden, als bestehe es aus mehreren ge­ trennten Objekten, von denen jedem eine Priorität in der Z- Richtung zuerkannt worden ist und jedes einen Ursprung ent­ lang der X- und Y-Achsen hat. Wie zu sehen sein wird, ist die Erfindung besonders zweckmäßig bei der Erzeugung des Displays, beispielsweise des Displays 25, zusätzlich zu anderen Dis­ plays. In der folgenden Beschreibung wird aus Zweckmäßigkeits­ gründen unterstellt, daß die neue Einrichtung mit generell rechteckigen Objekten oder Fenstern arbeitet. (Die Lehre der Erfindung kann zur Bildung von Polygonen benutzt werden; bei­ spielsweise kann, wie an sich bekannt, eine Vielzahl dieser Polygone zur Bildung komplexer Bilder verwendet werden). Die Verwendung der beschriebenen Einrichtung zur Entwicklung kom­ plizierter Displays wird in Verbindung mit nachfolgenden Figu­ ren, beispielsweise den Fig. 21a, 21b, 21c und 21d be­ schrieben.

Bei bekannten Displays werden häufig Rahmenpuffer verwendet. Der Rahmenpuffer speichert die anzuzeigenden Daten in einer Eins-Zu-Eins "abgebildeten" Beziehung mit der Displayposition. Displaydaten werden für jedes Pixel gespeichert. Die Daten werden aus dem Rahmenpuffer in Rastern mit einer Geschwindig­ keit gelesen, die mit der horizontalen Synchronisationsge­ schwindigkeit der Kathodenstrahlröhre synchronisiert ist. Beispielsweise kann ein Rahmenpuffer 24 Speicherbits für jedes Pixel enthalten, wodurch ermöglicht wird, daß jede der Farben rot, grün und blau mit acht Bits dargestellt werden kann.

Ein Display 30 ähnlich dem Display 25 in Fig. 1b ist in Fig. 2a gezeigt. Eine Bilddarstellung der das Display 30 bildenden Objekte ist in einem typischen bekannten Rahmenpuffer 34 ge­ zeigt. Die Lagen der Objekte im Display entsprechen gemäß der Darstellung Plätzen im Rahmenpuffer, wie dies für die Objekte 31 und 33 deutlich gemacht ist.

Meistens enthält der Rahmenpuffer einen Speicher mit direktem Zugriff (RAM), der für jedes Pixel des Displays zugreifbar ist. Der RAM stellt Speicherraum für eine vorgegebene Anzahl von Bits für alle Pixel entsprechend der Farbtiefe (Anzahl von Bits pro Pixel) des tiefsten Fensters im Display zur Verfü­ gung.

Im folgenden wird auf Fig. 2c Bezug genommen, bei der ein RAM, der bei der Erfindung zur Speicherung von Displaydaten (Objektbeschreibungen) dient, schematisch als RAM 35 darge­ stellt ist. Anders als bei dem bekannten Rahmenpuffer werden die Daten für jedes Objekt in Aufeinanderfolgenden Plätzen innerhalb des RAM 35 gespeichert. D.h. beispielsweise für Objekt 33, daß die Daten an aufeinanderfolgend zugreifbaren Speicherplätzen gespeichert sind. Dies steht im Gegensatz zu dem Puffer gemäß Fig. 2b, wo die Daten für Objekt 33 an Plät­ zen entsprechend der Objektposition auf dem Display gespei­ chert werden. Wie außerdem für das Objekt 31 zu sehen ist, werden die dieses Objekt darstellenden Daten an benachbarten Plätzen innerhalb des Speichers gespeichert, und erneut ähneln die Speicherplätze nicht der X-Y-Position dieses Objekts auf dem Display.

Die Tiefe des Speichers 35 wird geeignet gewählt. Wo bei­ spielsweise ein 32-Bit-Datenbus im Gerät benutzt wird, kann der Speicher eine Tiefe von 32 Bits haben. Dies wiederum steht im Gegensatz zum Speicher gemäß Fig. 2b, wo die Tiefe des Speichers gleich der für jedes Pixel verwendeten Anzahl von Bits gewählt wird. Für die Erfindung wesentlich ist, daß die zur Beschreibung jedes Pixels verwendete Anzahl von Bits für die einzelnen Pixel unterschiedlich sein kann. Dies bedeutet für ein vorgegebenes Objekt, daß beispielsweise ein Bit zur Beschreibung von einigen Pixeln im Objekt (z.B. schwarz oder weiß) verwendet werden kann, während bei anderen Pixeln eine Mehrzahl von Bits zur Definition einer komplexen Farbe benutzt werden kann. Die Anzahl von Bits in einer Display-Zeile (hori­ zontale Zeile von Pixeln) eines vorgegebenen Objekts kann auch für jede Displayzeile des Objekts unterschiedlich sein. Daher können für ein vorgegebenes Objekt sowohl die Bitzahlen zur Definition jedes Pixels als auch die Anzahl von Pixeln zur Definition jeder Displayzeile verschieden sein.

Zusätzlich zu den im RAM 35 gezeigten Displaydaten sind Attri­ bute für jedes Objekt in einer Objekt-Abfertigungstabelle (object dispatch table) gespeichert. Diese Tabelle kann in einem Abschnitt des RAM 35 oder in einem getrennten Speicher gespeichert werden. Bei dem beschriebenen Ausführungsbeispiel ist die Objekt-Abfertigungstabelle innerhalb des RAM 35 ge­ speichert, wird jedoch innerhalb eines "Verteiler" (dispa­ tcher) - Fig. 11 - genannten Funktionsblockes zur Verwendung zu einem anderen Speicher bewegt. Die für jedes Objekt gespei­ cherten Attribute sind generell in Fig. 2c gezeigt als: Lage des Objekts im Display (enthält Ursprung, Objekthöhe usw.); Priorität des Objekts, d.h. die Objektlage in der Z-Richtung gemäß Darstellung in Fig. 1a; Stelle im Speicher 35, wo das Objekt gespeichert ist; Begrenzung des Darstellungsfeldes, einschließlich Darstellungsfeldursprung, -grenze usw. (dies wird weiter unten beschrieben); und der erste Display-Listen­ befehl, der ebenfalls weiter unten erläutert werden wird. Beispielsweise beschreiben bei einer einfachen rechtwinkligen Bitabbildung die Attribute für ein Objekt die Größe des Ob­ jekts, dessen Lage, die Anzahl von Bits pro Pixel und seinen ersten konsekutiven Platz im RAM 35.

Fig. 3 zeigt den RAM 35 mit einem Konfigurationsdatenab­ schnitt 36, einer Objekt-Abfertigungstabelle 37 und den Ob­ jekt-Beschreibungsdaten, wie in Fig. 2c gezeigt. Der Konfi­ gurationsdatenabschnitt 36 enthält Informationen, wie die Lokalisierung der Objekt-Abfertigungstabelle, Initialisie­ rungsdaten, wie Informationen darüber, welches Interface zwi­ schen der erfindungsgemäßen Einrichtung und einer CPU vorgese­ hen sein sollte, usw. Die Objekt-Abfertigungstabelle vermit­ telt, wie erwähnt, Angaben beispielsweise darüber, wo jedes Objekt innerhalb des Speichers 35 abgelegt ist. Die Pfeile aus der Objekt-Abfertigungstabelle 37 in Fig. 3 weisen daher auf Daten für Objekte 40-44. Wie erwähnt, wird die Objekt-Abfer­ tigungstabelle 37 in einen Speicher innerhalb des Verteilers wieder eingeschrieben. Adressen zur Auswahl der Objekte selbst aus dem RAM 35 werden von dem Verteiler (dispatcher) erzeugt. Die Tabelle wird während der vertikalen Austastzeit zum Ver­ teiler übertragen.

Die Hinweise aus der Objekt-Abfertigungstabelle auf die Ob­ jekt-Beschreibungsdaten sind in Fig. 4 dargestellt. Die Ob­ jekt-Abfertigungstabelle 37 ist bei Speicherung der Attribute für Objekte 41-45 gezeigt. Ein Attribut für jedes Objekt ist ein Startadressenhinweis, der auf die erste Zeile von Display­ daten innerhalb des RAM 35 hinweist. Die Muster für die Objek­ te 40-44, gezeigt in Fig. 3, werden innerhalb der die Daten für jedes Objekt der Fig. 4 darstellenden Blöcke dupliziert, um eine Korrelation zwischen Fig. 3 und 4 zu schaffen. Zu beachten ist, daß die Anzahl von Zeilen von RAM 35, die zur Speicherung der Daten für jedes Objekt verwendet wird, sich von Objekt zu Objekt ändern kann.

In Fig. 4 ist jede Displayzeile (Zeile 0 bis n) mit derselben Breite im Speicher gezeigt. Dies ist jedoch nicht notwendig. Im folgenden wir kurz auf Fig. 10 Bezug genommen. Der untere Abschnitt der Figur zeigt das Abfertigungstabellen-Eingabe­ format. Feld 45 ist ein 10-Bit-Wort, das die Zeilenlänge be­ zeichnet, wenn alle Zeilen eines speziellen Objekts die glei­ che Länge haben, dient ein Zähler dazu, die Auswahl einer nächsten Zeile zu ermöglichen. Wenn jede Zeile von unter­ schiedlicher Länge in einem Objekt ist, weisen in den Display­ daten gespeicherte Wörter ein Zeilenendsignal im Befehlswort­ format auf. Im folgenden wird kurz auf Fig. 22 Bezug genom­ men. Der Zeilenendbefehl ist Bit 23 des Bit Map (BMAP)-Be­ fehls, Bit 23 des Run-Befehls, Bit 23 des Sequenz-Runs (SRUNS)-Befehls und Bit 23 des Run Screen (RSCREEN)-Befehls.

Überblick über das erfindungsgemäße Gerät

Das Video-Displaygerät gemäß der Erfindung liefert Videosi­ gnale für ein Display mit Rasterabtastung. Bei dem bevorzugten Ausführungsbeispiel sind 8-Bit-Digitalsignale für jede der Farben rot, grün und blau ("RGB") als Videosignale für einen Farbmonitor in einem Operationsmodus vorgesehen. (Wie zu sehen sein wird, liefert der Zeilenpuffer insgesamt 16 Bits von RGB-Daten in einem anderen Betriebsmodus.) Das Display selbst hat 640 Pixel in Horizontalrichtung und 480 Pixel in Vertikal­ richtung. Die unverschachtelten Rahmen treten mit einer Fre­ quenz von etwa 60 Zyklen auf. Diese spezielle Anzahl ist je­ doch für die Erfindung unkritisch.

Die drei Hauptkomponenten des Geräts gemäß Darstellung in Fig. 5 sind der Verteiler (dispatcher) 48, RAM 35 und Zeilen­ puffer 50. Der Verteiler 48 und der Zeilenpuffer 50 werden in Verbindung mit nachfolgenden Figuren genauer beschrieben. Bei dem beschriebenen Ausführungsbeispiel ist jedes dieser Kompo­ nenten als getrennte gewöhnliche integrierte Schaltung unter Verwendung bekannter Technologien, wie der CMOS-Technologie, realisiert. Bei dem Video-RAM-35 ist eine Vielzahl von im Handel erhältlichen dynamischen Direktzugriffsspeichern einge­ setzt; der RAM 35 wird weiter unten erörtert.

Die Display-Daten und die Objekt-Abfertigungstabelle werden in den RAM 35 durch eines von verschiedenen bekannten Mitteln eingeschrieben. Beispielsweise kann eine im Handel erhältliche Zentraleinheit (CPU 56), eine im Handel erhältliche Zeichenma­ schine 55, z.B. eine NEC Teil Nr. 7220, verwendet werden. Wie in Fig. 5 dargestellt ist, kann eine Netzwerk-Interface- Schaltung 57 zur Aufnahme der Displaydaten aus einem Netzwerk und danach zum Übertragen derselben in den Video-RAM 35 ver­ wendet werden. Die Netzwerk-Interface-Schaltung 57, CPU 56 und Zeichenmaschine 55 sind gezeigt als einige Wege zur Entwick­ lung der Videodaten für den RAM 35; es ist jedoch für den Fachmann klar, daß andere Mittel zur Entwicklung der Display­ daten und der Abfertigungstabelle in dem in der Anmeldung beschriebenen Format eingesetzt werden können. Generell lie­ fern diese Mittel die Daten zum Video-RAM durch Adressierung des RAM auf dem Bus 58 und durch Anlegen der Daten auf den Bus 59. Der Verteiler 48 liefert auch Adressen auf den Bus 58.

Ein Video-Eingabepuffer 54 und eine 3D arithmetische Maschine 53 sind zwar für die vorliegende Erfindung nicht notwendig, sind jedoch Beispiele von Funktionseinheiten, die den RAM 35 überbrücken können, um dynamische Objekt-Displaydaten direkt in den Zeilenpuffer 50 zu laden. Auf diese Weise brauchen rasch sich ändernde Objekte nicht bei jeder Änderung in den RAM 35 umgeladen zu werden. Die Objektbeschreibungen in sol­ chen Funktionaleinheiten wie diese sind im gleichen Adreßraum wie die Objektbeschreibungen im RAM 35 abgebildet. Ein Video- Eingabepuffer 54, der als ein "Rahmengreifer" zur Aufnahme von Rahmen beispielsweise aus einer Videokamera dienen kann, kann zur Lieferung der Daten in Verbindung mit denjenigen des Video-RAM 35 verwendet werden. Die 3D arithmetische Maschine 53 ist eine Funktionseinheit zur Berechnung der Objektbe­ schreibung von drei-dimensionalen Modellen und kann unter Verwendung von im Handel erhältlichen Teilen, beispielsweise denjenigen der Firma Weitek, aufgebaut werden.

Der Video-RAM-Puffer 51 ist ebenfalls für die Erfindung nicht erforderlich. Es gibt einige Anwendungen, in denen er zweck­ mäßig ist, da er die Speicherung eines ganzen Datenrahmens ermöglicht. Wie zu sehen sein wird, erzeugt der Zeilenpuffer 50 eine Datenzeile gleichzeitig und muß daher bei einer Ge­ schwindigkeit arbeiten, die mit dem horizontalen Synchronisa­ tionstakt konsistent ist. Wird der Puffer 51 verwendet, so ist er gleich einem typischen bekannten Rahmenpuffer organisiert, wie der in Verbindung mit Fig. 2b beschriebene Rahmenpuffer.

Generell wird für jeden Rahmen des Displays die Abfertigungs­ tabelle zuerst zum Verteiler 68 übertragen. Der Verteiler beginnt dann zu den Displaydaten für jedes der Objekte auf einer zeilenweisen Basis zuzugreifen. Bei Beginn mit Zeile Null des Displays bedeutet dies beispielsweise, daß der Ver­ teiler feststellt, welche Objekte Daten für die Zeile Null haben, und danach zu diesen Daten aus dem RAM 35 oder funk­ tionellen Einheiten 53 oder 54 durch Kopplung von Adressen über den Bus 58 zugreift. Wenn eine Adresse innerhalb des Adreßraums des RAM 35 abgebildet ist, so werden die Daten aus dem RAM 35 gelesen und über den Bus 60 zum Zeilenpuffer 50 gekoppelt. Wenn eine Adresse im Adreßraum einer funktionellen Einheit 53 oder 54 abgebildet ist, so koppelt die Einheit die Daten des durch die Adresse identifizierten Objekts über den Bus 60 durch zu dem Zeilenpuffer. Der Zeilenpuffer 50 setzt die Zeile Null aus den für die sich in Zeile Null erstrecken­ den verschiedenen Objekte empfangenen Daten zusammen. Die Objektpriorität (Z-Richtung in Fig. 1a) bestimmt die Reihen­ folge, in der die Daten für jedes Objekt aus dem RAM 35 und den funktionellen Einheiten 53 und 54 gelesen werden. Befehle sind in die aus dem RAM 35 und den funktionellen Einheiten 53 und 54 gelesenen Daten eingebettet. Diese Befehle werden, wie zu sehen sein wird, sowohl vom Verteiler 48 als auch vom Puf­ fer 50 interpretiert. Sowohl der Verteiler als auch der Zei­ lenpuffer arbeiten bei der Vorbereitung jeder Zeile von Video­ daten in einer einem verteilten Prozessor (distributed proces­ sor) ähnlichen Weise. Der Zeilenpuffer 50 führt zahlreiche Funktionen, wie den Vergleich von Adreßsignalen aus dem Ver­ teiler, durch, wie weiter unten beschrieben werden wird. Bei den bevorzugten Ausführungsbeispielen liefert der Zeilenpuffer 50 eine "Doppelpufferung", d.h. während eine Zeile von Video­ daten in einem Abschnitt des Puffers zusammengesetzt wird, wird eine zuvor in einem anderen Abschnitt des Puffers zusam­ mengesetzte Videodatenzeile zur Anzeige ausgelesen. Nach dem Zusammensetzen jeder Zeile von Videodaten im Puffer 15 wird sie zu D/A-Umsetzern 52 übertragen, um die RGB-Signale für einen Monitor zu erzeugen. Wenn der RAM 51 verwendet wird, werden die Videodaten zunächst zum RAM 51 übertragen, danach aus dem RAM 51 zu den D/A-Umsetzern 52 zur Erzeugung der RGB- Signale für einen Monitor ausgetastet.

Video-RAM

Bei dem bevorzugten Ausführungsbeispiel enthält der RAM 35 eine Vielzahl von im Handel erhältlichen dynamischen Direktzu­ griffsspeichern, die im Handel als "Video-RAMs" bezeichnet werden. Diese RAMs haben zwei Ports, einen seriellen Port, den anderen als gewöhnlicher Direktzugriffsport. Die Daten können in den Direktzugriffsport geschrieben und aus diesem ausgele­ sen werden. Der Direktzugriffport ist mit dem Bus 59 gekop­ pelt. Daten werden aus dem seriellen Port, der mit dem Bus 60 in Fig. 5 verbunden ist, gelesen. Tatsächlich werden die Daten im Inneren jedes der DRAMs aus dem interen RAM-Feld in ein Schieberegister bewegt und danach seriell aus dem Schiebe­ register ausgelesen. Obwohl das Schieberegister in Ausrichtung mit den Zeilen der internen RAM-Matrix geladen wird, können die Daten aus dem Schieberegister beginnend an irgendeinem Platz im Register ausgeschoben werden. Das Auslesen der Daten aus dem Schieberegister kann asynchron zu anderen Speicher­ operationen erfolgen. Ein typisches Beispiel für einen Video- RAM ist Part Nr. 41264, der von NEC Electronics, Inc. erhält­ lich ist. Der Speicher hat eine Zugriffszeit von 120 ns für den RAM-Port und 30 ns für den seriellen Port. Bei dem bevor­ zugten Ausführungsbeispiel verwendet der RAM 35 diese "DRAM- Chips" zur Bildung eines Speichers mit einer Kapazität von wenigstens 256 K Bytes, vorzugsweise jedoch 1 M Bytes. Die seriellen Ports sind mit den 32 Zeilen des Busses 60 derart gekoppelt, daß für jede Eingabeadresse, die zum Laden des Schieberegisters und zur Auswahl einer Schiebe-Startadresse an die DRAMs angelegt wird, bis zu 256 seriellen Ausgangsworten von jeweils 32 Bits auf den Bus 60 gekoppelt und durch ein einziges Taktsignal ausgelesen werden. Mit anderen Worten, nach einer Anfangsadresse, dem Laden des Schieberegisters mit einer Zeile und dem Identifizieren eines Schieberegisters mit einer Zahl können Daten mit Hilfe eines einzigen Taktsignals aus dem Schieberegister ausgelesen werden.

Gesamtablaufsteuerung

Es sei angenommen, daß die Einrichtung gemäß Fig. 5 eine spezielle Rasterzeile des Displays zusammenzusetzen beginnt. Im folgenden wird eine summarische Beschreibung der Ablauf­ steuerung gegeben, welche während dieser Zusammensetzung stattfindet.

Der Verteiler 48 stellt fest, welche Objekte die aktuelle Rasterzeile schneiden und welches dieser Objekte am weitesten im Hintergrund steht. Nach dieser Feststellung greift der Verteiler zu den Attributdaten dieses Objekts zu, die zuvor während der vertikalen Austastzeit in den Verteiler aus dem RAM 35 geladen worden sind. Der Verteiler übernimmt danach die Steuerung des Adreßbusses 58 und koppelt eine Adresse an die­ sen Bus, welche die erste Adresse der Daten für diese Zeile (die mit der aktuellen Rasterzeile des Display zusammenfällt) des Objekts ist. Eine der funktionellen Einheiten in Fig. 5 oder RAM 35 spricht auf die Adresse auf dem Bus 58 an. Die adressierten Daten werden dadurch lokalisiert und für die Übertragung auf den Bus 60 vorbereitet. Im Falle des Video-RAM 35 zeigt die Adresse an, welche Zeile zum Video-RAM-Schiebere­ gister übertragen ist und von wo im Register das Verschieben beginnen soll.

Gleichzeitig mit der Adreßerzeugung auf dem Bus 58 koppelt der Verteiler eine Folge von Befehlen (siehe Fig. 22 und 23), welche den Zeilenpuffer darauf vorbereiten, die Daten in Ab­ hängigkeit von der Adresse des Verteilers zu senden. (Zu be­ achten ist, daß diese Befehle identisch zu denjenigen Befehlen sind, die in Objektbeschreibungen, gespeichert im RAM 35 oder erzeugt durch die funktionellen Einheiten 53 und 54, enthalten sind; der Zeilenpuffer erhält einfach einen Befehlsstrom und arbeitet an ihm ohne seine Quelle zu kennen.) Diese Befehlsfol­ ge vom Verteiler hat im besonderen folgende Funktionen: (1) den Inhalt des Zeilenpuffers für das besondere Objekt vorzube­ reiten, einschließlich der Entwicklung eines absoluten Ur­ sprungs (ein horizontaler Referenzpunkt, von dem aus die hori­ zontale Positionierungsinformation für das Objekt verschoben wird), einem Konstantwort (Füllbits für Daten, die nicht von den Schreibdaten der Objektbeschreibung vorgesehen sind, z.B. 15 Bits für 1 Bit pro Pixel Bitabbilungen zum Auffüllen eines vollen 16-Bit-Worts), und gewisser Betriebsinformationen. (2) das Maskenbit über den Zeilenpuffer zu löschen (verhindert dadurch ein Einschreiben in die Zeilenpufferzellen). (3) das Maskenbit über einen fortlaufenden Abschnitt des Zeilenpuffers zu setzen (übergehen der gerade durchgeführten Löschoperation) entsprechend der gewünschten horizontalen Sichtbarkeitsausdeh­ nung des Objekts auf dieser Zeile, genannt dessen horitzonta­ les Darstellungsfeld (selbst wenn die in den Zeilenpuffer geladene Objekt-Zeilenbeschreibung sich über dieses Darstel­ lungsfeld hinaus nach links oder rechts erstreckt, wird nur der Teil des Zeilenpuffers innerhalb dieses Darstellungsfelds geändert, so daß das Objekt nur in diesem Darstellungsfeld auf dem Display sichtbar wird). (4) Entwicklung des ersten Worts des ersten Befehls für diese Zeile (wenn das Objekt beispiels­ weise eine rechteckige Bitabbildung (bit map) ist, so wäre dieses erste Wort ein Bit-Map-Befehl entsprechend Darstellung in Fig. 22).

Nach Beendigung der Adressierungsoperation auf dem Bus 58 und nachdem die Befehlsfolge das Laden aus dem Verteiler in den Zeilenpuffer beendet hat, gibt der Verteiler die Steuerung des Busses 58 auf und beginnt, den RAM 35 oder eine funktionelle Einheit, die mit der Adresse des Starts der Objektdaten für diese Zeile adressiert worden ist, zu takten (auf einer nicht dargestellten Einzelsignalleitung). Diese Daten können einen Befehl komplettieren, der von dem ersten, gerade vom Verteiler gesendeten Wort gestartet wurde (wie für den Fall, daß das erste Wort ein Bit Map- oder Sequenz-Runs-Befehl ist) oder sie können einen Befehl neu beginnen (wie in dem Falle, daß das erste Wort ein Run-Befehl war). Sobald der erste Befehl der Zeile das Laden beendet hat, können die nachfolgenden Daten danach zusätzliche Befehle für die Zeile enthalten, beispiels­ weise wenn eine komplexe Folge von Runs zum Beschreiben der Flächen eines 3D Polyederobjekts geladen wird.

Der Verteiler stellt fest, wann das Ende der Datenzeile für das Objekt erreicht worden ist, und zwar durch eine von zwei Möglichkeiten: Wenn das Objekt feste Zeilenlängen hat, durch Bestimmung des Ablaufs der Länge, und wenn das Objekt variable Zeilenlängen hat, durch Bestimmung eines Zeilenendbits (siehe Beispielsweise Bit 23 des Bit-Map-Befehls in Fig. 22) an dem letzten Befehl dieser Zeile des Objekts. An dieser Stelle unterbricht der Verteiler das Takten des RAM 35 oder der die Daten lieferenden funktionellen Einheit und stellt fest, ob ein anderes Objekt auf dieser Zeile erscheint. Ist dies der Fall, nimmt der Verteiler das nächste Objekt in den Vorder­ grund vor das gerade geladene Objekt und beginnt eine Ladeope­ ration für dieses Objekt in einer Weise, wie sie für das vor­ gehende Objekt oben beschrieben worden ist. (Zu beachten ist, daß dort, wo dieses Objekt mit dem vorhergehenden Objekt in der Zeile zusammenfällt, dies in dem Zeilenpuffer überschrie­ ben wird, wo durch es vor dem vorhergehenden Objekt er­ scheint). Gibt es keine Objekte auf dieser Zeile, so wartet der Verteiler bis zur nächsten horizontalen Austastlücke, um mit dem Zusammensetzen der nächsten Rasterzeile des Displays in den Zeilenpuffer in exakt der gleichen Weise wie das Zusam­ mensetzen der aktuellen Zeile zu beginnen.

Es gibt jedoch einen Ausnahmefall, wo eine Objekt-Zeilenbe­ schreibung im RAM 35 enthalten ist und eine Zeilengrenze kreuzt. In diesem Falle wird das Schieberegister im RAM 35 vollgeschrieben, bevor die Objektzeilen-Beschreibungsdaten das Laden beendet haben, so daß der Verteiler die Steuerung des Adreßbusses 58 zu diesem Zeitpunkt übernimmt und das Schiebe­ register mit dem Inhalt der nachfolgenden Zeile von RAM 35 neu lädt. Generell kann diese Umladeoperation vorweggenommen und mit dem Ausschieben von Daten synchronisiert werden, so daß das Schieberegister sich zwischen dem letzten Takt des Endes der ersten Schieberegisterladung und dem ersten Takt bei Be­ ginn des umgeladenen Schieberregisters umgeladen wird und die Datentaktgabe nicht unterbrochen wird.

Bei dem bevorzugten Ausführungsbeispiel werden zwei Zeilenpuf­ fer verwendet, wobei einer in der gerade beschriebenen Weise geladen werden kann, während der andere zum Display ausgeta­ stet wird, worauf während der nächsten horizontalen Austast­ lücke die Rollen vertauscht sind. Daher wird eine Zeile gerade während einer Zeilenzeit zusammengesetzt, bevor sie zur Anzei­ ge gebracht wird.

Wenn das Laden aller Zeilenbeschreibungen aller eine Raster­ zeile kreuzenden Objekte mehr Zeit kostet als in eine Horizon­ talzeilenzeit des Displays geladen werden kann, so wird die Zusammensetzung der Zeile nicht rechtzeitig fertig, bevor die Zeile für das Austasten benötigt wird. Dies ist eine fundamen­ tale Beschränkung der Konfiguration, bei der der Zeilenpuffer 50 direkt mit Digital/Analog-Umsetzern 52 gekoppelt ist; sie kann jedoch durch Einfügung des RAM 51 zwischen die Komponen­ ten 50 und 52 (Fig. 5) gelöst werden. RAM 51 ist eine dop­ peltgepufferte Speichermatrix, die zwei volle Videorahmen bei der größten, vom Zeilenpuffer erzeugbaren Zeilentiefe (16 Bits pro Pixel bei dem beschriebenen Ausführungsbeispiel) zu spei­ chern und auszugeben in der Lage ist. Mit diesem zusätzlichen RAM 51 kann der Rest des Geräts sich solange Zeit lassen, wie jede Zeile zum Zusammensetzen braucht, bevor sie in einen der Rahmenpuffer übertragen wird, da ein Rahmenpuffer den Bild­ schirm mit einem stabilen Bild regeneriert, während der andere Rahmen langsam Zeile für Zeile zusammengesetzt wird. Wenn diese Rahmenzusammensetzung abgeschlossen ist, wartet das Gerät auf eine Vertikalaustastung und schaltet die Rollen der Rahmenpuffer um und beginnt den nächsten Rahmen zusammenzuset­ zen, während der soeben vervollständigte zur Anzeige gebracht wird. Auf diese Weise kann ein beliebiger Grad an Komplexität bei der Zusammensetzung realisiert werden.

Abfertigungstabellenformat

Bei der aktuellen Implementierung ist die Objekt-Abfertigungs­ tabelle (mitunter als "ODT" bezeichnet) konfiguriert für 64 Objekte, wie in Tabelle 65 in Fig. 10 gezeigt. Die Objekt­ priorität (Z-Position) wird nicht direkt gespeichert, sondern abgeleitet aus dem Platz, an dem die Objektattribute gespei­ chert sind. Genauer gesagt, hat das Objekt 63 die höchste Priorität, d.h. es ist am nächsten zum Vordergrund und auf dem ersten Platz gespeichert (höchste Adresse, die der Abferti­ gungstabelle zugeordnet ist. Die Attribute für jedes Objekt umfassen vier 32-Bit-Worte (Wort 0-Wort 3) wobei die beson­ deren Inhalte jedes Worts in Fig. 10 unter der Überschrift "Abfertigungstabellen-Eingabeformat" gezeigt sind. Die gesamte Abfertigungstabelle besteht daher aus 1 K-Bytes oder bei der bevorzugten Anordnung für den RAM 35 aus einer Zeile des RAM. Auf diese Weise ist nur eine einzige Video-RAM-Serienport-La­ deoperation zum Lesen des RAM 35 erforderlich, wenn die Tabel­ le in den Verteiler übertragen wird.

Wort 0 für jedes der Objekte enhält ein 12-Bit-Feld 66, das den absoluten Ursprung des Objekts in der Horizontalrichtung des Displays liefert. Dieses Feld ist groß genug, um eine Platzierung des Ursprungs links oder rechts vom Display zu ermöglichen, was zweckmäßig ist, wie weiter unten zu sehen sein wird. Das 20-Bit-Feld 67 von Wort 0 liefert die Start­ adresse im RAM 35. Dies ist die als "Startadressenhinweise" der Zeile 0 in Fig. 4 gezeigte Adresse.

Das 9-Bit-Feld 68 von Wort 1 zeigt die Zeile vom oberen Ende des Displays an, auf der das Objekt beginnt. Das 9-Bit-Feld 69 liefert die Objekthöhe auf dem Display. Das Bit 70 von Wort 1 ist ein Speichersteuerbit zum Zugriff auf RAM 35. Das Bit 71 zeigt den Anzeigemodus bzw. Displaymodus an, insbesondere ob die Objektbeschreibungsdaten aus dem RAM 35 RGB-Signale dar­ stellen oder vielmehr einen Hinweis auf eine Farb-Nachschlage­ tabelle (gezeigt als X, L in den Zeilenpufferfiguren). Das Bit 72 zeigt an, ob die Zeilenlänge variabel oder fest ist, und, wie zuvor erwähnt, ob die Zeilenlänge selbst im 10-Bit-Feld 45 enthalten ist, wenn die Zeilenlänge fest ist.

Das 10-Bit-Feld 73 von Wort 2 liefert den Darstellungsfeldur­ sprung (am weitesten links gelegenen Ursprung), und das 10- -Bit-Feld 74 liefert die Darstellungsfeldgrenze (rechte Aus­ dehnung des Darstellungsfeldes). Das Darstellungsfeld wird weiter unten genauer beschrieben. Das 12-Bit-Feld 75 liefert ein konstantes Wort, das in Verbindung mit gewissen Befehlen zum "Auffüllen" von Pufferplätzen verwendet wird. Wenn ein 16-Bit-Konstantwort benötigt wird, wird ein besonderer Befehl verwendet, der in Fig. 22 als "Ersetze Konstante-Befehl" bezeichnet ist. Die oberen vier Bits und die unteren 12 Bits des "C-Worts" sind als Felder 76 bzw. 77 in Fig. 22 gezeigt.

Wort 3 ist ein 32-Bit-Feld 78, welches das erste Wort für die erste Zeile des Objekts ist. Insbesondere ist dieses Feld ein Befehl, wie "Bit Map" oder "Run", wie in Fig. 22 gezeigt.

Verteiler

Im folgenden wird auf Fig. 11 Bezug genommen. Die Abferti­ gungstabelle wird bei Übertragung zum Verteiler in einem ande­ ren Format im Verteiler gespeichert, um eine raschere Verar­ beitung zu ermöglichen. Der Speicher 81 speichert die Start­ adresse für jedes Objekt in einem Abschnitt 83. Die restlichen Attribute, mit Ausnahme der Startzeile und der Objekthöhe, werden im Speicher 81 in der mit "andere Abfertigungsdaten" bezeichneten Zone gespeichert.

Die Schaltung 82 weist 64 parallele Komparatoren auf, einen für jedes Objekt. Jeder Komparator erfüllt die Funktion eines Vergleichs der aktuellen Zeile (aus dem Zeilenzähler 88) so­ wohl mit der Start-Zeile (S Zeile) für das Objekt als auch der Endzeile (E Zeile) für das Objekt. Eine 1-Bit-Zelle ist jedem Objekt innerhalb des Abschnitts 84 der Schaltung 82 zugeord­ net. Für jedes Objekt bewirkt die Schaltung 82 eine UND-Ver­ knüpfung des Inhalts dieser Zelle mit den Ergebnissen des Vergleichs durch. Insbesondere findet das Folgende statt: "Zelleninhalt" <S Zeile <E Zeile. Wenn daher beispielsweise für Objekt 0 die Zelle 84 auf 1 gesetzt ist und die Startzeile 10 ist und die Endzeile 20, wird eine 1 ausgegeben, wenn der Zeilenzähler 88 zwischen 10 und 20 steht. Diese Aussage ist eine von 64 Eingaben für den Prioritätszuordner 89.

Wenn die Abfertigungstabelle aus dem RAM 35 zum Verteiler übertragen wird, werden die Daten durch den Puffer 85 durchge­ schoben und in den Speicher 81 geladen. Die Startzeile wird in die Schaltung 82 geladen. Die Startzeile für jedes Objekt wird auch in das Register 86 geladen und zur Objekthöhe im Addierer 87 addiert, um eine Endzeile (E Zeile) zu schaffen, welche in der Schaltung 82 gespeichert wird. Zu beachten ist, daß bei Bedarf die Endzeile selbst ein Attribut sein könnte, das im RAM 35 gespeichert und direkt in die Schaltung 82 geladen wird.

Die Funktion der Schaltung 82, des Prioritätszuordners 89 und des Decodierers 90 werden nach Kenntnis ihrer Zweckbestimmun­ gen leichter verständlich. Typischerweise deckt ein Objekt nicht den ganzen Display (von oben bis unten). Beträchtliche Zeit ginge verloren, wenn der Verteiler gemäß Fig. 11 Objekte für diejenigen Zeilen verarbeiten müßte, auf denen das Objekt nicht vorhanden ist. Es sei wiederum beispielsweise angenom­ men, daß Objekt 0 zwischen den Displayzeilen 10 und 20 vorhan­ den ist. Dabei ginge Zeit verloren, wenn die Objektattribute für die Zeilen 0 bis 9 und für die Zeilen 11 ff. geprüft wür­ den. Die 64 Parallelkomparatoren 82 liefern jeweils nur dann ein Signal an den Prioritätszuordner 89, wenn das Objekt auf der aktuellen Displayzeile des Zählers 88 vorhanden ist. Dies macht eine Betrachtung der Objekte für diejenigen Zeilen über­ flüssig, in denen das Objekt nicht vorhanden ist.

Zu Beginn jeder Displayzeile werden alle 64 Bits der Zellen 84 auf 1 gesetzt. Danach findet der Vergleich parallel für alle 64 Objekte statt, der bestimmt ob, das Objekt für die betrach­ tete Zeile vorhanden ist. Wenn das Objekt für die Zeile vor­ handen ist, so wird, wie erwähnt, ein Ausgangssignal für den Prioritätszuordner 89 ausgegeben. Der Prioritätszuordner 89 prüft die Ausgänge aus der Schaltung 82 und liefert ein Signal an den Decodierer 90, das die höchste vorhandene Prioritäts­ zahl angibt. Der Decodierer 90 wählt dann dieses Objekt aus dem Speicher 81 aus. Nach dieser Auswahl setzt der Decodierer das Bit im Abschnitt 84 für dieses Objekt auf Null. Dies ver­ hindert, daß das Objekt für eine spezielle Displayzeile erneut ausgewählt wird, da der Komparatorausgang für dieses Objekt auf Null abfällt. Der Prioritätszuordner wählt danach das Objekt mit der nächsthöchsten Priorität aus, bis alle für eine vorgegebene Zeile vorhandenen Objekte berücksichtigt sind. Bei Beginn der nächsten Displayzeile werden die Bits im Abschnitt 84 wiederum auf 1 gesetzt. Auf diese Weise werden nur diejeni­ gen Objekte berücksichtigt, die für eine vorgegebene Zeile beachtlich sind, und die Objekte werden in der Reihenfolge ihrer Prioritätshöhe berücksichtigt.

Das Register 92 (20-Bit-Register), ein Adreßinkrementer 94, ein Wortzähler 95 und ein Addierer 96 liefern Adressen über den Adreßpuffer 97 an den RAM 35. Während jedes Objekt von dem Decodierer 90 ausgewählt wird, wird seine Startadresse zum Register 92 und über den Puffer 97 zum RAM 35 gekoppelt, um das erste Datenwort für die Zeile auszuwählen. Wenn die Wort­ länge des Objekts fest ist (Bit 72 in Fig. 10), so wird das zur Auswahl des ersten Datenworts für die nächste Zeile benö­ tigte Inkrement durch den Adreßinkrementer 94 und den Addierer 96 gekoppelt und zur Adresse im Register 92 addiert. Die neue Adresse wird dann zum Abschnitt 83 des Speichers 81 zurückge­ führt und für die nächste Zeile verwendet. Wenn andererseits die Daten pro Zeile nicht fest sind, wird ihre Länge durch Feld 45 in Fig. 10 bestimmt. Der Wortzähler 95 zählt die Länge der Zeile, während die Worte aus dem RAM 35 ausgelesen werden. Während dieses Modus wird die alte Adresse zur Ausgabe des Zählers 95 im Zähler 96 addiert (Leitung 98), sobald die Objektzeile das Laden beendet hat. Wiederum ist eine neue Startadresse für die nächste Zeile das Ergebnis dieser Addi­ tion, und sie wird im Abschnitt 83 des Speichers 81 gespei­ chert. Zu beachten ist, daß der Wortzähler 95 für Objekte sowohl mit fester als auch mit variabler Länge erforderlich ist, da die für eine Zeile eines Objekts benötigten Daten die Zeilengrenzen der Daten aus dem RAM 35 kreuzen können, wodurch das Video-RAM-Schieberegister des RAM 35 neu geladen werden muß. Der Zähler 95 koppelt daher ein Signal zum Finite-Zu­ stand-Steuergerät 101 und gestattet es diesem Steuergerät, den RAM 35 die Schieberegister umladen zu lassen, wobei die näch­ ste Zeile im RAM die Adresse benutzt, welche durch die mittels des Addierers 96 berechnete und über die Leitung 99 zum Puffer 97 übertragene Summe des Wortzählers 95 und die im Register 92 gespeicherte alte Adresse bestimmt ist. Regenerierungsadressen werden von einer Schaltung 93 zur Steuerung der Regenerierung des dynamischen RAM 35 geliefert.

Daten aus dem Speicher 81, beispielsweise der absoulte Ur­ sprung, werden für jedes Objekt über Puffer 102 und den Daten­ bus 100 in den Zeilenpuffer gegeben. Das Finite-Zustand-Steu­ ergerät 101 steuert die Operation des Verteilers und dessen Zeitgabe. Es erhält ein Signal über die Leitung 105 aus der Schaltung 104 in Fig. 9. Dieses informiert den Verteiler darüber, daß der letzte Befehl (Endzeilenbit) empfangen worden ist und daß die Daten für das nächste Objekt gesendet werden sollten. Dies wird auch für den Zeilen mit variabler Länge-Mo­ dus verwendet, um festzulegen, wann eine Zeile der Objektdaten komplett geladen ist.

Zeilenpuffer

Zunächst wird auf Fig. 6 Bezug genommen. Der Zeilenpuffer hat 640 Zeilen, eine für jedes Pixel entlang einer Displayzeile. (Nur ein einziger Zeilenpuffer ist in Fig. 6 gezeigt; man sollte sich jedoch in Erinnerung rufen, daß zwei Zeilenpuffer zur Ermöglichung einer Doppelpufferung bei dem beschriebenen Ausführungsbeispiel vorgesehen sind, wobei der zweite Zeilen­ puffer beispielsweise in Fig. 7 gezeigt ist. (Jede Zelle hat eine Speicherkapazität für 16 Bits (bezeichnet RGB oder X, L), ein Modus-Bit und ein Maskier-Bit. Bei dem beschriebenen Aus­ führungsbeispiel werden die RGB-Daten in fünf Bits für rot, sechs Bits für grün und fünf Bits für blau unterteilt. Wenn RGB-Daten in der Zelle gespeichert sind, ist eine binäre Eins für das Modus-Bit (Bildmodus) gespeichert. In Fig. 6 ist dieses Bit entweder als I oder L zu Erläuterungszwecken ge­ zeigt. Die sechzehn Bits können alternativ zum Speichern von Daten verwendet werden, welche als ein Hinweis auf eine Nach­ schlagetabelle benutzt werden können. Dies ist der "L" (Farb­ nachschlagetabelle oder CLUT)-Modus. Die sechzehn Bits werden bei dem beschriebenen Ausführungsbeispiel unterteilt in acht Bits für eine Nachschlagetabelle und acht Extrabits, die bei­ spielsweise zur Auswahl einer besonderen Nachschlagetabelle verwendet werden können. In dem L-Modus werden die RGB-Farben aus der Nachschlagetabelle ausgewählt. In diesem Falle kann RGB acht Bits sein, die, wie gezeigt, mit den D/A-Umsetzern 52 in Fig. 5 gekoppelt sind. Das Maskierbit, gezeigt entlang der Zeile 107 verhindert oder gestattet ein Schreiben in eine spezielle Zelle. Die Verwendung dieses Bits wird weiter unten beschrieben. Wichtig ist, daß für eine vorgegebene Zeile RGB- Daten mit X, L-Daten gemischt werden. Wie in Fig. 6 gezeigt, kann daher die Zelle 109 (Pixel 4) RGB-Daten enthalten, welche direkt von den D/A-Umsetzern für den Monitor umgesetzt werden können, während der Inhalt der Zelle 110 (Pixel 5) eine Adres­ se für ein CLUT sein kann. Diese Flexibilität ermöglicht die Auswahl von Farben, die anderenfalls aus dem 16-Bit-Feld nicht zu gewinnen wären.

Die Speicherzellen für jedes Pixel sind in ungewöhnlicher Weise gruppiert, und dies ergibt, wie zu sehen sein wird, einen wesentlichen Vorteil. In Fig. 7 sind Zeilenpuffer A und Zei­ lenpuffer B mit zweiunddreißig Speicherzellengruppen gezeigt. Jede Speicherzellengruppe enthält 20 Zellen. Prüft man die Zellengruppe 0 (gezeigt im Rechteck 120 der Fig. 7) so spei­ chert diese Gruppe Pixeldaten für Pixel 0, 32, 64, 96 . . . bis Pixel 608, wie in Fig. 8 gezeigt ist. Speicherzellengruppe 1 speichert Pixeldaten für Pixel 1, 33, 65, 97 ... bis Pixel 609. Und schließlich speichert die Speicherzellengruppe 31 die Pixeldaten für die Pixel 31, 63, 95, 127 ... bis Pixel 639.

Im folgenden wird auf Fig. 7 Bezug genommen. Jede Gruppe von Speicherzellen ist mit einem Grenze-links-oder Bit-Map- Schreibadreßbus 112, Grenze-rechts-Bus 113, Schreibdatenbus 100, Konstantwortbus 115, Schreibsteuerbus 116, Leseadreßbus 117 und Lesedatenbus 118 gekoppelt. Die Signale auf diesen Bussen werden empfangen von dem in Fig. 9 gezeigten Zeilen­ puffer-Steuergerät, dem Verteiler und dem RAM 35.

Im folgenden wird auf Fig. 8 Bezug genommen. Jede Gruppe von Speicherzellen weist, wie erwähnt, 20 Zellen, d.h. Speicher­ raum für 20 Pixel auf. Jede Zelle, wie die Zelle 119, enthält die Display-Daten-Speicherungen (RGB oder X, L), die Modusbit­ speicherung und die Maskierbitspeicherung, wie zuvor in Ver­ bindung mit Fig. 6 erläutert wurde. Zusätzlich enthält jede Zelle einen Adreßdecodierer. Dieser Adreßdecodierer empfängt die Leseadreßsignale über den Bus 117 und ermöglicht es, daß die Daten in den Zellen auf Bus 118 ausgelesen werden (d.h. RGB (oder X, L) und Modusbit). Dies geschieht nach dem Zusam­ mensetzen einer Zeile im Puffer und deren Auslesen aus dem Puffer für die Anzeige. Zusätzlich enthält jede Zelle Rechen­ mittel, insbesondere logische Schaltungen, welche Vergleiche zwischen der Pixelzahl der Zellen und der linken Grenze (oder Bit Map-Schreibadresse) auf Bus 112 und der rechten Grenze auf Bus 113 durchzuführen gestattet. Beispielsweise enthält die Zelle 119, welche Daten für Pixel 128 speichert, eine Logik, welche die Grenze/Adresse auf Bus 112 vergleicht, um festzu­ stellen, ob diese Grenze/Adresse kleiner oder gleich 128 ist. Der Vergleicher bestimmt auch, ob die Grenze auf Bus 113 grö­ ßer als 128 ist. Wenn die Grenze/Adresse 112 kleiner oder gleich 128 ist, ist die Grenze 113 größer als 128, und es ist eine Eins in der Maskierbitzelle; dann akzeptiert die Zelle 119 Daten aus der Datenmisch- und Ausricht-Logikschaltung 121, erhält ein Konstantwort vom Bus 115 und die Daten vom Bus 100 und führt unter der Steuerung der Schreibsteuersignale auf Bus 116 Misch- und Ausrichtoperationen an diesen Signalen durch, so daß sie in die geeigneten Plätze innerhalb der Zelle oder der Zellen gekoppelt werden, die adressiert sind. Einige weni­ ge Beispiele, die in dieser Anmeldung folgen, machen den Zweck der Schaltung 121 klar.

Die Daten von der Schaltung 121 können gleichzeitig in ein oder mehrere Zellen in einer Zellengruppe geschrieben werden. Tatsächlich können die Daten aus der Schaltung 121 (und ähn­ liche Schaltungen sind anderen Zellengruppen zugeordnet) in alle Zellen aller Gruppen gleichzeitig geschrieben werden.

Zunächst sei ein Fall betrachtet, bei dem das Display gerade ein Einzelbit pro Pixel (eine 1 oder 0) erforderlich macht. Das Pixel-Speicherfeld für jede Zelle ist, wie gezeigt 16 Bits. Es sei ferner angenommen, daß fünfzehn der sechzehn Bits mit Nullen gefüllt sind. Ein 32-Bit-Wort, das die Einsen und Nullen des anzuzeigenden Bitmusters enthält, kann auf den Schreibdatenbus 100 gekoppelt werden. Die linken und rechten Grenzen auf den Bussen 112 und 113 können so eingestellt wer­ den, daß die Zellen für Pixel 0-32 die Daten vom Bus 100 ak­ zeptieren. (Zu beachten ist, daß dies wegen der Gruppierung im Sinne der Beschreibung der Fig. 7 möglich ist. Die Zellen für Pixel 0-32 sind jeweils in einer anderen Gruppe von Zellen angeordnet, und dementsprechend können die 32 Bits auf dem Bus 100 in die 32 Zellen verteilt werden.) Die restlichen 15 Bits, die alle Nullen sind, können an den Bus 115 angelegt und in die geeigneten Zellen gleichzeitig mit dem Erhalt der Daten vom Bus 100 geschrieben weren. Die Steuersignale auf Bus 116 ermöglichen dem Konstantwort das Einschleifen in geeignete Leitungen zur Kopplung der Zellen. Das obige einfache Beispiel zeigt den Vorteil der Gruppierung von Zellen, Konstantworten und linken und rechten Grenzen.

Betrachtet sei ein Beispiel, bei dem die Gesamtanzeige eine durch RGB-Signale definierbare Farbe ist. Die linken und rech­ ten Grenzen auf Bussen 112 und 113 können so gesetzt werden, daß alle Zellen Daten von ihren entsprechenden Datenmisch- und -ausricht-Logikkschaltungen 121 aufnehmen. Ein Einzelwort auf dem Schreibdatenbus 100 kann daher in allen 640 Zellen ge­ schrieben werden.

Andere Vorteile des Puffers werden in Verbindung mit besonderen Displays bzw. Anzeigen weiter unten in der Beschreibung erläu­ tert.

Befehlsworte

Es dürfte hilfreich sein, vor der Prüfung des Steuergeräts gemäß Fig. 9 das Befehlswortformat zu verstehen. Hierzu wird auf Fig. 22 Bezug genommen, in der sechs Befehlsworte gezeigt sind. Das erste Feld jedes der Worte dient zur Identifzierung des Befehls. Beispielsweise identifiziert 000 Bit Map (BMAP), 1 identifiziert Run, 001 Sequenz-Runs (SRUNS) usw. Dieses Feld wird mit dem Befehlsdecodierer 129 in Fig. 9 gekoppelt.

Das zweite Feld des Bit Map-Befehls identifiziert das verwen­ dete Datenformat und liefert schließlich die Schreibsteuersi­ gnale. Das Datenformat wird an das Datenformatregister 131 in Fig. 9 angelegt. Das 2-Bit-Feld "W-Modus" wird an das Schreibmodusregister 132 angelegt und identifiziert den zu verwendenden Schreibmodus. Das nächste Bit "E-Modus" bestimmt, ob eine eingebettete Maske verwendet werden soll; dies wird weiter unten erläutert. Das 10-Bit-Feld "R-Ursprung" ist der relative Ursprung des Bit-abgebildeten Objekts (im Gegensatz zu dessen absolutem Ursprung), beide werden weiter unten er­ läutert. Das letzte 10-Bit-Feld liefert eine Zählung von Da­ tenwörtern für die Bitabbildung (bit map) und wird zum Zähler 130 der Fig. 9 gekoppelt. Für diesen und andere Befehle wer­ den spezielle Beispiele weiter unten gegeben.

Der Run-Befehl ermöglicht einen Einzelrun, d.h. das Einschrei­ ben eines speziellen Datenworts in alle Zellen im Zeilenpuffer gemäß Fig. 6 zwischen definierten Grenzen. Der Run-Befehl enthält ein 7-Bit-Feld-Datenwort, welches das in die Zellen geschriebene Wort darstellt. Dieser Befehl enthält auch ein Endzeilen-Bit und ein 2-Bit-Schreibmodus-Steuerfeld. Ein "d- Ausricht"-Bit zeigt an, ob das in diesem Befehl gezeigte 7-Bit-Datenwort entsprechend der Darstellung in Fig. 6 im L-Feld oder X-Feld des Zeilenpuffers ausgerichtet ist und wird zum Datenformatregister 131 übertragen. Es gibt zwei 10-Bit- Felder im Run-Befehl, eines für den rechten Ursprung und das andere für die rechte Grenze, welche die Startzelle und die Endzelle des Zeilenpuffers definieren, zwischen denen das 7-Bit-Datenwort geschrieben wird.

Der Sequenz-Run-Befehl ist ähnlich dem Run-Befehl, weist je­ doch ein Datenformat mit einem 5-Bit-Feld auf, das zum Regi­ ster 131 in Fig. 9 gekoppelt ist. Es enthält auch das rechte Ursprungsfeld. Das letzte 10-Bit-Feld sorgt für das Zählen von Datenwörtern, (DW), die aus dem RAM 35 ausgewählt sind. Ein Sequenz-Run-Datenformat ist in der letzten Zeile der Fig. 23 gezeigt. Wie zu sehen ist, können zwei Datenworte pro 32-Bit- Buszyklus gewonnen werden.

Der Context-Schaltbefehl aktiviert das Zeilenpuffer-Steuer­ gerät für ein neues zu ladendes Objekt und enthält ein 12-Bit- Absolutursprungsfeld, ein Datenmodus-Bit und ein Bit, das zur Anzeige der Polarität einer eingebetteten Maske (E-Polarität) verwendet wird. Das Feld 77 wurde vorstehend erörtert. Dieser Befehl kann auch innerhalb eines Objekts dazu verwendet wer­ den, ein Unterobjekt zu wählen, wie weiter unten beschrieben wird.

Der Run-Schirm-Befehl dient beispielsweise zum Löschen des gesamten Bildschirms. Er enthält ein Datenformatfeld und ein 16-Bit-Datenfeld.

In Fig. 23 sind fünf Beispiele der Bit Map-Datenformate ange­ geben. Das "D-Format" 5-Bit-Feld informiert das Steuergerät gemäß Fig. 9 über das besondere Format der aus dem RAM 35 gelesenen Daten. Die erste Zeile zeigt ein 1-Bit pro Pixel- Format und die letzte ein 16-Bit pro Pixel-Format.

Zeilenpuffer-Steuergerät

Im folgenden wird auf Fig. 9 Bezug genommen. Das Steuergerät weist ein 12-Bit-Absolutursprung-Register 124, ein 12-Bit-Run- Startregister 125 und einen 12-Bit-Positionszähler 126 auf. (Während theoretisch nur 10 Bits für diese Register benötigt werden, sind zwei zusätzliche Bits zum "Abschneiden" (cropp­ ing) zweckmäßig).

Der absolute Ursprung wird beispielsweise vom Context-Schalt­ befehl an das Register 124 gegeben. Das Grenze-rechts-Feld vom Run-Befehl ist eine relative Grenze und muß in eine absolute Grenze umgesetzt werden. Dies geschieht durch einen Addierer 134. (Die Grenze wird auf den Bus 113 gegeben.) Dieses Merkmal ist besonders zweckmäßig, wenn Unterobjekte verwendet werden, wie dies nachfolgend erläutert werden wird. Die linke Grenze wird von dem rechten Ursprung und dem absoluten Ursprung von einem Addierer 135 abgeleitet. Das Run-Start-Register 125 wird für den Sequenz-Run-Befehl verwendet und ermöglicht die Fest­ stellung, wo der letzte Run endete. Der Positionszähler 126 dient dem Bit Map-Befehl zur Erzeugung der Bit Map-Schreib­ adresse. Die Grenze links/Adresse wird an den Bus 112 ange­ legt.

Wie oben erwähnt, wird das erste Feld des Befehlsworts an den Decodierer 128 angelegt, und nach der Decodierung steuert der Befehl die Operation des Steuergeräts über ein Finite-Zustand- Steuergerät 132′.

Der Datenwort-Zählwert vom Bit Map-Befehl und Sequenz-Run-Be­ fehl wird in einen Zähler 130 eingegeben und zählt abwärts, um das Zählen der Datenworte zu steuern. Das Format der Datenwor­ te wird über die Datenformatschaltung 131 aus den Datenformat­ feldern dieser Befehle ausgewählt. Diese liefern die Schreib­ steuersignale für Bus 116.

Der Zeilenpuffer-Leseadreßzähler 133 ist mit einem Horizontal­ zähler des Displays synchronisiert und macht es möglich, daß der Zeilenpuffer zur Ausgabe an das Display abgetastet wird. Diese Adressen werden über den Bus 117 zu den Zellen gekop­ pelt.

Das nächste Abfertigungssignal (Leitung 105) und Taktfrequenz­ signal bildet einen "handshake" zwischen dem Puffer und dem Verteiler, um einen Signaltransfer zu ermöglichen, wie dies häufig in Computersystemen geschieht.

Zeitgabe zwischen CPU und dem Zeilenpuffer

In Fig. 24 sind eine Reihe von CPU Speicherbuszyklen 138 entsprechend den Aktivitäten auf den Bussen 58 und 59 in Fig. 5 mit einer Reihe von Zeilenpuffer-Ladezyklen 139 entsprechend den Aktivitäten auf den Bussen 58 und 59 in Fig. 5 gezeigt. Dies veranschaulicht die Zeitperiode während des Ladens von Zeile 1 in den Zeilenpuffer, führend zu und folgend dem Über­ gang zwischen dem Laden der Zeile des Objekts n und der Zeile des Objekts n+1, welches die Displayzeile 1 kreuzt. Diese beiden Gruppen von Zyklen können asynchron sein; der Zeilen­ pufferzyklus und die Basiszeitgabe brauchen nicht mit der CPU-Busaktivität synchronisiert zu sein. Nach Beendigung des Ladens einer Zeile von Objekten n der Zeile 1 in Vorbereitung zum Laden einer Zeile des Objekts n+1 von Zeile 1 fertigt der Verteiler ein Signal ab, um zu bewirken, daß das Schieberegi­ ster und der RAM 35 mit den Daten zum Start dieser Zeile des Objets geladen werden, und gleichzeitig koppelt der Verteiler auf den Bus 60 gewisse Befehle (4 Befehle) zum Zeilenpuffer. Diese von dem Verteiler aus dem ODT im Speicher 83 der Fig. 11 abgeleiteten Befehle sind zuerst ein Context-Schaltbefehl, gezeigt in Fig. 22, ein Run-Schirm-Befehl zum Löschen des Maskenbilds über dem Zeilenpuffer, ein Run-Befehl zum Setzen des Maskenbits für ein Darstellungsfeld und schließlich das Wort des Befehls für die Objektbeschreibung jener Zeile. Wich­ tig ist, daß die CPU nicht am Zugriff zum RAM über Busse 58 und 59 während der Periode 142 gehindert ist, selbst wenn Daten gleichzeitig in den Zeilenpuffer über Busse 60 geladen werden. Die einzige Zeit, bei der der CPU-Zugriff zum RAM 35 gesperrt ist, liegt während der kurzen Perioden 141 am Über­ gang zwischen Objekten.

Die rechtwinklige Basis-Bitabbildung bzw. (Bit-Map) (Fig. 12a, 12b)

Fig. 12a zeigt eine einfache 1 Bit/Pixel Bit-Map mit Abmes­ sungen von 240 horizontal und 160 vertikal. Es sei angenommen, daß der Inhalt der Bit-Map eine Textnachricht von schwarzen Buchstaben auf einem weißen Grund ist. Ein "X" ist in den Figuren zur Darstellung der Displaystelle dieser Bit-Map ge­ zeigt. Eine Speicherabbildung bzw. Speicher-Map ist auch in Fig. 12b gezeigt, und zwar unter genauer Angabe, wo sich die Displaydaten im RAM befinden. (Das den Ziffern folgende "H" zeigt an, daß die Zahlenbasis Hexadezimal ist.) Zuerst ist zu beachten, daß die obere Hälfte eines 256 K RAM Feldes gezeigt ist und daß der Speicher in zwei Zeilen von 256 32-Bit-Wörtern (128 Zeilen sind gezeigt, 256 Zeilen stehen zu Verfügung) unterteilt ist. Ferner ist zu beachten, daß die schwarze Zone, die jedem Datenblock zugeordnet ist, in Schwarz gezeigt ist.

Beim Aufbau dieses Displays wird zunächst entschieden, wo eine Farb-Nachschlagetabelle (CLUT) und die Objekt-Abfertigungsta­ belle (ODT) gespeichert werden. Es sei angenommen, daß eine CLUT 128 Worte lang ist und irgendwo im RAM untergebracht werden kann, vorausgesetzt, daß sie nicht eine Zeilengrenze kreuzt. Sie ist bei 28 000H gezeigt. Die gleiche Zeilengren­ zenbeschränkung gilt für die ODT, so daß sie bei 26 000H ange­ ordnet ist.

Der nächste Platz ist der Bit-Map zugeordnet. Die Bit-Map kann als lineare Matrix aufgebaut sein, bei der eine Zeile der nächsten im Speicher folgt, jede Zeile auf eine ganzzahlige Anzahl von Worten aufgerundet. Da die Horizontalabmessung 240 Pixel beträgt, werden bei 1 Bit/Pixel 240 dividiert durch 32= 7,5 Wörter für jede Zeile benötigt. Die für jede Zeile benö­ tigte Speicherkapazität ist auf ein ganzes Wort aufgerundet, so daß 8 Worte jede Zeile einnehmen. Es gibt 160 Zeilen, so daß die gesamte RAM-Kapazität, die für diese Bit-Map benötigt wird, 160×8=1280 Wörter beträgt. Diese Daten sind bei 38 000H gezeigt und erstrecken sich bis 384FFH.

Es ist jetzt notwendig, die Abfertigungstabelleneingabe für das Objekt unter Verwendung des Formats gemäß Fig. 10 aufzu­ bauen.

A) Startadresse

Dieser Parameter weist auf den Beginn der Objektbeschreibung hin: Adresse 38 000H. Zu beachten ist jedoch, daß die codierte Zahl D 000H (38 000H, dividiert durch 4) ist, da eine Wortadres­ se in diesem Feld, nicht eine Byte-Adresse spezifiziert ist und alle Befehle auf 32-Bit-Wortgrenzen ausgerichtet sind.

B) Zeilenmodus

Dieser Parameter gibt an, ob die Zeilenbeschreibungen von fester oder variabler Länge sind. Im Falle dieses Beispiels funktioniert jeder Modus, da die Bit-Map-Zeilenbeschreibungen von fester Länge sind, so daß die Länge im Konstantlängenmodus angegeben werden könnte oder die Länge vom Verteiler durch Angabe des variablen Längenmodus berechnet werden kann. Für die Zwecke dieses Beispiels ist eine "1" für den Festlängenmo­ dus angegeben.

C) Zeilenlänge

Die Länge jeder Zeilenbeschreibung im RAM ist 8 Worte. Es ist notwendig, diesen Parameter anzugeben, da ein Festlängen-Zei­ lenmodus verwendet wird. Zu beachten ist, daß dieser Parameter nicht das erste Wort enthält (d.h. das "erste Wort"-Feld der ODT-Eingabe für das Objekt).

D) Startzeile

Dieses Objekt beginnt an der ersten Zeile der auf dem Bild­ schirm befindlichen Zone, Zeile 0 (siehe Diagramm).

E) Objekthöhe

Die Vertikalabmessung dieses Objekts ist 160, so daß dies auch dessen Höhe darstellt. Das System bedingt, daß das Resultat der Summe dieses Parameters mit der Startzeile die Endzeile, Zeile 159, ist. Daher ist die für diesen Parameter codierte Größe die Höhe Minus 1 oder 159.

F) Absoluter Ursprung

Die am weitesten links gelegenen Pixel dieses Objekts sind am Pixel 0 des Displays. Der absolute Ursprung kann irgendein Wert sein, der 0 oder kleiner ist, da er kleiner oder gleich der Horizontalposition des linken Randes des Objekts sein muß. Der Einfachheit halber ist er hier 0.

G) Konstantwort

Da nur zwei Farben in diesem Beispiel verwendet werden, schwarz und weiß, sei angenommen, daß sie zu Beginn der CLUT gespeichert werden. Es sei auch angenommen, daß das 1 Bit der Pixeldaten mit dem LSB des L-Byte in den Zeilenpufferzellen ausgerichtet ist. Daher bewirkt das Setzen der niedrigen acht Bits des Konstantworts auf 0, daß die 8 Bits der CLUT-Pixelda­ ten mit Ausnahme des LSB (am niedrigesten bewertetes Bit) alle 0 sind. Dadurch wird zwischen den ersten und zweiten CLUT-Ein­ gaben gewählt, welche die Farben schwarz und weiß darstellen.

Das am höchsten bewertete Bit des Konstantworts kann in diesem Parameter nicht spezifiziert werden; es wird auf Null gesetzt, wenn der Verteiler den Zeilenpuffer mit dem Context des Ob­ jekts belegt. Das zweit höchste Bit wird bei diesem Beispiel nicht verwendet, so daß es auf Null gesetzt ist. Auf diese Weise wird der Konstantwortparameter auf 000H gesetzt.

H) Darstellungsfeldursprung und -grenze

Diese Parameter geben an, welche horizontale Zone der Pixelda­ ten der Bit-Map tatsächlich angezeigt wird. Die Abbildung bzw. Map ist 240 Pixel horizontal; sie wird auf die nächsten ganzen Wörter aufgerundet, als ob die Bit-Map horizontal 256 Pixel wäre. Da das System nicht bestimmen kann, wo die realen Pixel des letzten Datenworts eines Bit-Map-Befehls enden und wo die 16 "Überschuß" Pixel beginnen, werden Darstellungsfeldparame­ ter zum Kappen des Displays verwendet, um die Wiedergabe die­ ser Überschußpixel zu verhindern.

Der Darstellungsfeldursprung identifziert das Pixel, wo die reale Bit-Map bzw. Bit-Abbildung beginnt, und zwar relativ zum absoluten Ursprung. Dieses Pixel ist 0 und der absolute Ur­ sprung ist 0, so daß der Darstellungsfeldursprung 0-0=0 ist. Die Darstellungsfeldgrenze identifziert das Pixel, bei dem die reale Bit-Map relativ zum absoluten Ursprung endet, +1. Pixel 239 ist, wo die Bit-Map endet, und der absolute Ursprung ist 0, so daß die Darstellungsfeldgrenze 239-0+1=240 ist. Die Überschußpixelzone (siehe 12 a) von Pixel 240 bis Pixel 255 ist jetzt maskiert, da sich das Darstellungsfeld nur zwischen den Pixeln 0 und 239 erstreckt. Die gewünschte Horizontaldimension von 240 wird auf diese Weise erreicht.

I) Displaymodus

Für dieses Beispiel werden X, L anstelle von RGB verwendet. Daher ist das Displaymodus-Bit 0.

J) Eingebettete Maskenpolarität

Die eingebettete Maskenfunktion wird nicht verwendet, so daß die Polarität nicht definiert zu werden braucht.

K) Erstes Wort

Dieses Wort hält den Bit-Map-Befehl und macht die lineare Bit-Map-Matrix-RAM-Organisation möglich. Wenn eine Datenzeile aus dem RAM in den Zeilenpuffer gelesen wird, wird der Puffer zunächst mit den oben aufgeführten relevanten Parametern kon­ figuriert, und danach wird das erste Wort (behandelt als Be­ fehlswort) verwendet. Erst danach wird der Rest der Zeilenbe­ schreibung aus dem RAM benutzt. Bei diesem Beispiel enthält das erste Wort einen Bit-Map-Befehl. Ein Bit-Map-Befehl wird gefolgt von Datenwörtern, die die Pixeldaten der Bit-Map ent­ halten. Diese Datenwörter werden in diesem Falle gefunden durch Start mit Beginn desjenigen Abschnitts der Zeilenbe­ schreibung im RAM, der dort liegt, wo die lineare Bit-Map-Ma­ trix gespeichert ist.

Beginnend mit der ersten Zeile des Objekts wird das Objekt an der Zeile 0 abgefertigt (d.h. der Verteiler initiiert das Laden der Objektbeschreibung für diese Zeile in den Zeilenpuf­ fer), und der Zeilenpuffer wird entsprechend den Abfertigungs­ tabellen-Eingabeparametern konfiguriert. Danach wird das erste Wort, der im vorhergehenden Absatz genauer beschriebene Bit- Map-Befehl, aufgenommen und ausgeführt. Der Zeilenpuffer wird für eine Bit-Map bzw. -abbildung vorbereitet und erwartet acht Datenwörter (256 1 Bit-Pixel), die zur Beschreibung der Bit- Map eingegeben werden. Die Startadresse weist auf das erste dieser Datenwörter, tatsächlich das Wort der Daten für die linear Bit-Map-Matrix, hin, und dieses und die folgenden sie­ ben Wörter werden zum Aufbau der ersten angezeigten Zeile für das Objekt geladen.

Bei der zweiten Zeile konfiguriert die CPU wiederum den Zei­ lenpuffer und führt das gleiche erste Wort erneut aus, und der Zeilenpuffer erwartet wiederum acht Worte von Bit-Map-Daten. Nur weist zu dieser Zeit die Startadresse aus dem Verteiler auf das neunte Datenwort. Es wurde durch den Wert im Zeilen­ längenparameter: 8 (siehe Fig. 10) inkrementiert. Die Daten­ wörter 9-16 (angenommene Numerierung aus 1) sind für die zweite Displayzeile des Objekts vorgesehen. Zu beachten ist, daß die neunten bis sechzehnten Wörter der linearen Bit-Map- Matrix genau der zweiten Zeile der Bit-Map entsprechen.

Dieser Prozeß setzt das Laden in jeder aufeinanderfolgenden Zeile der Bit-Map-Daten fort, bis das Zeilenende jeder Zeile des Objekts erreicht ist. Zu beachten ist, daß der gleiche Bit-Map-Befehl, der in der ODT gespeichert ist, für jede Zeile benutzt wird, da das bei diesem Beispiel verwendete Bit-Map- Objekt zufällig rechtwinklig ist.

Horziontale Positionierung (Fig. 13a und 13b)

Es sei unterstellt, daß das Objekt in Fig. 12a bewegt werden muß. Eine fundamentale Manipulation ist die Positionierung des Objekts im Displayraum. Die Positionierung ist in zwei ge­ trennte Schritte unterteilt, horizontal und vertikal. Zunächst sei die horizontale Positionierung betrachtet (die vertikale Positionierung wird im nächsten Abschnitt erörtert). Es sei beispielsweise angenommen, daß das Objekt um 160 Pixel nach rechts umpositioniert werden soll. Zu beachten ist, daß die Displaydaten identisch mit denjenigen des Objekts in dessen ursprünglicher Position in Fig. 12a sind; zum Umpositionieren des Objekts werden die Daten im RAM 35 nicht bewegt. Stattdes­ sen wird der Absolutursprung-Parameter in der Abfertigungsta­ belleneingabe geändert.

Während der absolute Ursprung im vorhergehenden Abschnitt auf 0 gesetzt wurde, wird er hier auf 160 gesetzt. Jetzt ist die horizontale Positionierung innerhalb der Objektbeschreibung überall auf 160 anstatt auf 0 bezogen, und alles verschiebt sich dementsprechend um 160 Pixel nach rechts.

Zu beachten ist, daß das durch den Darstellungsfeldursprung und die Darstellungsfeldgrenze definierte Darstellungsfeld zusammen mit dem Rest des Objekts verschoben wurde, so daß die Überschußpixel noch geeignet maskiert sind. Dies liegt daran, daß diese Parameter auf den absoluten Ursprung bezogen sind und jetzt ebenso um 160 verschoben sind. Es ist jedoch eben­ falls zu beachten, daß ein Bereich links von dem maskierten Objekt vorhanden ist. Er beeinträchtigt das Display in diesem Beispiel nicht, da nichts links von dem absoluten Ursprung geschrieben werden kann, jedoch kommt er in einem Beispiel weiter unten ins Spiel.

Dieses Objekt könnte von seiner Ursprungsposition in die neue Position (beispielsweise durch die CPU) zu irgendeiner Zeit bewegt werden, jedoch würde der Displayübergang zwischen Rah­ men auftreten. Das heißt, wenn in der Rahmenmitte, auf halbem Wege der Anzeige dieses Objekts, das Objekt von der CPU durch Änderung des Absolutursprungsparameters im RAM bewegt würde, so würde der Rest des Objekts in diesem Rahmen weiterhin mit dem alten Absolutursprungsparameter gezeichnet.

Vertikale Positionierung (Fig. 14a und 14b)

Zum Umpositionieren des Objekts der Fig. 12a in Vertikalrich­ tung ist es nur notwendig, den Startzeilenparameter zu ändern. Wenn die erste Zeile des Objekts die Zeile 80 sein soll, so wird die einfache Änderung des Startzeilenparamters auf 80 von dessen aktuellen Wert von 0 durchgeführt. Die CPU lädt danach die erste Zeilenbeschreibung bei Zeile 80, und jede nachfol­ gende Zeilenbeschreibung wird mit jeder nachfolgenden Zeile geladen. Das sich ergebende Bild ist in Fig. 14a gezeigt.

Die Speicheranordnung bleibt exakt die gleiche, wie in Fig. 14b gezeigt ist; die vorhergehende horizontale Positionierung (Fig. 14a) wird in keiner Weise von dieser Vertikaländerung berührt.

Wie bei der Horizontaländerung tritt unabhängig von dem Zeit­ punkt der Änderung des Startzeilenparameters die Vertikalver­ schiebung sauber zwischen Rahmen auf.

Horizontale Darstellungsfelder (Fig. 15a und 15b)

Der Darstellungsfeldmechanismus kann für mehr als die Maskie­ rung von Überschußpixeln benutzt werden. Zu betrachten ist das Display gemäß Fig. 15a.

Hier ist das bewußte Maskieren von einigen der realen Pixel der Bit-Map für das Objekt 0 gezeigt. Dies entspricht logisch dem, was stattfindet, wenn ein Fenster horizontal auf bei­ spielsweise einem Apple Macintosh Computer verkleinert wird, so daß es horizontal schmaler ist als die Bit-Map, die es enthält, und ein horizontaler Verschiebemec 20201 00070 552 001000280000000200012000285912009000040 0002003718501 00004 20082hanismus beispiels­ weise zum Sichtbarmachen unterschiedlicher Teile der Bit-Map verwendet wird. Auch hier bleibt die Speicheranordnung ungeän­ dert. Der gesamte Effekt wird von den Abfertigungstabellenein­ gaben gesteuert: Hauptsächlich dem Darstellungsfeldursprung und der Darstellungsfeldgrenze. Die linke Maskenzone wird hier verwendet, um einige Pixel abzudecken, während sie bei dem vorhergehenden Beispiel nicht verwendet wurde. Die rechte Maskenzone wird zum Abdecken einiger realer Pixel sowie der Überschußpixel benutzt. die Darstellungsfeldposition und -grö­ ße wird wie folgt gesteuert: Der Darstellungsfeldursprung weist auf die Pixel am linken Rand des Darstellungsfeldes relativ zum absoluten Ursprung hin, und die Darstellungsfeld­ grenze weist auf die Pixel am rechten Rand des Darstellungs­ feldes +1 und relativ zum absoluten Ursprung hin. In diesem Falle ist der Darstellungsfeldursprung 200-160=40 und die Darstellungsfeldgrenze 359-160+1=200.

Wie der Positionsänderung findet die Displayänderung des Ob­ jekts zwischen den Rahmen unabhängig davon statt, wann die Parameteränderung stattfindet. Beide Parameter müssen jedoch geändert sein, bevor ein Rahmen zur Anzeige gebracht wird. Um zu garantieren, daß ein Rahmen nicht mit dem neuen Darstel­ lungsfeldursprung, jedoch mit der alten Darstellungsfeldgrenze zur Anzeige gebracht wird, müssen beide Felder in einem nicht unterbrechbaren Speicherzyklus geschrieben werden.

Horizontale Bildverschiebung (Fig. 16 und 16b)

Wenn die Bit-Map ein Fenster wäre, wie bei dem oben erwähnten Macintosh-Computer, so wäre es erforderlich, einen horizonta­ len Bilddurchlaufeffekt innerhalb des horizontalen Darstel­ lungsfeldes zu unterstützen. Um diesen Effekt zu erreichen, wird das Objekt und nicht das Darstellungsfeld bewegt. Daher ist alles, was geändert wird, das relative Ursprungsfeld des Bit-Map-Befehls im ersten Wort, das in der ODT-Eingabe enthal­ ten ist, und die Bit-Map bewegt sich ohne Beeinträchtigung des Darstellungsfeldes. Wenn der relative Ursprung von 0 auf 20 geändert wird, ergibt sich das Display gemäß Fig. 16a (wie­ derum ist zu beachten, daß die Displaydaten im RAM die glei­ chen bleiben).

Eine Bildverschiebung nach links vom absoluten Ursprung kann nicht durchgeführt werden. Wenn daher eine Bildverschiebung nach links vom absoluten Ursprung erforderlich ist, muß der absolute Ursprung nach links bewegt werden, wobei der relative Ursprung des Bit-Map-Befehls und derjenige des Darstellungs­ feldursprungs und der Grenze zur Kompensation eingestellt werden.

Vertikales Darstellungsfeld (Fig. 17a und 17b)

In Fig. 17a ist das Objekt sowohl vertikal als auch horizon­ tal maskiert, d.h. es hat ein vertikales Darstellungsfeld sowie ein horizontales. Anders als bei horizontalen Darstel­ lungsfeldern ist ein direkte Unterstützung nicht vorgesehen, und die vertikalen Darstellungsfelder müssen von der CPU er­ zeugt werden, welche die ODT-Eingabe für dieses Objekt vorbe­ reitet.

Die Art, wie dies erreicht wird, besteht darin, daß die CPU die Objektbeschreibung derart ändert, daß sie nur die anzuzei­ genden Zeilen des Objekts beschreibt. Wenn das vertikale Dar­ stellungsfeld der Fig. 17a von Zeile 100 zu 199 reicht, be­ deutet dies, daß die Objektbeschreibung nur diese Zeilen des Objekts enthält. Dann zeigt das System die vom Darstellungs­ feld (viewport) "maskierten" Zeilen einfach nicht.

In diesem Beispiel sind die sichtbaren Zeichen des Objekts von der zwanzigsten Zeile zur 119ten Zeile, da 20 Zeilen von der Oberkante und 40 Zeilen von der Unterkante von dem Darstel­ lungsfeld maskiert sind. Der Startadressenparameter wird geän­ dert, um auf die Zeilenbeschreibung für die 20ste Zeile hinzu­ weisen, da dort das neue Objekt starten wird. Danach wird der Startzeilenparameter auf Zeile 100, die erste Zeile im Display des neuen Objekts, geändert. Schließlich wird der Objekthöhen­ parameter auf 99 eingestellt, um die neue Höhe des Objekts zu berücksichtigen. Das Ergebnis ist die angezeigte Zone im Zen­ trum der Fig. 17a.

Vertikaler Bilddurchlauf (Fig. 18a und 18b)

Ebenso wie der horizontale Bilddurchlauf-Mechanismus in einem Macintosh-Computer eine horizontale Bildverschiebung (scroll­ ing) bewirkte, bewirkt der vertikale Bilddurchlaufmechanismus die vertikale Bildverschiebung. Der Effekt einer vertikalen Bildverschiebung um 20 Zeilen aufwärts ist in Fig. 18a ge­ zeigt.

Die vertikale Bildverschiebung macht es wiederum erforderlich, das Objekt zu bewegen, während das Darstellungsfeld festgehal­ ten wird. Das Objekt wird vertikal in die gewünschte neue Position gebracht, beginnend mit der Zeile 60. Danach wird ein neues vertikales Darstellungsfeld ebenso wie vorher einge­ stellt, mit Ausnahme dessen, daß es an der 40sten Zeile des Objekts beginnt und an der 199sten Zeile endet.

Beliebig geformte Darstellungsfelder (Fig. 19a, 19b und 19c)

Manchmal wird ein Darstellungsfeld gebraucht, das nicht recht­ winklig ist. Dies läßt sich dadurch erreichen, daß ein Bit/Pixel-Objekt definiert wird, welches als eine Maske be­ nutzt wird. Dieses Objekt (Objekt 0 für die Zwecke der vorlie­ genden Erläuterung) wird direkt hinter dem Objekt (d.h. bei der nächst niedrigeren Priorität) angeordnet, auf das sich das Darstellungsfeld richtet (in diesem Beispiel als Objekt 1 bezeichnet). Das Schreibmodus-"Maskenbit" wird für Objekt 0 verwendet, so daß Objekt 0 in das Maskenbit in den Zellen (107 in Fig. 6) des Zeilenpuffers geladen wird. Wo Objekt 1 mas­ kiert werden soll, werden Nullen für das Bit verwendet, an­ derenfalls werden Einsen in die Zellen geschrieben. Dann wird in der Abfertigungstabelleneingabe für Objekt 1 die Darstel­ lungsfeldgrenze auf 0 gesetzt. Dadurch wird verhindert, daß der automatische Darstellungsfeldmechanismus in das Darstel­ lungsfeld eingreift, wenn Objekt 1 abgefertigt wird.

Objekt 0 wird auf folgende Weise erzeugt: (1) das automatische Darstellungsfeld wird zum Maskieren aller Pixel auf dem Schirm benutzt, (2) ein einzelner Run-Befehl für jede Zeile wird jetzt zum Löschen der Maskenbits von der linken zur rechten Seite der Ellipse für diese Zeile benutzt ( zu beachten ist, daß jeder Zeilenrun unterschiedlich ist, so daß das erste Wort der ODT-Eingabe nicht für den Run-Befehl genutzt werden kann), (3) ein NOP (no operation)-Befehl (gewonnen durch eine 0-Kon­ figuration eines gültiges Befehls) wird für das erste Wort angegeben, wobei ein Run-Befehl als das erste (und nur) Wort jeder Zeilenbeschreibung im RAM benutzt wird (d.h. der zweite Befehl jeder Zeilenbeschreibung). Für diese Zeilen über und unter der Ellipse wird ein NOP für jenes Wort gesetzt.

Die Objekt-Null-Maske ist in Fig. 19a gezeigt, und das resul­ tierende Display aus der Bit-Map der vorhergehenden Beispiele, aufgelegt auf die Oberseite von Objekt 0, ist in Fig. 19c gezeigt. Nur die Zone der Bit-Map in der Ellipse wird zur Anzeige gebracht. Zu beachten ist, daß Objekt 0 des vorherge­ henden Beispiels das Objekt 1 bei diesem Beispiel bildet.

Eingebettete Masken (Fig. 20a, 20b und 20c)

Es ist manchmal notwendig, einem Hintergrundobjekt ein Text- Bit-Map-Objekt aufzulegen, wobei der Hintergrund zwischen den Buchstaben durchscheint. Dies kann durch Verwendung eines Hintergrundobjekts und dann durch Verwendung eines gewöhn­ lichen Maskenobjekts, das dem Textmuster entspricht, und schließlich durch Verwendung des Textobjekts über der Maske erreicht werden. Es gibt jedoch einen einfacheren Weg unter Verwendung eingebetteter Masken.

Das Textobjekt ist bei diesem Beispiel eine 1 Bit/Pixel-Bit- Map und es tritt der Fall ein, daß zur Herstellung einer gewöhnlichen Maske eine 1 Bit/Pixel-Bit-Map mit genau dem gleichen Muster benötigt wird. Unter Nutzung dieser Tatsache lädt die Bit-Map in den Zeilenpuffer, und die Maskieroperation mit der gleichen Text-Bit-Map kann kombiniert werden.

Zunächst wird das Hintergrundobjekt gemacht (z.B. 240×160 und 4 Bits/Pixel) wie in Fig. 20a als Objekt 0 gezeigt ist. Zu beachten ist, daß es keine horizontale Maske hat. Dies liegt daran, daß bei 4 Bits/Pixel bei einer Horizitalabmessung von 240 exakt 30 Wörter pro Zeile (ohne überschüssige Pixel) ver­ wendet werden. (Zweckmäßigerweise wird das horizontale Dar­ stellungsfeld entaktiviert.) Wenn es erwünscht ist, daß 16 durch diese Bit-Map abgebildete Farben von den zwei Farben der Text-Bit-Map getrennt werden, wird das untere Byte des Kon­ stantworts so eingestellt, daß bei seiner Kombination mit den 4 Bits der Pixeldaten der resultierenden Index auf einen ge­ eigneten Platz in der CLUT hinweist.

Die Text-Bit-Map aus den vorhergehenden Beispielen kann zur Aktivierung der eingebetteten Maskenfunktion genutzt werden. Zunächst muß dafür gesorgt werden, daß die weißen Hintergrund­ masken nicht im Zeilenpuffer überschreiben und die schwarzen Buchstaben nicht maskieren, anstatt zu überschreiben. Dies wird durch das "e"-Polaritätsbit in der Abfertigungstabellen­ eingabe bestimmt. Wenn schwarz 1 und weiß 0 ist, so wird 1 zum Zulassen von Schreiboperationen verwendet, wodurch die e-Pola­ rität auf 1 gesetzt wird. Jetzt wird der Bit-Map-Befehl im ersten Wort so eingestellt, daß der eingebettete Maskenmodus gewählt wird mit dem e-Modusbit auf 1.

Zu beachten ist, daß die eingebetteten Masken nicht die Not­ wendigkeit beseitigen, in horizontales Darstellungsfeld zum Abdecken der Überschußbits dieses Objekts zu haben. Diese Maskierfunktion arbeitet mit dem Maskenbit in der Pixelspei­ cherzelle und ist unabhängig von der eingebetteten Maskenfunk­ tion. Wenn eine oder beide Masken Schreiboperationen an einem vorgegebenen Pixel verbieten, so wird die Schreiboperation gesperrt.

Das resultierende Display ist in Fig. 20c gezeigt. Das Dis­ play würde tatsächlich Text am Kopf eines Musters zeigen, wobei das Muster durch die Zwischenräume zwischen den Buchsta­ ben durchscheint. Die Speichernutzung ist in Fig. 20b ge­ zeigt.

Runs und komplexe Objekte (Fig. 21a, 21b, 21c und 21d)

Dieser Abschnitt zeigt Beispiele von Spezialobjekten, deren Objektbeschreibungen in solcher Weise spezifiziert werden können, daß Speicher, Zeit und Kapazität ökonomischer gemacht werden können. Zu beachten ist, daß alle in diesem Abschnitt gezeigten Objekte unter Verwendung der rechtwinkligen Bit-Map spezifiziert werden können, wie sie in den vorhergehenden Abschnitten mit geeigneter Maskierung erörtert worden ist. Spezialobjekte treten gewöhnlich in ausreichendem Umfange auf, und die Einsparungen gehen weit genug, so daß die besonderen Fähigkeiten, wie sie in diesem Abschnitt erörtert werden, zweckmäßig sind.

Die in diesem Abschnitt erörterten Spezialfall-Objekte beste­ hen weitgehend aus Runs (Durchläufen), und derartige Objekte werden als Run-Klassen-Objekte bezeichnet. Die Hauptfähigkeit, welche die Run-Klassen-Objekte lohnend macht, ist der voll parallele Ablauf. Dies wird dadurch implementiert, daß alle den Run bildenden Pixel gleichzeitig in den Zeilenpuffer ge­ schrieben werden.

Hintergründe (Einzelfarbe)

Ein Anwendungsgebiet, in welchem Run-Klassen-Objekte unmittel­ bar ihren Wert zeigen, ist dasjenige der Erzeugung von Hinter­ gründen. Hintergründe, die alle aus einer Farbe bestehen und anderenfalls durch eine große 1 Bit/Pixel-Bit-Map dargestellt würden, können jetzt mit einem einzigen Run pro Zeile gezeich­ net werden. Große Hintergründe mit statischen Objekten (z.B. Bäumen, Gebiergen, Wolken, Himmel) können mit einer handvoll Runs pro Zeile spezifiziert werden, was um Größenordnungen kleinere Speicher- und Zeilenpufferschreibzeiten als eine vergleichbare Bit-Map-Darstellung erforderlich macht. Tatsäch­ lich können Hintergründe, die größer als der Bildschirm sind, wirksam gespeichert und manipuliert werden, um die Illusion zu vermitteln, daß der Schirm ein Sichtfenster in eine andere Zone darstellt. (Vgl. Fig. 21a und 21c).

Um dies zu machen, wird die Abfertigungstabelleneingabe auf die Priorität gesetzt, bei der der Hintergrund erscheinen soll. Danach wird die Startzeile mit der ersten Hintergrund­ zeile geladen; Objekthöhe mit ihrer Höhe - 1; Absolutursprung auf die linke Grenze des Hintergrunds; Darstellungsfeldur­ sprung und -grenze beide auf 0; Konstantwort und Displaymodus beliebig; Startadresse, e-Polarität, Zeilenmodus und Zeilen­ länge auf beliebigen Wert. Jetzt wird das erste Wort mit einem Run-Befehl geladen, wobei R-Ursprung auf 0 gesetzt wird; R- Grenze auf die Horizontalabmessung des Hintergrunds; End-Zei­ le auf 1; und Daten-7, W-Modus und D-Ausrichtung wie ge­ wünscht.

Auf jeder Zeile des Objekts wird der eine Run-Befehl im ersten Wort ausgeführt, wobei ein Run von der linken Seite des Hin­ tergrunds nach rechts erzeugt wird. Zu beachten ist, daß kein Raum im RAM jedem Objekt zugeordnet ist, da jedes vollständig von dem ersten Wort erzeugt wird, mit Ausnahme natürlich der vier Wörter in der Abfertigungstabelleneingabe.

Hintergrund (mehrfarbig)

Zum Zwecke der Erläuterung werden im folgenden kleine Objekte, die zur Bildung eines einzigen zusammengesetzten Objekts zu­ sammengruppiert sind, als Subobjekte bezeichnet. Ein Objekt, das zwei oder mehr Subobjekte enthält, wird als ein komplexes Objekt bezeichnet. Ein komplexes Objekt (Waldszene) ist darge­ stellt, in dem jedes Subobjekt mit einem Buchstaben in Fig. 21a identifiziert ist.

Ein Subobjekt kann aus Bit-Maps, Runs oder aus beiden aufge­ baut sein, und es kann eine beliebige Anzahl von Subobjekten in einem Objekt vorhanden sein. In der Waldszene gemäß Fig. 21a gibt es 12 Subobjekte, von denen jedes ein fester, einfar­ biger und durch Runs dargestellter Bereich ist. Subobjekte können einander auch überlappen, und tatsächlich ist Subobjekt A ein einfaches Rechteck - der in der Figur für Subobjekt A gezeigte komplexe Bereich resultiert aus den Überlappungen der Subobjekte vor dem Subobjekt A.

Um die Objektbeschreibung für die Waldszene zu erzeugen, wer­ den die Subobjekte durch Subpriorität (die Überlappungspriori­ tät der Subobjekte) geordnet, Hintergrund zu Vordergrund. ("A" ist das am weitesten im Hintergrund gelegene Subobjekt, M das am weitesten dem Vordergrund zugewandte Objekt.) Eine Objektbeschreibung wird erzeugt, deren Zeilenbeschrei­ bungen auf den einzigen absoluten Ursprung des komplexen Ob­ jekts bezogen sind. Da die linke Grenze des komplexen Objekts bei Pixel -100 ist, wird sein absoluter Ursprung auf -100 eingestellt. Da jedes Subobjekt in diesem komplexen Objekt eine durchgehende Zone einer Farbe ist, kann jede Subobjekt- Zeilenbeschreibung durch einen einzigen Run-Befehl wiederholt werden. Subobjekte A, B, C, D, E, J, K und L sind alle recht­ winklig, so daß für jede der Zeilenbeschreibungen der gleiche Run-Befehl (beginnend am linken Rand des Rechtecks und endend an dessen rechtem Rand) spezifiziert werden kann. Beispiels­ weise ist Subobjekt B 40 Pixel breit, 220 Zeilen hoch und hat seinen linken Rand am Pixel 60. Es wird durch 220 Run-Befehle beschrieben, deren relativer Ursprung auf jeweils 40 (-60-(- 100)) und relative Grenze auf 80 (-21-(-100)+1) eingestellt sind.

Subobjekt F, G, H und I sind Kreise, die jeweils über ihren Mittelpunkt vertikal symetrisch sind; daher können die Zeilen­ beschreibungen für die obere Hälfte in ihrer Reihenfolge zur Erzeugung der unteren Hälfte reversiert werden. Zur Bestimmung des Run-Satzes der oberen Hälfte wird der linke und rechte Rand des Kreises auf jeder Zeile unter Verwendung einfacher Geometrie bestimmt, und danach wird ein Run-Befehl für jede Zeile erzeugt, dessen relativer Ursprung am linken Rand und dessen relative Grenze am rechten Rand ist.

Subobjekt M ist ein Dreieck. Wie bei den kreisförmigen Subjek­ ten wird Geometrie verwendet, um die linken und rechten Ränder jeder Zeile zu bestimmen; danach wird diese Information zum Auffinden des relativen Ursprungs und der relativen Grenze des Run-Befehls für die Zeilenbeschreibungen verwendet. Um diese Objektbeschreibungen für die verschiedenen Subjekte in die eine Objektbeschreibung des komplexen Objekts für die gesamte Waldszene zusammenzusetzen, ist es nötig, die verschiedenen Subobjekt-Zeilenbeschreibungen Zeile für Zeile zu verzahnen, und zwar mit der niedrigsten Subpriorität-Subobjekt-Zeilen­ beschreibung auf jeder Zeile zuerst und der höchsten Subprio­ rität der Subobjekt-Zeilenbeschreibung zuletzt. Dies ist in Fig. 21d gezeigt. Vergleiche beispielsweise die 480 Zeilen der Fig. 21d mit den 480 Zeilen der Waldszene. Beachte, daß die Vertikalabmessung und Lage des die Objektbeschreibung für jedes Subobjekt darstellenden gemusterten Balkens der vertika­ len Größe und Lage des Subobjekts selbst in der Waldszene entspricht. Dies liegt daran, daß die Objektbeschreibung jedes Subobjekts nur aus denjenigen Zeilen besteht, wo das Subobjekt existiert. Daher hält jede Zeile eines Schlitzes (siehe Zei­ lennumerierung nach links) die Zeilenbeschreibung entsprechend der gleichen Zeile des Schlitzsubobjekts in der Waldszene (2 Subobjektzeilenbeschreibungsproben sind im Diagramm angege­ ben).

Da jeder Schlitz einem Subprioritätsniveau entspricht, sind die Zeilenbeschreibungen auf jeder Zeile in richtiger Reihen­ folge für die Verzahnung, von links nach rechts, in einer Zeilenbeschreibung des komplexen Objekts (leere Schlitze eli­ minierend.) Das Diagramm auf der unteren rechten Seite zeigt die Schlitze eliminiert und nach links gepackt. Dies ist dann eine Darstellung der verzahnten Subobjekt-Zeilenbeschreibun­ gen, welche die Zeilenbeschreibungen für das komplexe Objekt ausmachen.

Zu beachten ist, daß die Subpriorität im Zeilenpuffer dadurch gehandhabt wird, daß man überschreibt, wenn jede Subobjekt- Zeilenbeschreibung in den Zeilenpuffer geladen wird. Die Subobjekte mit der niedrigsten Subpriorität werden in den Zeilenpuffer zuerst geschrieben (da sie die ersten in den komplexen Objekt-Zeilenbeschreibungen sind), und sie werden von Subobjekten mit höherer Subpriorität in deren Überlap­ pungsbereich übergeschrieben.

Die Objektbeschreibungen haben das erste Wort jeder Zeilenbe­ schreibung gemeinsam für alle Zeilen des Objekts in der Abfer­ tigungstabelleneingabe gespeichert. Wenn jede Zeilenbeschrei­ bung einer Objektbeschreibung mit dem gleichen Instruktionsbe­ fehlswort startet, so kann dann das Befehlswort in das "erste Wort" gelegt werden und dadurch vermieden werden, daß es indi­ viduell im RAM für jede Zeile der Objektbeschreibung gespei­ chert wird. Bei Prüfung des Balkendiagramms und der Waldszene ist zu erkennen, daß auf jeder Zeile das erste Worte das glei­ che ist: Es ist das Einzelwort eines Run-Befehls eines Subob­ jekts A. Auf jeder Zeile des komplexen Objekts erzeugt Subob­ jekt A einen Run-Befehl mit seinem relativen Ursprung bei 0 und seiner relativen Grenze bei 940. Daher können direkt 480 Worte (ein Wort pro Zeile) an Speicherkapazität dadurch ge­ spart werden, daß man diesen Befehl in das erste Wort legt.

Claims (44)

1. Videoanzeigegerät, gekennzeichnet durch:
einen ersten Speicher zur Speicherung von eine Vielzahl von Objekten für die Anzeige darstellenden Daten, die für jedes Objekt in angrenzend zugreifbaren Plätzen im ersten Speicher gespeichert sind, wobei der erste Speicher eine un­ terschiedliche Anzahl von Bits pro Pixel eines jeden der Ob­ jekte derart speichert, daß eines der Objekte in einer anderen Anzahl von Plätzen als ein anderes der Objekte speicherbar ist,
einen Attribute für jedes der Objekte speichernden zwei­ ten Speicher,
eine die Attribute aus dem zweiten Speicher zur Steuerung des Zugriffs zu den Daten in dem ersten Speicher steuernde erste Steuereinrichtung, die mit den ersten und zweiten Spei­ chern gekoppelt ist, und
einen die Daten aus dem ersten Speicher aufnehmenden Puffer, der mit dem ersten Speicher und der ersten Steuerein­ richtung gekoppelt ist,
wobei die im ersten Speicher gespeicherten Daten zur Anzeige vorbereitet werden.

2. Videoanzeigegerät nach Anspruch 1, dadurch gekennzeich­ net, daß der erste Speicher zur Speicherung von Informationen vorgesehen ist, welche die Anzahl von Bits pro Pixel von Daten darstellen, die im ersten Speicher für jedes der Pixel gespei­ chert sind.

3. Videoanzeigegerät nach Anspruch 1 oder 2, dadurch gekenn­ zeichnet, daß der erste Speicher eine Vielzahl von seriellen Ausgabewörtern für jede an den ersten Speicher angelegte Adresse liefert.

4. Videoanzeigegerät nach einem der Ansprüche 1 bis 3, da­ durch gekennzeichnet, daß eine zentrale Recheneinheit (CPU) mit dem ersten Speicher derart gekoppelt ist, daß sie zu dem ersten Speicher Zugriff nehmen kann, und daß dieser Zugriff der CPU asynchron zum Zugriff der ersten Steuereinrichtung zum ersten Speicher ist.

5. Videoanzeigerät nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, daß die ersten und zweiten Speicher in einem einzigen Speicher integriert sind.

6. Videoanzeigegerät, gekennzeichnet durch
einen ersten Speicher zur Speicherung von eine Vielzahl von Objekten für die Anzeige darstellenden Daten, die für jedes Objekt in benachbart zugreifbaren Plätzen des ersten Speichers gespeichert sind, wobei der erste Speicher eine andere Datenlänge für jede Zeile jedes der Objekte speichert, so daß eines der Objekte in einer anderen Anzahl der Plätze als ein anderes der Objekte speicherbar ist,
einen zweiten Speicher zur Speicherung von Attributen für jedes der Objekte,
eine die Attribute aus dem zweiten Speicher zur Steuerung des Zugriffs zu den Daten im ersten Speicher steuernde erste Steuereinrichtung, die mit den ersten und zweiten Speichern gekoppelt ist und eine Schaltung zur Bestimmung der Länge der Daten für jede der Zeilen enthält, und
einen die Daten aus dem ersten Speicher aufnehmenden Puffer, der mit dem ersten Speicher und der ersten Steuerein­ richtung gekoppelt ist,
wodurch die in dem ersten Speicher gespeicherten Daten zur Anzeige vorbereitet werden.

7. Videoanzeigegerät nach Anspruch 6, dadurch gekennzeich­ net, daß der erste Speicher eine Vielzahl von seriellen Ausga­ bewörtern für jede an den ersten Speicher angelegte Adresse liefert.

8. Videoanzeigegerät nach Anspruch 6 oder 7, dadurch gekenn­ zeichnet, daß eine zentrale Recheneinheit (CPU) mit dem ersten Speicher derart gekoppelt ist, daß sie zu dem ersten Speicher Zugriff nehmen kann, und daß dieser Zugriff der CPU asynchron zum Zugriff der ersten Steuereinrichtung zum ersten Speicher ist.

9. Videoanzeigerät nach einem der Ansprüche 6 bis 8, dadurch gekennzeichnet, daß die ersten und zweiten Speicher in einem einzigen Speicher zusammengefaßt sind.

10. Videoanzeigegerät, gekennzeichnet durch:
eine zentrale Recheneinheit (CPU),
einen ersten Speicher zur Speicherung von eine Vielzahl von Objekten für die Anzeige darstellenden Daten, die für jedes Objekt in benachbart zugreifbaren Plätzen im ersten Speicher gespeichert sind, wobei der erste Speicher eine be­ liebige Größe in Zuordnung zu jedem der Objekte derart hat, daß eines der Objekte in einer anderen Anzahl der Plätze als ein anderes der Objekte speicherbar ist, und wobei der erste Speicher einen ersten Datenport und einen zweiten Datenport aufweist und eine Vielzahl von seriellen Ausgabewörtern an dem zweiten Port für jede an den ersten Port angelegte Adresse aufweist,
einen die CPU mit dem ersten Speicher koppelnden ersten Bus,
einen Attribute für jedes der Objekte speichernden zwei­ ten Speicher, der mit der CPU gekoppelt ist, eine die Attribu­ te aus dem zweiten Speicher aufnehmende erste Steuereinrich­ tung, welche den Zugriff auf die Daten im ersten Speicher steuert und mit den ersten und zweiten Speichern gekoppelt ist,
einen zweiten Bus, der mit dem zweiten Port des ersten Speichers gekoppelt ist, und
einen die Daten aus dem ersten Speicher aufnehmenden ersten Puffer, der mit dem zweiten Bus und mit der ersten Steuereinrichtung gekoppelt ist.

11. Videoanzeigegerät nach Anspruch 10, dadurch gekennzeich­ net, daß die Datenübertragung über den ersten Bus asynchron mit der Datenübertragung über den zweiten Bus vorgesehen ist.

12. Videoanzeigegerät nach Anspruch 10 oder 11, dadurch ge­ kennzeichnet, daß die ersten und zweiten Speicher in einem einzigen Speicher integriert sind.

13. Videoanzeigegerät nach einem der Ansprüche 10 bis 12, dadurch gekennzeichnet, daß die erste Steuereinrichtung so ausgebildet ist, daß sie auf Daten für eine Displayzeile jedes Objekts zugreift, bevor sie auf Daten für eine andere Display­ zeile für die Objekte Zugriff nimmt.

14. Videoanzeigegerät nach Anspruch 13, dadurch gekennzeich­ net, daß der Puffer Daten für eine Displayzeile für jedes der Objekte aufnimmt und eine Videozeile für das Display liefert.

15. Videoanzeigegerät nach Anspruch 14, dadurch gekennzeich­ nete, daß zwei Puffer zur Erzeugung einer Doppelpufferung derart vorgesehen sind, daß eine Videodatenzeile aus einem der Puffer gelesen wird, wenn der andere der Puffer mit den Daten aus dem ersten Speicher geladen wird.

16. Videoanzeigegerät nach einem der Ansprüche 10 bis 15, dadurch gekennzeichnet, daß eine zweite Steuereinrichtung zur Steuerung des Puffers vorgesehen ist und daß die zweite Steu­ ereinrichtung mit dem Puffer und der ersten Steuereinrichtung gekoppelt ist.

17. Videoanzeigegerät nach Anspruch 16, dadurch gekennzeich­ net, daß die in dem ersten Speicher gespeicherten Daten Anwei­ sungen zur Steuerung der ersten und zweiten Steuereinrichtun­ gen enthalten.

18. Videoanzeigegerät nach einem der Ansprüche 10 bis 17, dadurch gekennzeichnet, daß die in dem zweiten Speicher für jedes der Objekte gespeicherten Attribute die Position der Objekte auf dem Display darstellen.

19. Videoanzeigegerät nach einem der Ansprüche 10 bis 18, dadurch gekennzeichnet, daß eines der im zweiten Speicher gespeicherten Attribute die relative Positon (Priorität) jedes der Objekte vom Vordergrund zum Hintergrund der Anzeige dar­ stellt.

20. Videoanzeigegerät nach Anspruch 19, dadurch gekennzeich­ net, daß die Priorität durch die Reihenfolge bestimmt ist, in der die Attribute für jedes der Objekte in der ersten Steuer­ einrichtung gespeichert werden.

21. Videoanzeigegerät nach einem der Ansprüche 10 bis 20, dadurch gekennzeichnet, daß die im zweiten Speicher gespei­ cherten Attribute die Lage der Daten für jedes der Objekte im ersten Speicher enthalten.

22. Videoanzeigegerät nach einem der Ansprüche 10 bis 21, dadurch gekennzeichnet, daß eines der im zweiten Speicher für jedes der Objekte gespeicherten Attribute eine Anweisung für die im ersten Speicher gespeicherte erste Zeile von Videodaten ist und daß die Anweisung von der zweiten Steuereinrichtung interpretiert wird.

23. Videoanzeigegerät, gekennzeichnet durch:
einen Speicher zur Speicherung von eine Vielzahl von Objekten für die Anzeige darstellenden Daten;
einen mit dem Speicher gekoppelten Puffer, der eine Zeile von Pixeldaten für alle die Zeile für die Anzeige kreuzenden Objekte zusammensetzt, bevor er eine andere Zeile von Pixelda­ ten erhält,
eine Steuereinrichtung zum Steuern des Datenzugriffs auf den Speicher derart, daß eine Zeile von Daten für jedes der Objekte in den Puffer eingelesen wird, um das Zusammensetzen der Pixeldatenzeile für die Anzeige zu ermöglichen, wobei der Puffer für jedes Pixel der Pixeldaten auch zusätzliche, die Art der in dem Puffer zusammengesetzten Pixeldaten darstellen­ de Daten speichert, so daß Pixeldaten unterschiedlicher Arten für die Anzeige geeignet zusammensetzbar sind.

24. Videoanzeigegerät nach Anspruch 23, dadurch gekennzeich­ net, daß eine der durch die zusätzlichen Daten dargestellten Arten von Pixeldaten aus Rot-Grün-Blau-Farbdaten für einen Farbvideomonitor besteht.

25. Videoanzeigegerät nach Anspruch 24, dadurch gekennzeich­ net, daß eine andere der durch die zusätzlichen Daten darge­ stellten Arten von Pixeldaten ein Hinweis auf eine Farbnach­ schlagetabelle ist.

26. Videoanzeigegerät nach Anspruch 25, dadurch gekennzeich­ net, daß die zusätzlichen Daten für jedes der Pixel von Pixel­ daten aus einem Bit bestehen.

27. Videoanzeigegerät nach einem der Ansprüche 23 bis 26, dadurch gekennzeichnet, daß der Speicher eine Vielzahl von Video-Direktzugriffsspeichern enthält.

28. Videoanzeigegerät nach einem der Ansprüche 23 bis 27, dadurch gekennzeichnet, daß die Daten für jedes der Objekte in benachbart zugreifbaren Plätzen in dem Speicher gespeichert sind und daß der Speicher eine willkürliche Unterteilung für jedes der Objekte derart hat, daß eines der Objekte in einer anderen Anzahl der Plätze als ein anderes der Objekte spei­ cherbar ist.

29. Videoanzeigegerät, gekennzeichnet durch:
einen Speicher zur Speicherung von eine Vielzahl von Objekten für die Anzeige darstellenden Daten;
einen mit dem Speicher gekoppelten Puffer, der eine Zeile von Pixeldaten für alle die Zeile für die Anzeige kreuzenden Objekte zusammensetzt, bevor er eine andere Zeile von Pixelda­ ten erhält,
eine Steuereinrichtung, welche den Zugriff auf die Daten in dem Speicher derart steuert, daß eine Zeile von Daten für jedes der Objekte in den Puffer eingelesen wird, um das Zusam­ mensetzen der Pixeldatenzeile für die Anzeige zu ermöglichen,
wobei der Puffer für jedes Pixel der Pixeldaten auch Maskierdaten speichert, welche festlegen, ob Datenpixel für gewisse Objekte in dem Puffer zum Zusammensetzen der Zeile von Pixeldaten zu verwenden sind, wodurch eine Maskierung von Daten erreichbar ist, während die Videodaten zusammengesetzt werden.

30. Videoanzeigegerät nach Anspruch 29, dadurch gekennzeich­ net, daß die Maskierdaten in dem Speicher als eines der Objek­ te speicherbar sind.

31. Videoanzeigegerät nach Anspruch 30, dadurch gekennzeich­ net, daß die Maskierdaten ein Bit pro Pixel in dem Puffer enthalten.

32. Videoanzeigegerät nach einem der Ansprüche 29 bis 31, dadurch gekennzeichnet, daß der Speicher eine Vielzahl von Video-Direktzugriffsspeichern enthält.

33. Videoanzeigegerät nach einem der Ansprüche 29 bis 32, dadurch gekennzeichnet, daß die Daten für jedes der Objekte in kontinuierlich zugreifbaren Plätzen im Speicher abgelegt sind und daß der Speicher eine willkürliche Unterteilung für jedes der Objekte derart hat, daß eines der Objekte in einer anderen Anzahl von Speicherplätzen als ein anderes der Objekte spei­ cherbar ist.

34. Videoanzeigegerät, gekennzeichnet durch:
einen Speicher zur Speicherung von eine Vielzahl von Objekten für ein Display darstellenden Daten,
einen Puffer, der eine Zeile von Pixeldaten für alle die Zeile für das Display schneidenden Objekte zusammensetzt, bevor er eine andere Pixeldatenzeile aufnimmt, und der mit dem Speicher gekoppelt ist, und
eine Steuereinrichtung zur Steuerung des Zugriffs auf die Daten im Speicher derart, daß eine Datenzeile für jedes der Objekte zum Ermöglichen eines Zusammensetzens der Zeile von Pixeldaten für das Display in den Puffer einlesbar ist, wobei der Puffer eine Vielzahl von durch die Steuereinrichtung gleichzeitig adressierbaren Zellen enthält, die jeweils zur Aufnahme von Daten aus dem Speicher über mehrere Datenleitun­ gen geeignet gekoppelt sind und eine Speicherung der Pixelda­ ten für eine Vielzahl von beabstandeten Pixeln derart bewir­ ken, daß von dem Speicher über die Datenleitungen übertragene Daten gleichzeitig in die Zelle für einen Block von benachbar­ ten Pixeln einlesbar sind.

35. Videoanzeigegerät nach Anspruch 34, dadurch gekennzeich­ net, daß jede der Zellen einen der Speicherung von Daten für jedes der Pixel zugeordneten Komparator zum Vergleichen von Adreßsignalen aus der Steuereinrichtung mit gespeicherten Werten aufweist, um festzustellen, ob Daten aus dem Datenbus in die Zellen geschrieben werden sollen.

36. Videoanzeigegerät nach Anspruch 35, dadurch gekennzeich­ net, daß der gespeicherte Wert die Pixelposition in einer Videozeile darstellt.

37. Videoanzeigegerät, gekennzeichnet durch:
einen Speicher zur Speicherung von eine Vielzahl von Objekten für eine Anzeige darstellenden Daten,
einen Puffer, der eine Zeile von Pixeldaten für alle die Zeile für die Anzeige schneidenden Objekte zusammensetzt, bevor er eine andere Zeile von Pixeldaten erhält, und der mit dem Speicher gekoppelt ist, und
eine Steuereinrichtung zur Steuerung des Zugriffs auf die Daten im Speicher derart, daß eine Datenzeile für jedes der Objekte in den Puffer eingelesen wird, um das Zusammensetzen der Pixeldatenzeile für die Anzeige zu ermöglichen, wobei der Puffer für jedes der Pixel der Pixeldaten Rechenmit­ tel zur Durchführung einer Rechnung auf der Basis der Position des Pixels in der Zeile enthält.

38. Videoanzeigegerät nach Anspruch 37, dadurch gekennzeich­ net, daß zwischen der Steuereinrichtung und dem Puffer ein Adreßbus angeordnet ist und daß die Rechenmittel auf Signalen basieren, die an diesen Bus angelegt sind.

39. Videoanzeigegerät nach Anspruch 37 oder 38, dadurch ge­ kennzeichnet, daß die Rechenmittel einen Vergleich ausführen.

40. Videoanzeigegerät, gekennzeichnet durch:
einen Speicher zur Speicherung von eine Vielzahl von Objekten für die Anzeige darstellenden Daten,
einen mit dem Speicher gekoppelten Puffer, der eine Zeile von Pixeldaten für alle die Zeile für die Anzeige schneidenden Objekte zusammensetzt, bevor er eine andere Zeile von Pixelda­ ten erhält, und
eine Steuereinrichtung, welche den Zugriff auf die Daten im Speicher derart steuert, daß eine Zeile von Daten für jedes der Objekte in den Puffer eingelesen wird, um das Zusammenset­ zen der Zeile von Pixeldaten für die Anzeige zu ermöglichen, wobei der Puffer für jedes der Pixel der Pixeldaten Rechenmit­ tel zur Durchführung einer Rechnung auf der Basis von im Puf­ fer gespeicherten Informationen enthält und die Informationen für jedes der Pixel gespeichert sind.

41. Videoanzeigegerät nach Anspruch 40, dadurch gekennzeich­ net, daß die gespeicherte Information programmierbar ist.

42. Videoanzeigegerät nach Anspruch 40 oder 41, gekennzeich­ net durch die Verwendung der gespeicherten Information zum Maskieren.

43. Videoanzeigegerät gekennzeichnet durch:
einen Speicher zur Speicherung von eine Vielzahl von Objekten für eine Anzeige darstellenden Daten;
einen Puffer, der eine Zeile von Pixeldaten für alle die Zeile für die Anzeige kreuzenden Objekte zusammensetzt, bevor er eine andere Zeile von Pixeldaten erhält,
einen den Speicher mit dem Puffer verbindenden Datenbus, eine Steuereinrichtung, welche den Zugriff auf die Daten im Speicher derart steuert, daß eine Datenzeile für jedes der Objekte in den Puffer über den Bus eingeschrieben wird, um ein Zusammensetzen der Zeile von Pixeldaten für die Anzeige zu ermöglichen,
einen den Puffer mit der Steuereinrichtung verbindenden Adreßbus,
wobei der Puffer eine Vielzahl von Zellen jeweils mit einer Vielzahl vorgegebener Pixelspeichermittel zur Speicherung von Daten für ein Pixel enthält und jedem der Pixelspeichermittel Rechenmittel zugeordnet sind, die mit dem Adreßbus zum Ver­ gleich von Signalen auf dem Adreßbus mit der entsprechenden Pixelposition in der Zeile gekoppelt sind und die Speicherung von Daten in den Speichermitteln aus dem Datenbus auf der Basis der Ergebnisse dieses Vergleichs selektiv ermöglichen.

44. Videoanzeigegerät, gekennzeichnet durch:
eine zentrale Recheneinheit (CPU),
einen mit der CPU gekoppelten ersten Speicher zur Spei­ cherung von eine Vielzahl von Objekten für eine Anzeige dar­ stellenden Daten, wobei die Daten für jedes Objekt in benach­ bart zugreifbaren Plätzen im ersten Speicher gespeichert sind und der erste Speicher eine willkürliche Größe für jedes der Objekte hat, so daß eines der Objekte in einer anderen Anzahl von Plätzen als ein anderes der Objekte speicherbar ist,
einen mit der CPU gekoppelten zweiten Speicher zur Spei­ cherung von Attributen für jedes der Objekte,
eine mit den ersten und zweiten Speichern gekoppelte erste Steuereinrichtung zur Aufnahme der Attribute aus dem zweiten Speicher und zur Steuerung des Zugriffs auf die Daten im ersten Speicher,
einen die Daten aus dem ersten Speicher aufnehmenden ersten Puffer, der mit dem ersten Speicher und der ersten Steuereinrichtung gekoppelt ist und Daten für eine Zeile der Anzeige aufnimmt, und
einen mit dem ersten Puffer gekoppelten zweiten Puffer zur zeilenweisen Aufnahme vollständiger Videozeilen aus dem ersten Puffer und zur Speicherung eines Datenrahmens für die Anzeige.