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.
http://www.b-plus.com/uploads/media/20160713_PC104Board.pdf Erste Muster kann man seit diesem Monat bestellen. Soll mind. 10 Jahre lieferbar sein und einen "echten" ISA-Bus haben. Stand neulich in der Markt&Technik.
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.
Schau dir mal soekris.com Europe an, das schwächere Board, PCI lpt Schnittstelle hinzufuegen.
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: > daß manches alte Programm direkt in den RAM > schrieb und früher (aus Zeitgründen) von dort Werte abgeholt wurden ... Zeitmaschine
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
Es ist doch per Definition so dass ein PC kompatibel zu MSDOS sein muss , sonst ist's ja "nur" ein Homecomputer
Auch heute bootet so manche BIOS Aktualisierung noch ins DOS.
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
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
"Mehrere Industriemaschinen laufen mit MSDOS. " Hi, was für Industriemaschinen sind denn das? Irgendwelche Fräsen oder Bohrmaschinen?
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
Georg schrieb: > 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, http://www.bowe-beregnung.de/images/touchhand.png
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.
Dass lpt oder rs232 durchgereicht wird muss aber auch konfiguriert werden, dann läuft es.
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.
Thread beobachten
Seitenaufteilung abschalten
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.