DOS vs. Linux Hardwarebelastung

[Dennis Grevenstein]

Hallo,

ich hätte da nochmal eine Frage an die Leute, die vor Ewigkeiten
schon Linux benutzt haben.
Ich spiele mittlerweile ganz gerne mit einem 386 PC rum und
hatte da ein altes Linux, was auf einem 25MHZ 386SX lief, aber
auf einem 40MHz 386DX nicht. Jetzt habe ich in den letzten Tagen
das ganzen Zeug einmal auseinandergenommen und aus den beiden
einen schönen PC zusammengesetzt mit den besten Teilen und nun
läuft das Linux auch auf dem 40MHz DX. Offensichtlich habe ich
da zufällig eine Sorte CF Karte erwischt, die reproduzierbar
auf dem einen PC läuft, aber an dem anderen nicht. Mit einer
anderen CF Karte klappt das nun.

Jedenfalls habe ich dabei festgestellt, dass Linux offenbar
sensibler mit der Hardware umgeht als DOS. Der 40MHz DX lief
prima mit DOS. Spiele und Kram ging immer alles ohne Problem.
Aber unter Linux gab es gerne mal seltsame Fehler, Signal 11,
usw. Jetzt habe ich heute mal die BIOS Einstellungen komplett
auf default gestellt, was den RAM mit 2 WS laufen lässt und den
ISA bus schön niedrig taktet. Jetzt läuft es offenbar stabil.
Die box compiliert seit 3 Stunden gcc ohne Fehler.

Kann das sein, dass DOS grosszügiger mit der Hardware umgehen
kann als Linux?
hier MS-DOS 6.22 vs. Linux 1.1.62.

gruss,
Dennis

[olaf]

Post by Dennis Grevenstein
Kann das sein, dass DOS grosszügiger mit der Hardware umgehen
kann als Linux?

Ja, es war damals allgemeinwissen das Linux "vernuenftigere"
Einstellung beim Ramtiming oder besseren Speicher braucht. Vermutlich
einfach weil es das Ram auch benutzt und DOS nicht so merkt wenn da
mal ein Bit irgendwo kippt.

Olaf

[Christian Corti]

Post by olaf

Post by Dennis Grevenstein
Kann das sein, dass DOS grosszügiger mit der Hardware umgehen
kann als Linux?

Ja, es war damals allgemeinwissen das Linux "vernuenftigere"
Einstellung beim Ramtiming oder besseren Speicher braucht. Vermutlich
einfach weil es das Ram auch benutzt und DOS nicht so merkt wenn da
mal ein Bit irgendwo kippt.

Vor allem nutzt Linux den Speicher auch "von hinten", sprich belegt
gleich auch den oberen Speicherbereich. Unter DOS kommt man sehr selten an das
Ende des Speichers, die Belegung erfolgt linear.

Christian

[Guido Grohmann]

Post by Dennis Grevenstein
Hallo,
Kann das sein, dass DOS grosszügiger mit der Hardware umgehen
kann als Linux?

Ich hatte mal einen PC mit Windows 98 und SuSe 7. Den hab ich auf 64 MB
RAM hochgerüstet, Windows lief damit, von gelegentliche Abstürzen,die
seinerzeit als normal angesehen wurden abgesehen. Linux beendete den
Bootptozeß auf identischer Hardware mit einer Kernel-Panic (Aieeeeee
killing Interrupt handlsers oder so ähnlich). Der Rückbau auf 32 MB
erbrachte wieder ein funktionsfähiges Linux, während sich bei WIn 98
nicht viel geändert hatte.

Guido

[Dennis Grevenstein]

Post by Guido Grohmann
Ich hatte mal einen PC mit Windows 98 und SuSe 7. Den hab ich auf 64 MB
RAM hochgerüstet, Windows lief damit, von gelegentliche Abstürzen,die
seinerzeit als normal angesehen wurden abgesehen. Linux beendete den
Bootptozeß auf identischer Hardware mit einer Kernel-Panic (Aieeeeee
killing Interrupt handlsers oder so ähnlich). Der Rückbau auf 32 MB
erbrachte wieder ein funktionsfähiges Linux, während sich bei WIn 98
nicht viel geändert hatte.

Ich antworte mal hier, weil das so am ehesten passt.
Als ich heute morgen wieder zu dem 386 bin, habe ich gesehen,
dass die Kiste heute nacht wieder einen Segmentation fault
gebracht hat. Das gcc make bootstrap ist in stage2 stehen
geblieben. Das ist schonmal ein Fortschritt, aber vielleicht
ist doch was mit dem RAM nicht in Ordnung. Ich habe 32MB
mit parity drin. Ich habe mal gesucht, aber keine Version
von memtest86 gefunden, die ich auf Floppy packen konnte
und die auch funkioniert. Hat hier jemand etwas, das bekannt
von Floppy funktioniert?

gruss,
Dennis

[Hartmut Scholz]

Post by Dennis Grevenstein

[...] > Ich habe mal gesucht, aber keine Version

von memtest86 gefunden, die ich auf Floppy packen konnte
und die auch funkioniert. Hat hier jemand etwas, das bekannt
von Floppy funktioniert?

https://www.memtest86.com/download.htm

weiter unten : Older versions

[Dennis Grevenstein]

Post by Hartmut Scholz
https://www.memtest86.com/download.htm
weiter unten : Older versions

Habe ich ausprobiert. Geht nicht.
Das DOS Programm hängt bzw. die Floppy bootet nicht.

Deswegen die Frage, ob irgendjemand hier was passendes hat,
wo bekannt ist, dass es funktioniert.

gruss,
Dennis

[Hanno Foest]

Post by Dennis Grevenstein
Das ist schonmal ein Fortschritt, aber vielleicht
ist doch was mit dem RAM nicht in Ordnung. Ich habe 32MB
mit parity drin.

Wird das parity richtig ausgewertet?

Post by Dennis Grevenstein
Ich habe mal gesucht, aber keine Version
von memtest86 gefunden, die ich auf Floppy packen konnte
und die auch funkioniert.

Es muß nicht unbedingt das RAM sein. Ich hatte weiland einen Coppermine
Celeron 533 mit 66 MHz FSB, den ich auf 100 MHz übertaktet hatte, was
einem P3 800 entsprach, auf einem Asus P3B-F mit ECC RAM. Allgemeines
Verständnis war damals, daß das ohne Probleme ginge (ich bin wenig
risikofreudig, was meine Daten angeht). Ich hatte trotzdem Bitfehler -
vermutlich sind die auf dem Bus zwischen Proz und Speichercontroller
entstanden.

Hanno

[Marcel Mueller]

Post by Dennis Grevenstein
Jedenfalls habe ich dabei festgestellt, dass Linux offenbar
sensibler mit der Hardware umgeht als DOS. Der 40MHz DX lief
prima mit DOS. Spiele und Kram ging immer alles ohne Problem.
Aber unter Linux gab es gerne mal seltsame Fehler, Signal 11,
usw. Jetzt habe ich heute mal die BIOS Einstellungen komplett
auf default gestellt, was den RAM mit 2 WS laufen lässt und den
ISA bus schön niedrig taktet. Jetzt läuft es offenbar stabil.
Die box compiliert seit 3 Stunden gcc ohne Fehler.

Das ist ein alter Hut. Matschige Hardware läuft unter DOS of trotzdem
noch, das es die Funktionseinheiten gar nicht wirklich auslasten kann.
Sobald man aber OS/2 Linux oder NT-Kernel darauf laufen lässt, trennt
sich die Spreu vom Weizen.

Post by Dennis Grevenstein
Kann das sein, dass DOS grosszügiger mit der Hardware umgehen
kann als Linux?

Jein, es benutzt vieles einfach nicht. Und wenn das dann kaputt ist, ist
das egal. In deinem Fall dürfte es Probleme mit DMA gegeben haben. Das
benutzt DOS nur für die Floppy und auch das nicht gleichzeitig zu
anderen Speicherzugriffen..


Marcel

[Chr. Maercker]

Post by Marcel Mueller
Das ist ein alter Hut. Matschige Hardware läuft unter DOS of trotzdem
noch, das es die Funktionseinheiten gar nicht wirklich auslasten kann.
Sobald man aber OS/2 Linux oder NT-Kernel darauf laufen lässt, trennt
sich die Spreu vom Weizen.

Wie sieht das aus, wenn DOS mit extended Memory arbeitet, i.a. per
EMM386.exe? Novells Client32 braucht z.B. mehr (extended) menory als das
gesamte übrige System. Trotzdem funktionierte DOS/Win3 ausgerechnet
damit weitaus stabiler als mit dem ganzen NDIS2-Gedöns. Aber OK,
fehlerhfater Speicher sollte schon damals die Ausnahme von der Regel
gewesen sein, während die Macken von NDIS2 ständiger Belgeiter waren.

Post by Marcel Mueller
Jein, es benutzt vieles einfach nicht. Und wenn das dann kaputt ist, ist
das egal. In deinem Fall dürfte es Probleme mit DMA gegeben haben. Das
benutzt DOS nur für die Floppy und auch das nicht gleichzeitig zu
anderen Speicherzugriffen..

Es gab auch NICs, die DMA gemacht haben, z.B. von BICC. Die
funktionierten in der Tat nicht mit jeder Hardware zuverlässig.

[Marcel Mueller]

Post by Chr. Maercker

Post by Marcel Mueller
Das ist ein alter Hut. Matschige Hardware läuft unter DOS of trotzdem
noch, das es die Funktionseinheiten gar nicht wirklich auslasten kann.
Sobald man aber OS/2 Linux oder NT-Kernel darauf laufen lässt, trennt
sich die Spreu vom Weizen.

Wie sieht das aus, wenn DOS mit extended Memory arbeitet, i.a. per
EMM386.exe?

Ein wenig schlechter. Aber solange niemand EMS anfordert, passiert da
auch nicht viel.

Post by Chr. Maercker
Novells Client32 braucht z.B. mehr (extended) menory als das
gesamte übrige System.

XMS oder EMS?

Post by Chr. Maercker
Trotzdem funktionierte DOS/Win3 ausgerechnet
damit weitaus stabiler als mit dem ganzen NDIS2-Gedöns. Aber OK,
fehlerhfater Speicher sollte schon damals die Ausnahme von der Regel
gewesen sein, während die Macken von NDIS2 ständiger Belgeiter waren.

Damals hatte noch jeder Rechner Partity Check. Da gab es keine unbemerkt
defekten RAMs.

Post by Chr. Maercker

Post by Marcel Mueller
Jein, es benutzt vieles einfach nicht. Und wenn das dann kaputt ist, ist
das egal. In deinem Fall dürfte es Probleme mit DMA gegeben haben. Das
benutzt DOS nur für die Floppy und auch das nicht gleichzeitig zu
anderen Speicherzugriffen..

Es gab auch NICs, die DMA gemacht haben, z.B. von BICC. Die
funktionierten in der Tat nicht mit jeder Hardware zuverlässig.

Ack.


Marcel

[Chr. Maercker]

Post by Marcel Mueller
Ein wenig schlechter. Aber solange niemand EMS anfordert, passiert da
auch nicht viel.

Post by Chr. Maercker
Novells Client32 braucht z.B. mehr (extended) menory als das
gesamte übrige System.

XMS oder EMS?

WIMRE muss EMM836 & Co. ausdrücklich gesagt werden, wenn XMS
bereitgestellt werden soll. Eine entpsrechende Option wurde auf unseren
PCs seltenst eingetragen. Deswegen gehe ich von EMS aus.

Post by Marcel Mueller

Post by Chr. Maercker
Trotzdem funktionierte DOS/Win3 ausgerechnet
damit weitaus stabiler als mit dem ganzen NDIS2-Gedöns. Aber OK,
fehlerhfater Speicher sollte schon damals die Ausnahme von der Regel
gewesen sein, während die Macken von NDIS2 ständiger Belgeiter waren.

Damals hatte noch jeder Rechner Partity Check. Da gab es keine unbemerkt
defekten RAMs.

Jetzt, wo Du's schreibst, ja. ;-)

[Gerrit Heitsch]

Post by Chr. Maercker

Post by Marcel Mueller
Ein wenig schlechter. Aber solange niemand EMS anfordert, passiert da
auch nicht viel.

Post by Chr. Maercker
Novells Client32 braucht z.B. mehr (extended) menory als das
gesamte übrige System.

XMS oder EMS?

WIMRE muss EMM836 & Co. ausdrücklich gesagt werden, wenn XMS
bereitgestellt werden soll. Eine entpsrechende Option wurde auf unseren
PCs seltenst eingetragen. Deswegen gehe ich von EMS aus.

Post by Marcel Mueller

Post by Chr. Maercker
Trotzdem funktionierte DOS/Win3 ausgerechnet
damit weitaus stabiler als mit dem ganzen NDIS2-Gedöns. Aber OK,
fehlerhfater Speicher sollte schon damals die Ausnahme von der Regel
gewesen sein, während die Macken von NDIS2 ständiger Belgeiter waren.

Damals hatte noch jeder Rechner Partity Check. Da gab es keine unbemerkt
defekten RAMs.

Jetzt, wo Du's schreibst, ja. ;-)

Es sei denn, es sind 2 Bits defekt.

Gerrit

[Kay Martinen]

Post by Chr. Maercker

Post by Marcel Mueller
XMS oder EMS?

WIMRE muss EMM836 & Co. ausdrücklich gesagt werden, wenn XMS
bereitgestellt werden soll. Eine entpsrechende Option wurde auf unseren
PCs seltenst eingetragen. Deswegen gehe ich von EMS aus.

