Diskussion:VESA BIOS Extension

Abwärtskompatibilität VBE 3.0

Hallo,

also ich bin mir da fast 100% sicher, das VBE 3.0 zu 2.0 abwärtskompatibel ist ... --80.128.113.241 18:03, 22. Jun. 2007 (CEST)

Bestreitet das jemand?
Im Text heißt es nur, dass mit VBE 2.0 bereits alle Wünsche erfüllt werden. Die wesentliche Neuerung von VBE 3.0 ist ja der Protected Mode Entry Point, der aber in modernen Systemen aus designtechnischen Gründen (es müsste Wechsel in 20 Bit Protected Mode stattfinden) nicht genutzt wird.

Ja, das habe ich dann wohl falsch verstanden. Habe das mal etwas unmissverständlicher formuliert.

-----------

Designtechnische Gründe: Ab dem 80386 kann ebenfalls auch im 16 Bit Protected Mode Segmentgrößen von bis zu 4 GiB verwendet werden, womit auch der LFB(im 4.GiB) adressiert und verwendet werden kann. Der Unterschied zum 32 Bit Protected Mode besteht lediglich nur darin, dass man für Befehle mit 32 Bit-Operanden/Adressen keine Operandsize/Adresssize-Prefixe verwenden darf, aber für Befehle mit 16 Bit-Operanden/Adressen diese Prefixe braucht und sich damit die Anzahl der Bytes im Codesegment ggf. veringert, wenn man überwiegend nur 32 Bit-Operanden/Adressen verwendet. Im 16 Bit Adressmode muss man für Befehle mit 32 Bit-Operanden/Adressen die Operandsize/Adresssize-Prefixe verwenden, aber nicht für 16 Bit-Operanden/Adressen.

Das die VBE-Modi mit 16 Bit Farbtiefe erst mit VBE 2.0 hinzukamen ist falsch. In der alten VBE 1.x-Mode-Liste gab es bereits auch schon vorher verschiedene VBE-Modi mit 16 Bit (5:5:5 und 5:6:5) und auch 24 Bit(8:8:8) Farbtiefe.
10Dh - 320x200 32K (1:5:5:5)
10Eh - 320x200 64K (5:6:5)
10Fh - 320x200 16.8M (8:8:8)
110h - 640x480 32K (1:5:5:5)
111h - 640x480 64K (5:6:5)
112h - 640x480 16.8M (8:8:8)
113h - 800x600 32K (1:5:5:5)
114h - 800x600 64K (5:6:5)
115h - 800x600 16.8M (8:8:8)
116h - 1024x768 32K (1:5:5:5)
117h - 1024x768 64K (5:6:5)
118h - 1024x768 16.8M (8:8:8)
119h - 1280x1024 32K (1:5:5:5)
11Ah - 1280x1024 64K (5:6:5)
11Bh - 1280x1024 16.8M (8:8:8)

Die im Beitrag verwendete "Liste der Modi" für VBE bis 1.x ist ab VBE 2.0 eigentlich gar nicht mehr gültig, bzw. die Hersteller können davon abweichende, eigene Modenummern verwenden, womit ggf. die selben Auflösungen zur Verfügung gestellt werden können, nur halt mit jeweils einer anderen Mode-Nummer. Ab VBE 2.0 kann man sich also nicht mehr darauf verlassen, dass diese alte Liste der VBE 1.x-Modenummern noch die gewünschte Auflösung zur Anzeige bringen. So ist es ab VBE 2.0 erforderlich die Modeliste, die vom Bios selber mitgebracht wird, zu verwenden und diese Liste Modenummer für Modenummer zu überprüfen, welche modespezifischen Eigenschaften damit jeweils vorhanden sind.

Immer noch unerfüllte Wünsche: Die Unterstützung von "secondary" display devices bei modernen GraKas mit 2 Monitor-Anschlüssen, womit man auch den Inhalt vom 2.LFB auf dem 2.Monitor ggf. auch in einer anderen Auflösung angezeigt bekommt. So fehlt auch noch DDC-Read EDID für den zweiten Monitor.

-----------

Die wesentlichen Neuerungen von VBE 3.0 (gemäß des kostenlos erhältlichen public documents "vbe3.pdf" von vesa.org) sind:

- VBE-Modi mit eigenen CRTC-Parameter, womit eine höhere Refreshrate (als nur die üblichen 60hz) eingestellt werden kann; (Zweckmässig ist eine vorherige Überprüfung der maximalen Kapazität des verwendeten Monitors über DDC/Read EDID-Funktion(int10h/AX=4F15h)); Zur Berechnung der "CRTC-Parameter" kann man das "VBEHz"-Tool verwenden;

