NVDI für den Falcon030

Es gibt Programme auf dem ATARI-Sektor, die man ohne Übertreibung als Klassiker bezeichnen darf. Hierzu zählt auch NVDI. Dieser Software-Blitter, der schon seit geraumer Zeit auf STs und TTs seinen Dienst verrichtet, ist nun endlich auch für den Falcon030 erhältlich.

Dabei hat es eigentlich gar nicht so lange gedauert, bis die Anpassung an den Falcon erfolgt war. Dennoch dürfte es so manchem Anwender wie eine Ewigkeit vorgekommen sein. Kein Wunder, die größere Farbvielfalt des Falcon, verglichen mit den Leistungsdaten der bisherigen ATARI-Computer, senkt zwangsweise die Geschwindigkeit bei der Bildaufbereitung. Zwar ist der Falcon030 ein ganzes Stück schneller als ein ST, aber je mehr Farben bereitstehen, um so mehr Rechenleistung wird auch gefordert.

Insbesondere die Bildschirmausgabe trägt viel zum ersten Eindruck bei, den man von der Gesamtgeschwindigkeit eines Computersystems bekommt. Und das ist auch nicht weiter erstaunlich. Gerade bei Systemen wie dem ATARI, wo die Optik einen wichtiger Bestandteil der Kommunikation mit dem Rechner darstellt, ist ein flüssiger Bildaufbau ein wichtiger Faktor. Es kommt schließlich nicht von ungefähr, daß auf dem Sektor der IBM-Kompatiblen verstärkt Grafikkarten mit speziellen Treibern zum Einsatz kommen, die vor allen Dingen der Ausgabegeschwindigkeit unter der grafischen Oberfläche WINDOWS Beine machen. Auf dem ATARI kommt man glücklicherweise ohne zusätzliche Hardware aus.

Speicherfresser

Es wurde bereits angesprochen, daß eine größere Farbpalette gleichbedeutend mit einer erhöhten Datenmenge ist, die zur Aufbereitung einer Grafik bewegt werden muß. In den High-Color-Modi des Falcon030 mit 65536 Farben benötigt der Bildschirmspeicher, aus dem sich das Videosystem seine Daten holt, je nach Auflösung mehr als ein halbes MByte RAM. Eine kleine Übersicht soll die Zusammenhänge zwischen Auflösung, Zahl der Farben und Größe des Bildschirmspeichers verdeutlichen, wobei bis auf die hohe TT-Auflösung alle aufgeführten Auflösungen ohne zusätzliche Hardware vom Falcon unterstützt werden (s. Tabelle 1).

Diese Auflösungen lassen sich per Software oder mit geeigneter Zusatz-Hardware weiter erhöhen, so daß im Extremfall nahezu ein MByte an Hauptspeicher für die Pufferung der Bilddaten verlorengeht.

Auch wenn manchmal noch von einem Falcon-Modell mit nur einem MByte Hauptspeicher die Rede ist, sieht man an diesen Zahlen, daß ein solches Gerät eigentlich keinen Sinn macht.

Was die High-Color-Auflösungen mit 640x400 und mehr Punkten angeht, lassen sich diese übrigens nur an einem Fernseher oder mit einem geeigneten Mehrfrequenzmonitor darstellen. Dabei wird das Interlace-Verfahren verwendet, bei dem die geraden und ungeraden Pixel-Zeilen in getrennten Durchgängen aufbereitet werden. Dies führt zwangsweise zu einem deutlichen Flimmern des Bildes.

Software statt Blitter

Vielen, die schon länger einen ATARI besitzen, dürfte NVDI bereits bestens bekannt sein. Selbst auf den Mega STs und Mega STEs, die mit einem speziellen Blitter-Chip zur Beschleunigung der Grafikausgabe ausgerüstet waren, kann mit NVDI eine deutliche Geschwindigkeitssteigerung beim Bildaufbau unter GEM erzielt werden. Bei Geräten ohne Blitter ist der Unterschied noch gravierender.

640x400 (ST hoch) 1 2 32000
1280x960 (TT hoch) 1 2 153600
640x480 (TT mittel) 4 16 153600
640x480 (Standard VGA) 8 256 307200
640x400 (Interlaced) 16 65536 512000
768x480 (Overscan-Modus) 16 65536 737280

