Controller zur Aufbereitung von kodierten Bildinformationen

Die Erfindung betrifft einen Controller zur Aufbereitung von kodierten Bildinformationen in einem elektrografischen Druck¬ oder Kopiergerat. Die Aufbereitung erfolgt so, daß ein Zei¬ chengenerator ein Ladungsbild in Abhängigkeit von der Bildin¬ formation auf einem Zwischenträger erzeugen kann. Die kodier- ten Bildinformationen werden dem Controller, wie er bei¬ spielsweise aus US 5 012 434 bekannt ist, in Form von Befeh¬ len einer bestimmten, standardisierten Sprache von einem HOST oder einer sonstigen Datenverarbeitungsanlage übergeben. Solche Sprachen sind z.B. PCL (Printer Control Language) von Hewlett Packard und IPDS (Intelligent Printer Data Stream) von IBM. Die Befehle enthalten sämtliche Informationen zum Aufbau einer zu druckenden Seite. Insbesondere sind dies Positionierungsinformationen zur Positionierung von Zeichen und Bildern auf einer Seite, Informationen aus welchem Font einzelne Zeichen entnommen werden sollen, Verknüpfungsinfor- mationen mit anderen Vorlagen wie z.B. Formularen und die Pixelinformation für spezielle zu druckende Bilder. Mit Hilfe des Controllers werden die empfangenen Bildinformationen so in matrixartig angeordnete Pixel umgesetzt, daß die Bildin- formationen zeilen- oder spaltenweise an einen nachgeordneten Zeichengenerator übergeben werden können.

Ein elektrografisches Druck- oder Kopiergerät, das einen optischen oder magnetischen Zeichengenerator enthält, ist beispielsweise aus EP-0 403 476 Bl bekannt. Als optischer Zeichengenerator eignet sich dabei sowohl ein einen Laser¬ strahl umlenkender Zeichengenerator als auch ein mit LED- Zeilen arbeitender Zeichengenerator. Mit einem Zeichengenera¬ tor werden in Pixelform vorliegende Druckinformationen in ein optisches oder magnetisches Bild umgesetzt, mit dem dann eine fotoleitende bzw. ferromagnetische Schicht einer kontinuier¬ lich umlaufenden Ladungsspeichertrommel oder eines entpre-

chenden bandförmigen Zwischenträgers des Druck- oder Kopier¬ geräts belichtet wird, um ein latentes Ladungs- bzw. magneti¬ sches Feldbild zu erzeugen. Dieses Bild wird in bekannter Weise entwickelt und auf einen Aufzeichnungsträger umge- druck .

Ein Controller muß abhängig von der Leistungsfähigkeit des Druck- oder Kopiergerätes, in dem er eingesetzt wird, eine entsprechende Rechen- und Rasterleistung aufweisen. Bei üblichen schnellen Druck- und Kopiergeräten werden 50 bis 350 DIN A4 Seiten pro Minute gedruckt. Abhängig von der spezifi¬ schen Leistung eines Druckers ist man gezwungen entweder spezielle Controller für den jeweiligen Drucker einzusetzen, oder aber eine Überdimensionierung des Controllers in Kauf zu nehmen. Die Rasterleistung wird durch die Zugriffszeiten auf die Speicher begrenzt und die Rechenleistung wird durch die Leistung des verwendeten Prozessors begrenzt.

Der vorliegenden Erfindung liegt die Aufgabe zugrunde, einen Controller zur Aufbereitung von kodierten Bildinformationen in einem elektrografischen Druck- oder Kopiergerät aufzuzei¬ gen, der so aufgebaut ist, daß die Leistungsfähigkeit des Controllers an die jeweiligen Anforderungen des Druck- oder Kopiergerätes, in dem er eingesetzt wird, anpaßbar ist.

Diese Aufgabe wird erfindungsgemäß durch die in den Patentan¬ sprüchen 1 und 7 angegebenen Merkmale gelöst. Vorteilhafte Ausgestaltungen und Weiterbildungen der Erfindung sind in Unteransprüchen angegeben.

Mit Hilfe der Umsetzungseinheit können die kodierten Bildin¬ formationen in voneinander unabhängig verarbeitbare Arbeits¬ pakete gebündelt werden. Diese Arbeitspakete können jeweils einem Rastermodul übergeben werden, das unabhängig von be- nachbarten Rastermodulen die Bildinformationen druckergerecht aufbereiten kann. Bei dieser Aufbereitung können die einzel¬ nen Rastermodule auf eine Ressourcen-Speichereinheit zugrei-

fen, die die Bitmaps verschiedener Fonts und spezielle Bit- aps von wiederzugebenden Bildern enthält. Durch die zentrale Ressourcen-Speichereinheit ist eine einfache Verwaltung der Ressourcen gewährleistet.

Durch diese Anordnung ist die Aufbereitung von kodierten Bildinformationen in zwei getrennte Arbeitsschritte aufge¬ teilt. Der erste Arbeitsschritt ist von seiner Arbeitsmenge her so gewählt, daß er sehr schnell im Vergleich zum zweiten Arbeitsschritt durchführbar ist. Dadurch ist es möglich, mit Hilfe der Umsetzungseinheit eine Mehrzahl von Rastermodulen mit Arbeitspaketen zu versorgen. Abhängig von der Leistung des Druck- oder Kopiergerätes, in dem der Controller einge¬ setzt wird, können eine entsprechende Anzahl von parallel, jedoch unabhängig voneinander arbeitenden Rastermodulen eingesetzt werden, wodurch eine Skalierbarkeit der Leistung des Controllers erreicht wird. Ein weiterer Vorteil der Aufteilung der Arbeit des Controllers in zwei Arbeitsschritte ist, daß beim Wechsel des Sprachstandards, mit dem die ko- dierten Bildinformationen die Schnittstelle des Controllers erreichen, lediglich die Umsetzungseinheit an den Standard angepaßt werden muß. Die übrigen Einheiten des Controllers können in unveränderter Form weiterverwendet werden.

