Forum: PC Hard- und Software DOS Installation auf UEFI Mainboaed zum Laufen bringen hängt bei HIMEM is testing extended memory


von Herbert He. (Gast)


Lesenswert?

Ein MS-DOS Programm befindet sich auf einer SATA SSD. Das Quellprogramm 
gibt es nicht. Das Ganze funktioniert auf einem PC mit Athlon X2 
Prozessor. Die dabei benutzten LPT, VGA und zwei COM Schnittstellen, die 
eine Industriemaschine anbinden, funktionieren dabei einwandfrei.

Jetzt möchte ich das Ganze auf einem neueren PC zum Laufen bringen. Dazu 
habe ich dieses Mainboard (mit den benötigten Schnittstellen) gekauft 
und die MS-DOS-SATA-SSD, die auf dem Athlon X2 PC funktioniert, dort 
angeschlossen:
http://www.asrock.com.tw/mb/Intel/J3355B-ITX/

Nach "Load UEFI Defaults" wird die SSD in der Boot Priority nicht 
angeboten. Offenbar erkennt das UEFI hier, dass sie nicht startfähig 
ist. Das ändert sich, wenn ich das CSM (Compatibility Support Module) 
auf "Enable" stelle. Jetzt kann von der SSD gestartet werden. Allerdings 
hängt das Ganze schnell:

Starting MSDOS
HIMEM is testing extended memory ...

Hinter den drei Punkten blinkt der Cursor. Durch nichts läßt sich der 
dort hängende Bootvorgang fortsetzen.

Ob das Problem in UEFI zu suchen ist, weiß ich nicht. Keine Einstellung 
in dessen Setup - insbesondere die Abschaltung der Secure und Trust 
Features - hat das Fehlerbild geändert.

Ich konnte lediglich Folgendes feststellen: Ein 64-bit Ubuntu läuft nach 
"Load UEFI Defaults" problemlos, die 32-bit Variante hingegen nicht. 
Letztere wiederum funktioniert (anders als MS-DOS) problemlos, nachdem 
das CSM (Compatibility Support Module) auf "Enable" gestellt wurde.

Hat jemand eine Idee, was das Hängen im Bootprozess von MS-DOS 
verursacht?

von bastel_ (Gast)


Lesenswert?

Ich glaub die neuen Atomboards haben nicht wirklich alles im BIOS, was 
normalerweise über den Interrupt angesprungen werden soll. Probier doch 
mal FreeDOS.

von Walter K. (Gast)


Lesenswert?

Ich würde auf jeden Fall virtualisieren - denn irgendwann bekommt man 
sowas wirklich nicht mehr nativ ans Laufen.

ich habe mit dem (kostenlosen) VMWareConverter gute Erfahrungen gemacht.
DOS ist lt. den ReleaseNotes als "guest operating systems  Experimental"
... Aber das war DOS ja auch immer;-)
meine Erfahrungen sind jedenfalls positiv.

Das gleiche gilt natürlich noch mehr für alte XP Büchsen, die es in der 
Industrie noch oftmals gibt.
Her gibt es nur Probs mit alten IDE Controllern - aber alles lösbar

von c-hater (Gast)


Lesenswert?

Herbert He. schrieb:

> Hat jemand eine Idee, was das Hängen im Bootprozess von MS-DOS
> verursacht?

himem.sys natürlich. Offensichtlich kommt es mit der gebotenen Hardware 
nicht klar. Möglicherweise ist schlicht und einfach zu viel RAM 
vorhanden.

Wie auch immer: erstmal kann man himem.sys schlicht und einfach 
deaktivieren. Einfach Linux booten, die Partition mounten, eine 
Sicherheitskopie der config.sys unter anderem Namen erzeugen und dann 
mit einem Texteditor die config.sys bearbeiten, die Zeile mit himem.sys 
einfach erstmal löschen.

Damit sollte das DOS erstmal weiter booten. Aber natürlich: für die 
Anwendung, die dann laufen soll, könnte natürlich nun zu wenig 
Speicher verfügbar sein.

Dann müßte man schauen, ob irgendeine der vielen Optionen von himem.sys 
Abhilfe schafft oder eine Reduzierung des RAM-Angebots.