Tabelle 1: Zusammenhang zwischen Auflösung, Anzahl der Farben und Bildschirmspeichergröße

Das wirft natürlich gleich die Frage auf, warum ATARI überhaupt einen Blitter einsetzt, wenn man alleine per Software die gleiche oder gar eine noch höhere Geschwindigkeit erreichen kann. Die Antwort ist leider ziemlich unbefriedigend: man muß davon ausgehen, daß die Programmierer des VDI (Virtual Device Interface), das die grundlegenden Grafikoperationen zur Verfügung stellt, nicht in der Lage waren, die Software so zu optimieren, daß ein Blitter unnötig gewesen wäre. Hinzu kommt, daß der Blitter lediglich das Verschieben von Daten und damit auch von Bildschirmbereichen (Fenstern) beschleunigt. Andere Grafikfunktionen profitieren weit weniger oder gar nicht davon. Dafür, daß sich im VDI eine ganze Menge optimieren ließe, ist NVDI der beste Beweis. Tun wir also das, was bei einem Test von Programmen wie NVDI unvermeidlich ist, und werfen einen Blick auf den Beschleunigungsfaktor.

NVDI in der Praxis

Die Werte für ST und TT sind im wesentlichen unverändert geblieben. Lediglich in der niedrigen TT-Auflösung sowie bei den Rasterfunktionen ergibt sich gegenüber NVDI 2.1 ein größerer Geschwindigkeitsvorteil.

Widmen wir uns also ganz dem Fal-con030. Zur Messung wurden Standardauflösungen mit 4, 8 und 16 Farbebenen, also mit 16, 256 und 65536 Farben herangezogen. Außerdem wurde die hohe ST-Auflösung berücksichtigt, da es leider noch immer Programme gibt, deren Programmierer noch nichts von anderen Monitoren als dem SM 124 gehört haben. Gearbeitet wurde mit einem VGA-Monitor bei 60 Hertz Bildfrequenz. Lediglich für die High-Color-Auflösung mit 640x400 Punkten wurde im PAL-Modus (Fernseher) gearbeitet. Werden im VGA-Betrieb höhere Bildfrequenzen als 60 Hertz verwendet (beim Falcon030 ist dies durch geeignete Software möglich), liegen die Werte zwangsweise niedriger, da in einer Zeiteinheit mehr Daten über den Videobus geschickt werden müssen. So beträgt der Geschwindigkeitsverlust bei einer Erhöhung der Bildfrequenz auf 78 Hertz ca. 6%. Dies gilt natürlich global, also nicht nur für das Arbeiten mit NVDI.

Als Referenzsystem diente mangels auf den Falcon030 abgestimmter Vergleichswerte ein normaler ST mit TOS 1.04. Dies schränkt die Aussagekraft der erhaltenen Werte jedoch in keiner Weise ein. Die Referenzauflösung war die hohe ST-Auflösung, was dazu führte, daß in den Farbauflösungen Werte von unter 100% auf-treten konnten. In Farbe geht vieles nun einmal langsamer. Es wurden Tests mit dem Programm QUICKINDEX (Tabelle 1) sowie mit dem im Lieferumfang von NVDI enthaltenen GEM_TEST (Tabelle 2) durchgeführt. Die Werte für die Ausgabe unter TOS sind dabei nicht so stark zu gewichten wie die Geschwindigkeit bei der Ausgabe unter GEM, denn man arbeitet ja auf dem ATARI hauptsächlich unter Grafikbedingungen. Daß für die High-Color-Tests keine Angaben für den Blitter-Betrieb vorliegen, erklärt sich ganz einfach dadurch, daß NVDI den Blitter für diese Modi aus Geschwindigkeitsgründen nicht unterstützt.

Wirft man einen Blick auf die erhaltenen Werte, muß man sich fragen, warum ATARI nicht gleich völlig auf den Blitter verzichtet hat. Bis auf wenige Ausnahmen werden mit NVDI höhere Geschwindigkeiten erreicht. Dies ist insbesondere für die Geschwindigkeit der Grafikausgabe unter GEM der Fall. Interessant ist, daß Ausgaben in den High-Color-Modi zum Teil schneller ablaufen als im Modus mit 256 Farben. Das liegt daran, daß die Bildschirmorganisation des Falcon030 bei 8 Farbebenen nicht sehr optimal gelöst ist, was zu Geschwindigkeitseinbußen führt.

