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)

Ich hatte recht

Siehst du, ich hatte recht, hier ist ein gescheiter Beleg dafür:

While the original VESA BIOS specification provided a hardware-independent method to access all of a video card's display RAM, there was a significant performance penalty because banking is inherently slow. For starters, bank switching is expensive, since the VESA BIOS interface is accessed via software interrupt 0x10. Not only is the interrupt slow, but there is a potential context switch from protected mode to real mode and back, compounding the expense.

https://jacobfilipp.com/DrDobbs/articles/DDJ/1995/9513/9513f/9513f.htm

Dieser fett markierte Satz, der mit einem potentiell betont wird, bezieht sich auf die DOS Extender. Also wenn das Spiel vom Protected Mode aus, auf VESA VBE 1.x zugreifen will. Dann muss in den Real Mode zurückgeschaltet werden. Das zurückschalten entfällt logischerweise, wenn das Spiel selbst direkt im Real Mode läuft. Und bevor das vergessen wird, der konventionelle RAM beträgt im Real Mode nur 640 KiB, das ist wenig, wenn man große Datenmengen für eine SVGA Auflösung nutzen möchte. Letzteres ist der Grund, warum man DOS Extender nutzte, damit fiel das Speicherplatzproblem im RAM weitgehend weg, weil man auf den ganzen Speicher oberhalb des HMA zugreifen konnte.

Und weiter heißt es dann im gleichen Artikel bezüglich VESA VBE 2.0:

To address the problems of banked frame-buffer access, the VESA committee has designed and ratified the VBE 2.0 specification. This major overhaul of the VBE interface introduces two performance-enhancing capabilities. The first is protected-mode bank switching, which removes the need for expensive context switching when banking. The second capability removes the need for banking altogether by handling the frame buffer as a single chunk of contiguous memory, assuming that the underlying hardware is capable of supporting such access.

Das bedeutet, dass mit VESA VBE 2.0 eine Möglichkeit geschaffen wurde aus dem Protected Mode heraus per Banking auf die Grafikkarte zuzugreifen, als auch linear.

Wollte man also die höheren SVGA Modi nutzen und das gleichzeitig performant, also ohne Kontextswitch zurück in den Real Mode, haben, dann benötigte man dafür VESA VBE 2.0.

Damit ist alles belegt, es muss nur noch in den Artikel, der übrigens mal gehörig überarbeitet und neu strukturiert gehört. Ich habe jetzt nur mal die Quelle eingebaut als Beleg für den linearen Zugriff. --93.229.166.99 21:35, 3. Jul. 2024 (CEST)

Und hier steht es nochmal:

Function Ah (Return VBE Protected Mode Interface) provides pointers and offsets to the protected-mode versions of the three time-critical functions. This was added to VBE 2.0 to support high-performance, protected-mode access to the VBE 2.0 interface. For most of the VBE 2.0 function calls, your program can switch to real mode, but functions 05h (Display Window Control), 07h (Set/Get Display Start), and 9h (Set/Get DAC Palette data) are likely to be used while your program is in the middle of drawing the screen. For a real-time graphics program, the state transitions will seriously degrade your performance. The protected-mode versions of these functions are completely relocatable, and are intended to be copied directly into your code segment and executed locally for the best performance.

Quelle: https://jacobfilipp.com/DrDobbs/articles/DDJ/1995/9507/9507h/9507h.htm

Es ist somit genau so, wie ich sagte. --84.158.114.152 23:13, 7. Jul. 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)

Ergänzung: Auch fehlt ein Geschichteabschnitt und wie der Zustand vor dem VESA VBE Standard war. Das findet man alles hier belegt: https://jacobfilipp.com/DrDobbs/articles/DDJ/1990/9004/9004f/9004f.htm --93.229.166.99 18:18, 5. Jul. 2024 (CEST)

Geschichte: Wechsel von VGA auf SVGA

