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?
Ich glaub die neuen Atomboards haben nicht wirklich alles im BIOS, was
normalerweise über den Interrupt angesprungen werden soll. Probier doch
mal FreeDOS.
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
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.
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?
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.
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?
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.
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
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?
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.
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.
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)
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.
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
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?
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.
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.
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
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
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.
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
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 :)
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 ....
------
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....
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).
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...
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.
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.
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.
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
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?
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?
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
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.
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.
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.