Aktionen abseits des Bildschirms

Ein neues Leistungsmerkmal von NVDI 2.5 ist die Unterstützung sogenannter „Off-screen Bitmaps“. Sie erlauben das Aufbereiten von Grafiken im Speicher, ohne daß der Bildschirminhalt dabei verändert wird. Dabei muß die Auflösung dieser Bitmaps nicht mit der Bildschirmauflösung übereinstimmen.

Eine interessante Anwendung von Off-screen Bitmaps ist beispielsweise die Aufbereitung von Grafiken für die Druckerausgabe. Dazu legt man eine Bitmap an, deren Auflösung identisch mit der Druckerauflösung ist. In diese Bitmap läßt sich nun mit den üblichen VDI-Funktionen zeichnen, ganz so, wie man es vom Bildschirm her kennt. Anschließend läßt sich die erhaltene Grafik ohne großen Aufwand zum Drucker übertragen oder als Bilddatei speichern. Die Ausgabe von Vektorgrafiken auf pixelorientierte Ausgabegeräte wird durch dieses Prinzip stark vereinfacht. Voraussetzung ist natürlich, daß genügend Speicherplatz für eine Offscreen Bitmap in der Geräteauflösung vorhanden ist. Soll eine DIN-A4-Grafik mit 300 oder 360 dpi aufbereitet werden, muß etwa 1 MByte freier Speicher bereitstehen. Offscreen Bitmaps in Bildschirmauflösung eignen sich dazu, Grafiken im Hintergrund aufzubereiten, um zu gegebener Zeit den Bildschirm zu aktualisieren. Dadurch läßt sich ein flüssigerer Grafikaufbau erreichen, als er beim direkten Zeichnen auf den Bildschirm möglich wäre.

Offscreen-Operationen ließen sich bisher deshalb nicht vernünftig realisieren, weil sich alle Grafikoperationen des Standard-VDI ausschließlich auf den Bildschirm beziehen. Nur durch unsaubere Tricks ließ sich die Ausgabe in den Speicher umlenken. Mit Offscreen Bitmaps lassen sich die Möglichkeiten des VDI nun sehr viel flexibler nutzen.

GDOS inbegriffen

Ein Aspekt von NVDI ist bei den bisherigen Betrachtungen völlig unter den Tisch gefallen, nämlich das integrierte GDOS (Grafics Device Operating System). Dieser Bestandteil des VDI ist bei den ATARI-Computern nicht im ROM integriert, sondern muß nachgeladen werden.

GDOS stellt Routinen zur Verfügung, ohne die eine geräteunabhängige Ausgabe von Grafiken unmöglich wäre. Außerdem lassen sich mit GDOS zusätzliche Zeichensätze verwalten. Nachdem die ersten von ATARI entwickelten GDOS-Versionen aufgrund ihrer geringen Geschwindigkeit als lästiges Übel angesehen wurden, machte das in NVDI integrierte GDOS diesen eigentlich elementaren Teil des GEM langsam salonfähig. Wer heutzutage keine eigenen Routinen für die Ausgabe von Grafiken auf Druckern oder anderen Peripheriegeräten schreiben will, wird sinnvollerweise auf GDOS zurückgreifen. Inzwischen ist nach langer Verzögerung endlich auch das sogenannte Speedo GDOS erhältlich, das Vektor-Fonts unterstützt. Solche Fonts lassen sich unter allen Programmen nutzen, die GDOS unterstützen. Das ist ohne Zweifel ein großer Vorteil gegenüber dem bisherigen Zustand, wo jedes Programm mit eigenen Fonts aufwartete. Es bleibt abzuwarten, ob die Verwendung von Vektor-Fonts auch einmal mit NVDI möglich sein wird.

Will man ein anderes GDOS als das in NVDI integrierte verwenden, schaltet sich das NVDI-GDOS automatisch ab. Die erhöhte Geschwindigkeit der VDI-Ausgaben auf den Bildschirm bleibt dabei weiterhin erhalten.

NVDI und virtueller Speicher