Vorsicht, nicht verwechseln. Extended Memory läuft über den EMM386.EXE
aber EMS über himem.sys dafür aber auch auf CPUs kleiner als 286.

Das wervechselst du gerade, es ist genau umgekehrt. EMM386.EXE emuliert
expanded memory (EMS) ab 80386, HIMEM.SYS ist für den Zugriff auf
extended memory (XMS) ab 80286 nötig also Speicher jenseits von 1 MB.
https://de.wikipedia.org/wiki/Expanded_Memory_Specification
https://de.wikipedia.org/wiki/Extended_Memory_Specification

Lies nochmal. Denn ich habe das DORT genau so gelesen wie ich es schrieb.

Gleichwohl hab ich früher eigentlich immer beide treiber geladen, DOS in
die HMA geladen und Treiber möglichst in UMBs. Mir ist das also nie
wirklich aufgefallen, ich weiß aber das EMS der Standard ist bei dem
Speicherseiten unter 1 MB eingeblendet werden - was wenig performant
erscheint.


Kay

[Gerald E:scher]

Post by Kay Martinen

Vorsicht, nicht verwechseln. Extended Memory läuft über den EMM386.EXE
aber EMS über himem.sys dafür aber auch auf CPUs kleiner als 286.

Das wervechselst du gerade, es ist genau umgekehrt. EMM386.EXE emuliert
expanded memory (EMS) ab 80386, HIMEM.SYS ist für den Zugriff auf
extended memory (XMS) ab 80286 nötig also Speicher jenseits von 1 MB.
https://de.wikipedia.org/wiki/Expanded_Memory_Specification
https://de.wikipedia.org/wiki/Extended_Memory_Specification

Lies nochmal.

Nicht nötig, ich weiß ja Bescheid. Die allwissende Müllhalde habe ich
verlinkt, weil ich nicht selber formulieren wollte :-)

Post by Kay Martinen
Gleichwohl hab ich früher eigentlich immer beide treiber geladen, DOS in
die HMA geladen und Treiber möglichst in UMBs. Mir ist das also nie
wirklich aufgefallen, ich weiß aber das EMS der Standard ist bei dem
Speicherseiten unter 1 MB eingeblendet werden - was wenig performant
erscheint.

Ja. Wurde wohl aus Gründen der Kompatibilität so gemacht.
Sowwohl für UMBs als auch EMS ist der EMM386.EXE zuständig.

[Marcel Mueller]

Post by Gerrit Heitsch

Post by Chr. Maercker

Post by Marcel Mueller

Post by Chr. Maercker
fehlerhfater Speicher sollte schon damals die Ausnahme von der Regel

Damals hatte noch jeder Rechner Partity Check. Da gab es keine unbemerkt
defekten RAMs.

Jetzt, wo Du's schreibst, ja. ;-)

Nah! Damals (TM) hatte noch jeder Rechner einen Speichertest der beim
Einschalten das RAM hoch zählt. Ob der aber wirklich konsequent jedes
Byte/word mit nullen und Einsen beschrieb und gegenlas möchte ich
bezweifeln.

Schwer zu sagen. Aber Speicher mit Prüfsumme, egal welche, *muss
initialisiert werden*, sonst steht die Kiste ein paar Sekunden später
mit "Parity error, system halted".

Und oft konnte man ihn auch abstellen weil das hochtickern
von mehr als 2 MB auf lahmen rechnern das Booten deutlich ausbremste.

Ja, dann hat er aber trotzdem noch hoch gezählt, nur eben viel
schneller. Das spricht dafür, dass doch etwas getestet wurde und nunmehr
nur der Init lief.

Einen "Parity Check" erkenne ich darin nicht. Dazu brauchte es 9 statt 8
Bits in jedem Speichermodul und eine Logik auf der Hauptplatine die das
Parity-Bit setzte, las und prüfte. Und das hatte gewiss nicht jedes Board.

Alle DIMM-Module hatten 9 Bit. Ich habe noch nie eines mit 8 gesehen.
Erst mit den PCI-Rechnern kamen die billigeren 8-Bit Chips in Mode.
Mein 486er mit VLB hatte auch noch 9 Bit pro Modul.

Post by Gerrit Heitsch
Es sei denn, es sind 2 Bits defekt.

Dafür gab es dann ECC RAM u.a. :-)

ECC war seinerzeit nicht üblich. Aber wenn zwei Bits defekt sind, knallt
es bei Parity trotzdem, nur halt statistisch gesehen nur noch jedes
zweite mal. Aber lange überlebt die Kiste damit nicht.


Marcel

[Nils M Holm]

Vorsicht, nicht verwechseln. Extended Memory l?uft ?ber den EMM386.EXE
aber EMS ?ber himem.sys daf?r aber auch auf CPUs kleiner als 286.

Auf dem 8086/80186 wird das schwierig mit nur 20 Addressleitungen.

[Kay Martinen]

Post by Nils M Holm

Vorsicht, nicht verwechseln. Extended Memory l?uft ?ber den EMM386.EXE
aber EMS ?ber himem.sys daf?r aber auch auf CPUs kleiner als 286.

Auf dem 8086/80186 wird das schwierig mit nur 20 Addressleitungen.

Oh, stimmt. Die A20-Gate Falle. Die diese CPUs noch nicht hatten aber
verursachten. Ich hab den Text unter

<https://de.wikipedia.org/wiki/Expanded_Memory_Specification>

nicht richtig gelesen. Blöde Formulierung "war für PC auf Basis von
8086, 80186, ggf auch 286 gedacht"

Kay

[Nils M Holm]

Post by Kay Martinen

Post by Nils M Holm
Auf dem 8086/80186 wird das schwierig mit nur 20 Addressleitungen.

Oh, stimmt. Die A20-Gate Falle. Die diese CPUs noch nicht hatten aber
verursachten. Ich hab den Text unter
<https://de.wikipedia.org/wiki/Expanded_Memory_Specification>

Du verwechselst da, glaube ich, was. EMS geht auch ohne A20, da die
Seiten in den 20-bit Addressraum eingeblendet werden. Was Du meinst,
ist HMA: https://en.wikipedia.org/wiki/High_Memory_Area

[Christian Corti]

Vorsicht, nicht verwechseln. Extended Memory läuft über den EMM386.EXE
aber EMS über himem.sys dafür aber auch auf CPUs kleiner als 286. Bei
mehr als 1MB Hauptspeicher gibt es auch keine löcher im Unteren
Adressraum in die EMS normalerweise seinen Seitenspeicher einblendet und

Da hast du einiges durcheinandergebracht ;-)
1. Extended Memory (XMS) braucht HIMEM.SYS (und evtl. einen
hardwarespezifischen Treiber wie für das Intel AboveBoard/2)
2. Expanded Memory (EMS) braucht EMM386.EXE (>=i386) oder einen
hardwarespezifischen Treiber (grundsätzlich bei <=i286!)
3. Kisten mit z.B. 1MB Speicher haben oft 640kB ab Adresse 0, und die
restlichen 384kB ab 1MB eingeblendet (beim PS/2 war das zumindest so)

Einen "Parity Check" erkenne ich darin nicht. Dazu brauchte es 9 statt 8
Bits in jedem Speichermodul und eine Logik auf der Hauptplatine die das
Parity-Bit setzte, las und prüfte. Und das hatte gewiss nicht jedes Board.

War standard bis so in die 386er-Ära hinein.

Christian

[Chr. Maercker]

Vorsicht, nicht verwechseln. Extended Memory läuft über den EMM386.EXE
aber EMS über himem.sys dafür aber auch auf CPUs kleiner als 286.

Es bedarf sowohl HIMEM.SYS als auch EMM386, um auch nur ein Bit mittels
LH (bzw. NIOS, im Fall Client32) über die 1MB-Grenze zu bekommen.
Betrifft aber mögicherweise nur MS-DOS, siehe unten.

Bei mehr als 1MB Hauptspeicher gibt es auch keine löcher im Unteren
Adressraum in die EMS normalerweise seinen Seitenspeicher einblendet und
ist damit eigentlich schon sinnlos. Es sei denn man hat Programme die
XMS nicht können/kennen.

Deswegen ja, allein schon der Client32.nlm war so fett, der hätte nie in
irknwelche Mini-Lücken unterhalb 1MB gepasst. Und es kamen diverse
weitere NLMs sowie der LAN-Driver hinzu.

Und AFAIR wurde für DOS=HIGH,UMB der himem.sys auch gebraucht.

ACK, aber stets zusammen mit EMM386.EXE etc. Ohne funktionierte Loadhigh
unter MS-DOS nicht. Evtl. aber bei einigen DR-DOS-Derivaten.

Post by Gerrit Heitsch

Post by Chr. Maercker

Post by Marcel Mueller
Damals hatte noch jeder Rechner Partity Check. Da gab es keine unbemerkt
defekten RAMs.

Jetzt, wo Du's schreibst, ja. ;-)

Nah! Damals (TM) hatte noch jeder Rechner einen Speichertest der beim
Einschalten das RAM hoch zählt. Ob der aber wirklich konsequent jedes
Byte/word mit nullen und Einsen beschrieb und gegenlas möchte ich
bezweifeln. Und oft konnte man ihn auch abstellen weil das hochtickern
von mehr als 2 MB auf lahmen rechnern das Booten deutlich ausbremste.

Viele BIOSs hatten eine Fast-Boot-Option. War die nicht dazu gedacht,
den RAM-Test entweder ganz zu überspringen oder auf einen Schnelltest zu
beschränken? Jedenfalls booteten viele PCs mit aktivem Fast-Boot
merklich schneller.

Einen "Parity Check" erkenne ich darin nicht. Dazu brauchte es 9 statt 8
Bits in jedem Speichermodul und eine Logik auf der Hauptplatine die das
Parity-Bit setzte, las und prüfte. Und das hatte gewiss nicht jedes Board.

Post by Gerrit Heitsch
Es sei denn, es sind 2 Bits defekt.

Dafür gab es dann ECC RAM u.a. :-)

Für Server und evtl. eine Handvoll High-End-PCs, versteht sich.

[Chr. Maercker]

Das wervechselst du gerade, es ist genau umgekehrt. EMM386.EXE emuliert
expanded memory (EMS) ab 80386, HIMEM.SYS ist für den Zugriff auf
extended memory (XMS) ab 80286 nötig also Speicher jenseits von 1 MB.
https://de.wikipedia.org/wiki/Expanded_Memory_Specification
https://de.wikipedia.org/wiki/Extended_Memory_Specificatio

Microsoft hat das offenbar nicht so streng getrennt. Um residendes
Gedöns oberhalb von 1MByte laden zu können, mussten bei MS-DOS
grundsätzlich diese drei Zeilen in der CONFIG.SYS stehen:
DEVICE = C:\DOS\HIMEM.SYS
DEVICE = C:\DOS\EMM386.EXE NOEMS [/V]
DOS = UMB,HIGH
NOEMS bedeutet, es wird XMS genutzt. Unter DR-DOS und Nachf. genügte
WIMRE HIMEM.SYS allein.

[Christian Corti]

Post by Chr. Maercker
DEVICE = C:\DOS\EMM386.EXE NOEMS [/V]

Eben nicht unbedingt, weil das auf einem 286er nicht läuft. Ich hatte
aber durchauch HIGH und UMB! Man brauchte dafür aber das Tool QRAM.

Christian

[Chr. Maercker]

Post by Christian Corti

Post by Chr. Maercker
DEVICE = C:\DOS\EMM386.EXE NOEMS [/V]

Eben nicht unbedingt, weil das auf einem 286er nicht läuft. Ich hatte
aber durchauch HIGH und UMB! Man brauchte dafür aber das Tool QRAM.

Die Vorläufer vom EMM habe ich nicht besonders stabil in Erinnerung.
Irgendwas in der Art hatten wir kurzzeitig getestet bzw. benutzt. Mit
Aufkommen der 386er und DOS5 verschwand das Zeug umgehend in der Versenkung.

BTW: in .de Ost waren 286er nicht allzu lange im Einsatz und wenn, dann
i.a. ohne EMS/XMS. Das lag daran, dass in es der DDR ab 1987 nur einige
XTs gab und ab 1990 bald erschwinliche 386er.

[Gerald E:scher]

Post by Chr. Maercker

Das wervechselst du gerade, es ist genau umgekehrt. EMM386.EXE emuliert
expanded memory (EMS) ab 80386, HIMEM.SYS ist für den Zugriff auf
extended memory (XMS) ab 80286 nötig also Speicher jenseits von 1 MB.
https://de.wikipedia.org/wiki/Expanded_Memory_Specification
https://de.wikipedia.org/wiki/Extended_Memory_Specificatio

Microsoft hat das offenbar nicht so streng getrennt.

Was meinst du mit "nicht streng getrennt"? HIMEM.SYS und EMM386.EXE
erfüllen andere Aufgaben.

Post by Chr. Maercker
Um residendes
Gedöns oberhalb von 1MByte laden zu können, mussten bei MS-DOS
DEVICE = C:\DOS\HIMEM.SYS
DEVICE = C:\DOS\EMM386.EXE NOEMS [/V]

HIMEM.SYS ist, jedenfalls bei M$-DOS, Voraussetzung für den EMM386.EXE,
der XMS-Speicher benötigt.

Post by Chr. Maercker
DOS = UMB,HIGH
NOEMS bedeutet, es wird XMS genutzt.