Gemäß einer Weiterbildung und Ausgestaltung der Erfindung enthält jedes Rastermodul einen Paket-Pufferspeicher, einen Ressourcen-Pufferspeicher und einen Rasterprozessor. Der Rasterprozessor kann auf einen virtuellen Adreßraum zugrei¬ fen, der größer ist als der bei Betrachtung aller Ressourcen- Pufferspeicher und der Ressourcen-Speichereinheit zur Verfü¬ gung stehende physikalisch tatsächlich vorhandene Speicher¬ raum. Mit Hilfe dieser virtuellen Speicherverwaltung wird der Gesamtspeicherbedarf minimiert. Jeder Prozessor kann auf jeden Speicherplatz des Gesamtsystems zugreifen, obwohl er nicht tatsächlich über die entsprechende Speicherkapazität lokal verfügt. Durch den blockweisen Datenaustausch stehen beim Folgezugriff auf ähnliche Adressen adressierte Speicher-

zellen lokal zur Verfügung. Dadurch wird die Anzahl der globalen Speicherzugriffe minimiert.

Durch das Merkmal, wonach der virtuelle Speicherraum größer ist, als der tatsächlich verfügbare physikalische Speicher¬ raum, wird zudem eine Fragmentierung der physikalischen Speicher vermieden. Die Fragmentierung der Speicher entsteht dadurch, daß die Lebensdauer von angeforderten Speicher¬ blöcken unterschiedlich lang ist, d.h., manche Blöcke werden zeitlich früher, manche zeitlich später wieder freigegeben. Irgendwann kommt es zu der Situation, daß im Speicher belie¬ big verstreut Speicherblöcke vorhanden sind, die noch nicht freigegeben wurden. Dies bewirkt nun, daß größere zusammen¬ hängende Speicherblöcke nicht mehr vorhanden sind. Durch die Wahl eines größeren virtuellen Adreßraums ist die Wahrschein¬ lichkeit sehr hoch, daß stets ausreichend große zusammenhän¬ gende Speicherblöcke adressiert werden können.

Ein Ausführungsbeispiel der vorliegenden Erfindung wird im folgenden anhand der Zeichnung näher erläutert. Dabei zeigen

Figur 1 ein Blockdiagramm der Funktionseinheit eines elek¬ trografischen Druckers mit Controller,

Figur 2 ein Blockdiagramm eines Rastermoduls eines Control- lers,

Figur 3 eine schematische Darstellung der Zuordnung zwischen Arbeitspaket und Ressourcen,

Figur 4 den schematischen Aufbau eines Metakommandos eines Arbeitspaketes, Figur 5 ein Ablaufdiagramm des Verfahrens zur Umsetzung von kodierten Bildinformationen in Arbeitspakete,

Figur 6 ein Ablaufdiagramm des Verfahrens zur Rasterung eines Arbeitspaketes,

Figur 7 ein Abiaufdiagramm des Verfahrensablaufs der Zutei¬ lung eines Arbeitspaketes durch eine Paket-Verwal¬ tungseinheit,

Figur 8 ein Ablaufdiagramm des Verfahrensablaufs des Druck- Prozesses zur Übergabe von Druckdaten an den Zei¬ chengenerator, und

Figur 9 eine schematische Darstellung der Zuordnung eines virtuellen Adreßrau es zu einem physikalischen Adreßraum.

Das Blockdiagramm gemäß Figur 1 zeigt die Funktionseinheiten eines elektrografischen Druck- oder Kopiergerätes, die für die Übertragung der von einem HOST gelieferten kodierten Bildinformationen als sichtbares Abbild auf einem Aufzeich¬ nungsträger 26 enthalten sind. Als Aufzeichnungsträger 26 dient beispielsweise Papier in Endlos- oder Einzelblattform. Die kodierten Bildinformationen werden von einer Schnitt¬ stelle 1, die im folgenden als HOST-Interface bezeichnet wird, empfangen. Dieses HOST-Interface 1 ist durch einen HOST-Datenbus 16 mit einer Umsetzungseinheit 2, die im fol- genden als Parser 2 bezeichnet wird, gekoppelt. Der Parser 2 setzt die kodierten Bildinformationen in ein nachfolgend näher beschriebenes Format um, das von den nachfolgenden Funktionseinheiten verarbeitbar ist.

Die Bildinformationen werden dabei in zwei Gruppen aufge¬ teilt. Eine erste Gruppe bilden die sogenannten Ressourcen, die vom Parser 2 über einen lokalen Ressourcen-Bus 17 zu einer Ressourcen-Speichereinheit 6 übertragen und in dieser gespeichert werden. Die Ressourcen-Speichereinheit 6 und die dieser Einheit zugeordnete Ressourcen-Verwaltungseinheit 9 bilden die Ressourcen-Einheit RE. Die andere Gruppe bilden die Arbeitspakete 30, die über einen lokalen Displaylist-Bus 18 zu einer Paket-Speichereinheit 3 übertragen und dort abgelegt werden. Die Paket-Speichereinheit 3 und die dieser

Einheit zugeordnete Paket-Verwaltungseinheit 4 bilden die Paket-Einheit PE.

