Mehrere Industriemaschinen laufen mit MSDOS. Die alten 486 PCs darin
sterben und sollen erneuert werden. Genutzte Anschlüsse sind parallele,
2xRS232 und VGA Schnittstelle. Die beiden PS2 Schnittstellen dienen zum
gelegentlichen Anschluss von Tastatur und Maus. Die Festplatte hat IDE
Anschluss.
Der Umzug per Festplattenimage auf PC mit Athlon 64 X2 und SATA
Festplatte ist gelungen. Dabei werden Tastatur und Maus jetzt per USB
angeschlossen. Für den Umzug war es wichtig, dass SATA, USB und das
Reduzieren der Prozessorgeschwindigkeit nativ von der Hardware
unterstützt wird, ohne dass es dazu ein modernes Windows oder Linux
braucht.
Jetzt würde ich gern auf einen aktuellen, kühlen Mini PC umziehen. Wie
bekomme ich neue Hardware mit den alten Schnittstellen, die nativ ohne
modernes Windows oder Linux und somit unter MSDOS funktionieren?
Jegliche Form von Virtualisierung der Maschinensoftware, von der es
keinen Quelltext sondern nur ein Festplattenimage gibt, funktioniert
nicht.
Ich kann sehr die Industrierechner von men empfehlen, die ein Kunde von
uns in mittleren Stückzahlen einsetzt. Die Entwicklungsabteilung sitzt
in Deutschland, und der Support stellt bei schwierigen bzw. spezifischen
Fragen auch den Kontakt zu den Entwicklern her.
Auch wenn auf den Webseiten keine explizite Unterstützung für MSDOS
angegeben wird, kann Dir men hierzu sicherlich weitere Informationen
geben.
https://www.men.de/products/
Kurt P. schrieb:> kühlen Mini PC umziehen. Wie> bekomme ich neue Hardware mit den alten Schnittstellen, die nativ ohne> modernes Windows oder Linux und somit unter MSDOS funktionieren?
MiniPC und LPT kenne ich nicht. Wenn du auf LPT verzichten kannst dann:
z.b. DS67U
der ist so sparsam, das es egal ist ob er Drosselt oder nicht.
Peter II schrieb:> der ist so sparsam, das es egal ist ob er Drosselt oder nicht.
Es kommt nicht immer auf den Strom, sondern auch auf die einstellbare
Taktfrequenz an, da alte MSDOS-Programme möglicherweise Zählschleifen
enthalten, die über 500MHz Taktfrequenz ZU SCHNELL ablaufen was dann zu
Fehlern führte. Alte Borland-SW machte z.B. Probleme.
oszi40 schrieb:> Es kommt nicht immer auf den Strom, sondern auch auf die einstellbare> Taktfrequenz an, da alte MSDOS-Programme möglicherweise Zählschleifen> enthalten, die über 500MHz Taktfrequenz ZU SCHNELL ablaufen was dann zu> Fehlern führte. Alte Borland-SW machte z.B. Probleme.
soweit runter bekommt man aktuelle CPUs eh nicht. Außerdem gab es für
das Problem einen Patch. Es gibt auch ein paar Speicherresidente
Programm die man einsetzen kann um den Bug zu verhindern.
schon dosbox probiert?
win311 und win95 laufen darin eigentlich problemlos... und anscheined so
ziemlich alles was es an dos-spielen gibt...
wenn du eh ein image hast, sollte das leicht auszuprobieren sein...
Ansonsten wäre vielleicht ein board mit Vortex86 denkbar...
http://www.icop.com.tw/en/category/3.5-Embedded-SBC/3_5-Embedded-Module.html
73
Peter II schrieb:> Außerdem gab es für DAS Problem einen Patch.
Leider existiert manche Firma gar nicht mehr, wo man Patche für
spezielle alte Programme brauchen könnte. Eine angeschlossene
100k€-Maschine deswegen wegzuwerfen wäre schade. Deshalb beglückwünsche
ich alle, die sich RECHTZEITIG darüber Gedanken machen.
oszi40 schrieb:> Leider existiert manche Firma gar nicht mehr, wo man Patche für> spezielle alte Programme brauchen könnte.
man kann nachträglich die exe patchen. Dafür braucht man die Firma
nicht.
Das Problem mit dem zu hohen CPU Takt kenne ich von der DOS basierten
SPS Software-Entwicklungsumgebung von Telemechanik (TSX Reihen auf 8051
Basis)
ihr glaubt nicht wo die überall noch werkeln.
Die PC software läuft maximal bis 60 MHZ darüber kommt es während des
Programmstarts zu einem Abbruch wegen eines Overruns eines SW Counters.
Da hilft auch dos box nur schwer zumal es dann immer noch Probleme mit
Bitbanging auf HW Schnittstellen geben kann wenn diese über USB laufen
sollen. Alles sehr heikel. mann hat damals sehr HW nah programmiert wenn
es zeitkritisch wurde. Die Maschinen leben länger als je von den
Entwicklern geplant,mit den bekannten Folgen.
Namaste
Kurt P. schrieb:> Jetzt würde ich gern auf einen aktuellen, kühlen Mini PC umziehen. Wie> bekomme ich neue Hardware mit den alten Schnittstellen, die nativ ohne> modernes Windows oder Linux und somit unter MSDOS funktionieren?
Voll daneben. Aus deiner Beschreibung des Sachverhaltes kann man leicht
ersehen, das diese historische Maschinensoftware eigentlich nur zwei
Sachen wirklich braucht: Zugriff auf die Hardware der beiden verwendeten
legacy-Schnittstellen (und dies auf den damals(tm) üblichen Adressen)
und einen nicht zu hohen Takt.
Das alles kannst du ganz leicht haben, indem du diese altertümliche
Software in einer "DOS-Box" laufen läßt. Das ist eine Software, die
speziell dafür gedacht ist, eine möglichst kompatible Umgebung für olle
DOS-Software bereitzustellen. Primärziel waren zwar Spiele, aber auch
damals(tm) galt bereits: worauf ein anspruchsvolles Spiel ausreichend
gut laufen kann, darauf läuft auch alles andere an Software...
> Jegliche Form von Virtualisierung der Maschinensoftware, von der es> keinen Quelltext sondern nur ein Festplattenimage gibt, funktioniert> nicht.
Das glaube ich nicht. Ich habe noch keine DOS-Anwendung erlebt, die sich
in einer DOS-Box nicht zum laufen bringen ließe. Jedenfalls so lange sie
nicht spezielle Hardware (also irgendwelche proprietären Steckkarten)
benutzt hat, die die Emulation der DOS-Box nicht abdeckt.
Alles andere läßt sich mit einer entsprechenden Konfiguration der
DOS-Box zum Laufen bringen.
Und das Gute ist: Die DOS-Box kostet erstens nix und zweitens gibt es
sie sowohl für Linux als auch für Windows. Du hast also auch noch die
freie Wahl für das Host-System...
Bloß die Arbeit, die passende Konfiguration zu finden, musst du noch
selber erledigen. Da dies aber alles recht gut dokumentiert ist, fällt
das mit genügend Kenntnissen der historischen Originaltechnik i.A. doch
ziemlich leicht...
c-hater schrieb:> Das glaube ich nicht. Ich habe noch keine DOS-Anwendung erlebt, die sich> in einer DOS-Box nicht zum laufen bringen ließe. Jedenfalls so lange sie> nicht spezielle Hardware (also irgendwelche proprietären Steckkarten)> benutzt hat, die die Emulation der DOS-Box nicht abdeckt.
ISA und Takt sowie spezielle Treiber, Schnittstellen und Drucker...
Hardwarenah heißt auch, daß manches alte Programm direkt in den RAM
schrieb und früher (aus Zeitgründen) von dort Werte abgeholt wurden ...
oszi40 schrieb:> Hardwarenah heißt auch, daß manches alte Programm direkt in den RAM> schrieb und früher (aus Zeitgründen) von dort Werte abgeholt wurden ...
also jeden aktuell Programm holt werte aus dem Ram und schreibt sie dort
wieder hin - das ist sinn und zweck vom Ram.
Da er schon alles auf einen Athlon am laufen hat, scheint sein Programm
wohl recht gutmütig zu sein.
c-hater schrieb:> Das alles kannst du ganz leicht haben, indem du diese altertümliche> Software in einer "DOS-Box" laufen läßt. Das ist eine Software, die> speziell dafür gedacht ist, eine möglichst kompatible Umgebung für olle> DOS-Software bereitzustellen. Primärziel waren zwar Spiele, aber auch> damals(tm) galt bereits: worauf ein anspruchsvolles Spiel ausreichend> gut laufen kann, darauf läuft auch alles andere an Software...
Nein ganz so ist es leider nicht. Zwischen einer virtualisierten
Maschine und realer Hardware bestehen teilweise gravierende
Unterschiede.
Ich kenne eine Messsoftware die nur auf realer Hardware bis max. Pentium
III läuft. Ab Pentium IV haben sich einige Instruktionen des
mathematischen C-Prozessors geändert mit denen die Software abstürzt und
einfach hängen bleibt. In der Software sind sehr viele Assemblerroutinen
enthalten, die direkt auf reale Hardware zugreifen wollen und in einer
Emulation ist das so nicht gegeben. Diese spezielle Software läuft z.B.
auch nicht auf dem alten NT4, weil hier bestimmte direkte
Hardwarezugriffe vom BS nicht zugelassen werden.
Also ich kann das durchaus nachvollziehen, das für spezielle Software
entsprechende reale Hardware erforderlich ist.
Wenn man da nicht entsprechend vorgesorgt hat bleibt eigentlich nur
Henkel anschrauben.
Ich würde die alten Boards weiter nutzen und nur die HD's austauschen
bzw. mir einen Stapel selbiger auf Lager legen.
Zeno
Zeno schrieb:> Assemblerroutinen enthalten, die DIREKT auf reale Hardware zugreifen
Genau da klemmts dann bei einigen alten Programmen.
Das ist aber nur ein kleines DOS-Übel im Gegensatz zu künftigen
Zertifikats-Geschichten, wo durch Zertfikatsablauf od. sonstige
Zertifikats-Krankheiten/-Fehler die modernsten Programme oder ganze
Systeme unbrauchbar gemacht werden
könnten.http://www.heise.de/security/meldung/Zertifikats-Schmu-bei-Windows-Update-beunruhigt-Nutzer-2837537.html
oszi40 schrieb:> Peter II schrieb:>> der ist so sparsam, das es egal ist ob er Drosselt oder nicht.>> Es kommt nicht immer auf den Strom, sondern auch auf die einstellbare> Taktfrequenz an, da alte MSDOS-Programme möglicherweise Zählschleifen> enthalten, die über 500MHz Taktfrequenz ZU SCHNELL ablaufen was dann zu> Fehlern führte. Alte Borland-SW machte z.B. Probleme.
Ups, da ist etwas falsch rübergekommen. Mir ging es im Originalposting
nicht darum, dass die Software bei hoher Taktfrequenz nicht läuft. Denn
dann hätte sie es auch auf dem Athlon64X2 Prozessor auch nicht getan.
Vielmehr geht es darum:
Auf dem Athlon64X2 PC besteht die Möglichkeit, die "Cool & Quiet"
Unterstützung des Prozessors also dessen Drosselung bei niedriger Last
einzuschalten. Wird sie nicht aktiviert, läuft der Prozessor trotz
popeligem MSDOS Programm heiß und ebenso wie dessen Lüfter mit
Höchstgeschwindigkeit. Bei anderen PCs ohne diese Einschaltmöglichkeit
lief der Prozessor immer heiß. Offenbar ist das MSDOS Programm - anders
als ein modernes Windows oder Linux - nicht in der Lage, diese
Drosselung vorzunehmen. Kein Wunder, denn solche Rechner gab es
seinerzeit noch nicht.
Damit macht der von Dir zitierte Einwurf von Peter II schon Sinn:
>> der ist so sparsam, das es egal ist ob er Drosselt oder nicht.
Kurt P. schrieb:> Offenbar ist das MSDOS Programm - anders> als ein modernes Windows oder Linux - nicht in der Lage, diese> Drosselung vorzunehmen. Kein Wunder, denn solche Rechner gab es> seinerzeit noch nicht.
Unter DOS 6.22 gibt es die POWER.EXE, welche eben das erledigen soll:
http://www.i8086.de/dos-befehle/power-exe.html
Als Ueberlegung (entweder fuer eine Uebergangszeit oder gleich zum
laengeren ersetzen):
Wie waer es als kuehler PC-Ersatz mit einem ehemaligen Thin-Client?
Diese Mini-PCs mit 300-1200Mhz laufen kuehl ohne Luefter.
Haben meist auch noch LPT und (1-2) serielle Schnittstellen und als
internen Massenspeicher CF-Karte bzw. 44-poligen IDE-Anschluss (Platz
aber meist fuer keine Platte) eher IDE-DOMs (DiskonModule).
Wenn man mal auf eBay nach Thin-Clients schaut, dann gibt es auch einige
mit PCI-Slot - teilweise auch mit eSATA.
Hier gibt es eine Uebersicht was drin ist und manchmal auch, wie man die
umbauen kann:
http://parkytowers.me.uk/thin/10zig/index.shtml
Vorzugsweise Fujitsu Siemens, HP, Newoware, Igel, Wyse, VXL und DELL
Hallo A.K.
jetzt erstaunst du mich aber ein wenig.
Das Bios wusste noch nie etwas vom DOS und konnte folglich nicht
dorthin Booten. Das BIOS tut was sein Name suggeriert es wickelt den
POST (Power on Self test) ab und stellt die Basic I/O s als System
bereit.
Anschließend versuchtes je nach Implementation und parametrierter
Reihenfolge von einer BOOTQuelle (Laufwerk oder Netzwerk) einen
Masterbootrekord zu laden, um diesen dann über dessen Startvector
anzuspringen und damit das Heft endgültig an diesen abzugeben.
Von da an stellt es lediglich seine Routinen für die
HW-Schnittstellenbedienung und das Matherom zur Verfügung, inwiefern
diese vom durch den MBR nachzuladenden OS genutzt werden oder dieses
eigene Routinen nutzt kann das BIOS nicht mehr beeinflussen. Lediglich
einige HW-Interrupts werden, so nicht umgelenkt, weiter bedient. Dies
betrifft vor allem die BIOS-Systemuhr.
Genau genommen muss der MBR überhaupt kein OS nachladen. Er kann auch
direkt eine Firmware laden z.B. für eine Maschine aber dass ist ein
anderes Thema.
Zahlreiche nicht DOS basierte Spiele booteten so, wie es auch auf
anderen (Heim)und Businessrechnern zuvor üblich war.
Namaste
Winfried J. schrieb:> jetzt erstaunst du mich aber ein wenig.
Was auch immer du in meinen zugegeben knapp formulierten Text
reininterpretiert hast...
Lad ein CD-Image runter, mit der ein Rechner-BIOS aktualisiert werden
soll. Dafür gibts heute zwar auch andere Methoden, aber nach wie vor
kann es sein, dass von der CD ein DOS gebootet wird, das für den Update
ein DOS-Programm startet um das BIOS zu flashen.
In solchen Fällen kann man sich jedenfalls recht sicher sein, dass der
Rechner noch kompatibel zu DOS ist. Zumindest so weit es dieser Vorgang
erfordert.
Jetzt habe ich dich verstanden, ja soherum wird ein Schuh draus. Da die
BIOSroutinen über keinen Bootloader für updates verfügen wird dies
mittels eines Abgespeckten DOS erledigt. Ja das habe ich schon mit
diversen MBs in den 90ern von diskette gemacht hier fliegen auch noch
ein paar davon rum.
Namaste
Wir habe sehr aufwendig einen alten PC-XT organisiert und die alte
Software wieder zum Laufen gebracht. Jetzt bin ich am Neuschreiben der
Software fuer das System. Es geht auch um mehrere 100kEuro.
Anstelle des PC mit interner IEEE Karte und ADC kommt jetzt ein AVR,
serial angehaengt, der die Acquisition, die Kommunikation und das Timing
macht.
Falls das Problem nur darin besteht dass die CPU heiss laeuft, ist es
der Waermeleitkleben zwischen CPU und kuehlkoerper. Mach den weg und
neuen drauf.
CNC Maschinen meist.
Jedoch auch Steuerungsanlagen für Hochregale bzw der Bussteuerung.
gibt halt noch viele Anlagen die auf die LPT/Serial Ports angewiesen
sind sowie mit Dos oder W95 laufen....
Hallo,
wären folgende Produkte als Kombination eine Lösung?
ETX-Modul
http://www.congatec.com/de/produkte/etx/conga-elxeco.html
Eval. Board
http://www.congatec.com/de/produkte/zubehoer/conga-eeval.html
Das Eval-Board könnte auch durch eine selbstentwickelte Leiterplatte
ersetzt werden.
Wird bei uns in der Firma in einem Messgerät eingesetzt auf dem ein
Turbo-Pascal-Programm unter Freedos läuft. Wir haben eine Leiterplatte
erstellt, auf der VGA (nur für Entwicklungs- und Testzwecke), LPT (als
Display-Anschluss), 2x seriell (1x mit MAX232) und PS2 für Tastatur
herausgeführt sind. Lüfterlos (mit originalem Heta-Spreader) im
geschlossenen Gehäuse nur handwarm.
Silvio
Für ganz alte Projekte habe ich noch die alten SMD Maschienen in der
Ecke stehen. Bestückter und Ofen, die laufen auch noch auf MS-DOS.
Ich glaube solche alten Schätzchen gibt es noch eine ganze Menge.
Poster schrieb:> Für ganz alte Projekte habe ich noch die alten SMD Maschienen in der> Ecke stehen. Bestückter und Ofen, die laufen auch noch auf MS-DOS.> Ich glaube solche alten Schätzchen gibt es noch eine ganze Menge.
und sie haben den Vorteil nicht dem Update~ und Lizenzterror folgen zu
müssen.
Nur die alten Datenträger und Teile der HW könne problematisch werden!
aber solange es noch VGA Monitore gibt ... lässt sich vieles machen.
Namaste
Winfried J. schrieb:> aber solange es noch VGA Monitore gibt
DOS braucht ja nicht viel: RAM, Massenspeicher, Tastatur, ev. COM und
LPT, aber das hängt von der Anwendungs-Software ab. Festplatten usw.
sowie Tastatur werden durch BIOS-Emulation bereitgestellt, auch wenn es
eine USB-Tastatur ist, bisher jedenfalls, und die Frage nach einem
Grafiktreiber stellt sich nicht weil DOS keine Grafik hat. Die Textmodi
kann heute noch jeder Monitor, hoffentlich bleibt das noch länger so.
Schwierig wird es beim Netzwerk, da muss man alte Karten suchen, für die
es noch DOS- oder WfW3.11-Treiber gibt. Die meisten solchen alten
Maschinen haben eh kein Netzwerk, aber meistens wäre es ungemein
praktisch wenn sie es hätten.
Das grösste Problem bei alten Geräten stellen hochwertige Karten mit
ISA-Bus dar, aber das ist wieder ein anderes Thema.
Georg
Allenfalls mal bei PC/104 reinschauen. Das ist ein embedded PC standard,
der ISA Buss kompatibel ist. Die werden immer noch hergestellt, da in
beliebig vielen Steuerungen verbaut.
https://www.google.com/search?q=PC%2F104
Winfried J. schrieb:> Das Problem mit dem zu hohen CPU Takt kenne ich von der DOS basierten> SPS Software-Entwicklungsumgebung von Telemechanik (TSX Reihen auf 8051> Basis)> ihr glaubt nicht wo die überall noch werkeln.>> Die PC software läuft maximal bis 60 MHZ darüber kommt es während des> Programmstarts zu einem Abbruch wegen eines Overruns eines SW Counters.>> Da hilft auch dos box nur schwer
Gerade DOSBOX kann man doch besonders gut runterdrosseln.
> zumal es dann immer noch Probleme mit Bitbanging auf HW Schnittstellen> geben kann wenn diese über USB laufen sollen.
Wenn man sowas benötigt, wird's natürlich haarig. Da hilft aber auch ein
nativ auf dem Rechner laufendes DOS nicht - das ist dann ein Problem der
Hardware.
Zeno schrieb:> Diese spezielle Software läuft z.B. auch nicht auf dem alten NT4, weil> hier bestimmte direkte Hardwarezugriffe vom BS nicht zugelassen werden.
Das ist logisch, denn NT kapselt ja geradedie Hardware von den
Programmen ab, damit sie nicht direkt darauf zugreifen können. Eine
Emulation soll aber diese nachbilden, so dass das Programm glaubt, auf
die reale Hardware zuzugreifen. Deshalb funktioniert das auch wie oben
schon geschrieben wurde mit Standard-Hardware, aber nicht mit
spezialisierten Geräten, da die nicht mit emuliert werden.
Kurt P. schrieb:> Auf dem Athlon64X2 PC besteht die Möglichkeit, die "Cool & Quiet"> Unterstützung des Prozessors also dessen Drosselung bei niedriger Last> einzuschalten. Wird sie nicht aktiviert, läuft der Prozessor trotz> popeligem MSDOS Programm heiß und ebenso wie dessen Lüfter mit> Höchstgeschwindigkeit. Bei anderen PCs ohne diese Einschaltmöglichkeit> lief der Prozessor immer heiß. Offenbar ist das MSDOS Programm - anders> als ein modernes Windows oder Linux - nicht in der Lage, diese> Drosselung vorzunehmen. Kein Wunder, denn solche Rechner gab es> seinerzeit noch nicht.
Es liegt vor allem daran, dass MSDOS noch kein Multitasking hat und
daher die Prozessorlast im Prinzip immer bei 100% liegt. Prozesse können
dem Betriebssystem nicht sagen, dass sie gerade den Prozessor nicht
brauchen, weil es schlicht keine Prozesse gibt. Als Resultat gibt's auch
keinen Idle-Prozess, der den Prozessor in Leerlaufzeiten schlafen legen
könnte.
> Prozesse können dem Betriebssystem nicht sagen, dass sie gerade den Prozessor
nicht brauchen
Dabei ist anzumerken, dass MSDOS auch kein wirkliches Betriebssystem
war. Es war eine Softwarelibrary und ein Programmlader. Die Kontrolle
ueber die Hardware wurde zu fast 100% dem Programm uebergeben.
Oh D. schrieb:> Dabei ist anzumerken, dass MSDOS auch kein wirkliches Betriebssystem> war. Es war eine Softwarelibrary und ein Programmlader. Die Kontrolle> ueber die Hardware wurde zu fast 100% dem Programm uebergeben.
es hat ein Dateisystem bereitstellt, es hat den Arbeitsspeicher
verwaltet (EMM) und Geräte Treiber geladen (CD-Rom, Sound).
Rolf M. schrieb:> Gerade DOSBOX kann man doch besonders gut runterdrosseln.
jain
das tool stürzt trotz dem zu über 90% im Initprozess ab und kommt mit
einem Overflow raus. Auch in der DOSBOX. Ist der Initprozess überwunden
läuft es stabil.
Ich habe eine Batch geschrieben, welche das das Programm so lange neu
startet wie Die "j"-Taste gedrückt ist. Wird die Taste nicht gedrückt
gehalten fragt die Batch ob sie abbrechen oder neu starten soll. Das
hatte ich schon vor DOS-Box auf einem alten Thinkpad mit WIN98SE so
gemacht welches noch heute für die Wartung von TSX17 herhält. Einziger
Reparaturaufwand Ausgangsrelais wechseln und Batterie erneuern und SW
neu aufspielen falls mit leere Batterie Power down. Dosbox hat sich
nicht bewährt zum einen verbessert sie den Programmstart nicht wirklich,
auch nicht bei Drosselung des virtuellen Systemtaktes (da die
BIOS-Systemuhr mit dem realen Hauptsystemtakt läuft?) und zum 2. die
Seriellen Schnittstelle mit 5-7 DatenBit und (Bitbanging für die
Handshakeleitungen?) betrieben werden.
Alles in allem ist das alte Thinkpad die Fieldtechnik für das Zeug.
Namaste
Kai A. schrieb:> CNC Maschinen meist.
Hi,
ich wollte mir ein Oszilloskop anschaffen und habe gesehen, dass es
sogar noch moderne - also aktuelle Oszilloskope gibt, die noch den
9poligen SUB-D-Serial-Anschluss haben.
Könnte man sagen, dass die serielle Schnitstelle noch lang nicht "out"
ist?
Das Problem ist oft, daß man die Hardware überrennt. Gabs schon vor 20
Jahren bei z.B. der RTC.
Vielleicht einen Starter/Debugger schreiben der das Programm in
Singlestep laufen lässt und bei jedem Step ein paar NOP`s einfügt?
Jüteboarg schrieb:> Könnte man sagen, dass die serielle Schnitstelle noch lang nicht "out"> ist?
Die Vorstellungen von Microsoft, Intel und Apple sind nicht unbedingt
massgebend für den Maschinenbau. Sonst gäbe es ja nur noch Maschinen mit
Touch Screen Bedienung und Kacheln, das wäre z.B. in einer
ölverschmierten Fertigungshalle ganz toll. Und die Fertigungsprogramme
werden natürlich in der Cloud gespeichert, und Facebook reklamiert alle
Rechte daran für sich.
Georg
Wenn es nur darum geht, dass der Rechner unter DOS "heissläuft" kann ich
dosidle.exe (einfach bei Google suchen) empfehlen. Das ist ein kleines
speicherresidentes Programm welches im Leerlauf die CPU mit Idle
Befehlen etwas schonender behandelt als es normalerweise der Fall ist.
Startet man ein DOS in einer Virtualisierung sieht man schön, dass der
Prozessor zu 100% ausgelastet ist. Nach der Installation von dosidle.exe
geht die CPU Auslastung bei Nichtstun auf Null. Das sollte also auch bei
nicht-virtalisiertem DOS etwas bringen.
Thomas
Peter II schrieb:> http://www.bowe-beregnung.de/images/touchhand.png
Nicht umsonst ist da die saubere, frisch manikürte Hand einer Hausfrau
abgebildet, und nicht ein ölverschmierter Schutzhandschuh.
Ich war mal in einer Fertigunshalle bei Ford, in der die Maschinen
Ölkühlung/Schmierung für die spanende Bearbeitung verwendeten, da
tropfte das Öl von den Wänden. Eine Steuerung zur Reparatur musste erst
mal ausgiebig gereinigt werden, damit man sie überhaupt anfassen konnte,
weil sie mit einem dicken schwarzen Schmierfilm überzogen war.
Georg
Winfried J. schrieb:> das tool stürzt trotz dem zu über 90% im Initprozess ab und kommt mit> einem Overflow raus. Auch in der DOSBOX. Ist der Initprozess überwunden> läuft es stabil.
Dann hast du schlicht den Takt in der DOS-Box nicht weit genug
heruntergedrosselt. RTFM!
DOSBox (http://www.dosbox.com/, nicht cmd/ntvdm) wird von den
Entwicklern auch nicht für Steuerungsaufgaben empfohlen. Die DOSBox wird
für Spiele entwickelt: Benutzer berichten von einem nicht richtig
funktionierenden Spiel, daraufhin wird DOSBox verbessert. Als
Nebeneffekt funktionieren auch viele sonstige Anwendungen.
DOSBox ist keine 100%-Emulation - aus Performance- oder anderen Gründen
gibt es hier und da Abweichungen.
Beispiele:
- Im Protected Mode werden die Segmentgrenzen nicht geprüft (Prüfung bei
jedem Speicherzugriff? Das Ding würde schnarchlahm, siehe Bochs)
- Der 286-Protected-Mode wurde weggelassen, weil nicht von einem Spiel
benötigt
- Wenn die x86-FPU vom Host nicht verwendet werden kann springt die
Floating-Point-C-Library ein - die hat aber nur Doubles -> 64 Bit, der
x87er hat 80 Bit.
- Die Systemzeit ist an den Rechentakt des Emulators geknüpft - solange
DOSBox immer dann die Host-CPU bekommt, wenn sie sie braucht, ist es
einigermaßen synchron, ansonsten läuft sie hinterher. Nur die CMOS-Zeit
wird von der Host-Systemzeit abgeleitet.
- Die System-INTs werden vorwiegend nur soweit implementiert und
getestet, wie sie von Spielen benötigt werden. Nutzt eine Anwendung
einen ausgefalleneren INT: Pech. Das Gleiche bei den CPU-Opcodes.
Wenn der Fräser dennoch nicht in das Werkstück gerammt wird, oder
Schlimmeres, kann man darüber schon etwas erstaunt sein :)
Peter II schrieb:> Wenn du auf LPT verzichten kannst
In den alten Zeiten war der Parallelport oft genau die Schnittstelle,
mit der man die Geräte angesteuert hat, "2xRS232 und VGA Schnittstelle"
würde dann auf Tastatur, Maus und Monitor hindeuten.
Es gab zwar Mäuse für den Anschluss an RS232-Schnittstellen, aber
Tastaturen wurden am PC noch nie darüber angeschlossen (wenn man jetzt
Spezialkonstrukte aus dem Barrierefreiheitslager beiseitelässt).
Sheeva P. schrieb:> In den alten Zeiten war der Parallelport oft genau die Schnittstelle,> mit der man die Geräte angesteuert hat, "2xRS232 und VGA Schnittstelle"> würde dann auf Tastatur, Maus und Monitor hindeuten.
nein, würde es nicht - dafür will er ja PS2
> Die beiden PS2 Schnittstellen dienen zum> gelegentlichen Anschluss von Tastatur und Maus.
*.* schrieb:> DOSBox (http://www.dosbox.com/, nicht cmd/ntvdm) wird von den> Entwicklern auch nicht für Steuerungsaufgaben empfohlen.
Richtig. Das ändert aber rein garnix daran, dass sie das auch kann. Die
Nichtempfehlung dürfte einfach dem amerikanischen Rechtssystem
geschuldet sein.
> DOSBox ist keine 100%-Emulation
Das ist keine Emulation.
> Beispiele:> - Im Protected Mode werden die Segmentgrenzen nicht geprüft (Prüfung bei> jedem Speicherzugriff? Das Ding würde schnarchlahm, siehe Bochs)
Spielt nur bei Fehlern der Software eine Rolle. Gut abgehangene
Steuerungssoftware weist solche Fehler typischerweise nicht mehr auf.
Das hätte nämlich auch auf der Originalhardware massiv gestört...
> - Der 286-Protected-Mode wurde weggelassen, weil nicht von einem Spiel> benötigt
Und auch von keiner mir bekannten Steuerungssoftware. Das liegt daran,
das der einfach mal Scheisse war und man ihn nichtmal mehr ordentlich
verlassen konnte...
> - Wenn die x86-FPU vom Host nicht verwendet werden kann springt die> Floating-Point-C-Library ein - die hat aber nur Doubles -> 64 Bit, der> x87er hat 80 Bit.
Wie sollte es deiner Meinung zu diesem Fall kommen, wenn die DOS-Box auf
einem neuzeitlichen x86-Rechner läuft?
> - Die Systemzeit ist an den Rechentakt des Emulators geknüpft
Genau so, wie sie auf einem echten System an dessen Takt gekoppelt ist.
Unter anderem deswegen ist es ja so wichtig, den virtuellen Takt der
DOS-Box möglichst gut einzustellen.
> - Die System-INTs werden vorwiegend nur soweit implementiert und> getestet, wie sie von Spielen benötigt werden. Nutzt eine Anwendung> einen ausgefalleneren INT: Pech.
Da könnte man aber auch bei einem originalen DOS und einem originalen
BIOS auf originaler Hardware Pech haben. Das wird wohl auch der Grund
sein, warum die Hersteller der Steuerungssoftwares zu jeder Zeit
versucht haben, möglichst wenig "exotisch" zu programmieren...
Tatsächlich nutzen sie von dem ganzen Geraffel, was BIOS und DOS bieten,
für die eigentliche Maschinensteuerung i.d.R. rein garnix. Nur für das
HMI und die Datei-Schnittstellen wird das Zeug benutzt. Und der Bereich
funktioniert in der DOS-Box perfekt, denn das brauchen Spiele ganz
genauso.
Übrigens: auch DOS-Spiele sind überwiegend nach dem Muster gestrickt,
nur das nötigste über DOS und BIOS abzuwickeln. Die eigentliche
Game-Engine läuft i.d.R. 100% autark mit direkten Hardwarezugriffen.
> Das Gleiche bei den CPU-Opcodes.
Das ist Quatsch. Die CPU-Emulationen sind vollständig. Natürlich ist es
möglich, das es noch Fehler in der Emulation gibt. Aber die gibt es
genauso bei echten CPUs. Die Errata von Intel und AMD füllen jedenfalls
problemlos recht viele Textseiten...
> Die Nichtempfehlung dürfte einfach dem amerikanischen Rechtssystem
geschuldet sein.
Nur sind die meisten Entwickler aus Europa. Und im rechtlichen
Zusammenhang wurde das meines Wissens [ich schreibe das, weil Du es auch
darfst] nicht erwähnt.
> Und auch von keiner mir bekannten Steuerungssoftware. Das liegt daran,
das der einfach mal Scheisse war und man ihn nichtmal mehr ordentlich
verlassen konnte...
Schön was Du alles kennst :) Muss man ihn in einer Steuerrungssoftware
verlassen wollen?
> Spielt nur bei Fehlern der Software eine Rolle. Gut abgehangene
Steuerungssoftware weist solche Fehler typischerweise nicht mehr auf.
Das hätte nämlich auch auf der Originalhardware massiv gestört...
Es gibt mindestens ein Spiel, das diesen Mechanismus nutzt, um die
Video-Bank umzuschalten. Ergebnis sind dann schwarze Linien im Bild bei
der DOSBox. Der Kreativität der Programmierer sind keine Grenzen
gesetzt...
> Die CPU-Emulationen sind vollständig.
Hast Du sie verifiziert? Womit? Und selten genutzte Opcodes können keine
Bugs enthalten? Mag ja in den allermeisten Durchläufen nicht relevant
sein, aber einer kann reichen, um den Fräser mal ins Werkstück zu
fahren... das Spiel würde bloß abkacken.
> Wie sollte es deiner Meinung zu diesem Fall kommen, wenn die DOS-Box auf
einem neuzeitlichen x86-Rechner läuft?
Wenn sie auf einem nicht-x86-Rechner läuft (soll es ja noch bzw. in
letzter Zeit verstärkt geben)
> Unter anderem deswegen ist es ja so wichtig, den virtuellen Takt der
DOS-Box möglichst gut einzustellen.
Und dann kommt Windows daher und meint, irgendeinen Cache zu leeren oder
etwas upzudaten, und schon stimmen deine Zeitstempel nicht mehr. Oder
ein Treiber blockiert hin und wieder mal kurz, oder ...
> Da könnte man aber auch bei einem originalen DOS und einem originalen
BIOS auf originaler Hardware Pech haben. Das wird wohl auch der Grund
sein, warum die Hersteller der Steuerungssoftwares zu jeder Zeit
versucht haben, möglichst wenig "exotisch" zu programmieren...
Das ist eine unzulässige Verallgemeinerung. Du kennst die Arbeitsweise
aller Programmierer? Großes Vertrauen. Die Honks haben es oft nicht mal
geschafft, ihre Routinen unabhängig von der Rechengeschwindigkeit zu
machen. CPU zu schnell -> Fehlfunktion. Und das ist nicht nur bei der
Laufzeitkomponente in einer gewissen Pascal-Bibliothek der Fall. Es gab
auch keine riesige Auswahl an BIOS- und MS-DOS-Herstellern, man konnte
von einer gewissen Grundlage ausgehen: "100% IBM-kompatibel". Die
BIOS-Hersteller mussten da auch einen gewissen Aufwand fürs
Reverse-Engineering treiben.
> Tatsächlich nutzen sie von dem ganzen Geraffel, was BIOS und DOS bieten,
für die eigentliche Maschinensteuerung i.d.R. rein garnix. Nur für das
HMI und die Datei-Schnittstellen wird das Zeug benutzt. Und der Bereich
funktioniert in der DOS-Box perfekt, denn das brauchen Spiele ganz
genauso.
Wieder Verallgemeinerung. Es gibt genug Programme, die z.B. die serielle
und parallele Schnittstelle über BIOS ansprechen. Da hatte die DOSBox
auch Probleme. Die HMI- und Dateischnittstellen können auch noch genug
Tretminen enthalten.
> Das ist Quatsch. Die CPU-Emulationen sind vollständig. Natürlich ist es
möglich, das es noch Fehler in der Emulation gibt. Aber die gibt es
genauso bei echten CPUs.
Die Fehler in der Emulation sind eher nicht deckungsgleich mit denen der
echten Hardware, und können somit nicht mal vom Programmierer erwartet
sein. Bis zum Anfang vom 486er gab es praktisch nur Intel und AMD, wobei
AMD von Intel abgekupfert hat. Folglich gibt es Spiele, die auf dem
Cyrix nicht mögen... Und von wegen CPU-Emulation vollständig: Takte pro
Anweisung werden nicht emuliert, d.h. jede Anweisung verbraucht in der
Emulation die gleiche Zeit. Auch ist die Zugriffszeit auf den
Arbeitsspeicher nicht emuliert, der gesamte Speicher hat sozusagen
L1-Cache-Geschwindigkeit. Zeitabhängige Routinen können hier Probleme
machen. Es gibt Spiele, bei denen man es nicht hinbekommt, dass alle
Routinen mit der richtigen Geschwindigkeit laufen.
*.* schrieb:> ...
Diese ganzen theoretischen Überlegungen sind aber gegenstandslos, wenn
man die SW ganz einfach mal in der Dosbox ausprobiert und sie dann doch
läuft.
Was spricht gegen ausprobieren? Dann bleibt man halt mal kurz vom
Werkstück weg und drückt Notaus, wenn was schiefgeht.
> Diese ganzen theoretischen Überlegungen sind aber gegenstandslos, wenn
man die SW ganz einfach mal in der Dosbox ausprobiert und sie dann doch
läuft.
Jo, aber nicht heulen, wenn es nur zu 99,99% läuft.
*.* schrieb:> Jo, aber nicht heulen, wenn es nur zu 99,99% läuft.
Das gleiche gilt dann aber auch, wenn man einen echten Rechner nimmt,
der nicht exakt von dem Typ ist, für den es mal ursprünglich entwickelt
wurde. Oder glaubst du, ein morderner PC mit Core-i-Prozessor und per
PCIe angebundener Schnittstelle verhält sich in jeder Hinsicht zu
100,00% gleich wie der ursprüngliche 486er-Rechner?
MaWin- schrieb:> Diese ganzen theoretischen Überlegungen sind aber gegenstandslos, wenn> man die SW ganz einfach mal in der Dosbox ausprobiert und sie dann doch> läuft.
Richtig, und deshalb habe ich Virtualisierungen und auch Dosbox
probiert. Ich habe eine Elektronik mit abgeschliffenen Chipbezeichnungen
in Verdacht, eine Art Hardware-Passwort zu sein. Sie verbirgt sich
unmittelbar in einem der Schnittstellenstecker der Maschine an den PC.
Und diese scheint mit keiner Virtualisierung kompatibel zu sein. Der
Bildschirm bleibt mit einem nervös blinkendem Unterstrich dunkel. Das
Booten hakt genau an derselben Stelle, als wenn ich diesen Stecker an
einem funktionierenden PC nicht stecke.
Wie gesagt, mit dem MSDOS Image habe ich es schon auf SATA Festplatte
sowie Tastatur und Maus an USB geschafft, möchte aber aus
Beschaffungsgründen versuchen, noch moderner zu werden.
Kurt P. schrieb:> MaWin- schrieb:>> Diese ganzen theoretischen Überlegungen sind aber gegenstandslos, wenn>> man die SW ganz einfach mal in der Dosbox ausprobiert und sie dann doch>> läuft.>> Richtig, und deshalb habe ich Virtualisierungen und auch Dosbox> probiert. Ich habe eine Elektronik mit abgeschliffenen Chipbezeichnungen> in Verdacht, eine Art Hardware-Passwort zu sein. Sie verbirgt sich> unmittelbar in einem der Schnittstellenstecker der Maschine an den PC.> Und diese scheint mit keiner Virtualisierung kompatibel zu sein. Der> Bildschirm bleibt mit einem nervös blinkendem Unterstrich dunkel. Das> Booten hakt genau an derselben Stelle, als wenn ich diesen Stecker an> einem funktionierenden PC nicht stecke.>> Wie gesagt, mit dem MSDOS Image habe ich es schon auf SATA Festplatte> sowie Tastatur und Maus an USB geschafft, möchte aber aus> Beschaffungsgründen versuchen, noch moderner zu werden.
Nun dann kannst du ja schauen auf welchen Pins dieser die Kontakte hat.
Immerhin hat der Serialport die Pins
TxD
RxD
RTS
CTS
DSR
GND
DCD
DTR
RI
und meist werden bei Virtualisierung die TxD und RxD genommen und nicht
immer die ganzen anderen Pins.
Wenn die aber darüber auch eine Kommunikation gemacht haben dürfte dies
das Problem sein.
Die Serial2USB Adapter haben ja auch fast nur noch TxD und RxD da die
anderen so nicht mehr gebräuchlich sind.
Evtl kannst du ja auch nen LED Tester zwischen schalten dann siehst du
anhand der LEDs ob auf den anderen Pins auch was läuft bei der Alten
Maschine und der neuen wo es nicht läuft...
Kurt P. schrieb:> Richtig, und deshalb habe ich Virtualisierungen und auch Dosbox> probiert. Ich habe eine Elektronik mit abgeschliffenen Chipbezeichnungen> in Verdacht, eine Art Hardware-Passwort zu sein. Sie verbirgt sich> unmittelbar in einem der Schnittstellenstecker der Maschine an den PC.
Könntest du villeicht mal ein wenig konkreter werden? Welche
Schnittstelle? und wie genau ist die verdächtige Hardware daran
angeschlossen?
Sie muss sich ja in der Maschine befinden, den PC willst du ja gegen was
anderes austauschen. Dieses andere Teil hätte diese Hardware ja
garnicht. Hoffentlich wenigstens tatsächlich die Schnittstelle in echter
Hardware. Es ist aber keinesfalls sicher, dass die sich dann auch
genauso verhält wie die Schnittstelle im Original-Rechner. Das ist sogar
eher unwahrscheinlich, schon durch die zwingend andere Busanbindung...
Kurt P. schrieb:> Richtig, und deshalb habe ich Virtualisierungen und auch Dosbox> probiert. Ich habe eine Elektronik mit abgeschliffenen Chipbezeichnungen> in Verdacht, eine Art Hardware-Passwort zu sein. Sie verbirgt sich> unmittelbar in einem der Schnittstellenstecker der Maschine an den PC.
Ist es schon soweit, dass man nicht mehr weiß, das es ein Dongel ist.
Die haben zu Recht ihre Mucken.