Da ich gerade die PC Player Ausgaben des Jahrgangs 1993 durchforste kann ich bestätigen, dass der Beginn, wann SVGA die klassische VGA Auflösung von 320x200 Bildpunkten bei 256 Farben in PC Spielen zunehmend ersetzte, das Jahr 1993 war. In diesem Jahr erschienen zunehmend mehr Titel, die auf eine SVGA Auflösung setzten. Als SVGA Auflösung wurde hier gewöhnlicherweise noch die niedrigste SVGA Auflösung 640x480 Bildpunkte bei 256 Farben verwendet, die Verwendung von noch höheren Auflösungen, wie bspw. 800x600 Bildpunkte bei 256 oder mehr Farben kamen erst später.

Bei der Art der Spiele waren das in der Regel Spiele, die noch keine hohen Bildwechsel und Änderungen im Bild erforderten. D.h. 3d Spiele blieben noch eine Weile bei der Standard VGA Auflösung, da die CPU Leistung für SVGA hier in der Regel noch nicht genügte. Bei 3d Spielen fällt somit der Beginn der SVGA Ära auf Ende 1994, als bspw. Wing Commander 3 erschien, welches SVGA Unterstützung bot. Ab Frühjahr 1996 war der Wechsel weitgehend abgeschlossen, so dass es ab diesem Zeitpunkt dann auch im 3d Bereich überwiegend SVGA Titel gab. Zu nennen wären hier bspw. Quake und Duke Nukem 3D).

All das könnte man im Artikel noch einbauen. --93.229.175.119 01:07, 26. Mai 2024 (CEST)

Siehe dazu z.B. wie DOSBox die Grafik-Hardware und Grafikmodi emuliert, damit man alte DOS-Spiele damit heute auf moderner Hardware noch spielen kann. SVGA ist eigentlich kein Standard, sondern das, was nach VGA kam. Einheitlichkeit ist was anderes. Der VESA-Standard war die Konsequenz daraus, dass es keinen einheitlichen Standard für SVGA gab. Aber nicht jedes Spiel hielt sich auch daran bzw. nicht jede Grafikkarte kann jeden VESA-Modus, sodass es auch hier teils zu Inkompatibilitäten kommt.

Siehe dazu u.a. diesen englischen Blog DOSBox Graphic and Machine Emulation, CGA, VGA, Tandy, PCJr, Hercules von The Developer's Tidbits.

Dabei vergisst man oft, dass es selbst unter den noch standardisierten Zeiten von MDA, CGA, EGA und VGA immer wieder Spiele gab, die "exotische" Modi nutzten, und daher auch teils auf nicht jeder Grafikkarte korrekt funktionierten: DOS Game Resolutions (englisch) aus dem Blog DOS Days.

Ich bin mir nur nicht sicher, wie man das, ohne gute Quellen, in den Artikel einbauen sollte. Und: würde das nicht den Rahmen sprengen? Zu viel Detail, dass sich obendrein dann vermutlich immer als unvollständig und angreifbar darstellen wird müssen, bringt wohl niemandem etwas. Wer sich hier genauer informieren will, ist in der Retro-Szene gut aufgehoben, etwa bei VCFED.org (Beispiel: 640x400 256 color mode on standard VGA) oder Vogons (Beispiel: SVGA and VESA Video Cards)...

‣Andreas•⚖ 14:17, 26. Mai 2024 (CEST)