Was mögen die beiden Begriffe miteinander zu tun haben? Um diese Frage zu beantworten, rufen wir uns kurz in Erinnerung, was es mit einer virtuellen Verwaltung des Hauptspeichers auf sich hat. Für den TT und Falcon030 sind zwei virtuelle Speicherverwaltungen erhältlich, nämlich OUTSIDE und VRAM. Beide Programme ermöglichen es, die Festplatte quasi als Speichererweiterung zu nutzen. Dies ist dann zwar nicht so schnell wie eine „richtige“ Speichererweiterung, aber deutlich billiger, und man kann problemlos bis zu 512 MByte virtuellen Speicher realisieren. Virtueller Speicher ist nur mit dem 68030-, nicht aber mit dem 68000-Prozessor des ST möglich.

Der Blitter des Falcon030 kann als eigenständiger Prozessor angesehen werden, der den Hauptspeicher direkt anspricht. Solche Zugriffe, die unabhängig vom 68030-Prozessor ablaufen, untergraben allerdings das Prinzip der virtuellen Verwaltung. Der Blitter greift unter Umständen auf falsche Daten zu oder auf Bereiche, an denen sich überhaupt keine Daten befinden, da sie gerade auf die Festplatte ausgelagert sind. Durch Eingriffe ins VDI, wie sie die virtuelle Speicherverwaltung OUTSIDE vornimmt, läßt sich dafür sorgen, daß trotz Blitter eine virtuelle Verwaltung des Speichers möglich ist. Allerdings geht dabei ein Teil des Speichers verloren, da Puffer für Blitter-Operationen angelegt werden müssen. Außerdem nimmt die Geschwindigkeit bei Grafikoperationen durch den VDI-Eingriff leicht ab.

Dies alles ließe sich vermeiden, wenn man den Blitter abschalten könnte. Beim Falcon030 ist das allerdings nicht möglich. Laut Auskunft von ATARI enthält das Falcon-TOS aus Platzgründen keine Grafikroutinen, die ohne Blitter zurechtkämen. Ein Blick in die TOS-ROMs bestätigt das. Nun ist aber NVDI ein Programm, das genau diese Routinen zur Verfügung stellt. Und in der Tat zeigt sich, daß in Verbindung mit NVDI virtuelle Speicherverwaltung auf dem Falcon030 wie schon beim TT ohne jegliche Einschränkungen möglich ist.

Es bleibt also festzuhalten, daß NVDI auf dem Falcon eine sinnvolle Ergänzung zu einer virtuellen Speicherverwaltung darstellt. Ähnlich dürfte die Situation übrigens bei Erweiterungskarten aussehen, die schnelles RAM für den Falcon bereitstellen, ähnlich wie man es vom TT her kennt. Auch hier kann der Blitter unangenehme Überraschungen bereiten, denen mit NVDI vorgebeugt werden kann.

Messungen mit GEM_TEST

  ohne NVDI mit NVDI,
Blitter aus
mit NVDI,
Blitter an
Farben: 2, Auflösung: 640x400 Punkte      
Textausgabe 300% 2569% 3201%
Linien 326% 655% 807%
Rechtecke 822% 950% 1328%
Polygone 210% 622% 636%
Kreise/Ellipsen 255% 1042% 1042%
Rasteroperationen 1174% 819% 1304%
Attributfunktionen 129% 1308% 1305%
Auskunftsfunktionen 136% 851% 851%
VDI-Escapes 183% 636% 636%
BIOS-Ausgabe 164% 368% 368%
GEMDOS-Ausgabe 171% 232% 232%
AES-Objekt-Ausgabe 198% 615% 647%
Farben: 16, Auflösung: 640x480 Punkte      
Textausgabe 238% 1680% 1611%
Linien 179% 364% 353%
Rechtecke 296% 364% 408%
Polygone 160% 347% 343%
Kreise/Ellipsen 218% 658% 655%
Attributfunktionen 121% 1102% 1107%
Auskunftsfunktionen 126% 718% 721%
VDI-Escapes 76% 83% 83%
BIOS-Ausgabe 79% 97% 97%
GEMDOS-Ausgabe 97% 106% 106%
AES-Objekt-Ausgabe 160% 463% 442%
Farben: 256, Auflösung: 640x480 Punkte      
Textausgabe 175% 1113%
Linien 98% 183%
Rechtecke 148% 159%
Polygone 112% 205%
Kreise/Ellipsen 172% 417%
Attributfunktionen 102% 915%
Auskunftsfunktionen 107% 587%
VDI-Escapes 38% 37%
BIOS-Ausgabe 43% 45%
GEMDOS-Ausgabe 59% 58%
AES-Objekt-Ausgabe 119% 297%
Farben: 65536, Auflösung: 320x480 Punkte      
Textausgabe 172% 744%
Linien 253% 714%
Rechtecke 42% 132%
Polygone 102% 216%
Kreise/Ellipsen 162% 618%
Attributfunktionen 103% 859%
Auskunftsfunktionen 108% 592%
VDI-Escapes 43% 62%
BIOS-Ausgabe 45% 72%
GEMDOS-Ausgabe 58% 69%
AES-Objekt-Ausgabe 112% 320%
Farben: 65536, Auflösung: 640x400 Punkte
Textausgabe 170% 818%
Linien 249% 611%
Rechtecke 37% 133%
Polygone 72% 181%
Kreise/Ellipsen 182% 459%
Attributfunktionen 112% 986%
Auskunftsfunktionen 118% 682%
VDI-Escapes 48% 77%
BIOS-Ausgabe 51% 90%
GEMDOS-Ausgabe 65% 83%
AES-Objekt-Ausgabe 117% 358%