von Walter K. (Gast)


Lesenswert?

c-hater schrieb:
> Wie auch immer: erstmal kann man himem.sys schlicht und einfach
> deaktivieren. Einfach Linux booten, die Partition mounten, eine
> Sicherheitskopie der config.sys unter anderem Namen erzeugen und dann
> mit einem Texteditor die config.sys bearbeiten, die Zeile mit himem.sys
> einfach erstmal löschen.

Gibts zum ändern der config.sys auch schon ne spezielle 
Linux-Distribution?

- oder könnte man vielleicht auch beim Booten die F8 Taste drücken?

von Markus (Gast)


Lesenswert?

Man kann auch per Adapter (USB SATA) auf die SSD zugreifen und per 
Notepad die Zeile mit rem auskommentieren.

von Rufus Τ. F. (rufus) Benutzerseite


Lesenswert?

Walter K. schrieb:
> - oder könnte man vielleicht auch beim Booten die F8 Taste drücken?

Wenn das auf der SSD installierte DOS etwas mit dieser Taste anfangen 
kann, dann ja. Das muss also mindestens MS-DOS 6.0 sein.

von Herbert He. (Gast)


Lesenswert?

bastel_ schrieb:
> Ich glaub die neuen Atomboards haben nicht wirklich alles im BIOS, was
> normalerweise über den Interrupt angesprungen werden soll. Probier doch
> mal FreeDOS.

Wie wechselt man auf einer lauffähigen Installation mit Anwenderprogramm 
auf einer SSD das MS-DOS gegen FreeDos aus? Der eigentliche Zugriff ist 
kein Problem, da ich Expirimentierklone der SSD hergestellt und auf 
einer weiteren Partition Ubuntu und einen (funktionierenden) Bootmanager 
Grub installiert habe. Aber was genau muss man gegen was tauschen?

von Jay W. (jayway)


Lesenswert?

Einfacher wird sein, eine FreeDOS Installation durchzuführen und dann 
die Anwendung(en) dahin zu kopieren. DOS kannte ja noch keine Registry, 
da konnte man (meistens) einfach die entsprechenden Verzeichnisse 
kopieren.
Das kann man ja ohne großen Aufwand mal ausprobieren.

von Frank K. (fchk)


Lesenswert?

Herbert He. schrieb:
>
> Starting MSDOS
> HIMEM is testing extended memory ...
>
> Hinter den drei Punkten blinkt der Cursor. Durch nichts läßt sich der
> dort hängende Bootvorgang fortsetzen.

> Hat jemand eine Idee, was das Hängen im Bootprozess von MS-DOS
> verursacht?

Neue Chipsätze und Prozessoren haben keinen Tastaturcontroller und auch 
kein A20 Gate mehr. Das wiederum braucht himem.sys, meine ich.

Einzige Lösung: Altes Board mit altem Chipsatz nehmen. Die Vortex86 
Chips werden immer noch produziert und sind auf vielen PC104-Boards 
drauf. Das sollte dann laufen.

fchk

von michael_ (Gast)


Lesenswert?

Herbert He. schrieb:
> Starting MSDOS
> HIMEM is testing extended memory ...

Dann kommentiere es doch erst mal aus.
In meiner dumpfen Erinnerung konnte man Himem auch mit Parametern 
versehen und begrenzen.

Vielleicht geht es auch nur nicht, weil sie nun endlich mal das Gate 
A-20 abgeschafft haben :-)

Wieviel RAM war auf dem Athlon X2?

von oszi40 (Gast)


Lesenswert?

config.sys: REM vor himem-Aufruf ist harmloser als Zeilen löschen.
Das Leiden wird nach einem gesunden Start von MSDOS noch keine Ende 
haben wenn die CPU zu schnell ist und Zeitschleifen überlaufen oder 
Borland-Produkte ins Spiel kommen über 500 MHz.

von bastel_ (Gast)


Lesenswert?

Drück einfach mal F8 beim booten, dann kann man selektiv die config.sys 
und autoexec.bat abarbeiten. F5 überspringt beide.

von michael_ (Gast)


Lesenswert?

Probiert hast du das aber unter DOS noch nicht?

DOS ist kein WIN!