NOEMS bedeutet, es wird kein EMS-Speicher emuliert, das Speicherfenster
zum Einblenden bleibt frei und kann für UMB genutzt werden. Ein DOS
Anwendungsprogramm, dass sowohl XMS als auch EMS verwenden kann, wird
dann zwangsläufig XMS nutzen.

[Chr. Maercker]

Post by Gerald E:scher
Was meinst du mit "nicht streng getrennt"? HIMEM.SYS und EMM386.EXE
erfüllen andere Aufgaben.

Gemeint ist, bei MSDOS müssen *beide* laufen, um XMS mittels LH o.ä.
nutzen zu können.

Post by Gerald E:scher

Post by Chr. Maercker
Um residendes
Gedöns oberhalb von 1MByte laden zu können, mussten bei MS-DOS
DEVICE = C:\DOS\HIMEM.SYS
DEVICE = C:\DOS\EMM386.EXE NOEMS [/V]

HIMEM.SYS ist, jedenfalls bei M$-DOS, Voraussetzung für den EMM386.EXE,
der XMS-Speicher benötigt.

Richtig. Wobei EMM386 den XMS kaum selbst braucht, sondern für andere
Software freigibt.

Post by Gerald E:scher

Post by Chr. Maercker
DOS = UMB,HIGH
NOEMS bedeutet, es wird XMS genutzt.

NOEMS bedeutet, es wird kein EMS-Speicher emuliert, das Speicherfenster
zum Einblenden bleibt frei und kann für UMB genutzt werden. Ein DOS
Anwendungsprogramm, dass sowohl XMS als auch EMS verwenden kann, wird
dann zwangsläufig XMS nutzen.

Die DOS-eigenen TSRs haben sich mit LH Richtung XMS verkrümelt, mit EMS
konnten die nix anfangen. Dito Client32 u.v.a.

[Gerald E:scher]

Post by Chr. Maercker

Post by Gerald E:scher
Was meinst du mit "nicht streng getrennt"? HIMEM.SYS und EMM386.EXE
erfüllen andere Aufgaben.

Gemeint ist, bei MSDOS müssen *beide* laufen, um XMS mittels LH o.ä.
nutzen zu können.

Du schmeißt da etwas durcheinander. XMS ist erst einmal dazu da, dass
datenintensive Programme mehr Speicher als nur innerhalb der 640 kB
nutzen können.

EMM386.EXE nutzt XMS-Speicher um
a) EMS zu emulieren und
b) TSRs mittels LH in UMBs laden zu können, die sich dann
zwar physikalisch in XMS-Speicher befinden, selbst aber davon nichts
mitbekommen

Post by Chr. Maercker

Post by Gerald E:scher

Post by Chr. Maercker
Um residendes
Gedöns oberhalb von 1MByte laden zu können, mussten bei MS-DOS
DEVICE = C:\DOS\HIMEM.SYS
DEVICE = C:\DOS\EMM386.EXE NOEMS [/V]

HIMEM.SYS ist, jedenfalls bei M$-DOS, Voraussetzung für den EMM386.EXE,
der XMS-Speicher benötigt.

Richtig. Wobei EMM386 den XMS kaum selbst braucht, sondern für andere
Software freigibt.

XMS ist ein Standard und XMS-Speicher wird vom HIMEM.SYS verwaltet! Je
nach Größe eines EMS-Speiches kann der EMM386.EXE den gesamten
XMS-Speicher verbrauchen.

Post by Chr. Maercker

Post by Gerald E:scher
NOEMS bedeutet, es wird kein EMS-Speicher emuliert, das Speicherfenster
zum Einblenden bleibt frei und kann für UMB genutzt werden. Ein DOS
Anwendungsprogramm, dass sowohl XMS als auch EMS verwenden kann, wird
dann zwangsläufig XMS nutzen.

Die DOS-eigenen TSRs haben sich mit LH Richtung XMS verkrümelt,

Nein, haben sie nicht, die haben von XMS (ein Standard!) keine Ahnung.

Post by Chr. Maercker
mit EMS konnten die nix anfangen.

Prinzipiell könnte ein mit LH hochgeladenes Programm durchaus
EMS-Speicher nutzen.
Irgendwie habe ich den Eindruck, dass du den Sinn und Zweck von XMS- und
EMS-Speicher nicht verstanden hast, sondern hast nur seinerzeit lustig
mit LH TSRs hochgeladen.

[Chr. Maercker]

Post by Gerald E:scher

Post by Chr. Maercker
Gemeint ist, bei MSDOS müssen *beide* laufen, um XMS mittels LH o.ä.
nutzen zu können.

Du schmeißt da etwas durcheinander. XMS ist erst einmal dazu da, dass
datenintensive Programme mehr Speicher als nur innerhalb der 640 kB
nutzen können.

Klar doch. Aber versuche mal, ohne EMM TSRs aus dem 640k-Bereich raus zu
bekommen.

Post by Gerald E:scher
EMM386.EXE nutzt XMS-Speicher um
a) EMS zu emulieren und
b) TSRs mittels LH in UMBs laden zu können, die sich dann
zwar physikalisch in XMS-Speicher befinden, selbst aber davon nichts
mitbekommen

Ob sie das mitkriegen oder dank Adressumsetzung nicht ist relativ egal,
entscheidend ist, wo sie Speicherplatz belegen.

Post by Gerald E:scher

Post by Chr. Maercker

Post by Gerald E:scher

Post by Chr. Maercker
Um residendes
Gedöns oberhalb von 1MByte laden zu können, mussten bei MS-DOS
DEVICE = C:\DOS\HIMEM.SYS
DEVICE = C:\DOS\EMM386.EXE NOEMS [/V]

HIMEM.SYS ist, jedenfalls bei M$-DOS, Voraussetzung für den EMM386.EXE,
der XMS-Speicher benötigt.

Richtig. Wobei EMM386 den XMS kaum selbst braucht, sondern für andere
Software freigibt.

XMS ist ein Standard und XMS-Speicher wird vom HIMEM.SYS verwaltet! Je
nach Größe eines EMS-Speiches kann der EMM386.EXE den gesamten
XMS-Speicher verbrauchen.

Und was macht er damit anderes, als TSRs etc. rein zu lassen?

Post by Gerald E:scher

Post by Chr. Maercker

Post by Gerald E:scher
NOEMS bedeutet, es wird kein EMS-Speicher emuliert, das Speicherfenster
zum Einblenden bleibt frei und kann für UMB genutzt werden. Ein DOS
Anwendungsprogramm, dass sowohl XMS als auch EMS verwenden kann, wird
dann zwangsläufig XMS nutzen.

Die DOS-eigenen TSRs haben sich mit LH Richtung XMS verkrümelt,

Nein, haben sie nicht, die haben von XMS (ein Standard!) keine Ahnung.

Du schreibst selbst und richtig, dass sie sich *physikalisch* im XMS
befinden. Ob sie das "wissen" interessiert nicht. Im Falle Client32 ist
es aber wirklich so, dessen NLMs laufen *grundsätzlich* und nur jenseits
der 1MB-Grenze.

Post by Gerald E:scher

Post by Chr. Maercker
mit EMS konnten die nix anfangen.

Prinzipiell könnte ein mit LH hochgeladenes Programm durchaus
EMS-Speicher nutzen.
Irgendwie habe ich den Eindruck, dass du den Sinn und Zweck von XMS- und
EMS-Speicher nicht verstanden hast, sondern hast nur seinerzeit lustig
mit LH TSRs hochgeladen.

Den wenigen Quellen, die ich seinerzeit dazu gefunden habe, war nur
sinngemäß zu entnehmen, extended Memory wäre eine lineare Erweiterung
des Adressraums jenseits von 1 MByte, während expanded memory ein
RAM-Mapping für (ältere) Programme wäre, die das halt so benötigen.
Genutzt habe ich in der Tat nur XMS, um die 640k für DOS frei zu halten.
EMS-lastige Software hatten wir kaum im Einsatz. HIMEM.SYS habe ich
deshalb als den Driver verstanden, der RAM jenseits von 1MB allgemein
verwaltet und EMM386 als die Komponente, die ihn als XMS, EMS oder
sonstwas anbietet, inklusive UMBs.
Wirklich nachvollziehbar war mir die Unterscheidung XMS/EMS sowieso nie.
Es war halt ein historischer Zopf, verursacht durch eine
vorsintflutliche CPU, die nur 1MB adressieren konnte, statt 8..16MByte
wie Z8000 oder M68000. Ergo war nur interessant, möglichst viel von dem
ganzen TSR-Krempel loszuwerden, damit DOS überhaupt noch arbeiten
konnte. Egal wie.

[Christian Corti]

Post by Chr. Maercker
Klar doch. Aber versuche mal, ohne EMM TSRs aus dem 640k-Bereich raus zu
bekommen.

Funktioniert wunderbar, wie ich schon mehrfach schrieb. Man kann
nämlich auch unbenutzten RAM aus diesem Bereich verwenden (z.B.
$B000-B7FF). Oder man stopfte ein SRAM in den Sockel für das Boot-ROM
einer Netzwerkkarte und blendete den ROM-Bereich ein. Man konnte vieles
machen ;-)

Post by Chr. Maercker

Post by Gerald E:scher
XMS ist ein Standard und XMS-Speicher wird vom HIMEM.SYS verwaltet! Je
nach Größe eines EMS-Speiches kann der EMM386.EXE den gesamten
XMS-Speicher verbrauchen.

Und was macht er damit anderes, als TSRs etc. rein zu lassen?

EMM nach LIM-Standard bereitstellen auf Rechnern, die keine
EMM-Speicherkarte haben. Das ging ab 80836 aufwärts.

Post by Chr. Maercker
Den wenigen Quellen, die ich seinerzeit dazu gefunden habe, war nur
sinngemäß zu entnehmen, extended Memory wäre eine lineare Erweiterung
des Adressraums jenseits von 1 MByte, während expanded memory ein
RAM-Mapping für (ältere) Programme wäre, die das halt so benötigen.

Dann hast du das Prinzip von Expanded Memory nicht verstanden. Sinn war,
auf Rechnern mit begrenztem Adreßraum (sprich 8088 und Konsorten), mehr
Speicher zu verwalten als adressierbar war. Dazu blendete man ein
verschiebbares Fenster der Speicherkarte (theoretisch beliebig groß, meist
hatten die ein paar MB) an eine feste Adresse im Adreßraum ein (z.B. bei
$D000-DFFF). Die Zugriffsmechanismen wurden zum Standard (LIM-EMS).

Post by Chr. Maercker
Genutzt habe ich in der Tat nur XMS, um die 640k für DOS frei zu halten.
EMS-lastige Software hatten wir kaum im Einsatz. HIMEM.SYS habe ich

DOS-Software konnte eher nichts mit XMS anfangen, aber EMS war (bei
größeren Programmpaketen) Pflicht.

Christian

[Chr. Maercker]

Post by Christian Corti

Post by Chr. Maercker
Klar doch. Aber versuche mal, ohne EMM TSRs aus dem 640k-Bereich raus zu
bekommen.

Funktioniert wunderbar, wie ich schon mehrfach schrieb. Man kann
nämlich auch unbenutzten RAM aus diesem Bereich verwenden (z.B.
$B000-B7FF). Oder man stopfte ein SRAM in den Sockel für das Boot-ROM
einer Netzwerkkarte und blendete den ROM-Bereich ein. Man konnte vieles
machen ;-)

Vorausgesetzt, in den UMBs ist wirklich RAM vorhanden und wird nicht nur
(von EMM386) dorthin gemappt. Unter dieser Voraussetzung müsste es sogar
ohne HIMEM.SYS gehen. Diese Voraussetzung hatten wir allerdings nie.

Post by Christian Corti

Post by Chr. Maercker

Post by Gerald E:scher
XMS ist ein Standard und XMS-Speicher wird vom HIMEM.SYS verwaltet! Je
nach Größe eines EMS-Speiches kann der EMM386.EXE den gesamten
XMS-Speicher verbrauchen.

Und was macht er damit anderes, als TSRs etc. rein zu lassen?

EMM nach LIM-Standard bereitstellen auf Rechnern, die keine
EMM-Speicherkarte haben. Das ging ab 80836 aufwärts.

Das war EMS, kein XMS. Für Programme gedacht, die das brauchten und die
Du weiter unten erwähnst.

Post by Christian Corti

Post by Chr. Maercker
Den wenigen Quellen, die ich seinerzeit dazu gefunden habe, war nur
sinngemäß zu entnehmen, extended Memory wäre eine lineare Erweiterung
des Adressraums jenseits von 1 MByte, während expanded memory ein
RAM-Mapping für (ältere) Programme wäre, die das halt so benötigen.

Dann hast du das Prinzip von Expanded Memory nicht verstanden. Sinn war,
auf Rechnern mit begrenztem Adreßraum (sprich 8088 und Konsorten), mehr
Speicher zu verwalten als adressierbar war. Dazu blendete man ein
verschiebbares Fenster der Speicherkarte (theoretisch beliebig groß, meist
hatten die ein paar MB) an eine feste Adresse im Adreßraum ein (z.B. bei
$D000-DFFF). Die Zugriffsmechanismen wurden zum Standard (LIM-EMS).

EMS ist also (wie ich schon andeutete) klassisches Memory mapping:
Physikalischen RAM an anderen Adressen anzubieten als er sich
tatsächlich befindet.

Post by Christian Corti

Post by Chr. Maercker
Genutzt habe ich in der Tat nur XMS, um die 640k für DOS frei zu halten.
EMS-lastige Software hatten wir kaum im Einsatz. HIMEM.SYS habe ich

DOS-Software konnte eher nichts mit XMS anfangen,

