Unreal Mode = beste Loesung fuer PM-Verabscheuer?

Wenn man ein OS schreiben moechte, aber trotzdem auf das BIOS zugreifen moechte und keine Treiber fuer den Protected Mode schreiben will, waere es dann die beste Idee, wenn man zuerst in den Protected Mode wechselt und dann wieder zurueck in den Real Mode? (also Unreal Mode)... Dann kann man ja 4 GB RAM verwenden und hat trotzdem noch Zugriff auf das BIOS.

Als generelle Idee ist dies unbrauchbar. Üblich ist, dass man sämtliche Funktionen in einem OS selbst erstellt. Eine Zwitterstellung hat der Virtual Mode (VM), der zu DOS-Zeiten geschaffen wurde, um DOS-Programme, die auf RM beruhten, auch im PM ausführen zu können. PrettyOS verwendet VM z.B. im Grafikmode.
vgl.: https://de.wikipedia.org/wiki/Virtual_8086_Mode

Mechanics

Ich glaube GRUB2 verwendet das an paar Stellen, bin mir jetzt aber nicht sicher. GRUB ist aber natürlich auch kein Betriebssystem. Ist denke ich keine gute Designentscheidung, das so aufzubauen, vielleicht als Zwischenlösung.

warum sollte man pm verabscheuen? war ein großer fortschritt.

warum sollte man pm verabscheuen? war ein großer fortschritt.

weil man das bios nicht mehr verwenden kann?! es seidenn, man hat lust, alle treiber fuer den pm zu schreiben.

Du schreibst doch keine Treiber für den PM speziell.

Das BIOS hat sicherlich auch keine Funktionen für deine neue Grafikkarte. Also. Echt.

Erhard Henkes

Es ist schon ein merkwürdiger Schritt, dass man alles neu aufbauen muss, findet wohl mancher am Anfang befremdend. Da existiert keine mir bekannte sinnvolle Alternative. Man muss alles im Sinne von "clean sheet" neu entwickeln. Das ist schwierig und mühsam, daher schaffen das nur wenig Leute im nachhaltigen Sinne.

Moin.

ErfinderDerTreiberPM schrieb:

Das BIOS hat sicherlich auch keine Funktionen für deine neue Grafikkarte. Also. Echt.

Huch, was geht denn hier ab?

Welches Bios hat denn (gar) keine Funktionen für eine neue Grafikkarte und wie kann man denn sonst das BIOS vom Mainboard einstellen, wenn nicht einmal der Textmode verfügbar ist?

Meine beiden "neuen" Grafikkarten (eine Geforce GTX 295(Colorfull) und auch eine Radeon 7950(Saphire)) bringen beide ein VBE 3 Bios mit, womit man auch einige widescreen Videomodi für den linearen framebuffer(im 4.Gib) einschalten kann, um z.B. die native Auflösung von 1920x1200(16:10 aspect ratio) für meinem 28" LCD zu bekommen.

Nebenbei gibt es mit einem VBE3-Bios auch noch refreshrate controlled Modi, womit man seine eigenen CRTC-Parameter verwenden kann, um eine höhere Refreshrate als die defaultmässigen 60hz auf einem CRT-Monitor zu verwenden. (Dafür ist es sinnvoll vorher die maximale Kapazität des verwendeten Monitors über dessen EDID zu überprüfen, womit die maximale KHZ und HZ und die bevorzugte Auflösung des Monitors ermittelt werden kann.) Weiterhin gibt es eine Bios-seitige Unterstützung von steroskopischen Shutterglasses und auch für hardware triple buffering, um ein "Flickering" und "Tearing" von sich bewegenden Bild-Inhalten zu vermeiden.

Alle diese VBE3 Funktionen lassen sich nur im Realmode, im 16 Bit Unrealmode und dem V86-Mode, aber nicht im PM verwenden. Mit der (nur selten vorhandenen) VBE-PM-Schnittstelle sind diese oben aufgeführten Fünktionen nicht verfügbar. Siehe dazu auch folgende public and costfree documents vbe3.pdf, EEDIDguideV1.pdf und EEDIDverifGuideRa.pdf von vesa.org (register/login erforderlich).

...

Videomode-Wechsel im PM ohne closed source Treiber:
Und wie bitte kann man so etwas denn selber entwickeln, um z.B. ohne die Unterstützung vom Bios einen Videomode mit einer hohen Auflösung selber einzuschalten, wenn es keine Dokumente darüber gibt und jeder Grafikkarten-Hersteller quasi sein eigenes Süppchen kocht und sich auch schon die Modellreihen eines einzigen Herstellers untereinander unterscheiden und jeweils eine andere Vorgehensweise erfordern und selbst GRUB auch nur das BIOS dafür verwendet?

Dann bitte auch gleich mal veraten, wie man auf einem secondary display device von einer Grafikkarte mit zwei Ausgängen einen andere Auflösung einstellen kann, die sich von der Auflösung des primäry display device unterscheidet und womit man den Inhalt des zweiten linearen Frambuffers zur Anzeige bringen kann. Ich behaupte mal in den Linux-Sourcen ist das auch nicht enthalten, aber ich würde mich gerne vom Gegenteil überzeugen lassen. Dann aber bitte mit konkreten Angaben darüber, wo man den Code dafür finden kann. Nur zu behaupten es sei dort zu finden genügt leider nicht.

...

Für den 16 Bit Unrealmode würde es dann schon genügen nur die Grösse von DS auf 4 Gib zu erweitern und DS wie gewohnt auf unser Datensegment zu legen. Die Segment-Adresse vom Datensegment können wir nun in einem 32 bit Register 4 mal nach links shiften und das Ergebniss davon von unserer physikalischen Offset-Adresse abziehen, um auch weiterhin einen Zugriff auf unser Datensegment zu behalten und ebenfalls auch den linearen framebuffer über DS:reg32 addressieren zu können. (Für die Segmentregister FS/GS wird immer ein segment override prefix benötigt, wenn darüber addressiert werden soll, aber bei Zugriffen über DS brauchen wir solche Prefixe nicht.)

Angefangen mit Himem.sys 3.02 hat Winzigweich doch selber jahrelang den 16 Bit Unrealmode verwendet und diverse DOS-Games ebenso und auch der System Management Mode verwendet den Unrealmode doch heute immer noch. Bitte was soll an MS DOS mit Himem.sys 3.02 eigentlich unbrauchbar sein?

Das Laden einer Segmentadresse in ein Segmentregister im Unrealmode verändert nicht die Segmentgrösse im hidden descriptor cache und Interrupts können problemlos im Unrealmode eingeschalte werden. Es gibt aber einige wenige PCI-Karten deren Bios selber in den PM und auch zurück in den RM schalten, womit der Unrealmode deaktiviert wird. Mir selber ist aber keine einzige Mainboard-Bios-Funktion bekannt, die etwas vergleichbares macht.

Dirk