von Mike B. (mike_b97) Benutzerseite


Lesenswert?

Meines Wissens sind die ATOMs explizit nicht mehr für den Betrieb unter 
DOS vorgesehen.
Einige der Chipsätze (z.B. D410PT und D510MO) unterstützen DOS nicht 
mehr.

Mit UEFI und DOS würde ich es gar nicht mehr probieren, HTT, 
Virtualisierung usw. würde ich alles im BIOS deaktivieren.
Festplatten-Controller auf Legacy-Mode stellen.

Und dann beten, wer mag.

von bastel_ (Gast)


Lesenswert?

Jaja. DOS ist kein WIN. Aber WIN war mal DOS.
Und sicherlich hab ich das schon probiert.
Denn das geht seit ms dos 6.0, seit dem man auch diese Bootmenüs basteln 
kann, wo selektiv verschiedene Blöcke aus der config.sys ausgeführt 
werden. Habe ich vor über 20 Jahren alles schon 'probiert' und gemacht 
und coole Menüs gebaut.
Und auch heute drück ich noch F5/F8 bei meinem DOS Bootstick mit Memtest 
und Bios Flashtools (ist in dem Fall ein MsDos von einem Win98)

von Alles Humbug (Gast)


Lesenswert?

oszi40 schrieb:
> Das Leiden wird nach einem gesunden Start von MSDOS noch keine Ende
> haben wenn die CPU zu schnell ist und Zeitschleifen überlaufen oder
> Borland-Produkte ins Spiel kommen über 500 MHz.

Patch schafft Abhilfe:

https://www.heise.de/ct/hotline/Nicht-schon-wieder-Runtime-Error-200-307662.html

von Freddi (Gast)


Lesenswert?

Hm... hatte ich auch mal mit ner DOS-Boot-Geschichte. Versuch es doch 
mal mit einem UEFI-faehigen bootloader und dann DOS auswaehlen und 
booten.

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Lesenswert?

Alles Humbug schrieb:
> oszi40 schrieb:
>> Das Leiden wird nach einem gesunden Start von MSDOS noch keine Ende
>> haben wenn die CPU zu schnell ist und Zeitschleifen überlaufen oder
>> Borland-Produkte ins Spiel kommen über 500 MHz.
>
> Patch schafft Abhilfe:
>
> https://www.heise.de/ct/hotline/Nicht-schon-wieder-Runtime-Error-200-307662.html

Obs daran liegen würde, kann man aber auch ohne Patch prüfen, indem man 
(sofern noch möglich) im BIOS den Level 1 Cache abschaltet, dann liefen 
meine alten Turbo Pascal Sachen (auf PII und PIII/500MHz). Wenns geht, 
hilft der c't Patch vermutlich.
Das hat aber mit himem.sys nicht viel zu tun, hier isses m.M.n. das 
fehlende A20 Gate.

: Bearbeitet durch User
von Roland E. (roland0815)


Lesenswert?

Schon mal Dosbox probiert?

von michael_ (Gast)


Lesenswert?

Für eine Maschinensteuerung?
Die in Echtzeit laufen soll?

von Josef ( Gast) (Gast)


Lesenswert?

Hallo

Ich habe ein DOS 6.22 auf USB Stick das ich noch gelegentlich für eine 
SPS Anwendung brauche und auf einem älteren Laptop einsetze.

Ich habe den USB Stick mal probehalber in meinen Ryzen Rechner mit Asus 
Mainboard und UEFI bios gesteckt und er ist sofort im DOS hochgefahren 
und Himem.sys hat auch keine probleme gemacht.
Ich habe das Programm gestartet und es lief sofort ohne Probleme, was 
mich auch etwas überraschte da es bei schnelle Rechnern auch schon das 
Runtime
Probleme hatte.

Gruß
Josef

von Michael B. (alter_mann)


Lesenswert?

Habe ich das überlesen oder hat es der TO noch nicht verraten?
Welche DOS-Version soll da werkeln?
Mit welchen Parametern wird himem.sys aufgerufen?
Und letztendlich: Auf welcher HW-Plattform hat das bisher gearbeitet?