Mittels der Paket-Einheit PE sind einzelne Rastermodule RM aus einer Mehrzahl von Rastermodulen RM auswählbar. Die

Rastermodule RM sind über einen Bus 20, der im folgenden als Displaylistbus 20 bezeichnet wird, mit der Paket-Einheit PE gekoppelt. Die Ressourcen-Einheit RE ist über einen Ressour¬ cenbus 22 mit den Rastermodulen RM gekoppelt. Die Steuerin- formationen zwischen den Rastermodulen RM, dem Parser 2, der Ressourcen-Einheit RE und der Paket-Einheit PE werden über einen Controlbus 21 ausgetauscht. Diese Trennung in einzelne Busse wird hier zur Vereinfachung der Beschreibung verwendet. Es versteht sich, daß beliebige BusStrukturen, wie z.B. eine MultibusStruktur, anwendbar sind.

Die Rastermodule RM bereiten anhand der in den Arbeitspaketen 30 enthaltenen Daten und der im Ressourcen-Speicher 6 hinter¬ legten Daten die Bildinformation in Pixelform auf. Da die in einem Arbeitspaket 30 enthaltenen Daten der Information entsprechen, die zum Aufbereiten einer kompletten zu drucken¬ den Seite benötigt werden, bereitet jedes Rastermodul RM eine komplette zu druckende Seite druckfertig auf.

Zur Wiedergabe der Bildinformation einer Seite auf einem

Aufzeichnungsträger 26, sind die Rastermodule RM über einen Pixelbus 23 mit einem Zeichengenerator 8 gekoppelt. Zum Druck einer Seite, liefert ein Rastermodul RM die Pixeldaten an den Zeichengenerator 8. Dieser steuert einen Laserstrahl oder eine LED-Zeile auf bekannte Weise so, daß ein latentes La¬ dungsbild auf einem fotoleitfähigen Zwischenträger 24 erzeugt wird. Dieses Ladungsbild wird in einer Entwicklerstation 26 auf bekannte Weise mit Hilfe von Tonerpartikeln entwickelt und in einer Umdruckstation 25 auf bekannte Weise mittels einer Corona auf den Aufzeichnungsträger 26 übertragen.

Beim beschriebenen Aufbau des Controllers werden in der Minimalversion zwei Hardware-Module, nämlich ein den Parser 2 und die Paket-Einheit PE enthaltendes I/O-Modul und ein Rastermodul RM benötigt. Wird jedoch ein Controller benötigt, dessen Leistungsfähigkeit auf die Leistungsfähigkeit einer Rastermoduls RM beschränkt sein soll, können das I/O-Modul und ein Rastermodul RM auch in einem Hardware-Modul zusammen¬ gefaßt werden.

Die Rastermodule RM sind gleichartig gemäß Figur 2 aufgebaut. Sie enthalten je einen mit dem Displaylistbus 20 gekoppelten Paket-Pufferspeicher 10, einen mit dem Ressourcenbus 22 gekoppelten Ressourcen-Pufferspeicher 11, einen mit dem Controlbus 21 und über lokale Busse 12, 13 mit den Puffer- speichern 10, 11 gekoppelten Rasterprozessor 14 und einen über einen Rasterpagebus 15 mit dem Rasterprozessor 14 gekop¬ pelten, als Ausgabeeinheit 7 dienenden Printprozessor 7. Der Rasterprozessor 14 und der Printprozessor 7 können unabhängig voneinander auf einen ihnen zugeordneten Raster-Pufferspei- eher RP zugreifen. Dieser Raster-Pufferspeicher RP dient zur Zwischenspeicherung des Rasterergebnisses. Der Printprozessor 7 ist über den Pixelbus 23 mit dem Zeichengenerator 8 gekop¬ pelt.

Die den Rastermodulen RM zugeführten Daten, werden durch den Parser 2 aufbereitet. Der Parser 2 schnürt aus der über das HOST-Interface 1 empfangenen, durch den Parser 2 dekodierten Bildinformation voneinander unabhängige Arbeitspakete 30, die jeweils eine vollständige zu druckende Seite als Displayliste 30 beschreiben. Die Arbeitspakete 30 werden von der Pake - Verwaltungseinheit 4 verwaltet, in der Paket-Speichereinheit 3 abgelegt und den Rastermodulen RM über den Displaylistbus 20 zur Verfügung gestellt. Font's und Images werden vom Parser 2 über den lokalen Ressourcenbus 17 an die Ressourcen- Verwaltungseinheit 9 übergeben und in der Ressourcen-Spei¬ chereinheit 6 abgelegt.

Die Art der vom HOST empfangenen Daten, und welcher Seite sie jeweils zugeordnet sind, ist aus dem empfangenen, kodierten Datenstrom entnehmbar. Der Parser 2 erhält beispielsweise ein Kommando, aus dem er schließen kann, daß eine neue zu druk- kende Seite anfängt. Wenn eine neue Seite anfängt, müssen zu dem Arbeitspaket 30 einer Seite eventuell noch Steuerinforma¬ tionen hinzugefügt werden, die vor Beginn der neuen Seite vom HOST gesendet wurden. Beispielsweise kann es gefordert sein, daß einer Seite ein sogenanntes Overlay, das zum Beispiel ein Firmenlogo oder ein Formular sein kann, hinzugefügt werden muß. Es müssen der aktuellen Seite auch Steuerinformationen hinzugefügt werden, die von einer vorhergehenden Seite auf die aktuelle Seite vererbt werden. Beispielsweise kann ein zu benutzender Font von einer Seite auf die nächste vererbt werden.