Du brauchst mir nicht erklären, was SVGA ist, das weiß ich ohnehin viel besser als du. VESA VBE ist ein Standard, und SVGA war die damals dafür übliche Schreibweise, keiner sagte VESA VBE dazu, man hat nicht einmal VESA VBE, sondern, wenn dann nur VESA dazu gesagt, wenn es darum ging noch genauer als SVGA sein zu wollen. In der PC Player wird VESA VBE als SVGA geführt, es kommt in den Spielebewertungsboxen als SVGA vor und im Fließtext wird auch nur SVGA entsprechend verwendet. VESA VBE steht da nirgends, bestenfalls wird beiläufig erwähnt, dass man einen VESA Treiber wie UniVBE benötigen würde. Und so gut wie alle Spiele nutzten VESA VBE, proprietäre nicht standardisierte Modi jenseits von VGA hat damals so gut keiner benutzt, solche Spiele kannst du an der Hand aufzählen. Der Flight Simulator 3 oder 4 könnte ein solches sein und wäre das einzige, das mir spontan dazu überhaupt einfällt, das brauchte dann aber spezielle Treiber für die Karte. Mit SVGA war also umgangsprachlich immer VESA VBE gemeint, proprietäre SVGA Modi spielten überhaupt keine Rolle. Es geht also hier um VESA VBE, das ist hier SVGA gleichgesetzt. Und daher ändert sich an meinem vorherigen Kommentar absolut nichts, ich bin davon ausgegangen, dass das jedem klar ist und die kürzere Schreibweise genügt. Scheinbar gibt es aber immer wieder jemanden, dem man es ganz genau erklären muss. Es ist geschichtlich relevant, wann SVGA (und für dich VESA VBE) in Spielen verwendet wurde. Ich werde hier nun wieder SVGA schreiben, so wie früher, denn es ist klar, was damit gemeint ist.

Stell dir vor, es gab vor der Einführung der VESA Modi sogar Grafikkarten, die gar keine VESA Modi können, das waren die, die VGA mit einem RISC Prozessor emulierten. Denen konnte man auch per UniVBE kein VESA beibringen.

== Zum Thema einbauen in den Artikel: ==

Was man machen kann, wäre eine Tabelle oder ein Balkendiagramm, in dem zusammengefasst ist, wie viele DOS Spiele pro Monat oder Quartal nur VGA hatten und wie viele SVGA. Wenn man hier als Grundlage alle PC Player Hefte von ca. 1993 bis einschließlich 1997 nimmt, erhält man eine statisch brauchbare und als Beleg geeignete Auswahl, die die Verbreitung und Zunahme von SVGA verdeutlicht. Man hat also pro Monat zwei Balken, der erste fasst alle VGA Spiele zusammen, der andere die, die auch SVGA können. Kann ein Spiel beides, VGA und SVGA, dann wird es zum SVGA Balken gezählt, nicht aber zum VGA Balken. Wollte man noch 3d Spiele von überwiegend 2d Spielen, in denen sich in der Regel nicht viel im Bild ändert, abtrennen, müsste man diese Unterscheidung von Hand machen, Ob ein Spiel ein 3d oder 2d Spiel ist, erkennt man an den Screenshots. 3d wären dann alle Formen von 3d Vektorgrafiken, Voxelgrafiken und vielleicht noch 2d Sprites im 3d Raum, aber letztere erschienen ab SVGA ohnehin nicht mehr, da nahm man lieber VGA und dafür Vektorgrafiken mit Texturen oder Gouraud Shading. Diese Unterscheidung in 2D und 3D wäre insofern interessant, da 3D mehr Leistung braucht und daher damit zu rechnen ist, dass bei 3d Spielen der Wechsel zu den SVGA Modi später stattfand. Und so war auch meine Erfahrung damals. Wollte man auch deren Wechsel aufzeigen, müsste man das also auch erwähnen. Damit wären es 4 Balken pro Monat oder Quartal, 2 Balken für 2d Spiele, 2 für 3d Spiele. Und monatsweise ist natürlich genauer als quartalsweise, benötigt aber auch mehr Platz. Am sinnvollsten wäre also, monatsweise die Daten erst einmal zu erheben und dann schauen, was man daraus machen kann. Wenn es eine Grafik ist, könnte man auch beide Formen als eigenständige Grafik auf Mediawiki unterbringen. Die PC Player hat auch darauf geachtet, nur dann ein Spiel mit unterstützt SVGA zu markieren, wenn es wirklich ein VESA SVGA Modi. D.h. Spiele, die nur den höher aufgelösten VGA Modus 640x480 bei nur 16 Farben verwendeten, werden in der PC Player als VGA Spiel geführt. Ein Beispiel dafür ist Syndicate, das verwendet kein SVGA und läuft in der Auflösung 640x480 bei 16 Farben.