Beitrag #5310330 wurde von einem Moderator gelöscht.
von Michael X. (Firma: vyuxc) (der-michl)


Lesenswert?

Das A20 Gate Handling ist nicht mehr im SoC drin. Ist seit dem Menlow 
so. Man konnte bisher eine SIO an den LPC hängen und es darüber 
programmieren. Das muß allerdings vom Bios unterstützt werden.
Dein UEFI-Bios kann das nicht, also mußt du den Himem-Treiber weglassen. 
Generell geht DOS auf den Atomen, allerdings eben mit dieser 
Einschränkung.

von Herbert He. (Gast)


Lesenswert?

Michael X. schrieb:
> Das A20 Gate Handling ist nicht mehr im SoC drin. Ist seit dem Menlow
> so. Man konnte bisher eine SIO an den LPC hängen und es darüber
> programmieren. Das muß allerdings vom Bios unterstützt werden.
> Dein UEFI-Bios kann das nicht, also mußt du den Himem-Treiber weglassen.

Mit dem A20 Gate in neueren Prozessorarchitekturen hast Du 
offensichtlich den Nagel auf den Kopf getroffen. Gemäß diesem Wikipedia 
Artikel
https://de.wikipedia.org/wiki/A20-Gate#Zukunft_des_A20-Gates
wird das Gate seit Haswell nicht mehr unterstützt und sollte demnach auf 
dem Vorvorgänger Sandy Bridge (Generation 2) noch laufen. Und 
tatsächlich startet die MSDOS-SSD (über USB) an einem Notebook mit 
i3-2328M. An einem Skylake Desktop, der nach Haswell herauskam, hingegen 
hängt es wie beim Problem-Mainboard bei Himem. Ob es darüber hinaus 
läuft, kann ich wegen der fehlenden Schnittstellen nicht feststellen. 
Aber zumindest der hängende Himem scheint geklärt.

Auch das Problem-Mainboard läuft durch, wenn ich den Treiber in der 
Config.sys auskommentiere. Ob es dann aber in der Maschine läuft, habe 
ich noch nicht testen können. Ansonsten wäre die Ivy Bridge als 
Vorgänger des Haswell wohl die letzte Architektur, auf dem das Ganze 
noch läuft. Mal sehen, ob ich da noch ein kompaktes Mainboard (oder PC) 
finde, das die benötigten Schnittstellen LPT, VGA und 2x COM 
bereitstellt.

von Winfried J. (Firma: Nisch-Aufzüge) (winne) Benutzerseite


Lesenswert?

Ich habe hier noch einige Boards aus dieser Zeit von 389 bis pentium5
wenn die Produktion dran hängt, würde ichnach sowas suchen unddie Elcos 
erneuern ev. auch eins auf die Seite legen. LAN Carte rein und sie sind 
sogar Netzwerkfähig.

Namaste

von georg (Gast)


Lesenswert?

Herbert He. schrieb:
> Mit dem A20 Gate in neueren Prozessorarchitekturen hast Du
> offensichtlich den Nagel auf den Kopf getroffen.

Zitat:
"Doch es gibt auch DOS-Varianten, zum Beispiel FreeDOS, die ohne 
A20-Gate problemlos klar kommen."

von https://www.elektronik-kompendium.de/sites/com/0811181.htm

Wäre zumindest einen Versuch wert.

Georg

von Peter D. (peda)


Lesenswert?

Das Himem.sys soll ja nur zusätzliche knapp 64kB RAM im Realmode 
freischaufeln.
Maximalen Speicherbedarf hatten aber fast nur Spiele, d.h. normale 
Anwendungen sollten auch ohne Himem.sys genug RAM haben.

von georg (Gast)


Lesenswert?

Peter D. schrieb:
> Maximalen Speicherbedarf hatten aber fast nur Spiele

Auch Netzwerkfähigkeit kriegt man ohne Himem kaum hin. Im vorhandenen 
System wird man Himem.Sys ja nicht bloss so zum Spass installiert haben.

Georg

von Hang ´Em High (Gast)


Lesenswert?

Herbert He. schrieb:


> Starting MSDOS
> HIMEM is testing extended memory ...
>
> Hinter den drei Punkten blinkt der Cursor. Durch nichts läßt sich der
> dort hängende Bootvorgang fortsetzen.