Bei der Generierung der Steuerinformationen durch den Parser 2, werden die vom HOST empfangenen Daten auch auf ihre Plau- sibilität und eventuelle Übertragungsfehler überprüft. Da- durch wird gewährleistet, daß sämtliche vom Parser 2 an die nachgeordneten Einheiten RE, PE übergebenen Daten bereits auf ihre Gültigkeit überprüft und korrekt sind. Die weitere Verarbeitung der Bildinformationen kann demzufolge nicht mehr durch nicht verarbeitbare Daten oder ähnliches gestört wer- den.

Die Displayliste 30 besteht aus einer Abfolge von einzelnen Steuerinformationen, die im folgenden als Metakommandos 31, 32 bezeichnet werden. Die Metakommandos 31, 32 können als interne Druckersprache interpretiert werden. Damit wird klar, daß der Parser 2 auch als Drucksprachenumsetzer eingesetzt wird. Wechselt die vom HOST verwendete Drucksprache bei¬ spielsweise von der PCL-Emulation zur IPDS-Emulation, kann durch einen Austausch des Parsers 2 der Controller an diesen Wechsel angepaßt werden. Die dem Parser 2 nachfolgenden

Prozesse brauchen nicht oder nur in geringem Umfang geändert werden.

Die Displayliste 30 ist in den Figuren 3 und 4 dargestellt. Ein einzelnes Metakommando 31 besteht aus dem eigentlichen Metakommando ID und Zusatzinformationen 36 zu diesem Metakom¬ mando ID. Beispielsweise lautet das eigentliche Metakommando ID "Drucke ein "A" und als Zusatzinformation 36 wird die Adresse des "A" und der entsprechende zu benutzende Font 33 genannt. Ein anderer Displaylisteneintrag 32 lautet ebenfalls "Drucke ein "A" und als Zusatzinformation 36 ist die Adresse des entsprechenden Buchstabens "A" und der zugehörige, sich vom erstgenannten Font 33 unterscheidende Font 34 angegeben.

Im folgenden wird ein Beispiel eines Displaylisteneintrags in seiner Bytefolge aufgezeigt.

Das aufgezeigte Beispiel würde den Ausdruck einer Leerseite bewirken. Durch das erste eigentliche Metakommando ID=20 wird festgelegt, daß eine neue Seite beginnt. Als Zusatzinforma- tion 36 werden die Seitenränder, die Seitengröße und die Orientierung des Drucks festgelegt. Mit dem nachfolgenden eigentlichen Metakommando ID=21 wird die Seite bereits wieder beendet, bevor ein Druckauftrag erfolgt.

Anhand der Figuren 5 bis 8 wird im folgenden das erfindungs¬ gemäße Verfahren dargestellt. Wie in Figur 5 gezeigt, wartet der Parser 2 nach seinem Start auf eine kodierte Bildinforma- tion des HOST. Empfängt der Parser 2 Daten, die einer zu druckenden Seite zuzuordnen sind, erstellt er aus diesen Daten Arbeitspakete in der Displayliste 30. Empfangene Daten DAT, die ein spezielles wiederzugebendes Bildmuster, eine sogenannte Bitmap, beinhalten, werden der Ressourcen-Einheit RE zugeleitet, und dort, wie unten näher erläutert, abgelegt. Jedes Arbeitspaket enthält eine Abfolge von Metakommandos 31, 32. Beim Seitenbeginn BEG wird das eigentliche Metakommando ID=20 gesetzt und als Zusatzinformation 36 die Randbedingun¬ gen der Seite eingetragen. Ist das Metakommando 31 zum Beginn BEG einer Seite erzeugt und zur Paket-Speichereinheit 3 übertragen, wartet der Parser 2 erneut auf eine kodierte Bildinformation vom HOST.

Aus den vom HOST empfangenen Daten DAT, die nachfolgend in der Regel den Inhalt der Seite betreffen, extrahiert der Parser 2 nun Informationen, die auf bestimmte Stellen im Ressourcen-Speicher 6 verweisen. Sollen bestimmte in einem Font 33, 34 hinterlegte Zeichen gedruckt werden generiert der Parser 2 ein entsprechendes eigentliches Metakommando ID und fügt diesem als Zusatzinformation 36 die Anfangsadresse des Zeichens IM in der Ressourcen-Speichereinheit 6 an, an der das Zeichen abgelegt ist. Soll eine spezielle Bitmap IM gedruckt werden, dann leitet der Parser 2 dieses Bitmap IM der Ressourcen-Einheit RE zu und generiert ein eigentliches Metakommando ID mit einer Zusatzinformation 36, die auf die Anfangsadresse des in der Ressourcen-Einheit RE abgelegten Bitmaps IM verweisen. Erkennt der Parser 2 aus den vom HOST empfangenen Bildinformationen das Ende END einer zu drucken¬ den Seite, generiert er ein Metakommando 31, 32, das das eigentliche Metakommando ID=21 enthält. Damit ist vom Parser 2 ein Arbeitspaket erstellt worden und als Displayliste 30 in

der Paket-Speichereinheit 3 hinterlegt. Der Parser 2 sendet eine Mitteilung A an die Paket-Verwaltungseinheit 4.

