Warum hat man die Hardware im Upper Memory Block eingeblendet?

UEFI hätte dann ja mit der Einführung zum 80386 schon dabei sein müssen.
Ich meine für einen 80386 wäre so ein Mainboard damals unbezahlbar geworden und es wäre aus Mangel an Anwendungen dafür auch gar keine Nachfrage vorhanden.

Dirk

freecrac schrieb:

Das Bios schaltet aber selber gar nicht in den V86-Mode und ist dafür auch gar nicht ausgelegt.

Das Bios wird in einem Protected Mode OS nicht mehr benötigt.

Das Real Mode Programm merkt davon nichts, deswegen hat man den Virtual 8086 Mode mit dem 386er eingeführt.

Vor dem Booten ist es aber irrelevant ob danach der Speicher auch anders verwendet werden kann und so weit sind wir ja noch gar nicht das wir booten können, wenn im untersten MB gar kein Bios mehr arbeiten kann.

Dirk

Das BIOS könnte man durchaus durch andere Firmware ersetzen die gleich im Protected Mode arbeitet. Die Zusatzhardware müßte dies natürlich eventuell berücklsichtigen.
Selbstverständlich macht das Heutzutage aber keinen Sinn, weil es dieses Speicherproblem unter einem modernen OS im Protected Mode mit Pageing nicht mehr gibt und man das BIOS weiterhin aus Kompatibilitätsgründen (wenn auch emuliert bei UEFI) gerne hätte.

freecrac schrieb:

UEFI hätte dann ja mit der Einführung zum 80386 schon dabei sein müssen.
Ich meine für einen 80386 wäre so ein Mainboard damals unbezahlbar geworden und es wäre aus Mangel an Anwendungen dafür auch gar keine Nachfrage vorhanden.

Dirk

Als der 386er eingeführt wurde, war DOS unter x86 Rechnern das noch am meisten verbreitete Betriebssystem und Speicher knapp, was dazu führte, das Protected Mode Betriebssysteme wie OS/2 kaum Verbreitung fanden, weil diese eben selbst viel Speicher brauchten um ordentlich zu laufen.

Und wenn der Speicher knapp ist, dann verwendet man soweiso viel lieber 16 Bit Programme anstatt 32 Bit Programme um auch hier Speicherplatz zu sparen.

Zur Info:
Der 80386 erblickte 1985 die Welt.

OS/2 1.0 erschien 1987 als 16 Bit Version, aber schon als Protected Mode OS, denn der 286er konnte bereits Protected Mode, nur halt eben nicht per Paging, sondern per Segmentierung und den Virtuel 8086 Mode kannte der 286er auch nicht.

Und 1 MB Speicher war 1987 noch sehr teuer.

Die 32 Bit Version von OS/2 erschien erst 1991 und man sollte hier nen Rechner mit 8 MB nutzen, damit man auch für Programme noch ordentlich Speicher hat.
Für Spiele war OS/2 darüberhinaus nicht brauchbar, weil es keinen direkten Zugriff auf die Grafikhardware zulies. Man hat an die Spieler einfach nicht gedacht.

So etwas gab's erst mit Win95 und das lief mehr schlecht als Recht, womit das erste brauchbare Proteced Mode OS, das auch für Spieler geeignet war, erst Windows 2000 mit DirectX 7.x war.

Real Mode! schrieb:

freecrac schrieb:

Das Bios schaltet aber selber gar nicht in den V86-Mode und ist dafür auch gar nicht ausgelegt.

Das Bios wird in einem Protected Mode OS nicht mehr benötigt.

Aber wie soll denn sonst ohne ein Bios überhaupt ein OS gebootet werden?

Das Real Mode Programm merkt davon nichts, deswegen hat man den Virtual 8086 Mode mit dem 386er eingeführt.

Vor dem Booten ist es aber irrelevant ob danach der Speicher auch anders verwendet werden kann und so weit sind wir ja noch gar nicht das wir booten können, wenn im untersten MB gar kein Bios mehr arbeiten kann.

Dirk

Das BIOS könnte man durchaus durch andere Firmware ersetzen die gleich im Protected Mode arbeitet.

Dann wäre aber die gesamte Kompatibilität zu der Mehrzahl der damaligen 16 Bit-Programme nicht mehr vorhanden und die Vielzahl an 32 Bit und 64 Bit-Anwendungen von heute gab es damals noch nicht.