HIMEM.SYS /testmem:off


Evtl. hängt es dann ja etwas tiefer :)

von Hang ´Em High (Gast)


Lesenswert?

Rufus Τ. F. schrieb:
> Walter K. schrieb:
>> - oder könnte man vielleicht auch beim Booten die F8 Taste drücken?
>
> Wenn das auf der SSD installierte DOS etwas mit dieser Taste anfangen
> kann, dann ja. Das muss also mindestens MS-DOS 6.0 sein.



ALT


----------------------- MS-DOS v6.22 Help: HIMEM.SYS 
-----------------------

/VERBOSE
    Directs HIMEM to display status and error messages while loading. By
    default, HIMEM does not display any messages unless it encounters an
    error. You can abbreviate /VERBOSE as /V. (To display status 
messages
    without adding the /VERBOSE switch, press and hold the ALT key while
    HIMEM starts and loads.)


--------------






>>> Autor: Walter K. (hunsbuckel)
>>> Ich würde auf jeden Fall virtualisieren

Wird wohl das vernünftigste sein.
Dann braucht man nicht dauernd neu booten bis es klappt, duck ....















------

von c-hater (Gast)


Lesenswert?

Peter D. schrieb:

> Das Himem.sys soll ja nur zusätzliche knapp 64kB RAM im Realmode
> freischaufeln.

Jepp. Und genau nur dazu braucht man eigentlich das A20-Gate. Darüber 
kann man im im RM diese zusätzlichen 64k (-16 Bytes) oberhalb der 
1M-Grenze adressieren, die aus der Mehrdeutigkeit der 
Segmentadressierung resultieren und die im DOS-Jargon "UMB" (upper 
memory block) heissen.

Wofür man das Gate allerdings nicht braucht, ist der Zugriff auf den 
ganzen Rest des RAM im Virtual86-Mode. Der Speicher, der auf diesem Weg 
bereitgestellt wird, nennt sich im DOS-Jargon "EMS". Der ist aus Sicht 
eines DOS-Programmes (oder -Treibers) allerdings im Unterschied zum UMB 
nicht transparent, sondern Zugriffe darauf müssen besonders 
initialisiert werden (über das allfällige Laden eines Segmentregisters 
hinaus), eben durch die Benutzung der entsprechenden Funktionen von 
himem.sys zum Mapping in das RM-Fenster.

> Maximalen Speicherbedarf hatten aber fast nur Spiele

Definitiv nein. Es gab unzählige DOS-Anwendungen abseits von Spielen, 
die Speicher jenseits der 1M-Grenze zumindest benutzen konnten oder 
sogar zwingend benötigten. Die ganze Palette von Anwendungen, von 
Textverarbeitung über Datenbanken bis hin zu Grafikbearbeitung, um nur 
mal ein paar Eckpunkte des Spektrums zu nennen. Allerdings haben diese 
Anwendungen und Spiele weitestgehend eins gemeinsam: sie benutzen dazu 
meist NICHT himem.sys, sondern einen sog. DOS-Extender, der 
überwiegend nur denselben Job macht, wie himem.sys, das allerdings 
deutlich schneller und besser vor dem Anwendungprogrammierer verborgen 
als bei der Krücke himem.sys  (dadurch, dass sie eben nicht den 
V86-Mode, sondern den 32Bit PM verwendet haben). Diese Extender waren 
allerdings üblicherweise so geschrieben, dass sie mit himem.sys 
koexistieren konnten, oft sogar einige Funktionen von himem.sys nutzten 
(z.B. den Zugriff auf das berühmte A20Gate).

Hier kommt allerdings die Ausnahme von der Regel in's Spiel: Gerade 
Spiele nutzten wiederum gelegentlich besondere Konfigurationsoptionen 
der DOS-Extender, die himem.sys praktisch kaltgestellt haben, dafür aber 
etliche Prozent mehr Performance ermöglichten. Aus solchen Spielen war 
dann bei Anwesenheit von himem.sys keine Rückkehr in die DOS-Umgebung 
mehr möglich, nachdem sie einmal gestartet waren. Es soll sogar 
Anwendungen gegeben haben, die das tun, ich kenne allerdings keine. So 
einen Dreck hätte ich allerdings auch sowieso niemals gekauft....