- hardware triple buffering(mit Vsync), wofür 3 verschiedene Adressbereiche als Buffer im Wechsel zur Anzeige gebracht werden;

- die Unterstützung von stereoskopischen Shutterglasses, wofür je ein Speicherbereich zur Anzeige für das rechte und für das linke Auge verwendet wird;

- Protected Mode Entry Point, wofür in den Protected Mode geschaltet werden muss Diese Schnittstelle enthält nur sehr wenige Funktionen (damit ist z.B. kein VBE-Modewechsel möglich); Im 16 bit Adressmode kann schon (ab 80386+ mit 32 Bit Adressregister) der gesamte 4GB-Adressraum (so auch der LFB im 4.GB) vollumfänglich adressiert werden; ... Entgegen den früheren Vermutungen eines bekannten deutschen Computer-Magazins unterstützen auch heute immer noch moderne Grafikkarten wie z.B. mit Radeon 7950-Chipsatz ein VBE3-Bios. Vergleichbare Grafik-Karten unterstützen verschiedene Auflöungen von bis zu 2048x1536 Pixel mit 8, 16, 24 und 32 Bits per Pixel Farben und mit einem Seitenverhältniss der horizontalen und vertikalen Auflösung von 4:3 und 5:4, sowie auch widescreen mit 16:9 und 16:10 (aspect ratio).

Dirk

----------- (nicht signierter Beitrag von 80.171.176.233 (Diskussion) 12:56, 26. Nov. 2013 (CET))

VBE unter Linux / Windows

Der Standard spielt heute jedoch noch unter Linux eine Rolle: Sind Open-Source-Grafikkartentreiber für bestimmte Grafikkarten nicht verfügbar, so können nur durch Verwendung eines Treibers, der die hier beschriebene Funktionalität nutzt, Auflösungen von mehr als 640×480 Pixel bei mehr als 256 Farben verwendet werden. - zwei Anmerkungen / Einwände dazu: 1. Da man unter Linux sowohl Open-Source als auch Closed-Source-Treiber nutzen kann, würde ich dort einfach "Open Source" rausnehmen. 2. Wenn unter Windows kein spezifischer Grafikkartentreiber installiert ist, stehen Funktionalitäten zur Verfügung, die mir doch sehr nach VBE aussehen, d.h. ich vermute doch sehr stark, dass Windows dort genauso vorgeht wie Linux. Kann das jemand nachtragen, der es sicher weiß? --Prauch 02:26, 9. Dez. 2009 (CET)

Was für weitere unterstützte Funktionen waren das?

Im Artikel steht: Sie sind eine üblicherweise im Grafikkarten-BIOS implementierte Programmierschnittstelle (API) die den Programmen Interrupts zur Verfügung stellt, um damit Aktionen wie das Setzen oder Abfragen von Videomodi durchzuführen sowie weitere von der Hardware unterstützte Funktionen anzusprechen.. Frage: Was für weitere Funktionen waren das genau? Gehörten dazu auch schon Beschleunigungsfunktionen wie das Zeichnen von Rechtecken oder Linien oder das Verschieben von Grafikausschnitten im Video-RAM dazu? Der ganze Artikel ist diesbezüglich leider etwas dünn. --95.117.95.40 00:39, 27. Mär. 2013 (CET)

--------

Diese unter "Blitting" bezeichneten "Accelerator Functions"(VBE/AF) z.B. für 2D Polygon Rendering sind nur über einen entsprechenden Treiber verfügbar. Siehe dazu auch "VBE-AF07.pdf" von vesa.org und "the free VBE/AF driver project": http://www.talula.demon.co.uk/freebe/

Die im Bios enthaltenen weiteren Funktionen sind:
SAVE/RESTORE STATE
DISPLAY WINDOW CONTROL (man nimmt lieber den FAR-Jump zur Bankumschalt-Funktion, oder bestenfalls die Portadresse wenn bekannt)
SET/GET LOGICAL SCAN LINE LENGTH (ein Teil der jeweiligen scan line kann sich ausserhalb des sichtbaren Bereiches befinden)
SET/GET DISPLAY START (für scrolling und buffering)
SET/GET DAC PALETTE FORMAT (für 4 und 8 Bit-Farb-Modi)
SET/GET PALETTE DATA (für 4 und 8 Bit-Farb-Modi)
GET/SET PIXEL CLOCK (für Modi mit eigenen CRTC-Parameter)
Dirk

Defekter Weblink

Dieser Baustein verhindert die automatische Archivierung dieses Abschnitts und seiner Unterabschnitte.