Dann müssten die ganzen TSRs wirklich nur in den UMBs gelaufen sein.
Ziemlich eng das.

Post by Christian Corti
EMS war (bei größeren Programmpaketen) Pflicht.

Hatten wir zu der Zeit kaum im Einsatz.

[Gerald E:scher]

Post by Chr. Maercker

Post by Christian Corti
Funktioniert wunderbar, wie ich schon mehrfach schrieb. Man kann
nämlich auch unbenutzten RAM aus diesem Bereich verwenden (z.B.
$B000-B7FF). Oder man stopfte ein SRAM in den Sockel für das Boot-ROM
einer Netzwerkkarte und blendete den ROM-Bereich ein. Man konnte vieles
machen ;-)

Vorausgesetzt, in den UMBs ist wirklich RAM vorhanden und wird nicht nur
(von EMM386) dorthin gemappt.

Außer mit irgendwelchen Stunts ist in den UMBs kein für Programme
nutzbares RAM vorhanden[1], ohne EMM386.EXE geht es nicht.

Post by Chr. Maercker

Post by Christian Corti

Post by Chr. Maercker
Genutzt habe ich in der Tat nur XMS, um die 640k für DOS frei zu halten.
EMS-lastige Software hatten wir kaum im Einsatz. HIMEM.SYS habe ich

DOS-Software konnte eher nichts mit XMS anfangen,

Selbstverständlich gab es Software, die XMS-Speicher nutzte.

Post by Chr. Maercker
Dann müssten die ganzen TSRs wirklich nur in den UMBs gelaufen sein.
Ziemlich eng das.

Bitte lies endlich die entsprechenden Artikel in der allwissenden
Müllhalde, wie
https://de.wikipedia.org/wiki/Extended_Memory_Specification#Zugriffsverfahren

Programmen nach der XMS Spezifikation zur Verfügung gestellter Speicher
kann von diesen Programmen nur für Daten genutzt werden!
Der EMM386.EXE hat alledings den Prozessor in den Virtuel 8086 Mode
geschaltet und Speicherblöcke jenseits von 1 MB als UMBs unterhalb von
1 MB eingeblendet, wo dann TSRs laufen konnten.


[1] WIMRE wurde sogar Video-RAM als Datenspeicher missbraucht, aber
vorgesehen war das nicht.

[Christian Corti]

Post by Gerald E:scher
Außer mit irgendwelchen Stunts ist in den UMBs kein für Programme
nutzbares RAM vorhanden[1], ohne EMM386.EXE geht es nicht.

Liest du eigentlich, was ich schreibe?

Post by Gerald E:scher
Selbstverständlich gab es Software, die XMS-Speicher nutzte.

Klar, aber erst recht spät und nur als "Ausnahme", weil die dann auf
<80286 nicht mehr lief.

Post by Gerald E:scher
Der EMM386.EXE hat alledings den Prozessor in den Virtuel 8086 Mode
geschaltet und Speicherblöcke jenseits von 1 MB als UMBs unterhalb von
1 MB eingeblendet, wo dann TSRs laufen konnten.

Ja doch! Und wie ich nun x-mal geschrieben habe, funktioniert das nun
mal nur ab 386er aufwärts!

Christian

[Gerald E:scher]

Post by Christian Corti

Post by Gerald E:scher
Außer mit irgendwelchen Stunts ist in den UMBs kein für Programme
nutzbares RAM vorhanden[1], ohne EMM386.EXE geht es nicht.

Liest du eigentlich, was ich schreibe?

Liest *du* was ich schreibe :-? Video-RAM nutzen oder ein SRAM in den
EPROM-Sockel der NIC stopfen sind Stunts.
Wobei ich ich bei letzterem annehme, dass die NIC modifiziert werden
muss, sprich die Leitung MEMW vom ISA-Stecker ans SRAM anschließen.

[Chr. Maercker]

Post by Gerald E:scher
Bitte lies endlich die entsprechenden Artikel in der allwissenden
Müllhalde, wie
https://de.wikipedia.org/wiki/Extended_Memory_Specification#Zugriffsverfahren

Eher das hier:
https://de.wikipedia.org/wiki/Upper_Memory_Block

Post by Gerald E:scher
Der EMM386.EXE hat alledings den Prozessor in den Virtuel 8086 Mode
geschaltet und Speicherblöcke jenseits von 1 MB als UMBs unterhalb von
1 MB eingeblendet, wo dann TSRs laufen konnten.

konnten dazu mehrere verschiedene Seiten aus dem Bereich > 1MB in die
UMBs eingeblendet und umgeschaltet werden? Sonst wäre es wie gesagt für
so viele Driver und TSRs, wie da bisweilen hoch geladen wurden, zu eng
geworden.

[Gerald E:scher]

Post by Chr. Maercker

Post by Gerald E:scher
Der EMM386.EXE hat alledings den Prozessor in den Virtuel 8086 Mode
geschaltet und Speicherblöcke jenseits von 1 MB als UMBs unterhalb von
1 MB eingeblendet, wo dann TSRs laufen konnten.

konnten dazu mehrere verschiedene Seiten aus dem Bereich > 1MB in die
UMBs eingeblendet und umgeschaltet werden?

Im Protected Mode ab i386 ist der Speicher als 4 kB große Speicherseiten
organisiert, die können beliebig als UMB eingeblendet werden.

[Kay Martinen]

Post by Gerald E:scher

Post by Chr. Maercker

Post by Gerald E:scher
Der EMM386.EXE hat alledings den Prozessor in den Virtuel 8086 Mode
geschaltet und Speicherblöcke jenseits von 1 MB als UMBs unterhalb von
1 MB eingeblendet, wo dann TSRs laufen konnten.

konnten dazu mehrere verschiedene Seiten aus dem Bereich > 1MB in die
UMBs eingeblendet und umgeschaltet werden?

Im Protected Mode ab i386 ist der Speicher als 4 kB große Speicherseiten
organisiert, die können beliebig als UMB eingeblendet werden.

Über die Paging unit der CPU und darum funktioniert das auch erst ab 386.

Hmm, wäre damit nicht auch ein Swap-out wenig benutzen Codes in ein FILE
möglich gewesen - unter DOS?

Ich erinnere mich grad nicht ob das je umgesetzt wurde.


Kay

[Gerald E:scher]

Post by Kay Martinen

Post by Gerald E:scher
Im Protected Mode ab i386 ist der Speicher als 4 kB große Speicherseiten
organisiert, die können beliebig als UMB eingeblendet werden.

Über die Paging unit der CPU und darum funktioniert das auch erst ab 386.
Hmm, wäre damit nicht auch ein Swap-out wenig benutzen Codes in ein FILE
möglich gewesen - unter DOS?

Möglich wäre es wohl gewesen. Aber da DOS nur 1 MB + knapp 64 kB HMA
adressieren kann, nicht sinnvoll.
Es sei denn, du möchtest z.B. einen 386er mit 256 kB RAM und Swap-Space
;-)

Post by Kay Martinen
Ich erinnere mich grad nicht ob das je umgesetzt wurde.

Halte ich für sehr unwahrscheinlich, denn 386er hatten allesamt mehr als
640 kB RAM und damit war der für DOS adressierbare Speicher vollständig
vergeben.

[Stefan Reuther]

Post by Kay Martinen

Post by Gerald E:scher

Post by Chr. Maercker
konnten dazu mehrere verschiedene Seiten aus dem Bereich > 1MB in die
UMBs eingeblendet und umgeschaltet werden?

Im Protected Mode ab i386 ist der Speicher als 4 kB große Speicherseiten
organisiert, die können beliebig als UMB eingeblendet werden.

Über die Paging unit der CPU und darum funktioniert das auch erst ab 386.
Hmm, wäre damit nicht auch ein Swap-out wenig benutzen Codes in ein FILE
möglich gewesen - unter DOS?
Ich erinnere mich grad nicht ob das je umgesetzt wurde.

Dazu müsstest du etwas haben, was stattdessen den Speicher benutzen
möchte. Um die verschiedenen Speicherbenutzungsanwärter unterscheiden zu
können, brauchst du ein Unterscheidungskriterium. In DOS-Programmen hast
du sowas nicht - wie wölltest du zwischen dem Erstbenutzer des UMB (eben
ausgelagert) und dem Zweitbenutzer des UMB unterscheiden, wenn die beide
potenziell an irgendwelchen Interruptvektoren rumferkeln?

Wenn du einen 32-bit linearen Adressraum hast, ist das trivial und wurde
auch unter DOS umgesetzt (von Windows im Erweiterten Modus, oder von
Extendern wie CWSDPMI).

Wenn sich die Programme an gewisse Konventionen halten, kannst du das
auch umsetzen, brauchst dann aber keine Paging-Einheit mehr. Das wäre
Windows im Real- oder Standard-Modus, oder sowas wie Borlands Overlays.
Die haben dann Mechanismen, um z.B. Adressen umzuschreiben, die auf
gerade ausgelagerten Code zeigen.


Stefan

[Gerald E:scher]

Post by Chr. Maercker

Post by Gerald E:scher

Post by Chr. Maercker
Gemeint ist, bei MSDOS müssen *beide* laufen, um XMS mittels LH o.ä.
nutzen zu können.

Du schmeißt da etwas durcheinander. XMS ist erst einmal dazu da, dass
datenintensive Programme mehr Speicher als nur innerhalb der 640 kB
nutzen können.

Klar doch. Aber versuche mal, ohne EMM TSRs aus dem 640k-Bereich raus zu
bekommen.

XMS-Speicher existierte bereits beim 286er, bei dem TSRs hochladen
per EMM386.EXE nicht möglich war.

Post by Chr. Maercker

Post by Gerald E:scher
EMM386.EXE nutzt XMS-Speicher um
a) EMS zu emulieren und
b) TSRs mittels LH in UMBs laden zu können, die sich dann
zwar physikalisch in XMS-Speicher befinden, selbst aber davon nichts
mitbekommen

[...]

Post by Chr. Maercker

Post by Gerald E:scher

Post by Chr. Maercker
Richtig. Wobei EMM386 den XMS kaum selbst braucht, sondern für andere
Software freigibt.

XMS ist ein Standard und XMS-Speicher wird vom HIMEM.SYS verwaltet! Je
nach Größe eines EMS-Speiches kann der EMM386.EXE den gesamten
XMS-Speicher verbrauchen.

Und was macht er damit anderes, als TSRs etc. rein zu lassen?

EMS-Speicher emulieren, sofern man es nicht explizit abschaltet. Habe
ich doch oben geschrieben!

Post by Chr. Maercker

Post by Gerald E:scher

Post by Chr. Maercker
mit EMS konnten die nix anfangen.

Prinzipiell könnte ein mit LH hochgeladenes Programm durchaus
EMS-Speicher nutzen.
Irgendwie habe ich den Eindruck, dass du den Sinn und Zweck von XMS- und
EMS-Speicher nicht verstanden hast, sondern hast nur seinerzeit lustig
mit LH TSRs hochgeladen.

Den wenigen Quellen, die ich seinerzeit dazu gefunden habe, war nur
sinngemäß zu entnehmen, extended Memory wäre eine lineare Erweiterung
des Adressraums jenseits von 1 MByte, während expanded memory ein
RAM-Mapping für (ältere) Programme wäre, die das halt so benötigen.
Genutzt habe ich in der Tat nur XMS, um die 640k für DOS frei zu halten.
EMS-lastige Software hatten wir kaum im Einsatz. HIMEM.SYS habe ich
deshalb als den Driver verstanden, der RAM jenseits von 1MB allgemein
verwaltet und EMM386 als die Komponente, die ihn als XMS, EMS oder
sonstwas anbietet, inklusive UMBs.

Nochmals, XMS-Speicher wird vom HIMEM.SYS verwaltet, der EMM386.EXE
fordert XMS-Speicher vom HIMEM.SYS an. Andernfalls würde er mit
DOS-Programmen, die ebenfalls XMS-Speicher nutzen, in Konflikt geraten.

Post by Chr. Maercker
Wirklich nachvollziehbar war mir die Unterscheidung XMS/EMS sowieso nie.

Wenn man keine DOS-Programme, die EMS-Speicher verwendeten, hatte,
konnte es einem egal sein, sonst nicht.

Post by Chr. Maercker
Ergo war nur interessant, möglichst viel von dem
ganzen TSR-Krempel loszuwerden, damit DOS überhaupt noch arbeiten
konnte. Egal wie.

Hättest du halt OS/2 benutzt. In dessen DOS-Emulation werden gängige
Treiber wie für Maus, CD-ROM-Laufwerk, etc. durch virtuelle Treiber
ersetzt, die nicht in den von DOS genutzten Speicher geladen werden,
sodass massenhaft konventioneller Speicher frei bleibt.

Ansonsten konnte man zusätzliche UMBs gewinnen, indem man die
Speicherbereiche der Monochrom-Karte und des von DOS nicht
benötigten Teil des BIOSes inkludiert hat
("EMM386.EXE I=mmmm-nnnn ...").

[Christian Corti]

Post by Gerald E:scher
XMS-Speicher existierte bereits beim 286er, bei dem TSRs hochladen
per EMM386.EXE nicht möglich war.

Eben! Aber es gab andere Tools, die das konnten bzw. dem DOS es
ermöglichten.

Post by Gerald E:scher
Ansonsten konnte man zusätzliche UMBs gewinnen, indem man die
Speicherbereiche der Monochrom-Karte und des von DOS nicht
benötigten Teil des BIOSes inkludiert hat
("EMM386.EXE I=mmmm-nnnn ...").