Die Zusatzhardware müßte dies natürlich eventuell berücklsichtigen.
Selbstverständlich macht das Heutzutage aber keinen Sinn, weil es dieses Speicherproblem unter einem modernen OS im Protected Mode mit Pageing nicht mehr gibt und man das BIOS weiterhin aus Kompatibilitätsgründen (wenn auch emuliert bei UEFI) gerne hätte.

Es hätte dann ja zwei verschiedene Entwicklung-Richtungen geben müssen.
Eine Richtungen für die meisten damaligen Anwenugen und eine Richtungen wofür es noch keine Anwendungen gibt. So etwas hätte doch kein damaliger Kunde sich angeschafft.

Es gab aber auch auf dem 80386 im 16 Bit Adressmode nie ein Problem den gesamten 4 GB-Adressraum zu adressieren, weil dafür ist der 32 Bitmode gar nicht erforderlich. Denn der einzige Unterscheid zwischen dem 32 Bit-Mode und dem 16 Bit-Mode ist die Bedeutung und Verwendung der Operandsize und Adressize-Prefixe. Die Menge des adresierbaren Speicherbereiches hat damit überhaupt nichts zu tun.

Dirk

Real Mode! schrieb:

Die 32 Bit Version von OS/2 erschien erst 1991 und man sollte hier nen Rechner mit 8 MB nutzen, damit man auch für Programme noch ordentlich Speicher hat.
Für Spiele war OS/2 darüberhinaus nicht brauchbar, weil es keinen direkten Zugriff auf die Grafikhardware zulies. Man hat an die Spieler einfach nicht gedacht.

So etwas gab's erst mit Win95 und das lief mehr schlecht als Recht, womit das erste brauchbare Proteced Mode OS, das auch für Spieler geeignet war, erst Windows 2000 mit DirectX 7.x war.

Ich habe eben im Dos-Forum über OS/2 etwas ganz anderes gelesen.
(Ich selbe habe OS/2 noch nie verwendet.)

yuggoth schrieb:

Durch Descent hab ich die Leistungsfähigkeit des DOS-Multitaskings von OS/2 Warp kennengelernt...
Ich hatte mir dieses zusammen mit meinem 486er-Board geholt, um es mal auszuprobieren und bequem zwischen diversen DOS-Programmen umschalten zu können. Ich war am Zocken (Fullscreen 320*200, 256 Farben) und habe dann zu CrossPoint umgeschaltet (Textmodus in einem Fenster auf 800*600, 256 andere Farben) um meine Mails zu lesen. Plötzlich hör ich das Geräusch eines angreifenden Roboters, wechsle zu Descent (jetzt auch im Fenster mit interpolierter recht ruckeliger Grafik) und kapiere, dass das Spiel entgegen meiner Annahme gar nicht gestoppt war, sondern die ganze Zeit im Hintergrund weiter lief... besonders beeindruckt war ich davon, wie gut der Grafiktreiber die Farben des Spiels auf die Farben der Fensteroberfläche interpoliert hat - unter Windows war Fensterdarstellung von VGA-Spielen damals IIRC gar nicht möglich.

Dirk

freecrac schrieb:

Real Mode! schrieb:

freecrac schrieb:

Das Bios schaltet aber selber gar nicht in den V86-Mode und ist dafür auch gar nicht ausgelegt.

Das Bios wird in einem Protected Mode OS nicht mehr benötigt.

Aber wie soll denn sonst ohne ein Bios überhaupt ein OS gebootet werden?

In dem man das BIOS durch was anderes ersetzt oder das OS bootet und dann gleich in den Protected Mode schaltet.

Der Punkt um denn es bei meinem Satz geht ist der, dass die BIOS Funktionen auf einem modernen OS nicht mehr notwendig sind, weil diese neuen OS alles selber machen und das stimmt auch.

Dann wäre aber die gesamte Kompatibilität zu der Mehrzahl der damaligen 16 Bit-Programme nicht mehr vorhanden und die Vielzahl an 32 Bit und 64 Bit-Anwendungen von heute gab es damals noch nicht.

Habe ich ja gesagt.