Der folgende Weblink wurde von einem Bot („GiftBot“) als nicht erreichbar erkannt.
Ausführliche Erläuterungen und Hilfe zur korrekten Behebung dieses Fehlers finden sich auf Wikipedia:Defekte Weblinks. Ist ein von einem Bot als defekt gemeldeter externer Link doch erreichbar, dann bitte berichten – wie auch sonstige Probleme.

• http://wiki.osdev.org/Getting_VBE_Mode_Info
  • Vielleicht ist eine archivierte Version geeignet: archive.org
  • Problem mit Ressource (HTTP-Statuscode 403)http://giftbot.dwl.invalid/http://wiki.osdev.org/Getting_VBE_Mode_Info

– GiftBot (Diskussion) 08:01, 3. Dez. 2015 (CET)

„… wird von den meisten modernen nVidia-Grafikkarten unterstützt“

Wie aktuell sind die Informationen im Artikel? Meine Nvidia (sic!) GeForce GT 1030 hat jedenfalls kein VESA-BIOS. Und die ist immerhin schon rund vier Jahre alt. Ich gehe davon aus, dass VBE heutzutage relativ bedeutungslos ist, und dass die Hersteller kaum noch Entwicklungsaufwand darin investieren. --Winof (Diskussion) 13:09, 13. Jan. 2021 (CET)

Ja, das sollte man wohl überarbeiten. VBE ist eine "BIOS Extension", das ist allein schon deshalb veraltet, weil heute UEFI eingesetzt wird. Betriebssysteme, die ein BIOS erfordern, sind alte Betriebssysteme. Grafiktreiber und Programme, die VBE benützen, waren eigentlich durchwegs Fallback-Grafiktreiber (etwa unter Linux, wenn nichts besseres – "accelerated" – verfügbar war) und grafische DOS-Programme/-Spiele.

‣Andreas•⚖ 13:18, 13. Jan. 2021 (CET)

Habe den Artikel angepasst und UEFI GOP als Nachfolger der VBE erwähnt. Nvidia in dem Satz zu erwähnen (aber ATI/AMD nicht) war eigentlich dort unsinnig, das habe ich gelöscht... ‣Andreas•⚖ 14:11, 13. Jan. 2021 (CET)

Ich danke Dir; das sieht jetzt schon viel besser aus!

Wird GOP eigentlich vom UEFI des Mainboards implementiert, oder kommt das von der Firmware der Grafikkarte? Ersteres ist schwer vorstellbar, da das Mainboard-UEFI ja kaum Treiber für alle möglichen GPUs enthalten kann – maximal für die Onboard-GPU, falls es eine gibt (mein aktuelles Mainboard hat z.B. keine). Also müsste GOP eher aus der Firmware der Grafikkarte kommen, was wiederum die Frage aufwirft, welche Grafikkarten das unterstützen. In den üblichen Datenblättern, die man so auf Hersteller-Web-Seiten findet, wird so etwas nicht erwähnt. --Winof (Diskussion) 15:33, 13. Jan. 2021 (CET)

Soweit ich weiß haben Grafikkarten immer noch ein Grafik-BIOS (oder eben eine Grafik-Firmware). Bei modernen Grafikkarten ist neben den BIOS-Funktionen wohl auch soetwas ähnliches für UEFI dabei. Oder aber es gibt einen UEFI-Standard, den die Grafikkarten ihrerseits implementieren. So oder so, GOP funktioniert als Framebuffer sehr gut, in allerlei Grafikmodi.

Ich konnte auch keine genauen Informationen dazu finden...

‣Andreas•⚖ 16:09, 13. Jan. 2021 (CET)

VBE hat nichts mit dem BIOS zu tun. Es ist Teil der Grafikkartenfirmware. Man kann VBE also auf einem uralten PC verwenden, dessen BIOS noch nie etwas von VBE gehört hat. Die Grafikkarte muss nur in den alten Rechner passen und wenn man die 32 Bit Modi nutzen will, dann muss das natürlich auch ein entsprechender Prozessor sein. Der 386 kam allerdings 1985 auf den Markt. --93.229.170.126 17:08, 24. Mai 2023 (CEST)