Richtig, das war auch auf <386er mit QRAM möglich.

Christian

[Stefan Reuther]

Post by Chr. Maercker

Das wervechselst du gerade, es ist genau umgekehrt. EMM386.EXE emuliert
expanded memory (EMS) ab 80386, HIMEM.SYS ist für den Zugriff auf
extended memory (XMS) ab 80286 nötig also Speicher jenseits von 1 MB.
https://de.wikipedia.org/wiki/Expanded_Memory_Specification
https://de.wikipedia.org/wiki/Extended_Memory_Specificatio

Microsoft hat das offenbar nicht so streng getrennt. Um residendes
Gedöns oberhalb von 1MByte laden zu können, mussten bei MS-DOS
DEVICE = C:\DOS\HIMEM.SYS
DEVICE = C:\DOS\EMM386.EXE NOEMS [/V]
DOS = UMB,HIGH
NOEMS bedeutet, es wird XMS genutzt. Unter DR-DOS und Nachf. genügte
WIMRE HIMEM.SYS allein.

Das sind verschiedene Dinge.

HIMEM.SYS macht erstmal den Speicher über 1 MB zugreifbar. Damit hat man
HMA (1024-1088 kB) und XMS (>1088 kB).

EMM386.EXE nimmt dann einen Teil von dem XMS und macht daraus (optional)
EMS und UMB und braucht dazu einen 386er und Paging. UMB = RAM an einer
Stelle im ersten Megabyte wo sonst kein RAM ist, also z.B. 64k RAM
zwischen 768k und 832k. EMS = das gleiche, aber ein Anwendungsprogramm
kann den Ausschnitt bestimmen, der da eingeblendet wird, also z.B. die
ersten 64k von 256k insgesamt.

Für 'DOS=HIGH' braucht es nur HMA (von HIMEM), für 'DOS=UMB' und 'LH'
braucht es UMB (von EMM386). In den UMB kann man eigentlich jedes
Programm packen, was halbwegs sauber geschrieben ist, HMA (und XMS und
EMS) muss das Programm explizit unterstützen.


Stefan

[Chr. Maercker]

Post by Stefan Reuther
HIMEM.SYS macht erstmal den Speicher über 1 MB zugreifbar. Damit hat man
HMA (1024-1088 kB) und XMS (>1088 kB).
EMM386.EXE nimmt dann einen Teil von dem XMS und macht daraus (optional)
EMS und UMB und braucht dazu einen 386er und Paging. UMB = RAM an einer
Stelle im ersten Megabyte wo sonst kein RAM ist, also z.B. 64k RAM
zwischen 768k und 832k. EMS = das gleiche, aber ein Anwendungsprogramm
kann den Ausschnitt bestimmen, der da eingeblendet wird, also z.B. die
ersten 64k von 256k insgesamt.

AKC, so etwa habe ich die Funktion der beiden Komponenten verstanden.

Post by Stefan Reuther
Für 'DOS=HIGH' braucht es nur HMA (von HIMEM), für 'DOS=UMB' und 'LH'
braucht es UMB (von EMM386). In den UMB kann man eigentlich jedes
Programm packen, was halbwegs sauber geschrieben ist, HMA (und XMS und
EMS) muss das Programm explizit unterstützen.

Liefen mit LH gestartete TSRs wirklich alle nur in den UMBs? Weil das
in manchen Configs derart viele waren, dass die dort kaum alle Platz
gehabt hätten. Es mussten ja obendrein Bereiche für BIOS(e) und
Video-RAM ausgeklammert werden.
Der eingangs des Teilthreads genannte Client32 war über solche Probleme
sowieso erhaben, NIOS.EXE unterstützte XMS.

[Kay Martinen]

Post by Chr. Maercker

Post by Stefan Reuther
HIMEM.SYS macht erstmal den Speicher über 1 MB zugreifbar. Damit hat man
HMA (1024-1088 kB) und XMS (>1088 kB).
UMB = RAM an einer
Stelle im ersten Megabyte wo sonst kein RAM ist, also z.B. 64k RAM

Sagen wir so "an einer Stelle wo bei einem PC mit weniger als 1 MB RAM
kein Speicher ist" nur bei jenen die 1 MB oder mehr haben.

Post by Chr. Maercker

Post by Stefan Reuther
zwischen 768k und 832k. EMS = das gleiche, aber ein Anwendungsprogramm
kann den Ausschnitt bestimmen, der da eingeblendet wird, also z.B. die
ersten 64k von 256k insgesamt.

Das bedeutet m.E. aber außerdem das man in EMS kaum sinnvoll Programme
unterbringen kann - nur Daten. Denn das Speicherfenster liegt an einer
Adresse, sein Inhalt jedoch an einer anderen und der Inhalt kann
jederzeits ausgetauscht worden sein. Schlechte Voraussetzungen für jedes
Programm. Relozierbare Programme (also generell EXE und COM nicht
zwangsläufig) machen nur im XMS sinn. Und eben in UMBs außerhalb eines
EMS-Fensters, BIOS oder Video RAM.

Post by Chr. Maercker

Post by Stefan Reuther
Für 'DOS=HIGH' braucht es nur HMA (von HIMEM), für 'DOS=UMB' und 'LH'
braucht es UMB (von EMM386). In den UMB kann man eigentlich jedes
Programm packen, was halbwegs sauber geschrieben ist, HMA (und XMS und
EMS) muss das Programm explizit unterstützen.

Da das Speichermodell FLAT war, es im Realmode keinen Speicherschutz
o.a. gab und die CPU ja 1 MB Adressraum kannte muß das Programm nur
*NICHT* gewisse Annahmen treffen wo und wie es es seinen Code, Daten,
Stack erwartet. Der Rest wird AFAIR von command.com und DOS beim laden
erledigt -> Programm an adresse X relozieren.

Aber: DOS Programme damals waren m.E. nie "sauber" geschrieben. Da wurde
eher munter direkt in die BIOS Routinen gesprungen oder gleich direkt
VideoRAM oder I/O beschrieben - obwohl es für den I/O ja DOS-Routinen
gab. Ich sehe die Notwendigkeit HMA XMS oder EMS zu unterstützen eher
darin obige Sperenzchen sein zu lassen und alles über das DOS/BIOS
gespann ab zu wickeln.

Post by Chr. Maercker
Liefen mit LH gestartete TSRs wirklich alle nur in den UMBs? Weil das
in manchen Configs derart viele waren, dass die dort kaum alle Platz

It depends, meine ich. Früher hab ich viel damit experimentiert und
lange nicht alle Treiber/Programme die man mit DeviceHigh oder LoadHigh
geladen hatte landeten auch dort. Oft kam es; bei fragmentiertem UMB;
auch auf die Ladereihenfolge an. Damit ein kleines Programm in eine
kleine Lücke passte und das größere in die größere lücke dahinter.

IMHO ab DOS 6 gab's 'memmaker' als (leider dummes) tool das dies
automatisieren sollte. Mußte man aber nach jeder kleinen Konfig-änderung
erneut laufen und es die Startdateien umschreiben lassen. Einmal hat es
sie unbenutzbar gemacht und ich mußte per Floppy Booten. seitdem: nie
wieder memmaker!

Post by Chr. Maercker
gehabt hätten. Es mussten ja obendrein Bereiche für BIOS(e) und
Video-RAM ausgeklammert werden.

Hmm. Das laufende DOS weiß i.allg. wo es das BIOS mit den
Einsprungpunkten und sein Video RAM findet. Ich denke diese Bereiche
sind automatisch ausgeklammert. Lesen und Schreiben kann man sie
dennoch. ;-)

Post by Chr. Maercker
Der eingangs des Teilthreads genannte Client32 war über solche Probleme
sowieso erhaben, NIOS.EXE unterstützte XMS.

Irgendwann muß ich mich mal Spaßeshalber mit Novell Netware auf Server
und CLient befassen. Aber ich war schon erschrocken als ich las das ein
Novell Server im Realmode von einer DOS Partition startet und dann in
den Protected Mode und sein SYSVOL wechselt - oder so ähnlich. Schräges
Zeuchs. ;-) Damals (tm) bin ich bei Lantastic geblieben, später bei
NETBEUI und erst dann zu TCPBEUI und IP gewechselt. IPX kenne ich nur
aus wenigen damaligen Spielen die es unterstützten (was mir mangels Netz
nichts brachte).


Kay

[Stefan Reuther]

Post by Kay Martinen

Post by Chr. Maercker

Post by Stefan Reuther
HIMEM.SYS macht erstmal den Speicher über 1 MB zugreifbar. Damit hat man
HMA (1024-1088 kB) und XMS (>1088 kB).
UMB = RAM an einer
Stelle im ersten Megabyte wo sonst kein RAM ist, also z.B. 64k RAM

Sagen wir so "an einer Stelle wo bei einem PC mit weniger als 1 MB RAM
kein Speicher ist" nur bei jenen die 1 MB oder mehr haben.

Post by Chr. Maercker

Post by Stefan Reuther
zwischen 768k und 832k. EMS = das gleiche, aber ein Anwendungsprogramm
kann den Ausschnitt bestimmen, der da eingeblendet wird, also z.B. die
ersten 64k von 256k insgesamt.

Das bedeutet m.E. aber außerdem das man in EMS kaum sinnvoll Programme
unterbringen kann - nur Daten. Denn das Speicherfenster liegt an einer
Adresse, sein Inhalt jedoch an einer anderen und der Inhalt kann
jederzeits ausgetauscht worden sein.

Korrekt. Aber es gibt ja nix, was es in Software nicht gibt: Turbo
Pascal konnte in den EMS immerhin Overlays auslagern. Die wurden dann
immer noch zwischen EMS und "normalem" RAM kopiert, spart aber immerhin
Platten-I/O. Eine XMS-Version des Overlay-Managers hat's irgendwie nie
in die Standardbibliothek geschafft.

Post by Kay Martinen

Post by Chr. Maercker

Post by Stefan Reuther
Für 'DOS=HIGH' braucht es nur HMA (von HIMEM), für 'DOS=UMB' und 'LH'
braucht es UMB (von EMM386). In den UMB kann man eigentlich jedes
Programm packen, was halbwegs sauber geschrieben ist, HMA (und XMS und
EMS) muss das Programm explizit unterstützen.

Da das Speichermodell FLAT war, es im Realmode keinen Speicherschutz

Nein, das Speichermodell war nicht flat, sondern segmentiert.

Post by Kay Martinen
o.a. gab und die CPU ja 1 MB Adressraum kannte muß das Programm nur
*NICHT* gewisse Annahmen treffen wo und wie es es seinen Code, Daten,
Stack erwartet. Der Rest wird AFAIR von command.com und DOS beim laden
erledigt -> Programm an adresse X relozieren.

Beim Laden eines Programmes werden nur die Segmente angepasst. Eine
*.com-Datei beginnt immer an Offset 0100h, nur das Segment kann frei
gewählt werden. Das klappt bei HMA nicht, da du für die Adresse (z.B.)
105000h keine Segmentnummer finden kannst, mit der du Offset 0100h
nutzen kannst.

Deswegen muss das Programm HMA explizit unterstützen, indem es z.B.
position-independant gebaut ist und sich selbst da hinkopiert.
position-independant code war damals wiederum kein Feature irgendeines
Compilers, man durfte sich also in Assembler abmühen.

Post by Kay Martinen
Aber: DOS Programme damals waren m.E. nie "sauber" geschrieben. Da wurde
eher munter direkt in die BIOS Routinen gesprungen oder gleich direkt
VideoRAM oder I/O beschrieben - obwohl es für den I/O ja DOS-Routinen
gab. Ich sehe die Notwendigkeit HMA XMS oder EMS zu unterstützen eher
darin obige Sperenzchen sein zu lassen und alles über das DOS/BIOS
gespann ab zu wickeln.