Die Paket-Verwaltungseinheit 4 reagiert auf diese Mitteilung A in der in Figur 7 dargestellten Weise. Ab einem Startzeit¬ punkt wartet die Paket-Verwaltungseinheit 4 auf Mitteilungen A, D, E vom Parser 2, vom Rasterprozessor 14 und vom Print¬ prozessor 7. Hat die Paket-Verwaltungseinheit 4 die Mittei¬ lung A erhalten, wonach ein Arbeitspaket 30 zur Rasterung in der Paket-Speichereinheit 3 vorliegt, überprüft sie, ob ein Rastermodul RM zur Bearbeitung des Arbeitspakets frei ist. Ist dies nicht der Fall, wartet die Paket-Verwaltungseinheit 4 solange, bis ein Rastermodul RM frei wird. Einem freien Rastermodul RM übergibt die Paket-Verwaltungseinheit 4 dann eine Mitteilung B. Diese Mitteilung B enthält die Anfangs¬ adresse des Arbeitspakets in der Displayliste 30.

Gemäß Figur 6 wartet das Rastermodul RM auf diese Anfangs- adresse D des Arbeitspakets. Anhand dieser Anfangsadresse B besorgt sich nun das Rastermodul- RM über den Displaylistbus 20 aus der Paket-Speichereinheit 3 einen Teil der zum Ar¬ beitspaket gehörigen Metakommandos 31, 32. Diese Metakomman¬ dos 31, 32 werden im Paket-Pufferspeicher 10 zwischengespei¬ chert. Über den lokalen Bus 12 greift der Rasterprozessor 14 nacheinander auf die Metakommandos 31, 32 zu, und führt abhängig von ihnen die erforderlichen Rasteroperationen durch. Das erste Metakommando 31 enthält das eigentliche Metakommando ID=20 für den Beginn BEG der Seite. Auf bekann¬ te, hier nicht näher beschriebene Weise, wird in Folge dessen die zu rasternde Seite in ihrer Größe und Ausrichtung vorbe¬ reitet. Die nachfolgenden Metakommandos 32 enthalten die Anfangsadressen der auf der Seite darzustellenden Bitmaps. Die benötigten, durch die Anfangsadressen festgelegten Spei¬ cherinhalte der Ressourcen-Speichereinheit 6, werden über den Ressourcenbus 22 in den Ressourcen-Pufferspeicher 11 des Rastermoduls RM übertragen. Der Rasterprozessor 14 erhält diese Speicherinhalte über den lokalen Bus 13 aus dem Res-

sourcen-Pufferspeicher 11. Die zu druckende Seite wird damit in bekannter Weise gerastert, und das Rasterergebnis wird im Raster-Pufferspeicher RP abgelegt. Erkennt der Rasterprozes¬ sor 14 anhand des eigentlichen Metakommandos ID=20 das Ende E D des Arbeitspakets, dann überträgt es eine entsprechende Meldung D an die Paket-Verwaltungseinheit 4 und wartet auf die Übermittlung einer neuen Anfangsadresse B eines neuen Arbeitspakets.

Erhält die Paket-Verwaltungseinheit 4 (Figur 7) die Meldung D über das Ende der Rasterung eines Arbeitspakets, dann über¬ prüft sie, ob ein Printprozessor 7 von einem der Rastermodule RM gegenwärtig einen Druckauftrag ausführt. Ist dies der Fall, überprüft die Paket-Verwaltungseinheit 4, ob ein neues zu bearbeitendes Arbeitspaket in der Paket-Speichereinheit 3 vorliegt, und ob ein Rastermodul RM zur Rasterung des Ar¬ beitspakets bereit ist. Ist dies der Fall, übergibt sie dieses neue Arbeitspaket an das entsprechende Rastermodul RM und überprüft erneut, ob ein Printprozessor 7 aktiv ist. Ist dies nicht der Fall, überprüft die Paket-Verwaltungseinheit 4, ob die nächste Seite, die dem Zeichengenerator 8 zugeführt werden soll, in einem der Raster-Pufferspeicher RP der Ra¬ stermodule RM verfügbar ist. Ist dies nicht der Fall, leitet die Speicher-Verwaltungseinheit 4 die Rasterung neuer Ar- beitspakete ein, wenn die oben genannten entsprechenden

Bedingungen erfüllt sind. Liegt bei einer Überprüfung, ob die nächste zu druckende Seite im Raster-Pufferspeicher RP eines Rastermoduls RM vorliegt, eine positive Quittungsinformation vor, dann wird das entsprechende Rastermodul RM zum Ausdruck der Seite aufgefordert.

Der Printprozessor 7 dieses Rastermoduls RM erhält gemäß Figur 8 das entsprechende Kommando C. Infolgedessen übergibt der Printprozessor 7 das Rasterbild Zeilen- oder spaltenweise an den Pixelbus 23. Dabei kontrolliert der Printprozessor 7 ständig, ob das Ende der Seite erreicht wird. Bei Erreiβhen dieses Seitenendes gibt der Printprozessor 7 den durch die

soeben ausgegebene Seite belegten Speicherplatz im Raster- Pufferspeicher RP zum Wiederbeschreiben frei. Anschließend gibt der Printprozessor 7 eine Druck-Ende-Meldung E an die Paket-Verwaltungseinheit 4 aus. Diese erkennt die Druck-Ende- Meldung E und erlaubt es, dem Printprozessor 7 des Rastermo¬ duls RM, das die nächste zu druckende Seite enthält, diese auf den Pixelbus 23 auszugeben.

Der Datenaustausch zwischen der Ressourcen-Einheit RE und der Paketeinheit PE mit den Rastermodulen RM, erfolgt über den Displaylistbus 20 und den Ressourcenbus 22. Die Steuerinfor¬ mationen dazu werden über den Controlbus 21 ausgetauscht. Der Datenaustausch erfolgt gemäß Figur 9 unter Verwendung eines virtuellen Adreßraums AYK, der auf einen physikalischen Adreßraum El, E2, E3 abgebildet wird.