Selbstverständlich hat VBE mit dem BIOS zu tun (die Abkürzung steht ja schließlich auch für VESA BIOS Extension). Die VBE ist nichts weiter als eine Erweiterung der in jedem PC-BIOS vorhandenen Video-Funktionen, die dort über den Software-Interrupt 10h aufgerufen werden. Die VBE hängt sich in diesen Software-Interrupt hinein und erweitert ihn um zusätzliche Funktionen, und damit wird die VBE praktisch selbst zu einem Teil des BIOS. Dabei spielt es keine Rolle, wo sich die Implementation der VBE befindet – ob in einem Chip auf einer Grafikkarte, oder auf dem Mainboard selbst, oder in Form eines Treibers, der vom Betriebssystem nachgeladen wurde (z. B. ein TSR unter DOS). Bei Notebooks war es eine Zeit lang üblich, dass die VBE-Funktionen im regulären BIOS mit drinsteckten; auch bei „normalen“ PCs mit Onboard-Grafik habe ich das schon gesehen. Aber wie bereits mehrfach erwähnt wurde: Heutzutage hat die VBE an Bedeutung verloren. (nicht signierter Beitrag von Winof (Diskussion | Beiträge) 19:37, 24. Mai 2023 (CEST))

Das ist so nicht korrekt. Mit BIOS ist hier das Video BIOS der Grafikkarte gemeint, also dessen Firmware. Lies dazu einfach mal die Einleitung des englischen WP Artikels und der Artikel https://en.wikipedia.org/wiki/Video_BIOS. Der Grund, warum man das bei Notebooks und Onboard Grafikkarten aufs gleiche ROM wie das gewöhnliche PC BIOS packt, liegt schlichtweg an der höheren Integration und dem Sparen von Bauteilen, man ja weiß, was da verbaut ist. Der erste IBM hatte nämlich nicht einmal VGA, sondern Anfangs nur einen reinen Textmodus und kurz darauf noch CGA. Die VBE ist also eine Erweiterung zum Video BIOS und nicht zum normalen PC BIOS. Und ja, es gibt dafür auch TSR Programme für Grafikkarten, die über kein aktuelles Video BIOS verfügen. --93.229.170.126 21:56, 26. Mai 2023 (CEST)

Ergänzung: Der deutsche WP Artikel hier ist also falsch. Da er das Video BIOS mit dem System BIOS vermischt. --93.229.170.126 22:02, 26. Mai 2023 (CEST)

Das Video BIOS und das System-BIOS gehen aber Hand in Hand. Eine Grafikkarte, die keine BIOS-kompatible Firmware besitzt, wird auf einem PC mit BIOS nicht funktionieren. Umgekehrt kann eine Grafikkarte für den PC, die ein Video BIOS als Firmware besitzt, nicht auf z.B. einem PowerMac mit Open Firmware genutzt werden, denn dieser benötigt eine Grafikkarte mit FCode-Firmware, nicht mit VBIOS. Funktionieren wird eine solche Grafikkarte trotzdem, aber nur wenn das Betriebssystem die Grafikkarte initialisiert: eine PC-Grafikkarte ist auf einem PowerMac also erstmal nicht unterstützt, der Monitor bleibt schwarz, ein Erreichen der Open-Firmware-Konsole (entspricht etwa dem BIOS-Setup) ist damit nicht möglich. Wenn man aber z.B. Linux auf einem PowerMac startet, das dann einen Grafiktreiber verwendet, der die Grafikkarte inklusive dessen VBIOS unterstützt (teils sogar Funktionen des VBIOS voraussetzt), dann hat man auch auf einem PowerMac ein Bild und die Grafikkarte funktioniert -- mit VBIOS! -- einwandfrei. Mac OS bzw. Mac OS X hat naturgemäß keine solchen Grafiktreiber und benötigt immer eine "Mac-Version" der Grafikkarte: als eine Firmware für die im Mac seinerzeit verwendete Open Firmware, und kein VBIOS. (Nur ganz wenige Grafikkarte hatten damals eine hybride Firmware, die sowohl ein BIOS-kompatibles VBIOS als auch eine Firmware in FCode, die Mac-kompatibel war, beinhalteten.)

Bei der Umstellung vom BIOS ("Legacy BIOS") zu UEFI (Extended Firmware Interface) war unter Windows 7 auch das Problem, dass die Grafiktreiber für Windows damals das VBIOS voraussetzten. Windows 7 x64 hat also zwar UEFI nativ unterstützt, aber es musste immer auch das CSM (Compatibililty Support Modul, also die BIOS-Emulation des UEFI) geladen werden, selbst im nativen UEFI-Modus. Damit wurde dann das VBIOS initialisiert, und sowohl das EFI-Setup ("BIOS-Setup") als auch Windows hat dann anstandslos mit jeglicher Grafikkarte funktioniert. Dass das ganze aber ein Ende haben musste, wusste man damals sowohl bei Intel als auch in der gesamten Industrie, weshalb ein neuer Grafikstandard GOP ("Graphics Output Protocol") entwickelt wurde. Grafikkarten haben "Hooks" in der Firmware, sodass das EFI die Grafikfunktionen der eingebauten Grafikkarte nutzen kann. Auch die Windows-Treiber von Nvidia und AMD sind inzwischen so umgeschrieben, dass sie ohne ein VBIOS auskommen. Damit ist CSM nicht mehr nötig, und UEFI ganz ohne VBIOS und auch ohne VBE heute der neue Normalfall.