von guest (Gast)


Lesenswert?

Peter D. schrieb:
> Das Himem.sys soll ja nur zusätzliche knapp 64kB RAM im Realmode
> freischaufeln.

Nö, dafür brauchte man das genau nicht. Das war die normale 
Funktionsweise der CPU. Gebraucht hat man das um die Funktion der 
älteren 8086 (Wraparound auf die unteren RAM-Adressen) zu emulieren.


c-hater schrieb:
> Jepp. Und genau nur dazu braucht man eigentlich das A20-Gate. Darüber
> kann man im im RM diese zusätzlichen 64k (-16 Bytes) oberhalb der
> 1M-Grenze adressieren, die aus der Mehrdeutigkeit der
> Segmentadressierung resultieren und die im DOS-Jargon "UMB" (upper
> memory block) heissen.

Fast. UMB (oder auch UMA) war der Bereich zwischen 640k und 1MB, die 
knapp 64k darüber waren der HMA (high memory area).

von c-hater (Gast)


Lesenswert?

guest schrieb:

> Fast. UMB (oder auch UMA) war der Bereich zwischen 640k und 1MB, die
> knapp 64k darüber waren der HMA (high memory area).

Ja, da hast du (fast) Recht. Lang ist's her.

Genau genommen ist HMA ist eine Untermenge des UMB, welches alles 
jenseits von Bill Gates' magischer 640k-Grenze umfasst, was im RM 
erreichbar sein kann...

Genau diejenige Untermenge, für die das A20-Gate eine Rolle spielt. 
Wobei auch der Rest des UMB etliche Fallstricke bereit hielt. Von der 
Problematik der Belegung durch ROM/RAM/MMIO von Peripherie bis zur 
DMA-(Un-)Fähigkeit bestimmter Teile bei bestimmten Chipsätzen, selbst 
wenn der RAM für die CPU zugreifbar war...

Ein Glück, dass das fast alles nur noch Geschichte ist. Kaum noch zu 
glauben, mit was für Problemen man sich mal rumgeschlagen hat...

Die heutigen sind allerdings oft nicht weniger krass und abstrus, nur 
halt: anders...

von guest (Gast)


Lesenswert?

c-hater schrieb:
> Genau genommen ist HMA ist eine Untermenge des UMB

Eigentlich nicht. UMB/UMA gab es ja schon beim XT. HMA kam dann erst 
beim AT dazu. Aber egal, lang lang ist's her.

c-hater schrieb:
> Wobei auch der Rest des UMB etliche Fallstricke bereit hielt ...

Du hast die Cache Problematik vergessen :) Und memmaker lag auch oft 
genug daneben.

Nett war auch das geteilte RAM-Layout von command.com. Ein Teil resident 
im unteren RAM-Bereich, der andere am oberen Ende. Letzterer konnte von 
anderen Programmen überschrieben werden und wurde bei deren Ende vom 
residenten Teil bei Bedarf wieder neu von Disc nachgeladen. Leider hatte 
MS bei der Erkennung ob der obere Teil noch intakt war oder neu geladen 
werden muß ziemlichen Mist gebaut, was zu diversen Abstüzen führte.

von Peter D. (peda)


Lesenswert?

Was ich damals schon nicht verstanden habe, das EMM386.EXE hat zwar die 
gesamten oberen 384kB RAM verschlungen, aber der freie DOS-Speicher 
erhöhte sich nur um etwa 30kB, also magere 8% Wirkungsgrad. Wo ist der 
Rest geblieben?
Ich hab deshalb auf EMM386.EXE verzichtet und die 384kB als Schreibcache 
mit HYPERDKX.EXE benutzt, das brachte die HDD aber ordentlich auf Trab.

von Rufus Τ. F. (rufus) Benutzerseite


Lesenswert?

Peter D. schrieb:
> Wo ist der Rest geblieben?

