Tabelle 4-1: CD-i-Audioqualitätsstufen
| Index | Zurück | Weiter |
Im diesem Kapitel wird das in [GreenBook90] spezifizierte CD-i-Basissystem [74] erläutert. Im Abschnitt 4.1 werden die wichtigsten Komponenten der Hardware aufgelistet. Die Abschnitte 4.2 und 4.3 präsentieren die Audio- und Videofähigkeiten der CD-i-Geräte. Und schliesslich werden im letzten Abschnitt 4.4 einige Eigenschaften des CD-i-Betriebssystems dargelegt.
Der CD-i-Standard definiert einige minimale Hardwareanforderungen, die alle CD-i-Geräte erfüllen müssen.
Diese Teile werden für das Base Case-System vorgeschrieben. Erweiterungen sind im Extended Case möglich. So kann zum Beispiel ein MPEG [82]-Dekoder, ein Drucker, ein Modem, ein MIDI-Interface, ein Co-Prozessor, ein LAN [83]-Interface, ein 3.5-Zoll-Laufwerk, eine Harddisk oder eine Tastatur angeschlossen werden.
Audiodaten können in unterschiedlichen Qualitätsstufen auf der CD-i gespeichert werden. Die folgende Tabelle 4-1 zeigt die vier zur Auswahl stehenden Audioformate [84].
Jede CD-i-Applikation kann Musikstücke mit der HIFI-Qualität der CD-DA abspielen. Allerdings wird eine Auslastung des Datenstroms von 100% erreicht, d.h. es können keine anderen Daten gleichzeitig gelesen werden. Wird Level-C-Mono verwendet, dann belegen die Audiodaten nur jeden sechzehnten Sektor einer RTF-Datei. Zwischen zwei Sektoren einer Audiodatei stehen dann fünfzehn weitere zur Verfügung, in denen andere Dateien gespeichert werden können.
Abstände zwischen den Audiosektoren
In der Tabelle 4-2 werden die Abstände zwischen den Audiosektoren pro Qualitätsstufe wiedergegeben:
Tabelle 4-2: Abstände zwischen den Audiosektoren
Zwischen zwei Sektoren einer Audiodatei in der Qualität Level-A-Mono, stehen drei Sektoren zur weiteren Verwendung bereit. Der Datenstrom wird durch eine Level-A-Mono-Datei also zu 25% ausgelastet. Wird Level-C-Stereo verwendet, dann können zwischen zwei Audiosektoren sieben Sektoren anderweitig belegt werden.
Soundmaps
Soundmaps ermöglichen das direkte Abspielen von Tönen aus dem RAM des CD-i-Gerätes. Würde nach einem Mausklick das Audio-Feedback ab der CD wiedergegeben, dann entstände eine für den Benutzer deutlich erkennbare Wartezeit. Um die unmittelbare Wiedergabe gewährleisten zu können, werden daher alle derartigen Audiodaten zuerst in den Speicher geladen
In diesem Kapitel werden diejenigen Spezifikationen aus [GreenBook90] wiedergegeben, die die Darstellung von Bildern auf dem Monitor betreffen. Alle hier aufgeführten Angaben und Einschränkungen müssen bei der Planung einer CD-i-Applikation berücksichtigt werden.
Das CD-i-System soll die Applikationsentwicklung für den internationalen Markt so einfach wie möglich gestalten. So können in einer RTF-Datei beispielsweise verschiedene Sprachen gleichzeitig gespeichert werden, aus denen der Benutzer wählen kann [85]. Da sich auf dem weltweiten Markt aber nicht nur die verwendeten Sprachen, sondern auch die Fernsehnormen unterschieden, muss der CD-i-Bildschirm verschiedene Auflösungen unterstützen.
Im wesentlichen wird zwischen der amerikanischen NTSC- und der europäischen PAL-Fernsehnorm unterschieden [86]. In der Tabelle 4-3 werden die möglichen Auflösungen des CD-i-Bildschirms wiedergegeben.
Tabelle 4-3: Unterstützte Bildschirmauflösungen
Mit CD-i-Geräten können Bilder, die in der PAL-Auflösung 384*280 gespeichert wurden, auch auf NTSC-Bildschirmen dargestellt werden. Allerdings entstehen dabei durch die Veränderung der Aspect Ratio [87] deutlich sichtbare Verzerrungen.
Da für das CIMEDIA-Projekt keine Wiedergabe für NTSC-Systeme vorgesehen ist, werden alle bildschirmfüllenden Bilder in der Auflösung 384*280 gespeichert.
Die horizontale Auflösung [88] kann verdoppelt werden. Der Bildschirm besteht dann für PAL-Systeme aus 768*280 Bildpunkten. Leider können in diesem Fall nur noch zwei spezielle Bildformate [89] dargestellt werden.
Die hohe Auflösung [90], in der sowohl die horizontale als auch die vertikale Auflösung verdoppelt wird, kann ohne zusätzliche Hardware nur für Bilder mit maximal 16 Farben verwendet werden.
Durch die unterschiedlichen Einstellungen und Toleranzen der Fernsehapparate ergibt sich die Tatsache, dass nie der ganze Bildschirm auf dem Monitor dargestellt wird. Nur was sich innerhalb des sicheren Bildschirmbereichs [91] befindet, wird auch garantiert auf jedem TV-Gerät sichtbar sein.
Tabelle 4-4: Sicherer Bildschirmbereich
In der CIMEDIA-Applikation werden daher alle wichtigen Bildteile wie die Knöpfe oder die Texte innerhalb dieses 320*250 grossen Bereichs positioniert.
Der CD-i-Standard definiert vier verschiedene Bildschirmebenen [92], aus denen das auf dem Monitor sichtbare Bild zusammengesetzt wird.
Abbildung 4-1: Die vier Bildebenen
Das Graphiksystem orientiert sich an den Bildschirmzeilen. In einer bestimmten Zeile wird entweder ein Bild aus der Ebene 'A' oder eines aus 'B' dargestellt. Zum Beispiel wird in der Abbildung 4-2 im obersten Bereich ein Text aus der Bildebene 'A' präsentiert. Anschliessend folgt im Mittelteil ein Bild mit graphischen Elementen, die in der Ebene 'B' gespeichert sind. Im unteren Teil folgt wieder ein Streifen aus 'A'. Der Cursor wird in der Cursorebene immer im Vordergrund gezeigt.
Abbildung 4-2: Verschiedene Bildstreifen
Derartige horizontale Streifen über die ganze Bildschirmbreite bezeichnen wir als Bildstreifen.
Zur Codierung der Bilder stehen vier verschiedene Möglichkeiten zur Auswahl. Mit dem RGB555- [97] und dem DYUV- [98]Format können Bilder in vielen Farbdetails dargestellt werden. Dafür sind sie in der Implementation wesentlich schwieriger zu handhaben [99] als die CLUT- [100]Formate, die Farbtabellen [101] verwenden. Zwei RLE- [102]Formate erlauben die Darstellung komprimierter Bilder.
Beim RGB555-Format wird die Farbe jedes Bildpunktes mit 5 Bit codiert. Es können also bis zu 215 verschiedene Farben gleichzeitig verwendet werden.
Abbildung 4-3: RGB555-Bildformat
Wie in der Abbildung 4-3 aufgezeigt, werden zur Darstellung eines RGB555-Bildes Informationen aus beiden Bildebenen gleichzeitig verwendet. In der Ebene 'A' werden primär der Rotwert und die zwei höchstwertigen Bit des Grünwertes gespeichert. Im Speicher der Bildebene 'B' müssen der Blauanteil und die drei ersten Bit des Grünwertes abgelegt werden. Der Bildpunkt in der Zeile k und der Spalte j wird durch die beiden Bytei,j in den zwei Speicherbereichen repräsentiert [103]. Jedes Bit7 der Ebene 'A' definiert, ob der entsprechende Bildpunkt transparent erscheinen soll oder nicht. Alle transparenten Pixel erscheinen in der Farbe der entsprechenden Hintergrundzeile. Ein PAL-Vollbild mit 384*280 Bildpunkten belegt zwei Speicherblöcke à 105 KByte, also total 210 KByte.
Der Vorteil dieser Codierung ist, dass sehr viele Farben gleichzeitig dargestellt werden können. Im Gegensatz zum gleich anschliessend erläuterten DYUV-Format ist es dabei relativ robust gegenüber den sporadisch auftauchenden Fehlern beim Lesen der Daten ab der CD. Ein fehlerhaft gelesenes Byte wirkt sich nur auf einen Bildpunkt aus.
Mit der DYUV [104]-Codierung wird nicht der Farbwert pro Bildpunkt gespeichert, sondern nur dessen relative Veränderung zum linken Nachbarpunkt, wobei für jede Zeile ein fixer Startwert [105] vorgegeben wird. Jedes Pixelpaar wird durch zwei Byte repräsentiert, wie dies in der Abbildung 4-4 schematisch dargestellt wird.
Abbildung 4-4: DYUV-Bildformat
Da die relativen Y-Werte für jeden Bildpunkt einzeln festgehalten, die Veränderungen der U- und V-Werte aber nur einmal pro Pixelpaar codiert werden, wird die Helligkeit [106] (Y) also mit der doppelten Bandbreite der Farbe [107] (UV) gespeichert. Mit der Verwendung des DYUV-Formates können 216 verschiedene Farbwerte gleichzeitig dargestellt werden, wobei ein PAL-Vollbild 105 KByte RAM belegt.
Auch diese Codierung hat den Vorteil, dass sehr viele Farben verwendet werden können. Allerdings wird dabei gegenüber dem RGB555-Format nur die Hälfte des Speicherplatzes verwendet. Da das CD-i-System mit nur einem MByte RAM auskommen muss, ist dieser Vorteil nicht zu unterschätzen.
Die Nachteile liegen in der extremen Anfälligkeit auf Lesefehler. Wird nämlich nur ein Pixelwert falsch eingelesen, dann wirkt sich das auf alle folgenden Bildpunkte dieser Zeile sofort aus. Ausserdem sind Manipulationen, wie das Kopieren oder Verschieben von Teilbereichen, eines Bildes aufwendig und sehr langsam, da im rechten Grenzbereich die relativen Veränderungen immer neu berechnet werden müssen. Das Betriebssystem der CD-i-Geräte stellt aus diesem Grund auch keine derartigen Funktionen zur Verfügung. Weiter muss darauf geachtet werden, dass ein Pixelpaar immer an einer geraden x-Koordinate beginnen muss.
In der CIMEDIA-Applikation wird für alle Bilder, die in vielen Farbdetails dargestellt werden müssen, grundsätzlich das DYUV-Format verwendet. Dadurch wird einerseits Speicher eingespart und andererseits können immer beide Bildebenen voneinander unabhängig eingesetzt werden.
CD-i unterstützt verschiedene Bildformate, die eine Farbtabelle verwenden. In dieser Tabelle können bis zu 256 RGB [108]-Werte je mit 8 Bit gespeichert werden. Da nicht für beide Bildebenen eine eigene Farbtabelle verwendet werden kann, wird sie in vier Blöcke à 64 Einträge aufgeteilt. Ein derartiger Block steht immer nur für eine Ebene zur Verfügung.
Grundsätzlich liegen die Vorteile dieser Codierungsarten in der Robustheit gegenüber den auftretenden Lesefehlern, da sich ein fehlerhaftes Byte nur auf einen Bildpunkt auswirkt [109]. Bildmanipulationen sind sehr einfach zu implementieren und werden zum Teil direkt vom CD-i-Betriebssystem unterstützt.
Der einzige Nachteil diese Formates ist, dass nur relativ wenige Farben gleichzeitig dargestellt werden können. Wie viele es genau sind, hängt davon ab, welches der zur Verfügung stehenden CLUT-Formate (CLUT8, CLUT7 oder CLUT4) eingesetzt wird.
CLUT8
Wird die CLUT8-Codierung verwendet, dann können Bilder in 256 verschiedenen Farben dargestellt werden. Jedes Byte im Bildschirmspeicher repräsentiert via Farbtabelle direkt einen einzelnen Bildpunkt.
Abbildung 4-5: CLUT8-Bildformat
Ein PAL-Vollbild belegt 105 KByte Speicher. Da die CLUT8-Codierung nur in der Ebene 'A' verwendet werden darf und kein Block der Farbtabelle mehr frei ist, kann in der Bildebene 'B' nur noch ein DYUV-Bild dargestellt [110] werden.
In CIMEDIA werden die Bilder der Benutzerschnittstellen im CLUT8-Format dargestellt, da hier viele Bildmanipulationen durchzuführen sind. Die Einschränkung, dass nur 256 verschiedene Farben gleichzeitig verwendet werden dürfen, kann für diese Bilder gut hingenommen werden. Alle Bilder der Interviews können in sehr guter Qualität präsentiert werden, da für diese Bilder das DYUV-Format gewählt wird.
CLUT7
Die CLUT7-Codierung verwendet eine aus nur zwei Bänken zusammengesetzte Farbtabelle. Es werden zwar nur 128 Farben gleichzeitig dargestellt, dafür kann diese Codierung in beiden Bildebenen gleichzeitig verwendet werden.
Abbildung 4-6: CLUT7-Bildformat
CLUT4
Bei der Anwendung der CLUT4-Codierung muss entweder die doppelte oder die hohe Auflösung [111] verwendet werden. Wie in Abbildung 4-7 schematisch aufgezeigt wird, definiert jedes Byte aus dem Bildschirmspeicher ein Pixelpaar auf dem Monitor. Ein PAL-Vollbild [112] belegt also immer noch mindestens 105 KByte Bildschirmspeicher. Das CLUT4-Format wird für Bilder verwendet, die in einer höheren Auflösung wiedergegeben werden müssen. Allerdings können nur noch 16 Farben gleichzeitig dargestellt werden. Diese Beschränkung ist so gravierend, dass CLUT4-Bilder in CIMEDIA nicht verwendet werden.
Abbildung 4-7: CLUT4-Bildformat
Das RLE [113]-Verfahren erlaubt die komprimierte Speicherung von Bildern, die eine Farbtabelle verwenden. Eine Sequenz gleichfarbiger Bildpunkte wird mit 2 Byte codiert. Im ersten Byte wird der Farbtabellenindex und im zweiten die Länge der Sequenz definiert. Die Länge '0' kann angegeben werden, wenn die Farbe des Pixels bis zum Ende der Bildschirmzeile verwendet werden soll. Jede Zeile muss auf diese Weise abgeschlossen werden.
Die RLE-Codierung steht in zwei Varianten zur Verfügung. Das RL7-Format erlaubt die gleichzeitige Darstellung von 256 Farben. Genügen deren 8 zur Wiedergabe eines Bildes, so kann die RL3-Codierung eingesetzt werden.
Der Vorteil der RLE-Formate ist, dass die Bilddaten komprimiert, d.h. platzsparend gespeichert werden können. Der Komprimierungsfaktor hängt von der Art der Bilder ab. Für das CIMEDIA-Projekt wurden die Bilder des Fabrikrundgangs versuchsweise mit dem RL7-Format komprimiert. Im Durchschnitt konnten ca. 50% Speicherplatz gegenüber der CLUT7-Codierung eingespart werden. Einige dieser Bilder konnten allerdings nur um etwa 10% reduziert werden.
Leider verhalten sich die RLE-Formate gegenüber den Lesefehlern nicht sehr robust. Eine fehlerhafte Sequenzlänge wirkt sich, ab der entsprechenden Spalte, über die ganze Bildschirmzeile aus. Ausserdem bietet das Betriebssystem keine Funktionen zur Manipulation von RLE-Bildern an.
In der folgenden Tabelle 4-5 werden die zur Verfügung stehenden Bildformate des CD-i-Standards und deren wichtigsten Eigenschaften zusammengefasst. In der Spalte 'Unterstützung' wird angegeben, ob das CD-i-Betriebssystem Kopierfunktionen für das entsprechende Bildformat anbietet.
Tabelle 4-5: Zusammenfassung der Bildformate
Die Bildschirmanzeige wird durch das sogenannte Display Control Program (DCP) gesteuert. Pro Bildebene werden zwei [114] Instruktionstabellen (LCT [115] und FCT [116]) verwendet, die entsprechende Steuerungsbefehle [117] aufnehmen. Die in den beiden FCT-Tabellen gespeicherten Befehle werden ausgeführt, während der Kathodenstrahl [118]des Fernsehgerätes, auf der in Abbildung 4-8 mit s1 bezeichneten Strecke, zur Darstellung eines neuen Halbbildes, in die linke obere Ecke bewegt wird. Während dieser Zeitspanne können bis zu 1024 DCP-Befehle abgearbeitet werden. In einer LCT-Tabelle können pro Bildzeile bis zu acht Befehle gespeichert werden. Diese werden bearbeitet, während der Kathodenstrahl an den Anfang der entsprechenden Zeile positioniert wird.
Der letzte Befehl in der FCT stellt die Verbindung zu einer LCT-Tabelle her. Ein einmalig ausgeführter Befehl gilt immer automatisch für alle folgenden Bildschirmzeilen, bis er mit neuen Argumenten wiederholt wird. Er setzt sich aus einem Byte Operationscode [119] und drei Byte zur Angabe der Parameter zusammen. Da das CD-i-System nur über einen 16-Bit-Datenbus verfügt, muss das Schreiben der 32-Bit-Befehle entweder mit dem Kathodenstrahl des Bildschirmes synchronisiert oder unter Anwendung eines Puffers erfolgen. Sonst kann es passieren, dass ein Befehl ausgeführt wird, der noch nicht vollständig geschrieben wurde. Dadurch kann das DCP-Programm und somit auch das ganze Betriebssystem abstürzen. Da das Synchronisieren oder Puffern nicht durch das Betriebssystem durchgeführt wird, müssen diese Aufgaben durch die Applikation erledigt werden.
Abbildung 4-8: Schematischer Ablauf des DCP
Bei der Planung einer CD-i-Applikation sollte berücksichtigt werden, welche Bildeffekte direkt eingesetzt werden können. In den folgenden Abschnitten werden daher die wichtigsten Effekte kurz vorgestellt.
Die sofortige Darstellung eines Bildes auf dem Bildschirm wird als Schnitt bezeichnet. Da dafür mehrere DCP-Befehle notwendig sind, kann ein Flackern entstehen, wenn ein noch nicht vollständig definiertes Bild schon auf dem Bildschirm erscheint. Darum sollte ein Bild immer zuerst in der versteckten hinteren Bildebene aufgebaut und erst danach durch das Wechseln der Darstellungsreihenfolge der Ebenen [120] auf dem Bildschirm präsentiert werden.
In einer LCT-Tabelle kann mit einem DCP-Befehl für jede Bildschirmzeile eine neue Speicheradresse angegeben werden. Dieser Befehl ermöglicht die sofortige horizontale oder vertikale Verschiebung eines Bildstreifens, ohne dass dafür langsame Speicheroperationen notwendig sind.
Bei der horizontalen Verschiebung von DYUV-Bildern muss der YUV-Startwert, der für jede Zeile den Anfangswert der Codierung vorgibt, zusätzlich durch die Applikation neu berechnet werden. RLE-Bilder können nur mit sehr grossem Berechnungsaufwand horizontal verschoben werden. Das CD-RTOS Betriebssystem [121] bietet hierzu keine Funktionen an.
Das CD-i-System kann nur Bildstreifen bearbeiten [122], die sich immer über die ganze Bildschirmbreite ausdehnen. Sollen kleinere Teilbilder dargestellt werden, dann müssen sie in einen Bildstreifen kopiert werden. Dies ist für RGB555- und CLUT-Bilder ohne Probleme möglich. Das Kopieren von DYUV- und RLE-Teilbildern wird vom Betriebssystem hingegen nicht unterstützt.
Die Farbtabelle wird in einer FCT-Tabelle definiert. Durch deren Veränderung kann also zwischen der Darstellung zweier Fernsehbilder, d.h. jede 1/25 Sekunde, die ganze Farbtabelle neu definiert werden. Diese Technik wird auch als CLUT-Animation bezeichnet. Ausserdem können auch in einer LCT-Tabelle neue Farbeinträge definiert werden. Pro Zeile können maximal acht Farben verändert werden.
Wie schon in den Abschnitten 4.3.1.6 und 4.3.4.1 erwähnt, kann die Darstellungsreihenfolge der beiden Bildschirmebenen auf jeder Zeile gewechselt werden. Es ist allerdings auch möglich, beide Ebenen gleichzeitig darzustellen. In einer LCT-Tabelle kann dazu für jede Bildschirmzeile ein prozentualer Bildbeteiligungsfaktor [123] angegeben werden. So kann zum Beispiel das Bild in der Ebene 'A' zu 30% und dasjenige in 'B' zu 60% wiedergegeben werden. Da insgesamt nur 90% erreicht werden, ist die Helligkeit des resultierenden Mischbildes um 10% reduziert. Durch Veränderung dieses Faktors können insbesondere auch Überblendungen zwischen den beiden Bildebenen erreicht werden. Im Gegensatz zum Schnitt, der ein Bild sofort darstellt, erscheint bei der Überblendung ein neues Bild nur langsam.
Durch spezielle DCP-Befehle können die Werte zweier sogenannter Matte-Register beeinflusst werden. Im Gegensatz zu den Befehlen, die immer eine ganze Bildschirmzeile steuern, können die Matte-Register Bildeffekte an beliebigen Positionen erzeugen. Sie kontrollieren den Bildbeteiligungsfaktor oder die Transparenz eines rechteckigen Bereichs auf dem Bildschirm.
Ein transparenter Bildpunkt erscheint durchsichtig. Es stehen drei kombinierbare Mechanismen zur Kontrolle der Transparenz in beiden Bildebenen zur Verfügung:
Mosaike werden durch spezielle DCP-Befehle in einer LCT-Tabelle erzeugt und erlauben die Bilddarstellung in reduzierter Auflösung. Es existieren zwei Varianten, die Körnung und die Vergrösserung, die mittels der Tabelle 4-6 erläutert werden.
Tabelle 4-6: Körnung und Vergrösserung
In der obersten Zeile der Tabelle 4-6 sind die ersten elf Bildpunkte Pi,0 bis Pi,11 der Bildzeile i dargestellt. Wird die Körnung mit dem Faktor 3 angewendet, dann überschreibt der erste Pixelwert Pi,0 die Punkte Pi,1 und Pi,2. Der erste Bildpunkt wird also dreimal dargestellt. Auf dieselbe Art werden die weiteren Bildpunkte (Pi,3, Pi,6, etc.) wiederholt. Bei der Vergrösserung werden alle Punkte einer Zeile mehrfach gezeichnet. Dadurch wird das Bild auf der rechten Seite abgeschnitten.
Um dieselben Effekte in vertikaler Richtung durchzuführen, muss die Applikation die entsprechenden Startwerte des Bildschirmspeichers für jede einzelne Zeile in die LCT-Tabelle schreiben.
Die Vergrösserung kann nur für RGB555- und CLUT-Bilder durchgeführt werden. Die Körnung steht hingegen für alle Bildformate zur Verfügung.
In den drei vorangestellten Kapiteln 4.1 bis 4.3 wurden die Hardware, die Audio- und die Videofähigkeiten der CD-i-Geräte vorgestellt. Nun werden wir deren Betriebssystem CD-RTOS [127] etwas genauer betrachten. Da CD-RTOS aus OS-9 entstand, sei für weiterführende Literatur auf [OS9Man91], [Dibble88], [Dibble92] und besonders auch auf [Dayan92] verwiesen.
OS-9 wurde speziell für den Einsatz in Echtzeitanwendungen [128], wie beispielsweise die Robotersteuerung, entwickelt. Daher wurden die Anforderungen an die Hardware sehr gering gehalten. So ist für den Betrieb von OS-9 nur sehr wenig RAM und weder eine Festplatte noch ein Terminal notwendig.
Heute finden sich OS-9-Systeme nicht nur in Steuerungen der Roboter, sondern auch in Simulatoren, Flugzeugsteuerungen und sogar in den Space Shuttles der NASA. Gerade für derartige Systeme sind die geringen Anforderungen an die Hardware und die Echtzeitfähigkeit von OS-9 besonders wichtig.
Angesichts dieser Eigenschaften von OS-9 wurde es von Philips und Sony, in einer leicht erweiterten Form als CD-RTOS, zum Betriebssystem der CD-i-Geräte gewählt.
OS-9 wurde von der Firma Microware anfangs der achtziger Jahre entwickelt. Ein kleines Team nahm UNIX als Vorbild und entwarf mit der Unterstützung von Motorola, dem Hersteller der 6809-Prozessoren, OS-9 als Mehrbenutzer- und Echtzeitsystem. Bei der Entwicklung wurde darauf geachtet, dass OS-9 ein sehr schnelles und kleines Betriebssystem wurde. Dies führte zur Entwicklung in der Sprache Assembler und damit in die Abhängigkeit zu den Prozessoren von Motorola. Später wurde mit OS-9000 (geschrieben in C) auch eine Portierung für die INTEL-Prozessoren entwickelt.
Für den Begriff Echtzeitsystem existiert keine allgemein anerkannte Definition. Eine mögliche Ausführung stammt von Donald Gillies [129]:
Definition Echtzeitsystem nach Donald Gillies
"In einem Echtzeitsystem hängt die Korrektheit des Ablaufs nicht nur vom logischen Resultat ab, sondern auch von der Zeit, innerhalb derer das Ergebnis produziert wurde. Falls ein Resultat nicht innerhalb der vordefinierten Zeitspanne produziert wird, ist das System fehlerhaft."
Das bedeutet nicht, dass solche Systeme extrem schnell sein müssen. Die Zeitspanne darf durchaus auch länger sein (z.B. mehrere Sekunden). Wichtig ist nur, dass die Reaktion in jedem Fall innerhalb der definierten Zeit eintritt.
Die folgende Tabelle 4-7 listet einige mögliche Einsatzbereiche für
Echtzeitsysteme auf:
| Bereich | Echtzeitanforderung |
| Robotersteuerung | Wenn ein Roboter Teile von einem Fliessband greifen soll, dann müssen sich seine Greifarme nicht nur am richtigen Ort, sondern auch zur richtigen Zeit schliessen. |
| Flugzeugsteuerung | In einem Flugzeug muss der Autopilot nicht nur die richtigen Steuerbefehle für die Ruder und Düsen generieren, sondern auch innerhalb genau definierter Zeitparameter reagieren. |
| Multimediasystem | Die Bild- und Toninformationen müssen zeitlich synchronisiert wiedergegeben werden. Auf eine Benutzeraktion muss innerhalb einer maximalen Antwortzeit reagiert werden. |
Tabelle 4-7: Einige Einsatzbereiche für Echtzeitsysteme
Echtzeitverhalten des CD-i-Systems
Jedes CD-i-Gerät muss, gemäss Spezifikation, 75 Sektoren pro Sekunde von der CD-Scheibe ablesen und verarbeiten können. Diese Forderung kann natürlich nicht alleine durch das Betriebssystem erfüllt werden, vielmehr muss auch die CD-i-Applikation den anfallenden Datenstrom bewältigen können.
Betrachten wir hierzu ein Beispiel. Eine RTF-Datei kann in einem Kanal verschiedene Bilder speichern. In der oberen Hälfte der Abbildung 4-9 wird der Beginn einer RTF-Datei dargestellt, in der durchnumerierte Bilder im Kanal '1' abgelegt werden. Nehmen wir an, dass für jedes Bild 10 Sektoren zur Speicherung benötigt werden. Beim Lesen eines Bildes vergehen somit 10/75 Sekunden [130]. Jedes Bild muss anschliessend verarbeitet und dargestellt werden [131]. Da dafür im Beispiel der Abbildung 4-9 15/75 Sekunden benötigt werden, entsteht ein fehlerhaftes Verhalten des Systems, denn der anfallende Datenstrom kann nicht mehr verarbeitet werden.
Abbildung 4-9: Fehlerhafte Anordnung der Bilder in einer RTF-Datei
Das erste Bild wird nach 25/75 Sekunden auf dem Monitor dargestellt. Zu diesem Zeitpunkt wird aber schon das Bild '3' eingelesen. Die Nummer '2' muss also noch in einem Puffer gespeichert sein. Je mehr Bilder eingelesen werden, desto mehr RAM wird zur Pufferung der schon gelesenen, aber noch nicht verarbeiteten Bilder benötigt. Die synchrone Darstellung der Bilder mit allfälligen Audiodaten in der RTF-Datei ist bei dieser Anordnung unmöglich. Dieses Problem kann auf zwei Arten gelöst werden, durch Überspringen oder durch Leerräume.
Überspringen
Damit kein zusätzlicher Speicher zur Pufferung verwendet werden muss, überspringt die CD-i-Applikation immer einige Bilder. Sie synchronisiert sich also mit dem anfallenden Datenstrom. Dies erfordert einen relativ intelligenten Manager, der laufend die anfallende mit der verarbeiteten Datenmenge vergleicht. Bei dieser Lösungsvariante gehen einige Bildinformationen verloren. In der Abbildung 4-10 werden beispielsweise die Bilder '2' und '4' nicht mehr dargestellt.
Abbildung 4-10: Überspringen einzelner Bilder einer RTF-Datei
Leerräume
Auf der CD können zwischen den einzelnen Bildern Leerräume [132] eingefügt werden. Im Beispiel der Abbildung 4-11 werden zwischen zwei Bildern immer 10 leere Sektoren eingefügt. Dadurch kann der ganze anfallende Datenstrom bearbeitet werden. Wir haben also schon bei der Erstellung der RTF-Datei die Datenmenge soweit reduziert, dass deren Verarbeitung vollständig durchgeführt werden kann. Die Schwierigkeit besteht darin, die Länge der Pausen abzuschätzen.
Abbildung 4-11: Verwendung von Leerräumen in einer RTF-Datei
Unter OS-9 können mehrere Prozesse [133] gleichzeitig ausgeführt werden. Die Systemleistung wird vom Betriebssystem auf die Prozesse gemäss den ihren zugeordneten Prioritäten verteilt. Das CD-RTOS-System führt alle Leseoperationen auf die CD und die Wiedergabe der Soundmaps asynchron, d.h. als eigenständige Prozesse aus.
Praktisch das ganze Betriebssystem ist im ROM untergebracht. Daher ist zum Starten der CD-i-Geräte keine 'System-CD' notwendig.
Da OS-9 für den 6809 entwickelt wurde, teilen sich alle Prozesse denselben Adressraum [134]. Virtueller Speicher kann nicht verwendet werden, da hierzu ein externes Speichermedium benötigt würde. Zudem würde sich die Speicherauslagerung auf die Antwortzeit von Echtzeitprogrammen auswirken.
OS-9 fasst den freien Speicher in einem Pool zusammen, aus dem bei Bedarf an die Prozesse RAM verteilt wird. Jeder verwendet eine eigene Speichertabelle, in der die zugeteilten Bereiche eingetragen werden.
Verlangt ein Prozess mehr Speicher, dann erfolgt die Zuteilung in den ersten zusammenhängenden Speicherblock mit genügender Grösse. Grenzt dieser an einen Bereich, der schon für den Prozess reserviert wurde, dann werden beide Blöcke zusammengefasst. Die Grösse der Speichertabelle ist auf 32 Einträge limitiert. Da OS-9 freie Bereiche nicht automatisch zusammenfasst [135], muss die Applikation sicherstellen, dass der Speicher nicht zu stark fragmentiert, d.h. in viele einzelne kleine Blöcke aufgeteilt wird.
Betrachten wir einige konkrete Beispiele. In der folgenden Abbildung 4-12 werden links der freie Speicherpool und rechts drei Speichertabellen der Prozesse 'A', 'B' und 'C' dargestellt. Der freie Speicher beginnt bei der Adresse $1000 [136]. Er wird in absteigender Reihenfolge an die Prozesse vergeben. Es werden nicht einzelne Byte, sondern nur Blöcke mit einer minimalen Grösse, meist 16 Byte ($10), verteilt.
Abbildung 4-12: OS-9-Speicherverwaltung mit drei Prozessen, Phase 1
In diesem Beispiel hat zuerst der Prozess 'A' einen, danach der Prozess 'C' drei und zuletzt der Prozess 'B' zwei Blöcke verlangt. Dies wird in den entsprechenden Speichertabellen durch Angabe der Startadresse und Blockgrösse vermerkt.
Nun wird der Prozess 'C' beendet. Da keine Zusammenlegung freier Speicherbereiche erfolgt, entsteht nun zwischen $0FF0 und $0FC1 ein kleiner, nicht zugeordneter Bereich. Die Abbildung 4-13 zeigt die Situation, nachdem von 'A' noch vier weitere Blöcke angefordert wurden.
Abbildung 4-13: OS-9-Speicherverwaltung mit drei Prozessen, Phase 2
Weil der kleine freie Bereich ($0FF0 bis $0FC1) nur drei Blöcke umfasst, muss ein neuer Speicherteil ab $0FA0 reserviert werden. Da dieser aber nicht an den bisherigen Speicher von 'A' angrenzt, wird ein neuer Eintrag in der Speichertabelle notwendig. Wenn also viele Prozesse ständig neuen Speicher verlangen und wieder freigeben, kann eine Speichertabelle zum Überlauf gebracht werden. Abbildung 4-14 zeigt, wie zwei Prozesse, die immer abwechslungsweise einen Speicherblock anfordern, die OS-9-Speicherverwaltung durcheinander bringen.
Abbildung 4-14: OS-9-Speicherverwaltung, ungünstiger Fall
Obwohl noch sehr viel Speicher im Pool verfügbar ist [137], können beide Prozesse keinen neuen Speicher mehr verlangen, da ihre Speichertabellen vollständig gefüllt sind. Fordern die zwei Prozesse den gewünschten Speicher nacheinander an, dann ergibt sich die in Abbildung 4-15 aufgezeigte Situation.
Abbildung 4-15: OS-9-Speicherverwaltung, günstiger Fall
Wenn der Prozess 'A' 32mal hintereinander je einen Block verlangt, dann kann in seiner Speichertabelle der bestehende Eintrag immer erweitert werden. Danach kann der Prozess 'B' völlig ungestört den gewünschten Speicher anfordern. In dieser Situation steht für beide Prozesse noch viel Speicher zur Verfügung.
Um die oben erwähnten Speicherprobleme nicht entstehen zu lassen, werden in der CIMEDIA-Applikation folgende Massnahmen getroffen:
Unter OS-9 muss das vorhandene RAM noch genauer spezifiziert werden. So kann beispielsweise zwischen schnellen und langsamen Speicherbereichen unterschieden werden. Für die CD-i-Systeme existieren drei verschiedene RAM-Typen:
Die Verwendung der RAM-Typen ist zwingend, d.h. ein Bild in der Bildschirmebene 'A' kann nicht im RAM vom Typ Bildschirmebene 'B' gespeichert werden. Dies liegt in der Verantwortung der CD-i-Applikation.
Da OS-9 auch auf Systemen ohne Harddisk eingesetzt wird, können keine Konfigurationsdateien verwendet werden. An deren Stelle treten die sogenannten Module, die zur Speicherung der Programme, Systemkonfigurationen oder beliebiger anderer Daten eingesetzt werden. Obwohl die Daten der Module im RAM gespeichert sind, werden sie wie Dateien behandelt.
Die Kommunikation zweier Prozesse erfolgt im OS-9-System entweder durch Signale, Alarme, Events, Pipes oder Datenmodule. Die CIMEDIA-Applikation verwendet nur die ersten drei Konzepte, die in den folgenden Abschnitten kurz beschrieben werden.
Signale dienen vor allem der Synchronisation von Prozessen und erzeugen einen maskierbaren [138] Software-Interrupt. Der Applikation wird nur die 2 Byte lange Nummer des Signals übermittelt. CD-RTOS löst in folgenden Situationen Signale aus:
Alarme lösen Signale zu einem bestimmten Zeitpunkt aus. Die Zeit wird in systemabhängigen Zeiteinheiten [141] gemessen. In CD-RTOS entspricht eine Einheit einer 1/100 Sekunde.
Bei den OS-9-Events handelt es sich um Semaphore, mit denen Deadlocks beim Zugriff auf gemeinsame Ressourcen vermieden werden können. Sie werden zum Beispiel verwendet, um das Schreiben der DCP-Befehle in die FCT- :und LCT-Tabellen mit dem Kathodenstrahl des Monitors zu synchronisieren [142].
In allen CD-i-Geräten wird das CD-RTOS-Betriebssystem verwendet, dessen Details aus [GreenBook90] zu entnehmen sind. Wir betrachten hier nur exemplarisch die Datenstrukturen, die zum Lesen einer RTF-Datei definiert werden müssen.
Dateimanager
Der CD-RTOS-Dateimanager bietet die üblichen Leseoperationen an. Mit dem Befehl ss_seek() wird beispielsweise der Lesekopf zu einer bestimmten Sektornummer positioniert. Wie alle anderen Operationen des Dateimanagers wird dieser Befehl asynchron ausgeführt, d.h. nach Erreichung der gewünschten Stelle wird ein Signal ausgelöst. Die wichtigste Funktion dieses Managers ist sicher der Befehl ss_play(), der das Lesen einer RTF-Datei ermöglicht. Als Parameter muss unter anderem ein sogenannter Play-Control-Block übergeben werden.
Play-Control-Block (PCB)
Der Play-Control-Block speichert folgende Informationen:
Channel-Index-Liste (CIL)
Diese Liste speichert für jeden Kanal je einen Zeiger auf eine Play-Control-Liste.
Play-Control-Liste (PCL)
Die PCL-Struktur dient im wesentlichen zur Speicherung der folgenden Werte:
Die Abbildung 4-16 soll das Zusammenspiel der oben erwähnten Strukturen verdeutlichen:
Abbildung 4-16: Zusammenspiel der PCB-, CIL- und PCL-Strukturen
Wir erkennen, dass im PCB nur ein Zeiger auf die Video-CIL angegeben wird. In diesem Beispiel werden damit keine Audio- und Computerdaten in den Speicher eingelesen. Falls in einem durch Audio-Channelmask ausgewählten Kanal Audiodaten in der RTF-Datei gespeichert sind, dann werden sie in diesem Fall direkt via Audioprozessor wiedergegeben. Der Umweg über das RAM des CD-i-Systems ist also nicht notwendig [144]. In der Video-CIL wird für die ersten vier Kanäle (0 bis 3) je ein Zeiger auf eine PCL-Struktur angegeben.
Die Videodaten des Kanals '0' werden in den durch PCL1 definierten Pufferspeicher übertragen, bis die Menge der eingelesenen Daten dem Wert Size of buffer in PCL1 entspricht. Danach wird das entsprechende Signal ausgelöst. Alle weiteren Daten im Kanal '0' werden einfach ignoriert, da der Zeiger Next PCL auf NULL gesetzt wurde.
Im Unterschied dazu werden nach dem vollständigen Füllen des in PCL2 definierten Puffers auch noch diejenigen in PCL3 und PCL4 verwendet.
In CIMEDIA werden keine mit NULL terminierten Listen verwendet, da zyklische Listen ohne Nachteile viel flexiblere Strukturen erlauben. In der Abbildung 4-16 werden zwei derartige Listen für die Kanäle '2' und '3' dargestellt.
Bei diesen Listen wird, nachdem der letzte definierte Puffer gefüllt wurde, automatisch wieder mit dem Einlesen in den ersten Puffer fortgefahren. Um der Applikation die Möglichkeit zu geben, die Pufferdaten abzuholen, werden in CIMEDIA meist mehrere Listenelemente eingesetzt. In obigem Beispiel können die Daten des Puffers in PCL6 verarbeitet werden, während PCL7 eingelesen wird.
[74] Das sogenannte Base Case-System. Es wird auch ein Extended Case-System definiert, welches zusätzliche Hardwarekomponenten enthalten kann.
[75] Central Processing Unit.
[76] Direct Memory Access.
[77] Random Access Memory.
[78] Vergleiche hierzu Abschnitt 4.4.7.1.
[79] Read Only Memory.
[80] Non Volatile Random Access Memory.
[81] Beispielsweise das X/Y-Eingabegerät oder der Audioprozessor.
[82] Motion Picture Expert Group. Ein Standard zur Komprimierung von Videosequenzen.
[83] Local Area Network.
[84] Die Grundlagen der digitalen Speicherung von Audiodaten werden im Anhang B wiedergegeben.
[85] Vergleiche hierzu Abschnitt 3.3.3.
[86] Eine Übersicht der Fernsehnormen wird im Anhang C präsentiert.
[87] Die Aspect Ratio definiert das Verhältnis 'Seite zu Höhe' eines Pixels. Für PAL-Systeme beträgt sie 1,05. NTSC-Pixel haben eine Aspect Ratio von 1,19.
[88] Wird als Double Resolution bezeichnet.
[89] Es sind dies CLUT4 (Abschnitt 4.3.2.3) und RL3 (Abschnitt 4.3.2.4).
[90] Wird als High Resolution bezeichnet.
[91] Wird als Safety Area bezeichnet.
[92] Wird als Plane bezeichnet.
[93] Wird als Backdrop Area bezeichnet.
[94] Wird als External Video bezeichnet.
[95] Wird als Cursor Plane bezeichnet.
[96] Vergleiche hierzu Abschnitt 4.4.7.1.
[97] Vergleiche hierzu Abschnitt 4.3.2.1.
[98] Vergleiche hierzu Abschnitt 4.3.2.2.
[99] Das RGB555-Format verwendet eine aufwendige Repräsentation der Bilder im Speicher. DYUV-Bilder können nur mit erheblichem Aufwand auf dem Bildschirm verschoben werden.
[100] Vergleiche hierzu Abschnitt 4.3.2.3.
[101] Wird als Color Lookup Table bezeichnet.
[102] Vergleiche hierzu Abschnitt 4.3.2.4.
[103] Wie schon in den Abschnitten 4.1 und 4.3.1.5 erläutert, wird der Speicher eines CD-i-Gerätes in zwei Blöcke eingeteilt, die je nur die Daten einer Bildebene aufnehmen können. Da für jede Bildschirmzeile eine neue Speicheradresse angegeben werden kann (Abschnitt 4.3.1.5), ist im allgemeinen die Bildschirm- mit der Framebuffer-Zeile nicht identisch (i<>k).
[104] Delta YUV. Das YUV-Farbmodell wird auch von der PAL-Fernsehnorm verwendet. Im Kapitel 13.2 von [FvDFH90] werden verschiedene Farbmodelle erläutert. Auch [Haberäcker95] bietet im Kapitel 3.2 eine gute Übersicht.
[105] Der Startwert wird in der FCT-Tabelle definiert. Vergleiche hierzu Abschnitt 4.3.3.
[106] Wird als Luminanz bezeichnet.
[107] Wird als Chrominanz bezeichnet.
[108] Red Green Blue.
[109] Ausser das falsche Byte wird für die Farbtabelle verwendet. In diesem Fall werden unter Umständen sehr viele Bildpunkte fehlerhaft dargestellt.
[110] Das RGB555-Format kann nicht benützt werden, da es beide Bildebenen gleichzeitig verwendet.
[111] Vergleiche hierzu die Abschnitte 4.3.1.2 und 4.3.1.3.
[112] In der doppelten Auflösung werden 768*280 Bildpunkte verwendet.
[113] Run Length Encoded.
[114] Es könnten auch mehrere miteinander verbundene LCT-Tabellen definiert werden.
[115] Line Control Table.
[116] Field Control Table.
[117] Ein vollständige Liste der Steuerbefehle wird im Anhang D wiedergegeben.
[118] Die Grundlagen der Fernsehtechnik werden im Anhang C präsentiert.
[119] Jedem DCP-Befehl wird ein Operationscode zugeordnet, der ihn eindeutig identifiziert.
[120] Dies wird durch einen DCP-Befehl erreicht.
[121] Vergleiche hierzu Kapitel 4.4.
[122] Vergleiche hierzu Abschnitt 4.3.1.6.
[123] Wird als Image Contribution Factor (ICF) bezeichnet.
[124] Vergleiche hierzu Abschnitt 4.3.2.1.
[125] Wird auch als Color Key bezeichnet.
[126] Allerdings werden von jedem RGB-Farbwert nur die Bit2 bis Bit7 beachtet. Die Bit0 und Bit1 werden einfach ignoriert.
[127] Compact Disc Realtime Operating System.
[128] Der Begriff Echtzeit wird im Abschnitt 4.4.4 erläutert.
[129] Diese Definition wurde aus der FAQ-Liste (frequently asked questions) zur USENET-Newsgroup 'comp.realtime' (http://www.cis.ohio-state.edu/hypertext/faq/usenet/realtime-computing/top.html) entnommen.
[130] Wir kürzen die Brüche nicht, da für 75 Sektoren genau eine Sekunde benötigt wird.
[131] Mögliche Verarbeitungen sind beispielsweise das Schreiben der DCP-Befehle oder das Kopieren in einen Bildschirmspeicher.
[132] Ein Leerraum besteht aus Sektoren des Datentyps Empty. Vergleiche hierzu Abschnitt 3.3.3.
[133] Wird auch als Task bezeichnet.
[134] Der 6809-Prozessor bietet keine Speicherverwaltung an.
[135] Wird auch als Garbage Collection bezeichnet.
[136] Die hexadezimale Schreibweise wird durch ein vorangestelltes '$' Zeichen gekennzeichnet.
[137] Für beide Prozesse konnten nur je 32*16 Byte = 0,5 KByte RAM reserviert werden.
[138] Ein maskierbarer Interrupt kann für eine kurze Zeitspanne unterdrückt werden.
[139] Die hier erwähnten Funktionen ss_seek(), ss_play() und sm_out() werden von CD-RTOS zur Verfügung gestellt.
[140] Beim Lesen einer RTF-Datei werden sowohl PCB- als auch PCL-Signale gesendet. Vergleiche hierzu Abschnitt 4.4.9.
[141] Eine Zeiteinheit wird oft als Tick bezeichnet.
[142] Grundsätzlich kann die Synchronisation mit dem Kathodenstrahl des Monitors auch durch Signale erreicht werden. Die Belastung des Systems durch die vielen zusätzlichen Unterbrechungen ist allerdings erheblich.
[143] Vergleiche hierzu Abschnitt 3.3.3.
[144] Falls die Audiodaten in Soundmaps gespeichert werden sollen, dann muss eine Audio-CIL definiert werden.
| Index | Zurück | Weiter |