Das Problem entsteht, weil man die Begriffe "BIOS" immer noch für die System-Firmware und "Video BIOS" für die Firmware der Grafikkarte nutzt, auch wenn heute technisch gesehen kein BIOS mehr in der Firmware zu finden ist (sondern eine UEFI-Implementierung) und auch kein Video-BIOS/VBIOS (sondern eine UEFI-kompatible Firmware, "Video Firmware" oder "Grafik(karten)-Firmware").

Versucht man eine ganz moderne Grafikkarte, die kein BIOS-kompatibles VBIOS mehr besitzt, in einem alten PC mit BIOS zu verwenden, wird diese genausowenig funktionieren wie eine Mac-Variante mit FCode...

‣Andreas•⚖ 16:38, 27. Mai 2023 (CEST)

Völlig richtig. Im Grunde genommen ist das, was man als „Video-BIOS“ bezeichnet, ja auch nichts weiter als eine Erweiterung des PC-BIOS (den Begriff Firmware sollte man vielleicht eher vermeiden, denn das fällt alles im weiteren Sinn unter Firmware). Seine Aufgabe ist es, die Hardware zu initialisieren und Funktionen für Betriebssysteme bereitzustellen (z. B. über den erwähnten INT 10h), die selbst keine eigenen Hardware-Treiber haben. Die Übergänge sind fließend. Wenn der Artikel in der englischsprachigen Wikipedia das anders darstellt, dann ist er korrekturbedürftig, nicht unserer.

Übrigens: Der IBM-PC wurde damals von Anfang an wahlweise mit MDA oder CGA ausgeliefert. Andere Grafikkarten waren zu diesem Zeitpunkt nicht vorgesehen, daher befanden sich die entsprechenden Funktionen im PC-BIOS (die Grafikkarten hatten zwar ROMs, aber darin befand sich kein BIOS). Mit anderen Worten: Damals war das, was man später als „Video-BIOS“ bezeichnete, also bereits im PC-BIOS integriert. Spätere Grafikkarten brachten dann ihr eigenes Video-BIOS mit, das sich in das PC-BIOS einklinkte. Übrigens beschränkt sich dieses Prinzip nicht auf Grafikkarten: Viele andere Erweiterungskarten brachten ebenfalls ihre eigenen Funktionen mit, die sich in die entsprechenden Software-Interrupts einklinkten und somit praktisch das PC-BIOS erweiterten. Ein typisches Beispiel waren die SCSI-Karten von Adaptec. --Winof (Diskussion) 17:17, 27. Mai 2023 (CEST)

Das hier "Das Video BIOS und das System-BIOS gehen aber Hand in Hand." muss ja logischerweise so sein, damit Systeme wie DOS damit klar kommen, aber das macht deine obige Aussage "VBE ist eine "BIOS Extension" (womit du das normale BIOS meinst) nicht richtiger, denn die VBE ist keine Erweiterung des normalen BIOS, sondern des Video BIOS. Also der Firmware der Grafikkarte. --93.229.170.126 21:17, 27. Mai 2023 (CEST)

Also, BIOS --> Video BIOS (als Erweiterung des BIOS) --> VBE als Extension/Standard im Video BIOS. Nun alles klar? ‣Andreas•⚖ 18:45, 28. Mai 2023 (CEST)

Bei deiner Logik wäre auch ein Betriebssystem eine Erweiterung des BIOS. --93.229.170.126 20:59, 29. Mai 2023 (CEST)

Wieso? Wenn ein Betriebssystem die BIOS-Funktionen aufruft, dann ist es doch egal, ob diese vom BIOS-ROM-Chip auf dem Mainboard, der Grafikkarte oder der SCSI-Controllerkarte stammen... ‣Andreas•⚖ 10:40, 30. Mai 2023 (CEST)