Jedem Hardware-Modul, in dem mindestens eine der Funktions¬ einheiten RE, PE, RM des Controllers angeordnet ist, ist ein physikalischer Adreßraum El, E2, E3 zugeordnet, der bei der gleichen Anfangsadresse 0 beginnt und bei einer Endadresse endet XI, X2, X3. Um jede Speicheradresse innerhalb des Controllers eindeutig zu machen, werden die Adressen AYK, auf die im laufenden Betrieb Bezug genommen wird, von den Adres¬ sen El, E2, E3 des physikalischen Speichers abgekoppelt. Dazu wird ein virtueller Adreßraum AYK eingeführt. Jedem Hardware- Modul der Funktionseinheiten RE, PE, RM ist dabei ein be¬ stimmter Abschnitt VI, V2, V3 im virtuellen Adreßraum AYK zugeordnet. Die Umsetzung der virtuellen Adressen VI, V2, V3 auf die physikalischen Adressen El, E2, E3 wird von der Memory Management Unit (MMU) der jeweiligen Prozessoren der Funk ionseinheiten RE, PE, RM vorgenommen.

Die Speicher der Funktionseinheiten RE, PE, RM, sind in Blöcke gleicher Länge aufgeteilt, die im folgenden als "page" bezeichnet werden. Eine gebräuchliche Größe für eine solche "page" ist 4KByte. Jeder physikalischen "page" kann über Tabellen eine andere, im Grunde beliebige virtuelle Adresse Y

bis K zugeordnet werden. Der Zugriff von Programmen über die virtuelle Adresse Y bis K auf die entsprechende Adresse 0 bis X im physikalischen Adressraum El, E2, E3 ist vollkommen transparent, da die Prozessoren die Umsetzung quasi auto a- tisch über Tabellen vornehmen.

Im dynamischen Betrieb erfolgt durch die zeitlich variable Freigabe von Speicherblöcken eine Fragmentierung des Spei¬ chers. Diese Fragmentierung wird durch Anwendung der virtuel- len Adressierung dadurch verhindert, daß der virtuelle Adre߬ raum AYK größer als der physikalische Adreßraum El, E2, E3 gewählt wird. Jeder physikalische Adressraum El, E2, E3 einer Funktionseinheit RE, PE, RM wird auf einen jeweils größeren virtuellen Adressraum VI, V2, V3 abgebildet. Der gesamte virtuelle Adressraum VI, V2, V3, auf dessen Adressen jede der einzelnen Funktionseinheiten direkt zugreifen kann erstreckt sich von einer Adresse Y bis zu einer Adresse K. Dabei gilt:

K = Y + v * (XI + X2 + X3) mit v als Vergrößerungsfaktor für den physikalischen Adress- räum El, E2, E3. Bei Verwendung eines virtuellen Adreßraums AYK, der doppelt so groß ist wie der physikalische Adreßraum El, E2, E3, es gilt v=2, werden Funktionsstörungen beim Rastern von Bildinformationen durch Speicherfragmentierung mit hoher Wahrscheinlichkeit vollständig vermieden.

Der Datenaustausch zwischen den Systemeinheiten RE, PE, RM, erfolgt nun über ein sogenanntes "paging" . Normalerweise wird das "paging" zusammen mit der virtuellen Adressierung in Betriebssystemen eingesetzt, um die Grenzen des physikali- sehen Speichers zu überwinden. Dies geschieht dadurch, daß unter der Bedingung, daß kein physikalischer Speicher mehr im System vorhanden ist, der Inhalt einer "page" oder mehrerer "pages" eines ersten Speichers zu einem zweiten Speicher ausgelagert werden. Der zweite Speicher ist dabei häufig ein Festplattenspeicher. Welche "pages" ausgelagert sind und welchen virtuellen Adreßraum diese "pages" umfassen, ist in Tabellen abgelegt. Dies Tabellen werden von der Speicherver-

waltung bearbeitet und von der Memory Management Unit (MMU) des Prozessors bei jedem Zugriff auf den Speicher interpre¬ tiert. Wenn auf eine derart ausgelagerte "page" zugegriffen wird, wird ein Interrupt ausgelöst, der eine Interrupt-Ser- vice-Routine zur Wiedererlangung der ausgelagerten "page" startet. Es wird zunächst durch Auslagerung nicht benötigter "pages" aus dem ersten Speicher in den zweiten Speicher Platz im ersten Speicher geschaffen. Dieser Platz wird dann mit den benötigten "pages" gefüllt. Anschließend werden die Tabellen der MMU entsprechend aktualisiert und der gewünschte Zugriff auf die "pages" kann erfolgen.