Es hätte dann ja zwei verschiedene Entwicklung-Richtungen geben müssen.
Eine Richtungen für die meisten damaligen Anwenugen und eine Richtungen wofür es noch keine Anwendungen gibt. So etwas hätte doch kein damaliger Kunde sich angeschafft.

Es war ja auch deine Idee, so etwas wie UEFI gleich mit dem 386er auszuliefern.

Es gab aber auch auf dem 80386 im 16 Bit Adressmode nie ein Problem den gesamten 4 GB-Adressraum zu adressieren, weil dafür ist der 32 Bitmode gar nicht erforderlich. Denn der einzige Unterscheid zwischen dem 32 Bit-Mode und dem 16 Bit-Mode ist die Bedeutung und Verwendung der Operandsize und Adressize-Prefixe. Die Menge des adresierbaren Speicherbereiches hat damit überhaupt nichts zu tun.

Dirk

Der 386er macht das durch den virtual 8086 Mode, jeder Prozess kriegt max 1 MB und wo die 1 MB liegen ist völlig unerheblich, deswegen kriegst du mit 16 Bit Realmode Programme natürlich auch den Speicher von 4 GB voll.

Mehr als 2^20 Byte (bzw. 2^21 Byte mit Addition) kann ein 16 Bit Real Mode Prozess also gar nicht ansteuern, auch nicht unter einem 386er.

freecrac schrieb:

Real Mode! schrieb:

Die 32 Bit Version von OS/2 erschien erst 1991 und man sollte hier nen Rechner mit 8 MB nutzen, damit man auch für Programme noch ordentlich Speicher hat.
Für Spiele war OS/2 darüberhinaus nicht brauchbar, weil es keinen direkten Zugriff auf die Grafikhardware zulies. Man hat an die Spieler einfach nicht gedacht.

So etwas gab's erst mit Win95 und das lief mehr schlecht als Recht, womit das erste brauchbare Proteced Mode OS, das auch für Spieler geeignet war, erst Windows 2000 mit DirectX 7.x war.

Ich habe eben im Dos-Forum über OS/2 etwas ganz anderes gelesen.
(Ich selbe habe OS/2 noch nie verwendet.)

yuggoth schrieb:

Durch Descent hab ich die Leistungsfähigkeit des DOS-Multitaskings von OS/2 Warp kennengelernt...
Ich hatte mir dieses zusammen mit meinem 486er-Board geholt, um es mal auszuprobieren und bequem zwischen diversen DOS-Programmen umschalten zu können. Ich war am Zocken (Fullscreen 320*200, 256 Farben) und habe dann zu CrossPoint umgeschaltet (Textmodus in einem Fenster auf 800*600, 256 andere Farben) um meine Mails zu lesen. Plötzlich hör ich das Geräusch eines angreifenden Roboters, wechsle zu Descent (jetzt auch im Fenster mit interpolierter recht ruckeliger Grafik) und kapiere, dass das Spiel entgegen meiner Annahme gar nicht gestoppt war, sondern die ganze Zeit im Hintergrund weiter lief... besonders beeindruckt war ich davon, wie gut der Grafiktreiber die Farben des Spiels auf die Farben der Fensteroberfläche interpoliert hat - unter Windows war Fensterdarstellung von VGA-Spielen damals IIRC gar nicht möglich.

Dirk

Hier geht es um den DOS Modus in OS/2, das ist etwas völlig anderes.

Aber der Hinweis auf das Spiel im Fenstermodus zeigt, dass OS/2 für Spiele nicht geeignet war.

Mit Spielen meine ich hier keine DOS Spiele, sondern Spiele die eben für das moderne OS geschrieben werden.
In diesem Fall also OS/2.

So etwas wie DirectX oder wenigstens Direct2d gab es in OS/2 nicht.
Erst ganz spät gab es dann mal OpenGL Support, aber da war das Rennen gegen Windows 9x schon verloren.

Bei Windows 95 wurde von Anfang an an einen schnellen Zugriff auf die Grafik- und Soundhardware für Spiele gedacht.
Bei Windows 3.1 wurden erste Versuche der so genannten WinG Lib(der Vorgänger von DirectX) unternommen, was dann für Win9x in DirectX mündete.
http://de.wikipedia.org/wiki/WinG

Real Mode! schrieb:

Der 386er macht das durch den virtual 8086 Mode, jeder Prozess kriegt max 1 MB und wo die 1 MB liegen ist völlig unerheblich, deswegen kriegst du mit 16 Bit Realmode Programme natürlich auch den Speicher von 4 GB voll.

Nachtrag:
Natürlich muss man dazu genug 16 Bit Prozesse starten.
Einer allein reicht dafür nicht.

Real Mode! schrieb:

freecrac schrieb:

Real Mode! schrieb:

freecrac schrieb:

Das Bios schaltet aber selber gar nicht in den V86-Mode und ist dafür auch gar nicht ausgelegt.

Das Bios wird in einem Protected Mode OS nicht mehr benötigt.

Aber wie soll denn sonst ohne ein Bios überhaupt ein OS gebootet werden?

In dem man das BIOS durch was anderes ersetzt oder das OS bootet und dann gleich in den Protected Mode schaltet.

Ja ok.

Der Punkt um denn es bei meinem Satz geht ist der, dass die BIOS Funktionen auf einem modernen OS nicht mehr notwendig sind, weil diese neuen OS alles selber machen und das stimmt auch.

Ich dachte eher das in einem Mainboard mit UEFI-Bios z.B im Bios ein Grafiktreiber vorhanden ist den verschieden OS verwenden können und das die OS selber gar kein Grafiktreiber mehr benötigen, weil nur noch der Treiber vom UEFI-Bios von allen OS benutzt wird.

Dann wäre aber die gesamte Kompatibilität zu der Mehrzahl der damaligen 16 Bit-Programme nicht mehr vorhanden und die Vielzahl an 32 Bit und 64 Bit-Anwendungen von heute gab es damals noch nicht.

Habe ich ja gesagt.

Es hätte dann ja zwei verschiedene Entwicklung-Richtungen geben müssen.
Eine Richtungen für die meisten damaligen Anwenugen und eine Richtungen wofür es noch keine Anwendungen gibt. So etwas hätte doch kein damaliger Kunde sich angeschafft.

Es war ja auch deine Idee, so etwas wie UEFI gleich mit dem 386er auszuliefern.

Weil ein 16 Bit-Bios dafür nicht geeignet ist oberhalb vom ersten MB zu arbeiten, wenn die Hardware in den untersten Adressbereich verschoben wird und dort kein Platz mehr vorhanden ist.

Es gab aber auch auf dem 80386 im 16 Bit Adressmode nie ein Problem den gesamten 4 GB-Adressraum zu adressieren, weil dafür ist der 32 Bitmode gar nicht erforderlich. Denn der einzige Unterscheid zwischen dem 32 Bit-Mode und dem 16 Bit-Mode ist die Bedeutung und Verwendung der Operandsize und Adressize-Prefixe. Die Menge des adresierbaren Speicherbereiches hat damit überhaupt nichts zu tun.

Dirk

Der 386er macht das durch den virtual 8086 Mode, jeder Prozess kriegt max 1 MB und wo die 1 MB liegen ist völlig unerheblich, deswegen kriegst du mit 16 Bit Realmode Programme natürlich auch den Speicher von 4 GB voll.

Mehr als 2^20 Byte (bzw. 2^21 Byte mit Addition) kann ein 16 Bit Real Mode Prozess also gar nicht ansteuern, auch nicht unter einem 386er.

Es gibt aber auch den 16 Bit PM womit die Segmentgrösse auf einem 80386 auf den gesamten 4GB Adressbereich ausgedehnt werden kann, womit eine 16 Bit-Anwendung mit einem 32Bit-Adressregister die vollen 4GB addressieren kann.

Wie schon gesagt, die Menge des adresierbaren Speicherbereiches hat damit überhaupt nichts zu tun, ob nun der 32Bit-Adressmode, oder der 16 Bit-Adressmode auf einem 80386+ verwendet wird. In beiden Fällen kann die Segmentgrösse in den Segmenteinträgen einer GDT/LDT auf 4 GB erweitert werden.
Die Wahl des 16 Bit, oder 32 Bit-Adressmodes entscheidet nur darüber wie ein Code im Codesegment mit und ohne Operandsize und Adressize-Prefixe ausgeführt wird. Operandsize und Adressize-Prefixe lassen sich im 16 Bit-Adressmode, sowie auch im 32 Bit-Adressmode, im RM, im PM und im V86-Mode ab 80386+ verwenden.