Ich habe das Gefühl, wir drehen uns im Kreis. Ja, VBE ist eine BIOS-Extension (es heißt ja auch so). Es gibt keinen Grund, hier zwischen Video-BIOS und „anderem BIOS“ zu unterscheiden, denn es bildet ohnehin eine funktionelle Einheit. „BIOS“ ist hier als Oberbegriff zu verstehen. Wie gesagt: Ob und welche Teile davon sich in einem separaten Chip auf einer Grafikkarte oder anderswo befinden, ist irrelevant. Die VBE klinkt sich in den Software-Interrupt 10h ein, und wo die übrigen Teile davon implementiert sind (was sowohl im Video-BIOS als auch anderswo sein kann), ist der VBE egal. Somit ist die VBE schlicht und ergreifend eine BIOS-Erweiterung, nicht mehr und nicht weniger. Übrigens, Zitat aus der offiziellen VBE-Spezifikation der VESA Association (Einleitung, Kapitel 1.0): „[…] supplement the System and INT 10h ROM BIOS functions to provide the VBE services.“ (Wobei dieses Dokument knapp 30 Jahre alt ist; damals waren typische PCs anders aufgebaut als heute.)

Da nicht abzusehen ist, dass diese Diskussion zu einer Verbesserung des Artikels führt, schlage ich vor, es im Sinne von WP:DISK dabei zu belassen. --Winof (Diskussion) 15:28, 31. Mai 2023 (CEST)

Moderne Geforce Karten haben nicht einmal eine vernünftige 2d Einheit. Die wurde ab der Geforce 8 nämlich rausgeschmissen um Platz für die 3d Einheit und deren Shader zu schaffen. Auch war bei den ersten Geforce Karten der DOS Support schon sehr bescheiden, die letzten brauchbaren Karten von NVidia dürfte hier die Karten mit Riva 128 Chipsatz gewesen sein. Die Voodoo 3, 4 und 5 Karten von 3DFX haben dagegen einen exzellenten DOS Support und unterstützen nahezu alle 2d Modi, die man unter DOS je benutzt hat. Die Nutzung der 3d Einheit mittels Glide war unter DOS natürlich ebenfalls möglich. --93.229.175.119 02:13, 16. Mai 2024 (CEST)

DOS Extender Spiele und VESA SVGA Modi

Was im ganzen Artikel fehlt und nicht deutlich herausgearbeitet wurde, ist der Punkt, dass VESA VBE 1.2 zwar höhere Auflösungen mit mehr Farben erlaubte, aber da für den Zugriff nach wie vor der 16 Bit Real Mode benutzt werden musste und man nur ein kleines 64 KiB Fenster zur Verfügung hatte und DOS Extender Spiele aufgrund ihrer RAM Anforderungen im 32 Bit Protected Mode laufen wollten und ein Wechsel in den Real Mode über DPMI zu häufigen Protected Mode zu Real Mode Wechseln geführt hätte, war das für eine flüssige Darstellung zu langsam.

Deswegen nutzten Spiele wie DOOM zwar DOS Extender um als 32 Bit Protected Mode Anwendung zu laufen und so mehr RAM zur Verfügung zu haben, aber sie nutzten keine VESA SVGA Modi. VESA VBE 1.2 wurde daher nur von Spielen genutzt, bei denen keine performante Bilddarstellung in den SVGA Auflösungen erforderlich war. D.h. hauptsächlich in Spielen mit Still-Images und Szenen, bei denen nur wenige Bildinformationen geändert werden mussten. Für 3d Grafik oder Spiele mit 2d Scrolling, wie bspw. Jump & Runs oder Echtzeitstrategiespiele war das absolut unbrauchbar.

Für solche Spiele war VESA VBE 2.0 nötig, welches einen linearen Speicherzugriff aus dem Protected Mode heraus erlaubte. Viele dieser Performance fordernden SVGA Spiele laufen daher nur ab VESA VBE 2.0. bzw. mit einem entsprechenden VESA VBE 2.0 Treiber, der das unterstützt und so einen linearen Speicherzugriff vom Protected Mode aus erlaubte. VESA VBE 2.0 ersparte den DOS Extender nutzenden 32 Bit Spielen das zurückschalten in den Real Mode. Eine weitere Anforderung für solche Spiele war eine schnelle BUS Anbindung der Grafikkarte. Der ISA Bus war für SVGA Auflösungen mit 256 Farben und einer flüssigen Framerate von über 20 fps in der Regel zu langsam. Es war somit auch eine Grafikkarte für den VESA Local Bus oder PCI BUS erforderlich.

Das bitte in den Artikel einbauen. --93.229.175.119 02:00, 16. Mai 2024 (CEST)

Wenn du gescheite Belege findest, darfst du das auch gerne selber einbauen in den Artikel. --RokerHRO (Diskussion) 23:28, 18. Mai 2024 (CEST)