Nein, das ist zu stark vereinfacht. Das Besondere an UMB ist eben, dass
es üblicherweise funktioniert, weil die Adressen genauso aussehen wie
immer, nur ein wenig größer. Alle anderen Speichertechnologien muss man
direkt mit extra Code unterstützen. Für den Zugriff auf XMS eben kein
'memcpy', sondern Aufruf einer Funktion von HIMEM ("Move extended memory
block"); für den Zugriff auf EMS 'memcpy' auch erst nach dem Einstellen
des korrekten Fensters usw.

Post by Kay Martinen

Post by Chr. Maercker
Liefen mit LH gestartete TSRs wirklich alle nur in den UMBs? Weil das
in manchen Configs derart viele waren, dass die dort kaum alle Platz

It depends, meine ich. Früher hab ich viel damit experimentiert und
lange nicht alle Treiber/Programme die man mit DeviceHigh oder LoadHigh
geladen hatte landeten auch dort. Oft kam es; bei fragmentiertem UMB;
auch auf die Ladereihenfolge an. Damit ein kleines Programm in eine
kleine Lücke passte und das größere in die größere lücke dahinter.

Genau.

'LH' stellt nur die Allokationsstrategie ein (INT 21/AX=5801,
http://www.ctyme.com/intr/rb-3008.htm). Wenn das Programm nicht in den
UMB passt, wird es kommentarlos in den konventionellen Speicher geladen.

Post by Kay Martinen

Post by Chr. Maercker
gehabt hätten. Es mussten ja obendrein Bereiche für BIOS(e) und
Video-RAM ausgeklammert werden.

Hmm. Das laufende DOS weiß i.allg. wo es das BIOS mit den
Einsprungpunkten und sein Video RAM findet. Ich denke diese Bereiche
sind automatisch ausgeklammert. Lesen und Schreiben kann man sie
dennoch. ;-)

Das DOS schaut beim Aufstarten nach 0040:0013
(https://github.com/cirosantilli/ralf-brown-interrupt-list/blob/master/inter61c/MEMORY.LST#L328)
und verwaltet alles bis dahin. Magie zum Finden von Speicher gibt's da
nicht. So haben sich bestimmte Netzwerkkarten (und bestimmte Viren)
Speicher abgeknappst, war dann daran zu erkennen, dass chkdsk auf einmal
nur 639k RAM angezeigt hat.

Die Speichermanager haben dann den Speicher, von dem sie wussten, noch
explizit dazugefügt; ob's da eine offizielle Schnittstelle gab oder ob
die einfach in den Datenstrukturen von DOS rumgepatched haben, weiß ich
aber nicht.


Stefan

[Chr. Maercker]

Post by Kay Martinen
Aber: DOS Programme damals waren m.E. nie "sauber" geschrieben.

Diese Erfahrung habe ich vor allem mit Spielen gemacht. Andere schlampig
programmierte Software stürzte i.a. oft genug ab, um sie zeitnah
auszusondern. Und viele Programme, allen voran der Norton Commander und
fast alle Tools von und für NetWare, liefen entgegen allen Unkenrufen
sogar unter XP noch.

Post by Kay Martinen

Post by Chr. Maercker
Liefen mit LH gestartete TSRs wirklich alle nur in den UMBs? Weil das
in manchen Configs derart viele waren, dass die dort kaum alle Platz

It depends, meine ich. Früher hab ich viel damit experimentiert und
lange nicht alle Treiber/Programme die man mit DeviceHigh oder LoadHigh
geladen hatte landeten auch dort. Oft kam es; bei fragmentiertem UMB;
auch auf die Ladereihenfolge an. Damit ein kleines Programm in eine
kleine Lücke passte und das größere in die größere lücke dahinter.

Stimmt auch wieder. Ich hatte schon überlegt, ob der EMM evtl. mehrere
verschiedene Pages in die UMBs einblendet und nach Bedarf umschaltet.

Post by Kay Martinen
IMHO ab DOS 6 gab's 'memmaker' als (leider dummes) tool das dies
automatisieren sollte. Mußte man aber nach jeder kleinen Konfig-änderung
erneut laufen und es die Startdateien umschreiben lassen. Einmal hat es
sie unbenutzbar gemacht und ich mußte per Floppy Booten. seitdem: nie
wieder memmaker!

ACK, nie ernsthaft eingesetzt ob solcher u.a. Macken.

Post by Kay Martinen

Post by Chr. Maercker
gehabt hätten. Es mussten ja obendrein Bereiche für BIOS(e) und
Video-RAM ausgeklammert werden.

Hmm. Das laufende DOS weiß i.allg. wo es das BIOS mit den
Einsprungpunkten und sein Video RAM findet. Ich denke diese Bereiche
sind automatisch ausgeklammert. Lesen und Schreiben kann man sie
dennoch. ;-)

WIMRE hatten wir fast immer Excludes in den EMM386-Aufrufen. Bei
SCSI-Adaptern mit eingenem BIOS o.ä. sowieso, aber nicht nur bei denen.
Bei manchen PCs schienen die Excludes entbehrlich zu sein, bei anderen
gab es ohne sie Abstürze.

Post by Kay Martinen

Post by Chr. Maercker
Der eingangs des Teilthreads genannte Client32 war über solche Probleme
sowieso erhaben, NIOS.EXE unterstützte XMS.

Irgendwann muß ich mich mal Spaßeshalber mit Novell Netware auf Server
und CLient befassen. Aber ich war schon erschrocken als ich las das ein
Novell Server im Realmode von einer DOS Partition startet und dann in
den Protected Mode und sein SYSVOL wechselt - oder so ähnlich. Schräges
Zeuchs. ;-)

DOS als Startrampe zu verwenden fand ich genial. Es ermöglichte, die
"Rakete" mit bekannten Bordmitteln startklar zu machen.

Post by Kay Martinen
Damals (tm) bin ich bei Lantastic geblieben, später bei
NETBEUI und erst dann zu TCPBEUI und IP gewechselt.

Also NDIS2-Krams? Das war im Vergleich zu den NetWare-Clients wirklich
grausig. Booting and booting again ...
Für TCPIP haben wir zunächst PC-TCP mit Packet Drivern benutzt, später
habe ich Client32 genommen, weil WfW mit NDIS nicht lief, sondern kroch
und crashte.

Post by Kay Martinen
IPX kenne ich nur
aus wenigen damaligen Spielen die es unterstützten (was mir mangels Netz
nichts brachte).

Im Grunde ist IPX der Vorläufer von IPv6. Mit Packet-Drivern und sowieso
mit Client32 ließen sich relativ einfach stabile Multipotokoll-Stacks
für IPX und IP aufbauen.

[Chr. Maercker]

Post by Chr. Maercker
WIMRE hatten wir fast immer Excludes in den EMM386-Aufrufen. Bei
SCSI-Adaptern mit eingenem BIOS o.ä. sowieso, aber nicht nur bei
denen. Bei manchen PCs schienen die Excludes entbehrlich zu sein, bei
anderen gab es ohne sie Abstürze.

Verwexlung, ist halt schon etliche Jährchen her: die Excludes waren für
die RAM-Schnipsel, die von den WD80x3-NICs im UMB eingeblendet wurden.

[Kay Martinen]

Post by Chr. Maercker

Post by Chr. Maercker
WIMRE hatten wir fast immer Excludes in den EMM386-Aufrufen. Bei
SCSI-Adaptern mit eingenem BIOS o.ä. sowieso, aber nicht nur bei
denen. Bei manchen PCs schienen die Excludes entbehrlich zu sein, bei
anderen gab es ohne sie Abstürze.

Verwexlung, ist halt schon etliche Jährchen her: die Excludes waren für
die RAM-Schnipsel, die von den WD80x3-NICs im UMB eingeblendet wurden.

Ich hatte damals SMC Ultra Combo Karten die m.W. auch einen WD80xx Chip
haben. Excludes hab ich nie gesetzt. Auch für SCSI nicht. Obwohl ich
letzteres später/eher auf dem Server hatte und der dann mit OS/2 lief.

Kay

[Kay Martinen]

Post by Chr. Maercker

Post by Kay Martinen
Aber: DOS Programme damals waren m.E. nie "sauber" geschrieben.

Diese Erfahrung habe ich vor allem mit Spielen gemacht. Andere schlampig
programmierte Software stürzte i.a. oft genug ab, um sie zeitnah
auszusondern.

Die besonderheit von Spielen ist ja das sie zu keinem anderen Programm
kompatibel sein müssen. Im Gegensatz zu aller anderer SW die evtl. daten
erzeugt oder verarbeitet.

Bei einem Spiel unter DOS ist es dagegen noch nicht mal wirklich
zwingend das nach dessen Ende das DOS den command.com findet oder laden
könnte. Die Geräte hatten alle Reset-Knöpfe und danach lief's ja
wieder... meistens. Und an die letzten DOS Games die Extender (mingw?)
brauchten erinnere ich das genau das auch häufiger mal vor kam. :)

Post by Chr. Maercker
Und viele Programme, allen voran der Norton Commander und
fast alle Tools von und für NetWare, liefen entgegen allen Unkenrufen
sogar unter XP noch.

Die Norton Programme (damals noch mit "Norton" inside) waren vielleicht
einfach nur kompatibel genug entwickelt - damit sie zusammenarbeiten
können. Was für netware wohl auch gelten dürfte.

Sind ja keine Daddelspiele. ;)

Post by Chr. Maercker

Post by Kay Martinen
Hmm. Das laufende DOS weiß i.allg. wo es das BIOS mit den
Einsprungpunkten und sein Video RAM findet. Ich denke diese Bereiche
sind automatisch ausgeklammert. Lesen und Schreiben kann man sie
dennoch. ;-)

WIMRE hatten wir fast immer Excludes in den EMM386-Aufrufen. Bei
SCSI-Adaptern mit eingenem BIOS o.ä. sowieso, aber nicht nur bei denen.
Bei manchen PCs schienen die Excludes entbehrlich zu sein, bei anderen
gab es ohne sie Abstürze.

Das los der "kompatibilität" :)

Post by Chr. Maercker

Post by Kay Martinen

Post by Chr. Maercker
Der eingangs des Teilthreads genannte Client32 war über solche Probleme
sowieso erhaben, NIOS.EXE unterstützte XMS.

Welches Programm meinst du mit client32 hier eigentlich genau? Kurze
Suche fördert mehr eintrage auf fragliche herkunft als anderes zu tage.
Obwohl mir der name doch von irgendwo bekannt vor kommt.

Post by Chr. Maercker
Also NDIS2-Krams? Das war im Vergleich zu den NetWare-Clients wirklich
grausig. Booting and booting again ...

Würde ich so nicht sagen. Ich hatte Zwei Olivetti 386SX-16 mit 1MB aber
ohne Platten. Die booteten in unter 1 Minute erst DOS, dann das LAN und
mounteten sich dann die Freigaben vom Server. U.a. auch ein
DOS-Verzeichniss. So liefen an jedem ein Analogmodem für meine Fidonet
Mailbox und die beiden PCs waren Line 1 und Line 2 meines FTN Mailers.

Ich hab Connect-versuche gehabt die länger dauerten als die zum Booten.
:-) Lag vielleicht auch daran das ich noch 16k8 und 19k2 Zyxels benutzte
als die meisten schon mit 28k8+ rum "surften"

Post by Chr. Maercker
Für TCPIP haben wir zunächst PC-TCP mit Packet Drivern benutzt, später
Mit Packet-Drivern und sowieso
mit Client32 ließen sich relativ einfach stabile Multipotokoll-Stacks
für IPX und IP aufbauen.

Das hab ich nur unter OS/2 ab Warp 3 / 4 gemacht, mit LAPS und MPTS.
Darum war der/das auch mein Server.


Kay

[Chr. Maercker]

Post by Kay Martinen
Die besonderheit von Spielen ist ja das sie zu keinem anderen Programm
kompatibel sein müssen. Im Gegensatz zu aller anderer SW die evtl. daten
erzeugt oder verarbeitet.

Auch bei Spielen gibt es rühmliche Ausnahmen, z.B. Lucas Arts. Monkey
Island lief bis XP einwandfrei, und selbst danach noch mit SCUMM-VM. :-)

Post by Kay Martinen

Post by Chr. Maercker
Und viele Programme, allen voran der Norton Commander und
fast alle Tools von und für NetWare, liefen entgegen allen Unkenrufen
sogar unter XP noch.

Die Norton Programme (damals noch mit "Norton" inside) waren vielleicht
einfach nur kompatibel genug entwickelt - damit sie zusammenarbeiten
können. Was für netware wohl auch gelten dürfte.
Sind ja keine Daddelspiele. ;)

FULL ACK. Verstehe bis heute nicht, warum weder M$ noch die Händler von
Anfang an klar und deutlich erklärt haben, W9x ist *exklusive* für
Daddelspiele, NT ist für ordentliche Software.

Post by Kay Martinen

Post by Chr. Maercker
WIMRE hatten wir fast immer Excludes in den EMM386-Aufrufen. Bei
SCSI-Adaptern mit eingenem BIOS o.ä. sowieso, aber nicht nur bei denen.
Bei manchen PCs schienen die Excludes entbehrlich zu sein, bei anderen
gab es ohne sie Abstürze.

Das los der "kompatibilität" :)

Hatte ich korrigiert, die Exkludes betrafen vor allem RAM auf
Netzwerk-Karten, evtl. auch SCSI-BIOSs.

Post by Kay Martinen

Post by Chr. Maercker

Post by Chr. Maercker
Der eingangs des Teilthreads genannte Client32 war über solche Probleme
sowieso erhaben, NIOS.EXE unterstützte XMS.

Welches Programm meinst du mit client32 hier eigentlich genau? Kurze
Suche fördert mehr eintrage auf fragliche herkunft als anderes zu tage.
Obwohl mir der name doch von irgendwo bekannt vor kommt.

Novell Client32. Gab es für DOS, W9x, NT..XP, (Win7?) und WIMRE auch für
MacOS, Linux und OS/2. Vorgänger war VLM. Bei novell.com, heute
Microfocus, gips das Ding evtl. noch zum Download. Ob es die
NetWare-Seiten von Stefan Braunstein noch gibt, müsste ich direkt mal
nachschauen.

Post by Kay Martinen

Post by Chr. Maercker
Also NDIS2-Krams? Das war im Vergleich zu den NetWare-Clients wirklich
grausig. Booting and booting again ...

Würde ich so nicht sagen. Ich hatte Zwei Olivetti 386SX-16 mit 1MB aber
ohne Platten. Die booteten in unter 1 Minute erst DOS, dann das LAN und
mounteten sich dann die Freigaben vom Server. U.a. auch ein
DOS-Verzeichniss. So liefen an jedem ein Analogmodem für meine Fidonet
Mailbox und die beiden PCs waren Line 1 und Line 2 meines FTN Mailers.

Das Problem bei NDIS2-Drivern war deren Laden via CONFIG.SYS. Das wurde
WIMRE erst 1998 behoben. Novell hatte mit LSL ab 1993/94 Driver, die
sich laden und bei Fehlconfig wieder entladen ließen, bis sie
funktionierten. Ohne 1001 Reboots. Mit dem Client32 wurde das ab 1995/96
perfektioniert.

[Stefan Reuther]

Post by Chr. Maercker