In der PC Player steht wie schon gesagt einfach ablesbar in der Spielebewertungsbox drin, ob das Spiel VGA oder SVGA oder beides verwendet. Viel mehr braucht man dafür auch nicht. Wenn mich meine Erinnerung nicht täuscht, könnte es auch sein, dass in den späteren Ausgaben, auch höhere Auflösungen als 640x480 separat erwähnt werden. Das alles zusammenzufassen ist eine reine Fleißarbeit und Hausmeisteraufgabe für jedermann. Die PC Player Ausgaben sind öffentlich und legal mit Genehmigung der Gamestar auf der Webseite www.pcplayer.de verfügbar, da kann also jeder mitmachen. Ich bin aber in der Wikipedia mit wichtigeren Baustellen beschäftigt, die IT Qualifikation erfordern, also werde ich diese Fleißarbeit nicht machen. Außerdem könnte ich das auch ohnehin nicht machen, weil man zum Online stellen von Grafiken ja einen aktiven Account braucht und den haben ein paar arbeitslose WP Admins ja unberechtigterweise aus rein politischem Wahn, Gehässigkeit und Feindlichkeit gegenüber der Wikipedia gesperrt. Also frag am besten bei denen nach, die haben in der Regel eh nichts zu tun außer denen, die die Wikipedia verbessern, das Leben schwer zu machen und der Wikipedia zu schaden. --93.229.175.119 12:31, 27. Mai 2024 (CEST)

Wenn du anfängst, Spiele zu zählen, in deinem Beispiel aus PC Player, dann ist das bereits WP:TF. Du darfst leider nicht zählen, aber wenn du ein Buch findest, dessen Autor genau das gemacht hat, dann kannst du dessen Zählung hier anführen.

‣Andreas•⚖ 14:10, 27. Mai 2024 (CEST)

Na wenn das Zusammenzählen von Belegen Theoriefindung ist, dann kann man die Wikipedia ja nur bedauern. Genauso bescheuert ist die Regel, wenn der Autor diese Zusammenzählarbeit in einem monatlichen Blog zusammenfasst, dann gilt es nicht, schreibt er aber einen Artikel, den er auf seiner Webseite präsentiert, wo nicht ein monatlicher Artikel erscheint, der Artikel also für sich steht, dann gilt es. Hirngaga vom Feinsten, so ist das in der deutschen Wikipedia. Ich bin mir sicher, auf so ein Buch kannst du lange warten. --93.229.175.119 15:48, 27. Mai 2024 (CEST)

Nein. Wikipedia-Autoren sind keine Journalisten. Wenn du bei einer Zeitschrift arbeitest, und dann dort die Spiele zusammenzählst, machst du das im Rahmen deiner journalistischen Tätigkeit. Kann aber sein, dass dann dein Chefredakteur fragt, ob du noch alle Tassen im Schrank hast. Soll heißen: was du als Journalist schreibst, fällt auf den Verlag zurück, und muss natürlich auch gewissen Standards entsprechen...

Wenn du als Spieleentwickler einen Blog schreibst, gilt das auch, obwohl es ein Blog ist, weil du dann jemand vom Fach bist.

Nur als Wikipedia-Autor steht es dir eben nicht zu. Du kannst aber gerne ein Studium an einer Universität deines Vertrauens beginnen, und im Rahmen einer deiner wissenschaftlichen Arbeiten dann Spiele zählen. Dann gilt es auch wieder...

Ich persönlich verstehe ja nicht, was daran so schwer zu verstehen ist. ‣Andreas•⚖ 15:56, 27. Mai 2024 (CEST)

Zu:

Wenn du als Spieleentwickler einen Blog schreibst, gilt das auch, obwohl es ein Blog ist, weil du dann jemand vom Fach bist.