Diese Funktionalität handelsüblicher Prozessoren wird nun zum Datentransfer zwischen den Systemeinheiten PE, RE, RM des Controllers in abgewandelter Form verwendet. Mit Hilfe des "paging" wird auf Daten zugegriffen, die nicht lokal im SpeicherlO, 11 eines Funktionsmoduls RE, PE, RM vorhanden sind. Greift beispielsweise der Rasterprozessor 14 eines Rastermoduls RM, E2 auf Grund einer im Metakommando 31 ent- haltenen Anfangsadresse einer Bitmap auf seinen Paket-Puffer¬ speicher 10 zu, dann stellt seine MMU zunächst fest, ob der im Metakommando 31 genannten virtuellen Adresse Y bis K eine lokal verfügbare physikalische Adresse 0 bis X2 zugeordnet ist. Ist dies nicht der Fall, wird die entsprechende Inter- rupt-Service-Routine ausgelöst. Diese Interrupt-Service- Routine bewirkt den Transfer der benötigten "page" zum Paket- Pufferspeicher 10 des Rastermoduls RM. Die "page" befindet sich beispielsweise in der Ressourcen-Speichereinheit 6. Die Interrupt-Service-Routine stoppt den Programmlauf des Raster- Prozessors 14 und stellt sicher, daß das Programm später an derselben Stelle wieder fortgesetzt werden kann. Die Spei¬ cherverwaltung MMU des Rasterprozessors 14 stellt mit Hilfe einer Tabelle fest, unter welcher physikalischen Adresse 0 bis XI in der Ressourcen-Speichereinheit 6 der Ressourcen- Einheit RE, El die "page" abgelegt ist. Die Speicherverwal¬ tung MMU des Rastermoduls RM kommuniziert dann über den Controlbus 21 mit der Speicherverwaltung MMU Ressourcen-

Verwaltungseinheit 9. Durch diese Kommunikation wird die benötigte "page" angefordert. Die Ressourcen-Verwaltungsein¬ heit 9 schickt dann eine Kopie der gewünschten "page" über den Ressourcenbus 22 zum anfordernden Rastermodul RM. Dort werden die Daten der "page" in den Ressourcen-Pufferspeicher 10, E2 unter einer lokal vorhandenen, physikalischen Adresse 0 bis X2 gespeichert. Der Tabelleneintrag in der Speicherver¬ waltung MMU des Rastermoduls RM wird entsprechend aktuali¬ siert und der Rasterprozessor 14 wird zur Fortsetzung des Programmablaufs aufgefordert.

Für den Fall, daß im Paket-Pufferspeicher 10 des Rastermoduls RM zu wenig Platz zur Eintragung der von der Ressourcen- Speichereinheit 6 transferierten "page" vorhanden ist, wird von der MMU diejenige im Paket-Pufferspeicher 10 enthaltene

"page" ausgewählt, die am längsten nicht mehr benötigt worden war. Die ausgewählte "page" wird für ungültig erklärt und durch die Daten der neuen "page" überschrieben. Die ausge¬ wählte "page" kann deshalb einfach gelöscht werden, weil es sich lediglich um eine Kopie aus der Ressourcen-Speicherein¬ heit 6 handelt. Es kann also auf eine zeitaufwendige Auslage¬ rung dieser "page" verzichtet werden, wodurch der Rasterpro¬ zeß zusätzlich beschleunigt wird.

Es versteht sich, daß bei entsprechendem Bedarf die Ressour¬ cen-Speichereinheit 6 auch ganz oder teilweise in einem Paket-Pufferspeicher 10 eines Rastermoduls RM ausgelagert werden kann. Es ist beispielsweise zur Steigerung der Raster¬ leistung eines Controllers möglich, ein Rastermodul RM mit vergrößertem Ressourcen-Pufferspeicher 11 in den Controller einzufügen. Dadurch kann ohne zusätzlichen Eingriff in die Ressourcen-Einheit RE die Kapazität des Controllers zur Aufnahme von Bit aps erhöht werden.

Durch die Anwendung des "paging" beim Datenaustausch zwischen den Systemeinheiten RE, PE, RM, wird zusätzlich ein "Cache- Effekt" erzielt. Bei der Anforderung benötigter Daten werden

stets Datenblöcke, d.h. "pages" definierter Größe zwischen den Systemeinheiten RE, PE, RM ausgetauscht. In einer "page" sind jedoch mehr Daten enthalten, als zur Ausführung des nächsten Befehls beim Rastern benötigt werden. Beispielsweise soll beim aktuellen Befehl ein "A" eines bestimmten Fonts 33 geschrieben. Das "A" ist in einer "page" enthalten, die auch noch die Rasterinformation für die Buchstaben B, C, D und E enthält. Soll mit dem nächsten Befehl ein "C" des gleichen Fonts 33 auf der zu rasternden Seite eingefügt werden, dann ist dieses "C" bereits lokal im Ressourcen-Pufferspeicher 11 verfügbar. Soll ein anderer, in der ersten "page" nicht enthaltener Buchstabe des Fonts 33 gerastert werden, wird die entsprechende "page" in den lokalen Ressourcen-Pufferspeicher 11 geholt. Auf diese Weise wird der ganze Font 33 auf den lokalen Ressourcen-Pufferspeicher 11 übertragen. Zu druckende Texte dieses einen Fonts 33 können dann vom Rastermodul RM gerastert werden, ohne daß weitere Beanspruchungen des Res¬ sourcenbusses 22 erfolgen. Die dem Font 33 zugeordneten "pages" werden auf Grund der Bedingung, daß stets diejenige "page" überschrieben wird, die am längsten nicht mehr benö¬ tigt wurde, erst gelöscht, wenn der Font 33 nicht mehr benö¬ tigt wird.

Es ist auch möglich, bei der Anforderung einer aktuell benö- tigten "page" gleich weitere nachfolgende "pages" mit anzu¬ fordern. Dadurch kann beispielsweise ein kompletter Font 33 mit einer einzigen Anforderung einer Interrupt-Service-Routi¬ ne in den Ressourcen-Pufferspeicher 11 eines Rastermoduls RM geholt werden.

