Hallo, mehrere baugleiche Maschinen haben hier einen MSDOS 6.22 PC im Bauch. Die IDE FAT 16 Festplatten und bisweilen die Computer sterben an Altersschwäche, vermutlich auch unterstützt durch die Vibrationen in der Maschine. Es ist gelungen von IDE Festplatte und Motherboard auf SATA umzuziehen, um zukunftsfähig zu bleiben. Jetzt frage ich mich, ob man noch einen Schritt weitergehen kann und insbesondere wegen der Vibrationen auf SSD umzieht. Spricht da etwas dagegen? Ich denke da insbesondere an den fehlenden Trim-Befehl, der vermutlich bei MSDOS 6.22 nicht unterstützt wird. Um entsprechenden Ideen den Wind aus den Segeln zu nehmen: Auf Dosbox und virtualisiert funktioniert das Programm nicht.
Hans schrieb: > Spricht da etwas dagegen? Ich denke da insbesondere an den > fehlenden Trim-Befehl, der vermutlich bei MSDOS 6.22 nicht unterstützt > wird. ja und? Ohne Trim ist die Festplatte etwas langsamer beim schreiben, aber immer noch schneller als alles was DOS jemand ansprechen kann.
Kann DOS nicht nur 2GB adressieren? Da würde ja schon die kleinste SSD ausreichen. Wenn nicht viel geschrieben wird, könnte vielleicht auch eine SD-Karte oder USB-Stick helfen?
:
Bearbeitet durch User
Oder solche Module wenn das DOS nicht so groß ist. http://www.pollin.de/shop/dt/MDEyODkyOTk-/Computer_und_Zubehoer/Hardware/Festplatten_intern/DiskOnModule_PQI_IDE_128_MB.html Einfach aufstecken, fertig. Größer und teurer gibt es die bei Reichelt usw.. Auch als 44-Pin Version. Immer noch einfacher als mit SSD.
michael_ schrieb: > Immer noch einfacher als mit SSD. was ist an SSD nicht einfach? Das SATA Kabel steckt sich zumindest einfacher als ein IDE kabel an.
Hallo Hans, Genau die Probleme hatten wir auch. Von Transcend gibt es die einzig sinnvolle Lösung: 40 Pin http://de.transcend-info.com/Products/No-531 44 Pin http://de.transcend-info.com/Products/No-533 Ganz wichtig ist auch dass die SSD eine SLC ist keine MLC, dann kann DOS damit perfekt ewig arbeiten. Uns sind nach etlichen Jahren eher die Mainboards flöten gegangen, da die Kondensatoren ausliefen. Aber es läuft bis Heute und das in einem Sicherheitsrelevantem bereich ;-)
Marco K. schrieb: > Ganz wichtig ist auch dass die SSD eine SLC ist keine MLC, dann kann DOS > damit perfekt ewig arbeiten. das ist doch Unsinn. Wenn man eine 128GB SSD mit MLC und davon 2GB für Dos nutzt dann hat sie so viele Reserve Sektoren das es noch ein paar tausend Jahre reicht. Und warum sollte man immer noch auf IDE Setzen und nicht auf SATA?
Marco K. schrieb: > Von Transcend gibt es die einzig sinnvolle Lösung: Dank neuem Mainboard hat er jetzt vmtl. kein IDE mehr.
A. K. schrieb: > Dank neuem Mainboard hat er jetzt vmtl. kein IDE mehr Es gibt ja sowohl Adapter IDE->SATA als auch SATA->IDE. Aber das ist zuviel um die Ecke gedacht, SATA->SATA ist doch am einfachsten. Georg
Georg schrieb: >> Dank neuem Mainboard hat er jetzt vmtl. kein IDE mehr > Aber das ist zuviel um die Ecke gedacht, Eben. Erst Mobo wechseln und dann für eine SSD einen IDE-Konverter verwenden wär pervers.
Hallo, als Verfasser des Originalpostings würde ich gern noch einmal auf das Ursprungsthema "SATA-SSD an MSDOS 6.22" zurückgehen. Die bisherige Diskussion hat sich vielfach auf IDE-SSD konzentriert. Eine SATA-SSD nutzt ihre physischen Speicherzellen unter einem ausdrücklich sie unterstützenden Betriebssystem gleichmäßig ab. Würde das unter MSDOS 6.22 auch geschehen oder ist mit einer ungleichmäßigen Abnutzung und damit deutlich verkürzten Standzeit zu rechnen? Die SATA-SSD müsste ebenso wie die derzeite SATA-Festplatte mit einer primären 2GB Partition versehen werden. Ansonsten bleibt die restliche SSD unpartitioniert. Würde unter MSDOS 6.22 die SSD die gesamte physische Kapazität der Festplatte abnutzen (was vorteilhaft für die Standzeit wäre) oder nur 2GB davon? Da häufig verkauft und durchweg gut bewertet, habe ich an diese SSD gedacht: http://www.mindfactory.de/product_info.php/60GB-Kingston-SSD-Now-V300-2-5Zoll--6-4cm--SATA-6Gb-s-MLC-asynchron--SV30_820946.html
Hans schrieb: > Eine SATA-SSD nutzt ihre physischen Speicherzellen unter einem > ausdrücklich sie unterstützenden Betriebssystem gleichmäßig ab. wo hast du das gelesen? Ich habe bis jetzt noch kein Dateisystem im Datenblatt einer SSD gesehen > Würde > das unter MSDOS 6.22 auch geschehen oder ist mit einer ungleichmäßigen > Abnutzung und damit deutlich verkürzten Standzeit zu rechnen? nein, weil das Dateisystem meines Wissens egal ist. > Die SATA-SSD müsste ebenso wie die derzeite SATA-Festplatte mit einer > primären 2GB Partition versehen werden. Ansonsten bleibt die restliche > SSD unpartitioniert. Würde unter MSDOS 6.22 die SSD die gesamte > physische Kapazität der Festplatte abnutzen (was vorteilhaft für die > Standzeit wäre) oder nur 2GB davon? ja, Wear Leveling ist die Partitionierung egal
Hans schrieb: > Eine SATA-SSD nutzt ihre physischen Speicherzellen unter einem > ausdrücklich sie unterstützenden Betriebssystem gleichmäßig ab. Würde > das unter MSDOS 6.22 auch geschehen oder ist mit einer ungleichmäßigen > Abnutzung und damit deutlich verkürzten Standzeit zu rechnen? Unter so altem DOS bleibt ein großer Teil der SSD unparitioniert. Das sollter der Controller erkennen. Unter DOS wird i.d.R. erheblich weniger auf die Platte geschrieben als unter Windows. Bevor Du Dir da Sorgen machst würde ich erstmal feststellen wieviel im Betrieb überhaupt geschrieben wird. Hans schrieb: > Würde unter MSDOS 6.22 die SSD die gesamte > physische Kapazität der Festplatte abnutzen (was vorteilhaft für die > Standzeit wäre) oder nur 2GB davon? Wenn der SSD-Controller Chip halbwegs korrekt arbeitet verteilen sich die Zugrifffe mittels Wear-leveling auf den ganzen Bereich.
Jim M. schrieb: > Unter so altem DOS bleibt ein großer Teil der SSD unparitioniert. Das > sollter der Controller erkennen. warum sollt er das erkennen, und was geht ihm das überhaupt an? Der Controller kennt Sektoren und muss wissen ob sie belegt sind oder nicht.
Stimmt, CompactFlash wäre die praktischte Lösung (mit einem Adapter auf IDE), weil diese ein IDE IF hat.
Random .. schrieb: > Stimmt, CompactFlash wäre die praktischte Lösung (mit einem Adapter auf > IDE), weil diese ein IDE IF hat. und wenn er gar kein IDE mehr hat?
Peter II schrieb: > Random .. schrieb: >> Stimmt, CompactFlash wäre die praktischte Lösung (mit einem Adapter auf >> IDE), weil diese ein IDE IF hat. > > und wenn er gar kein IDE mehr hat? ok :-)
Hans schrieb: > Eine SATA-SSD nutzt ihre physischen Speicherzellen unter einem > ausdrücklich sie unterstützenden Betriebssystem gleichmäßig ab. Würde > das unter MSDOS 6.22 auch geschehen oder ist mit einer ungleichmäßigen > Abnutzung und damit deutlich verkürzten Standzeit zu rechnen? Die Betriebssystem-Unterstützung beschränkt sich darauf, dass das OS der SSD mitteilt, welche Blöcke derzeit unbenutzt sind. Das kann die Platte so ohne Kenntnis der Dateisystemstruktur schliesslich nicht wissen. Ohne den SATA TRIM-Befehl sieht die SSD alle jemals verwendeten Blöcke als mit Nutzdaten belegt an. Ob das in Deinem Anwendungsfall irgendeinen messbaren Unterschied auf die Lebensdauer hat, wage ich zu bezweifeln. Wenn Du auf Nummer sicher gehen willt, lass 10-20% der Kapazität frei. Frei heisst unpartitioniert und niemals jemand drauf schreiben lassen, der kein Trim beherrscht.
soul e. schrieb: > Wenn Du auf Nummer sicher > gehen willt, lass 10-20% der Kapazität frei. er will sogar viel mehr Frei lassen. > Die SATA-SSD müsste ebenso wie die derzeite SATA-Festplatte mit einer > primären 2GB Partition versehen werden. Ansonsten bleibt die restliche > SSD unpartitioniert
Hans schrieb: > Die SATA-SSD müsste ebenso wie die derzeite SATA-Festplatte mit einer > primären 2GB Partition versehen werden. Achte dabei auf die Ausrichtung der Blöcke (z.B. parted mit "-a optimal" starten). Alles weitere sollte das Wear-Leveling übernehmen, sonst taugt die SSD nix.
Peter II schrieb: >> Unter so altem DOS bleibt ein großer Teil der SSD unparitioniert. Das >> sollter der Controller erkennen. > > warum sollt er das erkennen, und was geht ihm das überhaupt an? Der > Controller kennt Sektoren und muss wissen ob sie belegt sind oder nicht. Wenn die SSD frisch war, oder mit einem entsprechenden Tool als frisch definiert wurde, dann ist der SSD der vom DOS nicht ansprechbare Teil als unbelegt bekannt und wird vom wear levelling entsprechend genutzt.
Angehängte Dateien:
-
Converter.jpg
34 KB
Hans schrieb: > Jetzt frage ich mich, ob man noch einen > Schritt weitergehen kann und insbesondere wegen der Vibrationen auf SSD > umzieht. Spricht da etwas dagegen? Ich denke da insbesondere an den > fehlenden Trim-Befehl, der vermutlich bei MSDOS 6.22 nicht unterstützt > wird. Da die heutigen SSDs größer 2GB sind, würde ich keinen Schaden erwarten. Allerdings ist mir noch nicht klar, wie DOS6.22 diese SATA ohne passenden Treiber ansteuern kann. XP hat das erst ab SP3 geschafft. Ein Versuch wäre ein IDE-SATA-Converter wie z.B. der LogiLink AD0005A. Ob es auch mit der Geschwindigkeit Probleme (z.B. bei Zählschleifen) gibt wäre noch zu erforschen.
oszi40 schrieb: > Allerdings ist mir noch nicht klar, wie DOS6.22 diese SATA ohne > passenden Treiber ansteuern kann. XP hat das erst ab SP3 geschafft. Ein > Versuch wäre ein IDE-SATA-Converter wie z.B. der LogiLink AD0005A. Ob es > auch mit der Geschwindigkeit Probleme (z.B. bei Zählschleifen) gibt wäre > noch zu erforschen. einfach über die Bios Routinen wie es dos schon immer gemacht hat. Man müsste eventuell vorher von AHCI auch IDE im Bios umstellen.
Hans schrieb: > Die SATA-SSD müsste ebenso wie die derzeite SATA-Festplatte mit einer > primären 2GB Partition versehen werden. Ansonsten bleibt die restliche > SSD unpartitioniert. Mit den Kommentaren wird nun klar, dass dem Programm mehr als der 58GB große unpartitionierte Bereich zum lustigen Schreiben und anschließenden Löschen verbleibt. Ich wage mal die Prognose, dass das MSDOS Programm selbst für ein einmaliges Beschreiben Jahre braucht. Zumindest aus dieser Warte müsste die SSD mich überleben. Klar ist dabei, dass die Elektronik um die Speicherzellen herum auch früher sterben kann. Zumindest könnte die SSD deutlich länger leben als eine Festplatte und daher bei nahezu gleichem Preis für die Variante mit kleinstem Speicherplatz zu bevorzugen sein.
Dein DOS schreibt erst mal gar nichts zurück. Es ist dann höchstens dein Programm. Deine SSD schläft ein vor Langerweile. Laut einem Artikel der c't ist die Ausfallwahrscheinlichkeit etwa gleich. Aber unter Bedingungen von WIN, wo täglich Virenscanner, Update usw. drüberrattern. Also keine Sorge!
Peter II schrieb: > einfach über die Bios Routinen wie es dos schon immer gemacht hat. Das kann ich aus den Erfahrungen bestätigen, die ich beim Umzug des in Frage stehenden MSDOS Programmes von IDE auf SATA gewonnen habe. Es hat gedauert, bis man eine funktionierende Einstellung gefunden hatte, ohne die Innereien des Programmes zu kennen. Problematisch waren auch die vielen benötigten alten Schnittstellen. Da mussten erst die seltenen Kabel beschafft werden, mit dem sie vom Motherboard zum Slotblech geführt wurden. Erst dann erschienen sie im BIOS und erst dann konnte heraus gefunden werden, ob sie sich auf die vom Programm benötigte Anschluss Nummer und Adresse mappen ließen. Mit PCI Karten war das zuvor zwar schon gelungen, aber trotzdem mochte das Programm diese nicht. Schlussendlich funktionierte nur das, was direkt auf dem Motherboard implementiert war. Zudem läuft das Ganze nur mit Hardware-Dongle, der vom IDE PC übernommen wurde. All das ist dann wohl auch der Grund dafür, dass unter Virtualisierung nichts zum Laufen gebracht werden konnte. > Man müsste eventuell vorher von AHCI auch IDE im Bios umstellen. Das hat das ansonsten zickige Programm zu meiner Verwunderung nicht benötigt. Ein Glück, denn das schlussendlich funktionierende Motherboard bietet den Punkt nicht an. Jetzt aber steht das Muster, um alle Maschinen im Falle eines PC Defekts zu updaten.
Hans schrieb: > Da mussten erst die seltenen Kabel beschafft werden, mit dem sie vom > Motherboard zum Slotblech geführt wurden. Erst dann erschienen sie im > BIOS Unwahrscheinlich. Der PC bekommt nicht mit, ob da ein Kabel gesteckt ist oder nicht; die Schnittstellen tauchen natürlich auch so im BIOS auf.
Hans schrieb: > Peter II schrieb: >> einfach über die Bios Routinen wie es dos schon immer gemacht hat. > > Das kann ich aus den Erfahrungen bestätigen, die ich beim Umzug des in > Frage stehenden MSDOS Programmes von IDE auf SATA gewonnen habe. Das nennt sich INT-13. Da ist es dann egal, ob über MFN, SCSI, IDE, ... angeschlossen wird. Hans schrieb: > Das hat das ansonsten zickige Programm zu meiner Verwunderung nicht > benötigt. Gar nicht zickig! DOS ist ehrlich, geradlinig, überschaubar und echtzeitfähig :-)
Hans schrieb: > Mit > PCI Karten war das zuvor zwar schon gelungen, aber trotzdem mochte das > Programm diese nicht. Schlussendlich funktionierte nur das, was direkt > auf dem Motherboard implementiert war Was willst du erwarten, wenn das Programm die Hardware an bestimmten Adressen erwartet wie z.B. 3F8 - PCI-Interfaces haben ganz andere Adressen und PnP kann DOS halt nicht. Georg Korrektur: (3) NM9835M - Drivers for NM9835 (2S1P or 1S1P) PCI I/O card DOS - DOS Mode Driver Ver 3.00 Es gibt also DOS-Treiber für serielle und parallele Schnittstellen, aber ich weiss nicht ob die dein Problem lösen - bestimmt nicht, wenn dein Programm garkeine Treiber benutzt, sondern die Hardware direkt, wie unter DOS sehr beliebt. Probiert habe ich sowas nie.
Georg schrieb: > Es gibt also DOS-Treiber für serielle und parallele Schnittstellen, aber > ich weiss nicht ob die dein Problem lösen - bestimmt nicht, wenn dein > Programm garkeine Treiber benutzt, sondern die Hardware direkt, wie > unter DOS sehr beliebt. Probiert habe ich sowas nie. Serielle Schnittstellen wurden unter DOS so ziemlich nie per BIOS angesprochen. Entweder direkt, oder durch so etwas wie den separaten FOSSIL Treiber.
Rufus Τ. F. schrieb: >> Da mussten erst die seltenen Kabel beschafft werden, mit dem sie vom >> Motherboard zum Slotblech geführt wurden. Erst dann erschienen sie im >> BIOS > > Unwahrscheinlich. Der PC bekommt nicht mit, ob da ein Kabel gesteckt ist > oder nicht; die Schnittstellen tauchen natürlich auch so im BIOS auf. Für mich war das auch eine neue Erfahrung, dass es bei diesem Motherboard eben nicht geschah. Interne- und USB-Laufwerke werden auch dann angezeigt, wenn sie nicht ansteckt sind, im letzteren Fall mit dem Hinweis "not present". Bei Slotblechen hingegen tauchen die zugehörigen Schnittstellen nur auf, wenn der zugehörige Stecker ans Motherboard angesteckt ist. Dann erst wird klar, welche Konfigurationsmöglichkeiten es gibt. Zunächst hatte ich das nur vermutet. Gewissheit hatte ich erst, nachdem ich dieser habhaft wurde.
Hans schrieb: > Für mich war das auch eine neue Erfahrung, dass es bei diesem > Motherboard eben nicht geschah was war das für ein Mainboard?
Georg schrieb: > Es gibt also DOS-Treiber für serielle und parallele Schnittstellen, aber > ich weiss nicht ob die dein Problem lösen - bestimmt nicht, wenn dein > Programm garkeine Treiber benutzt, sondern die Hardware direkt, wie > unter DOS sehr beliebt. Georg schrieb: > Es gibt also DOS-Treiber für serielle und parallele Schnittstellen, Genau diese habe ich verwendet und damit auf die richtige Adresse mappen können. > aber ich weiss nicht ob die dein Problem lösen Wie ich schrieb, ist das Problem schon gelöst, indem ich die Onboard Schnittstellen nutzbar machen konnte. > - bestimmt nicht, wenn dein > Programm garkeine Treiber benutzt, sondern die Hardware direkt, wie > unter DOS sehr beliebt. Das ist genau das, was ich vermute. Mit einem anderen DOS Programm funktionieren die Schnittstellen auf PCI Karten, nur mit dem hier in Frage stehenden nicht.
Hans schrieb: > Das ist genau das, was ich vermute. Mit einem anderen DOS Programm > funktionieren die Schnittstellen auf PCI Karten, nur mit dem hier in > Frage stehenden nicht. dann muss nicht mal an der Zugriffsart liegen. Es gibt Programm das ist die IO-Adresse fest hinterlegt, gute Programm lesen die Adresse aus dem Bios aus - dann funktioniert das auch mit anderen Adressen
Peter II schrieb: > was war das für ein Mainboard? Ich komme nicht ran, da der PC jetzt in der laufenden Maschine sitzt. Eine Typbezeichnung des Motherboards konnte ich nicht entdecken. Das war eingepfercht und großenteils vom CPU Abluftschacht bedeckt. Ich vermute mal, es ist nur innerhalb des Komplett-PCs erhältlich, der von der Stange in Büros herumsteht.
Hans schrieb: > Bei Slotblechen hingegen tauchen die zugehörigen > Schnittstellen nur auf, wenn der zugehörige Stecker ans Motherboard > angesteckt ist. Der muss dann eine Möglichkeit zur Erkennung gehabt haben, z.B. eine Kurzschlussbrücke zwischen 2 Pins. Deshalb waren das dann auch Spezialkabel. Ansonsten hat Rufus recht, der PC kann kein angeschlossenes Kabel detektieren, nicht mal bei Ethernet - da muss am anderen Ende was sein. Und speziell bei RS232C ist auch das ohne zusätzliche Hardware nicht prüfbar, weil sich beim Verbinden mit der Gegenstelle meistens kein Signal ändert - unverbundene Eingänge nehmen den Default-Wert an, und das ist dasselbe wie der inaktive Signalzustand. So ganz sinnlos ist so eine Kodierung nicht, es ist schon ein Komfort-Fortschritt, wenn nur Schnittstellen angezeigt werden, die auch am Gehäuse verfügbar sind, jedenfalls für unbedarfte Anwender. Georg
Wie wäre es denn mit so etwas: http://www.amazon.de/SATA-adapter-card-M-ware%C2%AE-ID10232/dp/B00530S5P4 Vielleicht hilft das hier auch weiter: http://www.computerbase.de/forum/showthread.php?t=777216
Erfahrungsbericht aus der Praxis: Wir setzen ausschließlich auf SSDs von swissbit, die gibts auch in SLC mit PATA oder SSD Schnittstelle. Die kosten zwar etwas mehr, dafür ausgezeichneter Support und sehr zuverlässige Funktion. - You get what you pay for - :)
Georg schrieb: > Ansonsten hat Rufus recht, der PC kann kein > angeschlossenes Kabel detektieren, nicht mal bei Ethernet - da muss am > anderen Ende was sein. Nachdem es PHYs zu kaufen gibt, die eine Unterbechung am anderen Ende des Kabels lokalisieren können, würde es mich sehr wundern, wenn es nicht auch spezielle Netzwerkkarten gäbe mit dieser Eigenschaft.
Dann müsste solch eine Netzwerkkarte auch erkennen können, wenn ein nackter (d.h. nicht mit einem Kabel verbundener) RJ45-Stecker eingesteckt wird. Etwas anderes liegt vor, wenn prinzipiell ein Link besteht (d.h. am anderen Kabelende eine Gegenstelle in Form eines Switches, Hubs, einer anderen Netzwerkkarte oder was auch immer vorliegt) und nur Einzeladern gestört sind.
vn n. schrieb: > Nachdem es PHYs zu kaufen gibt, die eine Unterbechung am anderen Ende > des Kabels lokalisieren können, Es ist kein Problem, so etwas zu erkennen. Jeder Ethernet-Tester kann das, mit Angabe der Länge vom Kabel oder bis zur Unterbrechung. Aber das ist eben eine Aufgabe für Messequipment und nicht für 08/15 PCs.
A. K. schrieb: > Es ist kein Problem, so etwas zu erkennen. Jeder Ethernet-Tester kann > das, mit Angabe der Länge vom Kabel oder bis zur Unterbrechung. Aber das > ist eben eine Aufgabe für Messequipment und nicht für 08/15 PCs. https://ttcshelbyville.files.wordpress.com/2013/01/cable.jpg es bieteten aber einige an
Peter II schrieb: > es bieteten aber einige an Klar, als Goodie kann man das auch anbieten. Aber man kann nicht unbedingt erwarten, dass es in einem bliebigen Adapter drin steckt. Und erst recht nicht, dass man unter DOS damit einen Blumentopf gewinnen kann, egal ob es um Ethernet, IDE oder SATA geht.
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.