Du widersprichst dir selbst. Bau mal diese Belege zu Artikel von Raymond Chen in die jeweiligen Artikel. Der Mann ist Entwickler von Windows und damit vom Fach, und trotzdem wird rumgemault, dass es ein Blog sei.

Das kannst du hier:

• Diskussion:Microsoft Windows 95#Windows 95 IST ein Betriebssystem
• Diskussion:Microsoft Windows 95#Thema: Anstrengungen, um Kompatibilität zu bestehenden DOS und Windows 3.x Anwendungen zu erreichen

als auch insbesondere hier, wo das ganze gleich reverted wurde

• https://de.wikipedia.org/w/index.php?title=Aktives_Fenster&diff=prev&oldid=243875555
• https://de.wikipedia.org/w/index.php?title=Jog_Dial&diff=prev&oldid=243875525

nachlesen. Im Win95 hast du dich sogar selber über die Quelle beschwert.

Ihr habt also echt ein Problem mit eurer eigenen Definition und verrennt euch ständig in Widersprüche.Eure Definitionen sind Hirngaga eben, mal gilt es, mal gilt es nicht, mal gilt es, aber eure Reverter legt die Regeln anders aus und schon ist es wieder revertiert.

Und man muss auch kein Journalist sein, es reicht eine privat geführte Webseite. Aus dem OS/2 Museum wird bspw. alles akzeptiert, außer vielleicht die newsartigen Artikel, die wie ein Blog aussehen, auch diese Seite ist privat geführt und da schreibt kein Journalist:

• http://www.os2museum.com

Auch ein Autor eines Buches ist kein Journalist, sondern eben ein Buchautor.

Was ich oben im letzten Kommentar geschrieben habe, ist ebenso Fakt, die Frage ist nur, ob du es verstanden hast, jetzt wo du mir hier wieder widersprechen willst. Zähl selber, ich habe dir bereits im Eingangsposting gesagt, dass ich es nicht machen werde. Deswegen steht das auch nicht im Artikel, sondern auf der Diskussionsseite.

Im übrigen ist eine Zusammenzählung bereits dann eine Zusammenzählung, wenn man im Fließtext so Sachen schreibt wie bspw. "Windows XY ist die n-te Version von Windows." --93.229.175.119 16:12, 27. Mai 2024 (CEST)

Ach noch etwas. Wollte man bspw. für einen WP Artikel belegen, wie viele Spiele in der PC Player Ausgabe 10-1993 getestet wurden, dann würde das deiner Meinung ja wieder nicht gehen, denn dazu müsstest du ja zählen. So lachhaft! --93.229.175.119 16:21, 27. Mai 2024 (CEST)

Nein, ich widerspreche mir nicht. Ich kann dann in den Artikel schreiben, dass es nach Meinung eines Entwicklers so sei. Das ist belegt. Ich kann nicht schreiben, dass es so ist. Ich kann aber andere Quellen mit dem Blog des Entwicklers bestätigen und eventuell etwas erweitern, aber ich kann eben nicht hergehen und behaupten, dass das unumsößlich so sei. Ich kann aber auch nicht einen Blog von irgendwem, der überhaupt keinen Bezug dazu hat bzw. der noch nichts geleistet hat, dafür hernehmen. Verständlich soweit?

‣Andreas•⚖ 16:33, 27. Mai 2024 (CEST)

Dann beweise es und mach mal für die beiden Artikel Aktives Fenster und Jog_Dial. Die nötigen Daten dafür hast du ja oben schon, du findest alles nötige in der dortigen Artikelhistorie. --93.229.175.119 17:06, 27. Mai 2024 (CEST)

Und den Leuten im Windows Artikel auf der Diskussionsseite, erkläre folgenden Satz:

Wenn du als Spieleentwickler einen Blog schreibst, gilt das auch, obwohl es ein Blog ist, weil du dann jemand vom Fach bist.

--93.229.175.119 17:07, 27. Mai 2024 (CEST)