Post by Kay Martinen
Aber: DOS Programme damals waren m.E. nie "sauber" geschrieben.

Diese Erfahrung habe ich vor allem mit Spielen gemacht. Andere schlampig
programmierte Software stürzte i.a. oft genug ab, um sie zeitnah
auszusondern. Und viele Programme, allen voran der Norton Commander und
fast alle Tools von und für NetWare, liefen entgegen allen Unkenrufen
sogar unter XP noch.

Definiere "schlampig programmiert". Wenn du Grafik und Sound haben
willst, musst du Ferkeleien mit Assembler, Interrupts & Ports anstellen,
weil es dafür keine Betriebssystemschnittstellen gibt. Dass die Spiele
unter Windows XP nicht laufen, liegt dann gerne einfach daran, dass
Windows nicht weiß, wie es Mode-X o.ä. in ein Fenster hinein und wieder
raus verfrachten soll.

Der Norton Commander braucht im Wesentlichen die normalen Syscalls zum
Einlesen von Dateien, und das, was er direkt ansteuert (Bildspeicher
schreiben damit's schnell geht, COM-Port für Commander Link) ist
hinreichend unspektakulär bzw. macht eh jeder.

Allerdings gab's da durchaus auch Programme, die direkt das Filesystem
geparsed haben, da war dann halt auch irgendwann Schluss (bei Norton
sowas wie undelete, ansonsten erinnere ich mich da an xtree).


Stefan

[Chr. Maercker]

Post by Stefan Reuther
Definiere "schlampig programmiert". Wenn du Grafik und Sound haben
willst, musst du Ferkeleien mit Assembler, Interrupts & Ports anstellen,
weil es dafür keine Betriebssystemschnittstellen gibt.

Wenn dokumentiert wird, dass mit dgl. zu rechnen ist, OK. Und es
beschränkt sich auf Spiele und einige Programme, die Grafik brauchen.
Was gelegentlich unter DOS schon durch regelmäßige Abstürze "glänzte"
und deshalb später unter Windows gar nicht erst in die engere Wahl kam,
waren indes oft genug Programme, die im Textmode liefen und keinen Sound
brauchen. Bei Diagnosetools kam es vor und bei denen war klar, dass die
nicht immer systemkonform arbeiten können. Wobei gerade von denen
erstaunlich viele noch unter NTff. laufen, wenngleich sie in virtueller
DOS/BIOS-Umgebung nicht mehr wirklich funktionieren bzw. nicht mehr
sinnvoll einsetzbar sind.

Post by Stefan Reuther
Dass die Spiele
unter Windows XP nicht laufen, liegt dann gerne einfach daran, dass
Windows nicht weiß, wie es Mode-X o.ä. in ein Fenster hinein und wieder
raus verfrachten soll.
Der Norton Commander braucht im Wesentlichen die normalen Syscalls zum
Einlesen von Dateien, und das, was er direkt ansteuert (Bildspeicher
schreiben damit's schnell geht, COM-Port für Commander Link) ist
hinreichend unspektakulär bzw. macht eh jeder.
Allerdings gab's da durchaus auch Programme, die direkt das Filesystem
geparsed haben, da war dann halt auch irgendwann Schluss (bei Norton
sowas wie undelete, ansonsten erinnere ich mich da an xtree).

Dass z.B. Norton Utilities jenseits von echtem DOS nicht mehr einsetzbar
sind, ist klar, die fallen unter die o.g. Kategorie.

[Hermann Riemann]

Post by Dennis Grevenstein
Kann das sein, dass DOS grosszügiger mit der Hardware umgehen
kann als Linux?

Bei mir hat Linux, im Gegensatz zu DOS, windows und OS/2
auf 386 seinen Dienst verweigert nachdem ich einen
387 (floating point chip) Chip einsetzte.

Vermutlich versuchte nur Linux ihn zu benutzen.



Ein anderer Fall war als Festplattenlaufwerk
nur eine Syquest Wechselplatte.


DOS Problemlos.

OS/2 ging nicht direkt.
hotline von IBM Anweisung: deren BIOS Ersatz deaktivieren.

Linux (Distri SuSE) ließ sich nicht direkt installieren
hotline Anweisung: DOS installieren und dann update machen.

Übel war windos.
Die Installation war problemlos.
Beim Editieren und warten wurde die Wechselplatte deaktiviert.
Beim abspeichern wurde versucht, das Laufwerk zu reaktivieren.
Da es nicht schnell genug war meinte windows das Laufwerk sei nicht da.
Nach dem wieder hochfahren waren etliche Inhalte
falschen Dateien zugeordnet, weil interne Verweis Tabellen
nicht gespeichert wurden..


Hermann
nicht sicher ob SuSE es gelernt hat,
bei update mit mehr als einem Laufwerk umzugehen.

[Wolf gang P u f f e]

Post by Hermann Riemann

Post by Dennis Grevenstein
Kann das sein, dass DOS grosszügiger mit der Hardware umgehen
kann als Linux?

Bei mir hat Linux, im Gegensatz zu DOS, windows und OS/2
auf 386 seinen Dienst verweigert nachdem ich einen
387 (floating point chip) Chip einsetzte.
Vermutlich versuchte nur Linux ihn zu benutzen.

Ich hatte 2 identische 386DX40 + Copro seiner Zeit.
Einer lief stabil unter MSDOS/Win3.1(3.11) und unter NWDOS, der andere
stürzte sehr oft unter Windows ab.
Der Kummerkasten lief dann stabil, als ich den Co gezogen hatte.

[Arno Welzel]

Dennis Grevenstein:

[...]

Post by Dennis Grevenstein
Kann das sein, dass DOS grosszügiger mit der Hardware umgehen
kann als Linux?
hier MS-DOS 6.22 vs. Linux 1.1.62.

Ein Problem könnten auch Lastwechsel sein.

Bei DOS gibt es kein "idle" sondern die CPU wird immer maximal
ausgelastet und die Spannungsregler laufen immer mit einer gewissen
Grundlast.

Bei Linux dagegen schwankt die Auslastung der CPU deutlich stärker und
das kann bei älterer Hardware Probleme machen, wenn die Elkos auf den
Boards schon stark gealtert sind und Spannungsschwankungen durch
Lastwechsel nicht mehr gut ausgleichen.

[Nils M Holm]

[...]

Kann das sein, dass DOS grossz?giger mit der Hardware umgehen
kann als Linux?
hier MS-DOS 6.22 vs. Linux 1.1.62.

Ein Problem k?nnten auch Lastwechsel sein.
Bei DOS gibt es kein "idle" sondern die CPU wird immer maximal
ausgelastet und die Spannungsregler laufen immer mit einer gewissen
Grundlast.

Schon, aber ein 386-40 duerfte bei Volllast 2 bis 3W verbrauchen,
idle dann eben ein bisschen weniger. Waere dieser Lastwechsel
wirklich ein Problem fuer den Kondensator?

[Gerrit Heitsch]

Post by Nils M Holm

[...]

Kann das sein, dass DOS grossz?giger mit der Hardware umgehen
kann als Linux?
hier MS-DOS 6.22 vs. Linux 1.1.62.

Ein Problem k?nnten auch Lastwechsel sein.
Bei DOS gibt es kein "idle" sondern die CPU wird immer maximal
ausgelastet und die Spannungsregler laufen immer mit einer gewissen
Grundlast.

Schon, aber ein 386-40 duerfte bei Volllast 2 bis 3W verbrauchen,
idle dann eben ein bisschen weniger. Waere dieser Lastwechsel
wirklich ein Problem fuer den Kondensator?

Eher nicht, weil der 386 noch mit 5V läuft, also direkt vom Netzteil
versorgt wird.

Gerrit

[Andreas Kohlbach]

Post by Arno Welzel
[...]

Post by Dennis Grevenstein
Kann das sein, dass DOS grosszügiger mit der Hardware umgehen
kann als Linux?
hier MS-DOS 6.22 vs. Linux 1.1.62.

Ein Problem könnten auch Lastwechsel sein.
Bei DOS gibt es kein "idle" sondern die CPU wird immer maximal
ausgelastet und die Spannungsregler laufen immer mit einer gewissen
Grundlast.

IIRC Windows 9x (bei 98 bin ich mir nicht sicher) auch nicht. Es gab
dafür ein externes Zusatzprogramm namens Rain, was HLT Anweisungen
einfügte.

Da meine Pentium 1 CPU (133 MHz) keinen Ventilator hatte, fiel mir kein
Vorteil auf. Später auf einem 233er mit Ventilator dann schon, dass der
auf einmal abschaltete (oder sich langsamer drehte).

[Hermann Riemann]

Post by Andreas Kohlbach
Da meine Pentium 1 CPU (133 MHz) keinen Ventilator hatte, fiel mir kein
Vorteil auf. Später auf einem 233er mit Ventilator dann schon, dass der
auf einmal abschaltete (oder sich langsamer drehte).

Beruflich hatte ich lange windows als Terminal für BS2000 (mainframe)

Der Ventilator war nur hörbar, und dann deutlich,
wenn der Bildschirmschoner für Irrgarten lief.

Hermann
fragend, was da geschont wurde.

[Michael Bäuerle]

Post by Andreas Kohlbach
[...]
Da meine Pentium 1 CPU (133 MHz) keinen Ventilator hatte, fiel mir kein
Vorteil auf. [...]

Ging das wirklich?

Ich habe noch einen P54C mit 75 MHz und großem passiven Kühlkörper.
Alle P54C-Maschinen mit 100 Mhz und mehr hatten angeblasene Kühler.

[Dennis Grevenstein]

Post by Michael Bäuerle
Ich habe noch einen P54C mit 75 MHz und großem passiven Kühlkörper.
Alle P54C-Maschinen mit 100 Mhz und mehr hatten angeblasene Kühler.

Bei Marken PCs, wo man mehr Energie in das Design des Gehäuses
investiert hat, konnte man auch da noch CPUs ohne aktiven Kühler finden.
HP Vectra waren ein Beispiel. Meiner Erfahrung nach kam der Sprung
von passiv auf aktiv bei den billig DOSen in der 486er Generation.

gruss,
Dennis

[Gerrit Heitsch]

Post by Dennis Grevenstein

Post by Michael Bäuerle
Ich habe noch einen P54C mit 75 MHz und großem passiven Kühlkörper.
Alle P54C-Maschinen mit 100 Mhz und mehr hatten angeblasene Kühler.

Bei Marken PCs, wo man mehr Energie in das Design des Gehäuses
investiert hat, konnte man auch da noch CPUs ohne aktiven Kühler finden.
HP Vectra waren ein Beispiel. Meiner Erfahrung nach kam der Sprung
von passiv auf aktiv bei den billig DOSen in der 486er Generation.

Ich hatte als Bürorechner mal einen Compaq Desktop mit PPro-200 der noch
passiv gekühlt war. Funktionierte zuverlässig, war aber SEHR auf Kante
genäht. Ein leicht anders plaziertes Kabel brachte die Kiste nach 1-2h
zum Absturz weil der Luftstrom nicht mehr 100% passte. Kabel wieder so
wie vorgesehen verlegt und das Problem war gelöst.

Gerrit

[Michael Bäuerle]

Post by Gerrit Heitsch

Post by Dennis Grevenstein

Post by Michael Bäuerle
Ich habe noch einen P54C mit 75 MHz und großem passiven Kühlkörper.
Alle P54C-Maschinen mit 100 Mhz und mehr hatten angeblasene Kühler.

Bei Marken PCs, wo man mehr Energie in das Design des Gehäuses
investiert hat, konnte man auch da noch CPUs ohne aktiven Kühler finden.
HP Vectra waren ein Beispiel. Meiner Erfahrung nach kam der Sprung
von passiv auf aktiv bei den billig DOSen in der 486er Generation.

Ja, so ab 486DX2-66 habe ich das auch in Erinnerung.

Post by Gerrit Heitsch
Ich hatte als Bürorechner mal einen Compaq Desktop mit PPro-200 der
noch passiv gekühlt war. Funktionierte zuverlässig, war aber SEHR auf
Kante genäht. Ein leicht anders plaziertes Kabel brachte die Kiste nach
1-2h zum Absturz weil der Luftstrom nicht mehr 100% passte. Kabel
wieder so wie vorgesehen verlegt und das Problem war gelöst.

Ich meinte keine Spezialkonstruktionen, wo das Netzteil den Kühlkörper
mit einem definierten Luftstrom versorgt. Der genannte P54C-75 sitzt
auf einem 08/15-Board in einem 08/15-Gehäuse.

[Gerald E:scher]

Post by Michael Bäuerle

Post by Dennis Grevenstein
Bei Marken PCs, wo man mehr Energie in das Design des Gehäuses
investiert hat, konnte man auch da noch CPUs ohne aktiven Kühler finden.
HP Vectra waren ein Beispiel. Meiner Erfahrung nach kam der Sprung
von passiv auf aktiv bei den billig DOSen in der 486er Generation.

Ja, so ab 486DX2-66 habe ich das auch in Erinnerung.

Fast. Beim 486DX2-66 reichte noch ein kleiner, passiver Kühlkörper.

[Guido Grohmann]

Post by Gerald E:scher

Post by Michael Bäuerle
Ja, so ab 486DX2-66 habe ich das auch in Erinnerung.

Fast. Beim 486DX2-66 reichte noch ein kleiner, passiver Kühlkörper.

Das hing aber doch auch vom Gehäuse ab. Mir sind die ersten kleinen
CPU-Lüfter im PC auch bei den DX2-66 in Desktiop-Gehäusen untergekommen,
in meinem Bigtower gings aber auch ohne.

Guido

[Andreas Kohlbach]

Post by Michael Bäuerle

Post by Andreas Kohlbach
[...]
Da meine Pentium 1 CPU (133 MHz) keinen Ventilator hatte, fiel mir kein
Vorteil auf. [...]

Ging das wirklich?
Ich habe noch einen P54C mit 75 MHz und großem passiven Kühlkörper.
Alle P54C-Maschinen mit 100 Mhz und mehr hatten angeblasene Kühler.

Ich musste den Desktop das erste Mal aufmachen, nachdem ich in
irgendeiner Software sah, dass er auf 100 statt 133 MHz lief. Der
Anbieter (Computech) hatte den Jumper auf 100MHz gestellt. Da fiel mir
auf, dass die CPU einen Kühlkörper (aber keinen Ventilator) hatte.

Keine Ahnung, warum man CPUs kühlen muss. Die 6510 in meinem Commodore 64
kam ganz ohne aus. ;-)

[Gerrit Heitsch]

Post by Andreas Kohlbach

Post by Michael Bäuerle

Post by Andreas Kohlbach
[...]
Da meine Pentium 1 CPU (133 MHz) keinen Ventilator hatte, fiel mir kein
Vorteil auf. [...]

Ging das wirklich?
Ich habe noch einen P54C mit 75 MHz und großem passiven Kühlkörper.
Alle P54C-Maschinen mit 100 Mhz und mehr hatten angeblasene Kühler.

Ich musste den Desktop das erste Mal aufmachen, nachdem ich in
irgendeiner Software sah, dass er auf 100 statt 133 MHz lief. Der
Anbieter (Computech) hatte den Jumper auf 100MHz gestellt. Da fiel mir
auf, dass die CPU einen Kühlkörper (aber keinen Ventilator) hatte.
Keine Ahnung, warum man CPUs kühlen muss. Die 6510 in meinem Commodore 64
kam ganz ohne aus. ;-)