Der Transfer von Arbeitspaketen zwischen der Paketeinheit PE und einem Rastermodul RM, erfolgt in analoger Weise. Der Rasterprozessor 14 eines Rastermoduls RM, erhält die virtu¬ elle Anfangsadresse Y' bis K' des Arbeitspakets in der Dis- playliste 30. Mit Hilfe der Interrupt-Service-Routine wird eine "page", die die Anfangsadresse des Arbeitspakets 30 enthält, in den Paket-Pufferspeicher 10 übertragen. In dieser

"page" ist eine Mehrzahl von Metakommandos 31, 32 enthalten. Erst nach Abarbeitung all dieser Metakommandos 31, 32, wird ein neuer Interrupt ausgelöst und die Interrupt-Service- Routine zur Erlangung der Folge-"page" ausgelöst. Die Bela- stung des Displaylistbusses 20 ist entsprechend gering.

Sollen Bitmaps beispielsweise ein Font 33, 34 oder eine auf einer Seite darzustellende Grafik in der Ressourcen-Speicher¬ einheit 6 des Controllers gespeichert werden, dann muß ein sogenannter Speicher-Pool erzeugt werden. Ein solcher Spei¬ cher-Pool hat folgende Eigenschaften:

Ein erzeugter Pool bekommt eine innerhalb des Controllers eindeutige Kennung. Die Größe eines Pools ist bedingt durch das "paging", ein Vielfaches einer einzelnen "page" (z.B. 4KByte) .

Innerhalb eines erzeugten Pools können einzelne Speicherab¬ schnitte dem Pool zugewiesen oder freigegeben werden. Die Größe der zugewiesenen Speicherbereiche kann zwischen einem Byte und dem größten zusammenhängenden physikalischen Spei¬ cherbereich innerhalb des Pools liegen. In welcher Funktions¬ einheit RE, PE, RM der Pool erzeugt wird, wird durch einen Parameter festgelegt. Die MMU der jeweiligen Funktionseinheit RE, PE, RM stellt die notwendigen Funktionen, die zur Zuwei¬ sung oder zur Freigabe von Speichern benötigt werden, zur Verfügung. Wird ein Pool freigegeben, werden auch alle inner¬ halb des Pools liegenden, diesem Pool zugewiesenen Speicher¬ bereiche freigegeben.

Für einen Pool ist ein Eigentumsrecht definiert. Eigentümer des Pools ist zunächst der, der den Pool erzeugt hat. Dieses Eigentumsrecht kann vergeben und wiedererlangt werden. Der Eigentümer des Pools darf alle definierten Operationen auf diesem Pool durchführen. Ein Zugriff von Nichteigentümern auf den Pool führt zu einem Fehler. Wird das Eigentumsrecht«auf den Pool abgegeben, dann existiert kein Eigentümer mehr für

den Pool. In diesem Fall darf jede Funktionseinheit RE, PE, RM lesend auf den Pool zugreifen.

Gelangt beispielsweise eine Grafik über den HOST zum Parser 2, dann aktiviert der Parser 2 die Ressourcen-Verwaltungsein¬ heit 9. Die Ressourcen-Verwaltungseinheit 9 erzeugt einen Pool in der Ressourcen-Speichereinheit 6 und weist diesem Pool eine Kennung zu. Diese Kennung gibt sie an den Parser 2 weiter, der sie zur Erstellung des Metakommandos 31 verwen- det. Mit Hilfe dieses Metakommandos kann später ein Rastermo¬ dul RM auf den Pool zugreifen. Die Ressourcen-Verwaltungsein¬ heit 9 hat nun die Kontrolle über den Pool und kann diesen je nach Bedarf durch Zuweisen oder Freigeben von Speicherplatz vergrößern bzw. verkleinern. In diesem Pool wird die vom HOST erhaltene Bitmap gespeichert. Ist die gesamte Bitmap im Pool enthalten, gibt die Ressourcen-Verwaltungseinheit 9 die Kontrolle über den Pool ab. Jetzt kann jede beliebige Einheit RE, PE, RM auf den Pool lesend zugreifen. Sollen nachträglich Änderungen am Pool vorgenommen werden, kann durch eine spezi- eile Anforderung die Poolkontrolle wiedererlangt werden und die Änderung vorgenommen werden. Eine solche Änderung kann beispielsweise das Freigeben oder Löschen des Pools sein. Beim Löschen eines Pools ist gleichzeitig dafür gesorgt, daß alle Kopien des Pools, auch von Teilen des Pools, ebenfalls gelöscht oder für ungültig erklärt werden. Ein nochmaliger

Zugriff auf einen gelöschten Pool führt dann zu einer Fehler¬ meldung.

Die Ausgabe der gerasteten Bildinformation aus dem Rastermo- dul RM über den Pixelbus 23 zum Zeichengenerator 8, erfolgt auf folgende Weise. Der Printprozessor 7 eines Rastermoduls RM, das die gerasterte Bildinformation für die nächste zu druckende Seite enthält, wird von der Paketverwaltungseinheit 4 darüber informiert, daß er bei der nächsten Anforderung aus dem Pixelbus 23 eine bestimmte Seite auf den Pixelbus 23 auszugeben hat. Der nachfolgende Interrupt auf den Pixelbus 23, wird entsprechend von diesem Printprozessor 7 empfangen.

Der Printprozessor 7 überträgt die erforderlichen Daten zum Auslesen der gesamten Seite an die Steuerung des Pixelbus 23, woraufhin diese die gesamte Seite aus dem Rasterpufferspei¬ cher RP des Rastermoduls RM ausliest. Durch einen weiteren Interrupt signalisiert der Pixelbus 23 dem Printprozessor 7 das erfolgreiche Auslesen der Seite, woraufhin der Druckpro¬ zeß abgeschlossen ist.