Das ist eure Aufgabe, da ihr in der Wikipedia diesen Belegfanatismus habt, das sind nicht meine Regeln, die da aufgestellt wurden, mir würde Zusammenhänge und logische Schlussfolgerungen und echte Softwaretests genügen. Es ist auch unwahrscheinlich, dass das ein Programmierer irgendwo niederschreibt oder an Journalisten so detailliert erklärt und die das dann irgendwo niederschreiben, weil so etwas nun wirklich sehr tief ins Detail geht und somit sehr speziell ist, zu speziell für einen Spieletest oder eine Spielevorschau. Und als Programmierer würde man es durch Logik merken, aller spätestens aber beim Testen der Software. Belegbar ist, dass der Kontextswitch vom Protected Mode in den Real Mode und zurück teuer ist, also viel Zeit benötigt. Wenn man das aber mit dem segmentierten VESA 1.2 und 32 Bit Software, die mithilfe von DOS Extendern läuft unter DOS läuft, kombiniert, dann sind wir beim Thema Zusammenhänge und logischen Schlussfolgerungen, da ich nicht glaube, dass man hier einen Beleg findet, aber das reicht ja euch wieder für die Wikipedia nicht. Für euch muss das praktisch auf dem Silbertablet ganz einfach im Zusammenhang von A, B und C stehen und nicht nur als Schlussfolgerung aus A stehen. Und all das, obwohl es vollkommen klar ist.

Aber um noch einmal auf die Journalisten und deren Arbeit zurückzukommen. Bei DOOM wurde bspw. laut der Computerzeitschrift DOS-Trend Extra DOOM 1993-04 angekündigt, dass DOOM auch SVGA Modi bieten würde und die PC Player 1993-05 schrieb sogar von 32k Farben. Vielleicht wurde das, sofern das kein Wunschdenken der Journalisten selber war, die in DOOM zuviel hinein interpretierten, den Journalisten sogar auch in den Vorabpressekonferenzen von ID Software so angekündigt, aber spätestens bei ID Software wird man dann beim Versuch das so zu Implementieren gemerkt haben, dass es mit VESA VBE 1.2 auf der damals gegebenen Hardware nicht schnell genug ist. DOOM nutzt daher nur VGA 320x200 bei 256 Farben.

Frühe Egoshooter, die 32 Bit DOS-Extender nutzten, also im 32 Bit Protected Mode liefen, nutzten die VESA Modi daher erst ab VESA VBE 2.0, das im November 1994 rauskam, denn erst das war für solche Spiele auch auf älteren Rechnern schnell genug, aus den oben bereits von mir genannten Gründen. Egoshooter, die 32 Bit DOS Extender und VESA VBE 1.2 (als Rückfallmodus) nutzen, wenn kein VESA VBE 2.0 zur Verfügung stand, kamen erst nach dem Release von VESA VBE 2.0 heraus, zu einer Zeit, als die CPUs für VESA VBE 1.2 und 32 Bit Software schon schnell genug waren. Der langsame Kontextswitch also mit schierer Brute Force Leistung der CPU umgangen werden konnte.

Die Build Engine Spiele, wie Duke Nukem 3D (1996) sind bspw. solche Kandidaten. Diese bieten einen Rückfallmodus auf das segmentierte VESA VBE 1.2, wenn kein VESA VBE 2.0 gefunden wurde, das war aber dann schon in einer Zeit, nachdem der Pentium bereits zur Verfügung stand und die CPUs bereits eine Taktfrequenz von über 100 Mhz hatten und den Kontextwechsel praktisch mit purer Brute Force Leistung schnell genug hinbekamen. Mit einem 486er mit 33 MHz aber VLB, auf dem bereits DOOM lief, kann man das nicht vergleichen.

Dass VESA VBE 2.0 deutlich performanter als VESA VBE 1.2 ist, sieht man übrigens auch an den Einträgen im Quellcode der Build Engine. Darin schrieb Ken Silverman in der BUILD2.TXT Datei folgendes:

10/17/95

...

- Added auto screen-buffering mode for linear VESA modes. (In

case you didn't know, reading video memory can be 10 times

slower than reading non-video memory.) Auto-buffering

means that if the engine detects that more than 1/8th of the

screen has transluscence or mirrors, then it will switch into

a screen-buffering mode. Screen-buffer mode in linear VESA

not only will still have smooth page flipping, but will be

faster than standard screen buffer mode on some video cards

just because it's linear memory. (That's a good thing)

Damit wird belegt, das VESA VBE 2.0 (siehe lineare VESA) aufgrund des linearen Speicherzugriffs auf das Video RAM schneller ist als in allen anderen segmentierten Grafik Modi (also Standard VGA und VESA VBE 1.2).

Und folgender Eintrag zeigt,