Aber schon der VIC-II hatte in den meisten C64 eine passive Kühlung. Er
produziert nur ca. 1.5W Verlust, aber das reicht um sich die Finger dran
zu verbrennen.

Gerrit

[Andreas Neumann]

Post by Andreas Kohlbach
Keine Ahnung, warum man CPUs kühlen muss. Die 6510 in meinem Commodore 64
kam ganz ohne aus. ;-)

Die ARMs in den ersten 3 Raspi-Gens auch, bei Rechenleistungen >>486. Ok,
das letztere ist geschätzt, ich habe jetzt nicht nachgeschaut. Vielleicht
können die sogar mehr als Pentiums.
Wirkungsgrad war offensichtlich kein Entwicklungsziel.

[Kay Martinen]

Post by Andreas Kohlbach

Post by Michael Bäuerle

Post by Andreas Kohlbach
[...]
Da meine Pentium 1 CPU (133 MHz) keinen Ventilator hatte, fiel mir kein
Vorteil auf. [...]

Ging das wirklich?
Ich habe noch einen P54C mit 75 MHz und großem passiven Kühlkörper.
Alle P54C-Maschinen mit 100 Mhz und mehr hatten angeblasene Kühler.

Compaq Prolinea 575. Desktop Gehäuse und die CPU hat nur einen
Kühlkörper aber keinen eigenen Lüfter. Hat hier einige Zeit als Router
gedient. Schön leise da das Netzteil nach hinten pustete.

Post by Andreas Kohlbach
Ich musste den Desktop das erste Mal aufmachen, nachdem ich in
irgendeiner Software sah, dass er auf 100 statt 133 MHz lief. Der
Anbieter (Computech) hatte den Jumper auf 100MHz gestellt.

Das ist seinerzeit bei den Pentiums aber auch so'ne Sache gewesen. AFAIR
konnte nicht jede CPU mit 133 MHz FSB laufen und ggf. sogar welche nicht
stabil die's eigentlich sollten - weil irgendwas auf dem Mainboard nicht
mit machen wollte. Ergo: 100MHz Default. Das man die 33 MHz "gemerkt"
hätte würde ich nicht behaupten. Eher merkte man's wenn die Kiste bei
133 abschmierte. :-)

Post by Andreas Kohlbach
Da fiel mir
auf, dass die CPU einen Kühlkörper (aber keinen Ventilator) hatte.

Es gibt auch heute Geräte mit CPUs die keinen Miefquirl brauchen. Bei
PCs ist das dann eher die Edel-klasse - oder etwas selbstgefrickeltes.

Post by Andreas Kohlbach
Keine Ahnung, warum man CPUs kühlen muss. Die 6510 in meinem Commodore 64
kam ganz ohne aus. ;-)

Weil's früher Cool war wenn man sich an Hot-lips ähh -Chips die Finger
verbrannte und CMOS noch recht neu war. Und man zwischenzeitlich mehr
lernte über Leistungsausbeute und Effizienz, also genau die zwei Dinge
mit denen sich die Wirtschaft am Liebsten befasst, die
Leistungserbringer ausbeuten um effizienter Geld scheffeln zu können. :)

Übrigens: 1MHz, 8-Bit vergleichst du mit 75MHz, 32Bit... das ist nicht
mehr Äpfel vs. Birnen das ist schon Tomate versus Salami! :-)

Der Vergleich hinkte nicht mal mehr, der ist hintenüber gefallen vor Lachen.

Kay

[Andreas Kohlbach]

Post by Kay Martinen

Post by Andreas Kohlbach
Ich musste den Desktop das erste Mal aufmachen, nachdem ich in
irgendeiner Software sah, dass er auf 100 statt 133 MHz lief. Der
Anbieter (Computech) hatte den Jumper auf 100MHz gestellt.

Das ist seinerzeit bei den Pentiums aber auch so'ne Sache gewesen. AFAIR
konnte nicht jede CPU mit 133 MHz FSB laufen und ggf. sogar welche nicht
stabil die's eigentlich sollten - weil irgendwas auf dem Mainboard nicht
mit machen wollte. Ergo: 100MHz Default. Das man die 33 MHz "gemerkt"
hätte würde ich nicht behaupten. Eher merkte man's wenn die Kiste bei
133 abschmierte. :-)

Ich hatte einen 133 MHz Computer bestellt (meine erste telefonische
Bestellung in 1995). Der lief aber nur auf 100 MHz. Hatte damals schon im
Web gesucht (Google gab es noch nicht) und die Belegung des DIP-Switches
gefunden, um ihn auf 133 zu stellen. Lief über Jahre problemlos.

Post by Kay Martinen

Post by Andreas Kohlbach
Keine Ahnung, warum man CPUs kühlen muss. Die 6510 in meinem Commodore 64
kam ganz ohne aus. ;-)

Weil's früher Cool war wenn man sich an Hot-lips ähh -Chips die Finger
verbrannte und CMOS noch recht neu war. Und man zwischenzeitlich mehr
lernte über Leistungsausbeute und Effizienz, also genau die zwei Dinge
mit denen sich die Wirtschaft am Liebsten befasst, die
Leistungserbringer ausbeuten um effizienter Geld scheffeln zu können. :)

Keine Ahnung, ob die 6510 je heiss wurde. Vermutlich nicht, sonst hätte
es viele Probleme mit Commodore 64 gegeben.

Post by Kay Martinen
Übrigens: 1MHz, 8-Bit vergleichst du mit 75MHz, 32Bit... das ist nicht
mehr Äpfel vs. Birnen das ist schon Tomate versus Salami! :-)
Der Vergleich hinkte nicht mal mehr, der ist hintenüber gefallen vor Lachen.

:-)

[Hermann Riemann]

Post by Andreas Kohlbach
Keine Ahnung, warum man CPUs kühlen muss. Die 6510 in meinem Commodore 64
kam ganz ohne aus. ;-)

Meine Atari ST* auch.

Hermann
nicht wissend, nei welchem intel/AMD es mit
passivem und bei welchem es mit aktvivem Kühlkörper los ging.
Und an Zukunft mit "intel outside" dachte,
bei dem der Kühlkörper auf dem Hausdach befestigt werden müsste.

[Andreas Kohlbach]

Post by Hermann Riemann

Post by Andreas Kohlbach
Keine Ahnung, warum man CPUs kühlen muss. Die 6510 in meinem Commodore 64
kam ganz ohne aus. ;-)

Meine Atari ST* auch.

So mein Amiga 500, der auch eine M68 CPU hatte. Die war IIRC noch
"lang". Neuere waren quadratisch, hatten aber auch keinen Kühlkörper. Wie
beim C64 wurde nur das externe Netzteil wirklich warm (und der VIC II im
C64). Wurde der Legende nach von einigen wohl als Fußwärmer im Winter
genutzt. *g*

[Dennis Grevenstein]

Post by Hermann Riemann

Post by Andreas Kohlbach
Keine Ahnung, warum man CPUs kühlen muss. Die 6510 in meinem Commodore 64
kam ganz ohne aus. ;-)

Meine Atari ST* auch.

Im ST war doch ne 68000 drin? (aber auch ohne Kühlkörper...)

gruss,
Dennis

[Hermann Riemann]

Post by Dennis Grevenstein

Post by Hermann Riemann

Post by Andreas Kohlbach
Keine Ahnung, warum man CPUs kühlen muss. Die 6510 in meinem Commodore 64
kam ganz ohne aus. ;-)

Meine Atari ST* auch.

Im ST war doch ne 68000 drin? (aber auch ohne Kühlkörper...)

Im ST ST* STM STE ja.
Später ST ( die ich nicht mehr hatte) hatten 68020 ..

Hermann
vermutent, das selbst 68060 keine Kühlkörper brauchte.

[Michael Noe]

Post by Hermann Riemann

Post by Dennis Grevenstein

Post by Hermann Riemann

Post by Andreas Kohlbach
Keine Ahnung, warum man CPUs kühlen muss. Die 6510 in meinem Commodore 64
kam ganz ohne aus. ;-)

Meine Atari ST* auch.

Im ST war doch ne 68000 drin? (aber auch ohne Kühlkörper...)

Im ST ST* STM STE ja.
Später ST ( die ich nicht mehr hatte) hatten 68020 ..

Nein, einen 020 hatte ein (Mega) ST(E)/TT/Falcon ab Werk nie.

Aber etwa der Amiga 2500 (viel später auch der 1200) oder der Macintosh
II.

BTW: Hatte eigentlich die Atari Transputer Workstation 800 CPU-Lüfter?

Post by Hermann Riemann
vermutent, das selbst 68060 keine Kühlkörper brauchte.

Das ist nicht richtig. Zumindest bei den CPU-Karten, die mir bekannt
sind. (Ist aber "dennoch" eine tolle CPU.)

Die CPU meines Amiga 4000/040 ist jedoch auch passiv gekühlt. Immerhin
gibt es da einen Gehäuselüfter.

[Hermann Riemann]

Post by Michael Noe

Post by Hermann Riemann

Post by Dennis Grevenstein

Post by Hermann Riemann

Post by Andreas Kohlbach
Keine Ahnung, warum man CPUs kühlen muss. Die 6510 in meinem Commodore 64
kam ganz ohne aus. ;-)

Meine Atari ST* auch.

Im ST war doch ne 68000 drin? (aber auch ohne Kühlkörper...)

Im ST ST* STM STE ja.
Später ST ( die ich nicht mehr hatte) hatten 68020 ..

Nein, einen 020 hatte ein (Mega) ST(E)/TT/Falcon ab Werk nie.

Nach
https://de.wikipedia.org/wiki/Atari_TT
hatte der TT einen 68030
und nach
https://en.wikipedia.org/wiki/Atari_Falcon
hatte der Falcon einen 68030
( Also >= 68020 )

Post by Michael Noe
Aber etwa der Amiga 2500 (viel später auch der 1200) oder der Macintosh
II.
BTW: Hatte eigentlich die Atari Transputer Workstation 800 CPU-Lüfter?

http://www.atari-computermuseum.de/atw800.htm
Loading Image...
ohne Lüfter

Hermann
dessen Transputer nie Strom gespürt gaben.

[Michael Noe]

Post by Hermann Riemann

Post by Michael Noe

Post by Hermann Riemann
Im ST ST* STM STE ja.
Später ST ( die ich nicht mehr hatte) hatten 68020 ..

Nein, einen 020 hatte ein (Mega) ST(E)/TT/Falcon ab Werk nie.

Nach
https://de.wikipedia.org/wiki/Atari_TT
hatte der TT einen 68030
und nach
https://en.wikipedia.org/wiki/Atari_Falcon
hatte der Falcon einen 68030
( Also >= 68020 )

Ich weiß. Aber eben > 68020, nicht =. ;-)

(Ansonsten hat auch mein heimischer Linux-Xeon-Server hier auch noch
einen ollen >= Intel 8086... was ja auch stimmt -> dann lieber 68k! :-))

SCNR

[Kay Martinen]

Post by Michael Noe
(Ansonsten hat auch mein heimischer Linux-Xeon-Server hier auch noch
einen ollen >= Intel 8086... was ja auch stimmt -> dann lieber 68k! :-))

Huch! Und ich dachte immer Intel hätte erst ab Pentium die XEON-CPUs für
Server so genannt. Da ist ein 8086-XEON wohl eine Rarität.

Post by Michael Noe
SCNR

Ach so, war'n Scherz? :-)


Kay

[Fritz]

Post by Dennis Grevenstein
Hallo,
ich hätte da nochmal eine Frage an die Leute, die vor Ewigkeiten
schon Linux benutzt haben.

Auf DOS bezogen und Schon etwas älter ....

http://www.askos.de/ram/