Tabelle 3: Benchmarks mit GEM_TEST

Alles so schön schnell hier

Die durchgeführten Tests zeigen, daß sich die Anschaffung von NVDI für den Falcon auf jeden Fall lohnt, egal in welcher Auflösung man bevorzugt arbeitet. Für diejenigen, die eine virtuelle Speicherverwaltung auf dem Falcon einsetzen, kommen noch weitere Vorteile hinzu. Natürlich gehört zu NVDI auch ein Handbuch, in dem auf gut 100 Seiten alle unterstützten VDI-Funktionen mit ihren Aufrufparametern erklärt werden. Dabei finden sich auch Hinweise auf Fehler im Original-VDI. NVDI in der neuen Version 2.5 gibt es für 129,-. Für die Grafikkarten Crazy Dots, Spectrum und Resolution existiert weiterhin eine spezielle Version (NVDI ET4000), die für 149,- direkt bei den Autoren zu beziehen ist. Die Update-Konditionen waren bei Redaktionsschluß noch nicht bekannt. Somit gilt nun auch auf dem Falcon nicht mehr nur die Devise: „Alles so schön bunt hier.“ Nein, mit NVDI ist es auch noch schnell.

Bezugsadressen:
BELA Computer GmbH Schwalbacherstr. 20 W-6236 Eschborn

NVDI ET4000:
Behne & Behne Systemsoftware GbR Lindenkamp 2 W-3050 Wunstorf

Positiv:

Negativ:

Messungen mit QUICKINDEX 2.1

Farben: 2, Auflösung: 640x400 Punkte    
  ohne NVDI mit NVDI
TOS-Textausgabe 161 % 552 %
TOS-String-Ausgabe 167% 268 %
TOS-Scrolling 214% 241 %
GEM-Dialog 197% 613%
Farben: 16,Auflösung: 640x480 Punkte    
  ohne NVDI mit NVDI
TOS-Textausgabe 89% 170%
TOS-String-Ausgabe 108% 157%
TOS-Scrolling 40% 45%
GEM-Dialog 159% 422 %
Farben: 256, Auflösung: 640x480 Punkte    
  ohne NVDI mit NVDI
TOS-Textausgabe 49% 90%
TOS-String-Ausgabe 65% 100%
TOS-Scrolling 16% 17%
GEM-Dialog 118% 265 %
Farben 65536, Auflösung: 320x480 Punkte    
  ohne NVDI mit NVDI
TOS-Textausgabe 66% 163%
TOS-String-Ausgabe 83% 139%
TOS-Scrolling 18% 18%
GEM-Dialog 100% 280 %
Farben: 65536, Auflösung: 640x400 Punkte    
  ohne NVDI mit NVDI
TOS-Textausgabe 70% 197%
TOS-String-Ausgabe 87% 160%
TOS-Scrolling 12% 13%
GEM-Dialog 104% 318%

Tabelle 2: Benchmarks mit QUICKINDEX


Uwe Seimet
Aus: ST-Computer 06 / 1993, Seite 51

Links

Copyright-Bestimmungen: siehe Über diese Seite