Dirk

Real Mode! schrieb:

freecrac schrieb:

Real Mode! schrieb:

Die 32 Bit Version von OS/2 erschien erst 1991 und man sollte hier nen Rechner mit 8 MB nutzen, damit man auch für Programme noch ordentlich Speicher hat.
Für Spiele war OS/2 darüberhinaus nicht brauchbar, weil es keinen direkten Zugriff auf die Grafikhardware zulies. Man hat an die Spieler einfach nicht gedacht.

So etwas gab's erst mit Win95 und das lief mehr schlecht als Recht, womit das erste brauchbare Proteced Mode OS, das auch für Spieler geeignet war, erst Windows 2000 mit DirectX 7.x war.

Ich habe eben im Dos-Forum über OS/2 etwas ganz anderes gelesen.
(Ich selbe habe OS/2 noch nie verwendet.)

yuggoth schrieb:

Durch Descent hab ich die Leistungsfähigkeit des DOS-Multitaskings von OS/2 Warp kennengelernt...
Ich hatte mir dieses zusammen mit meinem 486er-Board geholt, um es mal auszuprobieren und bequem zwischen diversen DOS-Programmen umschalten zu können. Ich war am Zocken (Fullscreen 320*200, 256 Farben) und habe dann zu CrossPoint umgeschaltet (Textmodus in einem Fenster auf 800*600, 256 andere Farben) um meine Mails zu lesen. Plötzlich hör ich das Geräusch eines angreifenden Roboters, wechsle zu Descent (jetzt auch im Fenster mit interpolierter recht ruckeliger Grafik) und kapiere, dass das Spiel entgegen meiner Annahme gar nicht gestoppt war, sondern die ganze Zeit im Hintergrund weiter lief... besonders beeindruckt war ich davon, wie gut der Grafiktreiber die Farben des Spiels auf die Farben der Fensteroberfläche interpoliert hat - unter Windows war Fensterdarstellung von VGA-Spielen damals IIRC gar nicht möglich.

Dirk

Hier geht es um den DOS Modus in OS/2, das ist etwas völlig anderes.

Aber der Hinweis auf das Spiel im Fenstermodus zeigt, dass OS/2 für Spiele nicht geeignet war.

Wenn es so spielbar ist, dann ist es doch auch geeignet.

Mit Spielen meine ich hier keine DOS Spiele, sondern Spiele die eben für das moderne OS geschrieben werden.
In diesem Fall also OS/2.

Gab es denn überhaupt schon moderne Spiele für OS/2 und für Windows?

So etwas wie DirectX oder wenigstens Direct2d gab es in OS/2 nicht.
Erst ganz spät gab es dann mal OpenGL Support, aber da war das Rennen gegen Windows 9x schon verloren.

Bei Windows 95 wurde von Anfang an an einen schnellen Zugriff auf die Grafik- und Soundhardware für Spiele gedacht.
Bei Windows 3.1 wurden erste Versuche der so genannten WinG Lib(der Vorgänger von DirectX) unternommen, was dann für Win9x in DirectX mündete.
http://de.wikipedia.org/wiki/WinG

OK.

Dirk

muemmel

Hi Dirk,

freecrac schrieb:

Morle schrieb:

... kann man IMHO nicht sagen, dass die Entwickler damals nicht nachgedacht hätten.

Wie weit vorausschauend bei der Entwicklung nachgedacht wurde lässt sich andererseits ja auch schon am 2K-Bug gut erkennen.

Dirk

Damals als die zweistellige Datumsspeicherung eingeführt wurde (CP-M 1972, MS-DOS 1980, die Großrechner noch mal Jahrzehnte früher) konnte niemand davon ausgehen, dass nach einem Vierteljahrhundert immer noch mit dem gleichen System gearbeitet werden würde.
Außerdem war damals Speicherplatz so teuer, dass es einfach nicht vertretbar war, da jeweils Speicher zu verschenken.