Nun, oberhalb der 640K ist erst mal Schluss mit RAM, da lässt sich 
nichts ohne Lücken anhängen. Ab 0xA0000 kommt das Video-RAM, ab 0xC0000 
das Video-ROM, und in weiteren Bereichen u.a. Erweiterungs-BIOSe von 
Festplattencontrollern, Netzwerkkarten-ROMs und natürlich das BIOS 
selbst.
Dazwischen aber sind an verschiedenen Stellen Lücken, und in die kann 
RAM eingeblendet werden, in das wiederum Devicetreiber o.ä. geladen 
werden können, die sonst den Bereich unter der 640k-Grenze zumüllen.

von Alles Humbug (Gast)


Lesenswert?

Peter D. schrieb:
> Was ich damals schon nicht verstanden habe, das EMM386.EXE hat zwar die
> gesamten oberen 384kB RAM verschlungen, aber der freie DOS-Speicher
> erhöhte sich nur um etwa 30kB, also magere 8% Wirkungsgrad. Wo ist der
> Rest geblieben?

Der konnte dann in der sog. "Upper Memory Area" genutzt werden. Dazu gab 
es einen Load High Befehl fürs Himem.

https://en.wikipedia.org/wiki/Upper_memory_area

von Icke ®. (49636b65)


Lesenswert?

Winfried J. schrieb:
> Ich habe hier noch einige Boards aus dieser Zeit von 389 bis pentium5

Du hast da aber echt seltene Exemplare. Unikate, direkt aus Intels 
Labor?

von michael_ (Gast)


Lesenswert?

Was hat man sich damals gequält, die Speichererweiterungen einzubinden.
Ohne zwingenden Grund befasse ich mich nicht damit.

Aber warum zum Teufel will man einen funktionierenden Computer an einer 
Maschine erneuern?

Am Ende gibt es doch Null Nutzen.

Was sind Beweggründe für so einen Schritt?

von georg (Gast)


Lesenswert?

michael_ schrieb:
> Was sind Beweggründe für so einen Schritt?

Intelligente Menschen ersetzen eine uralte Hardware, bevor sie endgültig 
und überraschend ausfällt. Wie gesagt, intelligente, das ist nicht jedem 
gegeben.

Georg

von michael_ (Gast)


Lesenswert?

Sicher dir!
Intelligent ist doch nur ein Kunstbegriff.
Nur Schabbel-Wabbel.

Uralt mit Athlon X2?
Ob Ein, Zwei, Vier, Hundertkern-CPU, dem DOS ist das wurscht.

Da läuft der Stromverbrauch der CPU zu Höchstleistung auf.

von Rufus Τ. F. (rufus) Benutzerseite


Lesenswert?

georg schrieb:
> Intelligente Menschen ersetzen eine uralte Hardware, bevor sie endgültig
> und überraschend ausfällt. Wie gesagt, intelligente, das ist nicht jedem
> gegeben.

Von der dämlichen Arroganz abgesehen sollte das auch inhaltlich etwas 
anders formuliert werden.


Wer Uralthardware betreibt und davon wirtschaftlich abhängig ist, tut 
gut daran, auf einen Ausfall der Uralthardware vorbereitet zu sein, 
d.h. zu erkunden, welche Schritte nötig sind, um die Hardware ersetzen 
zu können, bevor die Hardware ausfällt.

Dazu gehört es, zu erkunden, ob die Software, die auf der alten Hardware 
läuft, auf neuerer Hardware ebenfalls läuft, und welche Anpassungen 
entweder der Hardware, der Laufzeitumgebung (Betriebssystem o.ä.) und 
gegebenenfalls der Software selber nötig sind.

Stellt sich bei diesen Untersuchungen heraus, daß das ganze sehr 
kritisch ist, sollte Ersatzhardware beschafft und eingelagert werden.

Sollte weder Ersatzhardware beschaffbar noch die alte Software auf 
neuerer Hardware betreibbar sein, sollte mit der Beschaffung/Entwicklung 
neuer Software für zeitgemäße Hardware begonnen werden.

von S. R. (svenska)


Lesenswert?

HIMEM.SYS stellt den int 15h bereit, mit dem man Speicher oberhalb von 1 
MB benutzen kann. Dafür braucht es Zugriff auf A20. Einfach den gleichen 
Treiber von FreeDOS benutzen und gut ist.

HIMEM ist überhaupt buggy.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.