10/26/95 - Added support for VESA 2.0 protected mode extensions. With the

protected mode extensions, the page-flipping is less likely to

flicker, if at all. This is because the retrace timing isn't

screwed up as badly as if it had to switch to real mode.

dass mit VESA 2.0 nicht mehr in den Real Mode geschaltet werden muss.

Erstmals erwähnt wird VESA VBE 2.0 in dieser Datei übrigens am 14. September 1995, wobei sich das nur auf weitere VESA VBE 2.0 Modi bezieht. Darin wird aber auch angegeben, dass man VESA VBE 2.0 für Duke Nukem 3d benötigen würde. Mit chained Buffer Mode dürfte Standard VGA, genauer der Mode Y und Mode X gemeint sein und der Support dafür flog raus weil VESA VBE 2.0 besser geeignet war. Mode Y, also der 320x200x8 Bit chained Mode wird übrigens von DOOM verwendet.

9/14/95 - Added a new bunch of graphics modes using the new VESA 2.0 linear

buffer. (I replaced the useless chain-buffer mode with VESA

2.0 modes) See my new SETUP. Since most cards only support

VESA 1.2 right now, you will probably need a VESA 2.0 driver.

I have been using the UniVBE(tm) 5.1 from SciTech Software

(ftp: ftp.scitechsoft.com, www: http://www.scitechsoft.com)

Note that since I inserted the new modes between chained mode

and screen buffer mode, you will need to update your setup

program and fix your initengine calls.

Der Rückfallmodus zu VESA 1.2 wird zudem erst wieder mit Windows NT/2K/XP interessant. Am 21.September 2001 bringt er als Patch ein kleines TSR Programm Namens NOLFB für die NTVDM von Windows NT/2000/XP heraus, damit auf diesen Systemen Duke Nukem 3d wieder in höheren Auflösungen laufen kann. Der VM86 Mode von Windows NT, also NTVDM unterstützt nämlich nur segmentierte Zugriffe auf Hardware, die dann natürlich von Windows Funktionen umgesetzt werden, denn direkten Hardwarezugriff gibt es für Userspace Programme oder Programme die in der VM86 laufen, unter Windows NT sowieso nicht. Womit lineares VESA VBE 2.0 ausscheidet.

Duke Nukem 3d erschien übrigens am 29. Januar 1996. Die Changelogeinträge stammen also aus einer Zeit vor dem Release von Duke Nukem 3d.

Grundsätzlich sieht man das auch an der Art der SVGA bzw. VESA Spiele. 3d Spiele, die 32 Bit DOS Extender nutzten und SVGA VESA Modi nutzten, die bildschirmfüllend flüssig laufen müssen, kamen nämlich überwiegend erst ab VESA 2.0 auf den Markt. Die SVGA bzw. VESA 1.2 Spiele davor waren so Spiele wie bspw. Links 386 Pro. Dieses Spiel bestand überwiegend nur aus Stillimages, mit nur wenigen Animationen in kleinen Bereichen. Das musste also keine bildschirmfüllenden 20 fps liefern. Eine Ausnahme wäre vielleicht Wing Commander 3. Das kam auch mit VESA 1.2 Support, erforderte dafür aber auch einen Pentium mit mindestens 75 MHz und PCI (oder eventuell 486DX4@100 MHz mit VLB), wenn man dieses in den SVGA anstatt VGA Modi halbwegs flüssig spielen wollte. Mit genügend CPU Brute Force Leistung, siehe oben, geht es ab irgendeinem Punkt dann halt doch.

Andere SVGA Spiele mit 32 Bit DOS Extender Nutzung, wie bspw. System Shock (1994), Need for Speed (1995), IndyCar Racing II (1995) oder Mechwarrior 2 (1995) verlangen nach VESA VBE 2.0.

Also, um nochmal zum Eingangsthema "Belege" zurückzukommen, belegt werden könnte, dass der Kontextswitch vom Protected Mode in den Real Mode viel Zeit kostet. Der Rest müsste in der Form "erschließt sich logisch" eingebaut werden, da ich davon ausgehe, dass man einen besseren Beleg wahrscheinlich nicht findet. Aber du kannst mich gerne vom Gegenteil überzeugen. --93.229.175.119 06:26, 19. Mai 2024 (CEST)

Überarbeiten: Struktur

Dem Artikel fehlt es an Struktur. Wünschenswert wäre eine Struktur wie im englischen Artikel bei dem jede neue Version ihren eigenen Abschnitt hat und dort dann die Verbesserungen und Änderungen gegenüber der Vorgängerversion aufgelistet sind. --93.229.175.119 09:17, 19. Mai 2024 (CEST)