Sicher ist es immer gut, auch an die Zukunft zu denken, aber das wichtigste ist doch immer die Absicherung der Gegenwart.
Bei den allerersten Rechnern hat man sogar Redundante Bits in den einzelnen Speicheradressen genutzt um da noch ein paar Daten unterzubringen. Zum Beispiel hatte Fortran damals neben den normalen "Zeichenkette" noch eine andere Form, wo nicht der ganze ASCII-Zeichensatz von 0-256 zugelassen wurde sondern nur Zahlen und buchstaben, und wo man wohl 10 Zeichen in 6 Bytes unterbringen konnte. Unter solchen Gesichtspunkten Speicherplatz zu verschwenden, nur um in einem Vierteljahrhundert auf der sicheren Seite zu sein war einfach nicht vermittelbar.
Auch das damals vermutlich beste Betriebssystem OS/2 ist an zu hohen Hardwareansprüchen gescheitert, obwohl das damals mit weniger ausgekommen ist als heute ein normals Handy hat.

Gruß Mümmel

f.-th. schrieb:

Ist schon Technik aus früher PC-Zeit.

@ 640kbyte Grenze

Programmiere auf deiner 486er Kiste mal die Grafikkarte direkt und in Farbe mit verschiedenen Farbtiefen und Bildschirmauflösungen, also ohne Interrupt oder Herstellertreiber. Wo du die Infos zur Adressierung her bekommst

-> VESA Modus (bei nicht all zu alten SVGA karten), also VESA BIOS Extension, ist aber nicht das Thema hier.

Wenn du wirklich die alten Geschichten wissen willst, besorge dir die Infos zu den alten CPU und ihrer Adressierung. Wer hat sich den vor etwa 30 Jahren da in Rechnern fürs Volk versucht?
8080 von Intel: PC
Z80 von Zilog: Amstrat
9900 von TI: TI
6800 von Motorola: Appel
Das sind die, die mir spontan einfallen. Bis auf den TI, der schon 16 bit hatte, waren das damals 8bit. Auf 16 oder 32bit hat man die erst später gebracht.

Der 8080 von Intel, also des IBM PC IST eine 16 Bit CPU, nur 8 Bit hatten nur die Datenleitungen nach außen.

P.S.:Aktuelle Mainboards können zum Teil gar kein altes DOS mehr. Steht jedenfalls so in der Bedienungsanleitung. Da könnt ihr nur noch neuere Betriebssysteme darauf los lassen.

UEFI

Hier hat man wohl den BIOS Emulationssupport in UEFI nicht implementiert.

Bashar

640kbyte Grenze schrieb:

Wenn du wirklich die alten Geschichten wissen willst, besorge dir die Infos zu den alten CPU und ihrer Adressierung. Wer hat sich den vor etwa 30 Jahren da in Rechnern fürs Volk versucht?
8080 von Intel: PC
Z80 von Zilog: Amstrat
9900 von TI: TI
6800 von Motorola: Appel
Das sind die, die mir spontan einfallen. Bis auf den TI, der schon 16 bit hatte, waren das damals 8bit. Auf 16 oder 32bit hat man die erst später gebracht.

Der 8080 von Intel, also des IBM PC IST eine 16 Bit CPU, nur 8 Bit hatten nur die Datenleitungen nach außen.

Die CPU des PC war der Intel 8088. Der 8080 ist in der Tat ein 8-Bit-Prozessor.

Bashar schrieb:

640kbyte Grenze schrieb:

Wenn du wirklich die alten Geschichten wissen willst, besorge dir die Infos zu den alten CPU und ihrer Adressierung. Wer hat sich den vor etwa 30 Jahren da in Rechnern fürs Volk versucht?
8080 von Intel: PC
Z80 von Zilog: Amstrat
9900 von TI: TI
6800 von Motorola: Appel
Das sind die, die mir spontan einfallen. Bis auf den TI, der schon 16 bit hatte, waren das damals 8bit. Auf 16 oder 32bit hat man die erst später gebracht.

Der 8080 von Intel, also des IBM PC IST eine 16 Bit CPU, nur 8 Bit hatten nur die Datenleitungen nach außen.

Die CPU des PC war der Intel 8088. Der 8080 ist in der Tat ein 8-Bit-Prozessor.

Ok, hast Recht. Hab auch die letzte Ziffer nicht so genau geachtet.

Trotzdem ist dann die Aussage

8080 von Intel: PC

Dann falsch, denn mit PC ist ja hier wohl der IBM PC gemeint und der hatte eben mit dem 8088 einen 16 Bit Prozessor mit 8 Bit Datenleitungen nach außen.