delay-Funktion für DOS

[JimBim]

Hallo,
ich habe folgendes Problem: Ich würde in C++ (möglicherweise mit Inline-Assembler) gern eine delay-Funktion für DOS schreiben. Also im Prinzip das gleiche, was die Funktion Sleep in Windows macht, nur eben in DOS.

Wichtig ist mir jetzt aber die Tatsache, dass die Funktion prozessorschonend ist. Das heißt, sowas hier:

void delay(int milliseconds)
{
clock_t start = clock();

while ((clock() - start) * 1000 / CLOCKS_PER_SEC < milliseconds)
{
// Do nothing.
}
}

kommt nicht in Frage. Denn diese Funktion lässt den Prozessor sofort auf voller Leistung arbeiten. Und auch wenn DOS gleichzeitig nur ein Programm laufen lassen kann und man sich somit keine Sorgen um andere Anwendungen machen braucht, finde ich es nicht gut, für eine simple Wartefunktion gleich mal den Prozessor auf Maximum laufen zu lassen. Benutzer mit lauten Lüftern werden sich freuen, wenn wegen sowas das Geratter erst richtig losgeht. Ich suche also wirklich etwas, das das Programm für diese Zeit tatsächlich anhält.

Turbo C++ hat eine Funktion namens delay, aber die macht genau das, was ich nicht will, und setzt die Prozessorauslastung hoch. Dann gibt es dort noch eine Funktion sleep. Bei der bleibt der Prozessor schön unten, aber die kann nur ganze Sekunden warten, ich brauch aber Millisekunden.

Im Prinzip brauche ich also eine Funktion, die prozessorschonend wie das sleep ist, aber millisekundengenau wie delay. (Also, wie gesagt, das, was Sleep in Windows bereits kann.) Was muss ich dafür tun?

[DOSferatu]

Soweit ich mich erinnere, gibt's da so einen WAIT Befehl, der so lange die CPU idlen läßt, bis irgend ein Interrupt von außen sie aufweckt. Könnte man mit dem TimerTick (IRQ 0, INT 08) kombinieren.
Müßte da aber noch mal genauer nachforschen.

Aber: Normalerweise läuft die CPU unter DOS immer mit voller Leistung (außer man hat es im BIOS anders eingestellt), weil DOS selber kein Power Management unterstützt.

[JimBim]

Leider kenne ich mich mit Assembler und den ganzen Low Level-Befehlen gar nicht aus. Was müsste ich also lernen, um so einen Timer zu implementieren, ohne gleich ein ganzes Kompendium zu studieren?


"Aber: Normalerweise läuft die CPU unter DOS immer mit voller Leistung (außer man hat es im BIOS anders eingestellt), weil DOS selber kein Power Management unterstützt."

Klar, aber ich denke mal, dass sie nur in voller Leistung läuft, solange sie auch wirklich was macht. Das heißt, wenn das Programm wartet, dass man bei einem cin.get() auf Enter drückt, wird während der Wartezeit wohl kaum 100% Prozessorauslastung sein. (Zumindest denke ich das.) Und genau darauf will ich hinaus: Dass das delay wirklich eine Wartefunktion ist, damit er in der Zeit eben nicht eine Million Mal durch eine while-Schleife zischt, um ständig die Zeit abzufragen.

[freecrac]

Leider kenne ich mich mit Assembler und den ganzen Low Level-Befehlen gar nicht aus. Was müsste ich also lernen, um so einen Timer zu implementieren, ohne gleich ein ganzes Kompendium zu studieren?


"Aber: Normalerweise läuft die CPU unter DOS immer mit voller Leistung (außer man hat es im BIOS anders eingestellt), weil DOS selber kein Power Management unterstützt."

Klar, aber ich denke mal, dass sie nur in voller Leistung läuft, solange sie auch wirklich was macht. Das heißt, wenn das Programm wartet, dass man bei einem cin.get() auf Enter drückt, wird während der Wartezeit wohl kaum 100% Prozessorauslastung sein. (Zumindest denke ich das.) Und genau darauf will ich hinaus: Dass das delay wirklich eine Wartefunktion ist, damit er in der Zeit eben nicht eine Million Mal durch eine while-Schleife zischt, um ständig die Zeit abzufragen.

Ich denke schon das fast 100% Prozessorauslastung auch beinm Warten auf eine Enter-Taste im Realmode unter DOS vorhanden sind. Denn nebenbei werden ja auch noch einige Interrups ausgeführt.
Zwar werden dann nicht alle vorhandenen Prozessor-Einheiten verwendet, aber die Integer-Einheiten werden bestimmt voll ausgelastet. Andere Einheiten wie die FPU, oder SIMD-Einheiten werden aber nur dann benutzt, wenn Anwendungen solche Befehle verwenden.

Dirk

[JimBim]

Was, echt? Das heißt, wenn ich ganz normal am Command Prompt warte, dann läuft der Prozessor bereits auf Hochtouren?

[freecrac]

Was, echt? Das heißt, wenn ich ganz normal am Command Prompt warte, dann läuft der Prozessor bereits auf Hochtouren?

Ja so könnte man es umschreiben, zu mindest der Integerbereich läuft dann quasi auf Hochtouren. Um aber wirklich eine große CPU-Last zu erzeugen, dafür muss aber ein Mix aus allen Befehlen verarbeitet werden. DOS verwendet aber nur wenige Befehle und kennt auch noch keine SIMD-Einheiten(MMX,XMM,SSE,3DNow) und deren Befehle. Auch wird der Protectmode und die Einheites davon nur marginal benutzt wenn man einen EMS-Mammorymanager verwendet.
Auch bin ich mir nicht sicher ab DOS für sich selber überhaupt die FPU verwendet. Also nur für das Warten auf eine User-Eingabe bestimmt nicht.

Den CPU-Zusatand "Idle" kennt DOS auch noch nicht.

Dirk

[Dosenware]

Was, echt? Das heißt, wenn ich ganz normal am Command Prompt warte, dann läuft der Prozessor bereits auf Hochtouren?

Jepp, das kannst du bereits im Bios erkennen, dann sind keinerlei Stromsparmodi aktiv und mein Core I7 hat 56°C - unter Win sinds dann nur noch 39°C.

[DOSferatu]

Das Ganze liegt daran, daß die Entwicklung von (MS-) DOS nur bis 1994 geführt wurde (ohne jetzt mal den DOS-Untersatz von Win9x zu berücksichtigen). Das war noch zu einer Zeit, als ein normaler PC noch nicht (wie heute) als elektrische Raumheizung benutzt werden konnte. Es waren noch keine "Idle-" oder "Stromsparmodi" in Motherboards/CPUs eingebaut (die den Rechner langsamer machen und dadurch auch kühler), da man froh war, wenn der Rechner so schnell wie möglich war. In PCs waren noch keine 3 GHz CPUs eingebaut. Das normale MS-DOS v6.22 kann eben keine Dinge berücksichtigen/unterstützen, die irgendwann Jahre später überhaupt erst quasi "erfunden" wurden, bzw. in PCs eingebaut wurden. Wenn man das will, muß man es entweder selbst nachrüsten (irgendwelche Subroutinen einbauen, die die Stromsparmodi der CPUs aktivieren, bzw. diese Motherboardtreiber selber schreiben (ja, selbst für das verdammte MoBo brauchts heute schon Treiber - es ist eine steinkalte Schande...)) - ODER mit einer Zeitmaschine ca. 17-18 Jahre in die Vergangenheit reisen und Microsoft überzeugen, daß sie in ihr DOS Support für Dinge einbauen, die noch gar nicht erfunden sind.
DOS ging zwar - so lange es weiterentwickelt wurde - immer mit der Zeit, unterstützte größeren Speicher, größere Festplatten, etc. Aber alles, was danach in PCs reingepflanzt wurde, wird (logischerweise) natürlich nicht mehr unterstützt. DOS war eben nie für diese 3,x GHz Quadcore Heizlüfter mit Spielfunktion, die es heute gibt, konzipiert worden.

[JimBim]

Interessant. Ich hab's jetzt auch mal selbst gesehen. Ich hab mir unter VirtualPC mal Windows 98 installiert und dann parallel in meinem richtigen Windows den Taskmanager angemacht: Wie erwartet liegt die Auslastung bei 0 bis 1%. Aber sobald ich die virtuelle Maschine im DOS-Modus neu starte (also der richtige DOS-Modus von Windows 98, nicht nur ein Eingabeaufforderungsfenster aus dem Startmenü) springt die Auslastung sofort auf Maximum und bleibt dort.
Tja, wenn das so ist, dann hat sich meine obige Frage wohl erledigt. Denn dann ist das ja das standardmäßige und erwartete Verhalten unter DOS und ich brauche für mein DOS-Programm nichts dergleichen einbauen, weil das früher auch nie gemacht wurde.

[Dosenware]

ja, selbst für das verdammte MoBo brauchts heute schon Treiber - es ist eine steinkalte Schande...

1. Brauchte man das schon immer - nur hieß es damals noch Bios
2. erinnere dich an W3.11 und den 32Bit Festplattenzugriff (da brauchte es auch bereits Chipsatztreiber)
3. Wie willst du funktionen mit der bestmöglichen Geschwindigkeit über die Weichwareinterrupts der Biosse umsetzen? - mal abgesehen davon das bei dem aktuellem Funktionsumfang der damals vorgesehene Speicherbereich überläuft.

und 4. funktioniert das Mainboard auch ohne Treiber - nur lassen sich dann einige Funktionen (allen Voran AHCI (Sata)) nicht benutzen - selbst mein Core i7 startet noch Dos (und auf IDE-Emulation umgestellt, werden auch die Festplatten erkannt)

also nicht auf die neue Technik schimpfen und gleichzeitig andere neue Technik verteidigen...

[DOSferatu]

1. Brauchte man das schon immer - nur hieß es damals noch Bios

Ja, und das war eingebaut und brauchte nicht erst nachgeladen und installiert zu werden.

2. erinnere dich an W3.11 und den 32Bit Festplattenzugriff (da brauchte es auch bereits Chipsatztreiber)

Habe Win3.11 nie benutzt.

3. Wie willst du funktionen mit der bestmöglichen Geschwindigkeit über die Weichwareinterrupts der Biosse umsetzen?

Indem man es gleich aufs Motherboard einbaut und nicht wieder Installations-Fallera betreiben muß (und damit beschränkt ist auf die OS, für die auch die entsprechenden Treiber angeboten werden).
Und übrigens gab's mal eine Zeit, in der jede Hardware durch direkte Portzugriffe, bzw wo benötigt auch IRQ und DMA betrieben wurden - also quasi direkt (und nicht durch ein Software-Nadelöhr) - und damit war Hardware überall nutzbar - heute ja eher nur, wenn man das OS benutzt, für das Treiber für diese Hardware geschrieben werden (die ohne Treiber quasi so nützlich sind wie ein Türstopper).

- mal abgesehen davon das bei dem aktuellem Funktionsumfang der damals vorgesehene Speicherbereich überläuft.

Daaamals[tm] hat man auch Dinge erweitern können, ohne dem User diesen Mist anzutun ("Laden Sie die aktuellen und zu ihrem Rechner/Board passenden Treiber aus dem Netz" - bzw "Laden Sie das 500 MB Treiber-Paket aus dem Netz und ich suche mir DANACH das 1 MB raus, das ich brauche").

und 4. funktioniert das Mainboard auch ohne Treiber

Das ist mir bekannt. Aber wenn die Hardware sowieso diese Treiber braucht, kann man sie auch gleich quasi einbauen. Nenn' mich meinetwegen doof - aber wenn man sich z.B. eine VGA/VESA-Grafikkarte kauft, ist der VESA-Treiber gleich mit drauf... (Dadurch hat man das VESA - egal welches OS da grade drüberwerkelt.)

also nicht auf die neue Technik schimpfen

Doch! SCHIMPF! ZETER! GEBALLTE-FÄUSTE-SCHÜTTEL!

und gleichzeitig andere neue Technik verteidigen...

Ich verteidige neue Technik? Seit wann denn das?

[Dosenware]

Ja, und das war eingebaut und brauchte nicht erst nachgeladen und installiert zu werden.

Mein Bios brauche ich auch nicht nachzuladen
Treiber brauchts im wesentlichen um alles mit optimaler Geschwindigkeit betreiben zu können, bzw. Dinge nachzurüsten die sich auf die alten Biosschnitstellen nicht abbilden lassen (z.b. die Stromsparmodi)

Indem man es gleich aufs Motherboard einbaut

Das würde sich auch wieder alle paar Jahre ändern um mit der technischen Entwicklung mithalten zu können.

Und übrigens gab's mal eine Zeit, in der jede Hardware durch direkte Portzugriffe, bzw wo benötigt auch IRQ und DMA betrieben wurden - also quasi direkt (und nicht durch ein Software-Nadelöhr)

Dann kam das Bios(-nadelöhr) und sorgte dafür dass nicht mehr für jede kleine Hartwurstmodifikation das Betriebssystem geändert werden musste - obgleich direkte Hartwarezugriffe dann immernoch funktionierten - geht heute immernoch, zumindest wenn man die Rechte dazu hat (Ring 0 und so Kram)

Daaamals[tm] hat man auch Dinge erweitern können

Einen Speicherbereich der seit Dos 1.0 unverändert vorhanden und für die Kompatibilität essentiell war?
Ohne Speichermanager gibts bloß 1MB(+64kb) und davon sind schonmal 640Kb+64Kb (A000)+64kb(>1MB)+64Kb(B000+BFFF) weg - da bekommt man die Routinen für die heutige Hartwurst (ist halt saumäßig viel) garnicht rein - und wenn du die erst Später einblenden willst (wie den LFB bei Vesa) brauchts erstmal wieder einen Speichermanager und wenn deine Weichware auch noch am Speicher rummatscht (Flatmode, unrealmode, Protected, etc.) gehts gleich garnicht

"Laden Sie das 500 MB Treiber-Paket aus dem Netz und ich suche mir DANACH das 1 MB raus, das ich brauche").

das meiste davon ist Weichwurst und JA das NERVT.

aber wenn man sich z.B. eine VGA/VESA-Grafikkarte kauft

Braucht dein Programm eine höhere Vesaversion die du z.b. mit Univbe/Univesa nachrüstest - aber nur wenn in dem Treiberpaket (was anderes ist das ja nicht) der passende auch dabei ist

Ich verteidige neue Technik? Seit wann denn das?

Stromsparmodi

Doch! SCHIMPF! ZETER! GEBALLTE-FÄUSTE-SCHÜTTEL!

Dafür gibts den hier

[DOSferatu]

Indem man es gleich aufs Motherboard einbaut

Das würde sich auch wieder alle paar Jahre ändern um mit der technischen Entwicklung mithalten zu können.

Ja, aber dann wäre es auch ein neues Motherboard. Das Motherboard bräuchte ja sowieso nur die Dinge (per "integriertem" Treiber) supporten, die es auch hardwaremäßig drauf hat.

aber wenn man sich z.B. eine VGA/VESA-Grafikkarte kauft

Braucht dein Programm eine höhere Vesaversion die du z.b. mit Univbe/Univesa nachrüstest - aber nur wenn in dem Treiberpaket (was anderes ist das ja nicht) der passende auch dabei ist

Naja, eigentlich sollte auf der Grafikkarte alles, was sie kann (und im VESA supportet ist) auch per VESA supporten. OK, als VESA gerade erfunden war (VESA 1.0) und die entsprechenden Karten gebaut wurden, mußte man softwaremäßig nachhelfen, wenn man auch die HiColor/TrueColor Modi (und nicht nur die 16/256-Farben Modi, die VESA 1.0 supportet) haben wollte - aber das ist ja quasi auch wieder Mist. Denn EIGENTLICH konnte die GraKa schon die hohen Modi und EIGENTLICH hatte selbst VESA 1.0 schon die Möglichkeit, Modi einzutragen für R-G-B-Anteile (und eben auch Hi/Truecolor Modi), nur hat's keiner gemacht und was dann per Software nachgemurkst werden mußte, obwohl der VESA-Standard es erlaubte (sonst wär's ja auch per UniVBE nicht darstellbar gewesen) und obwohl die GraKa es hatte.

Ich verteidige neue Technik? Seit wann denn das?

Stromsparmodi

Die habe ich nicht verteidigt. Ich habe nur erklärt, woran es liegt, daß DOS die nicht supportet. Einfach, weil die zu DOS-Zeiten noch in keinem Rechner eingebaut waren. Vielleicht fährt ja der Ford Model T auch nicht mit E10-Sprit, weil man den damals nich nicht kannte.

Doch! SCHIMPF! ZETER! GEBALLTE-FÄUSTE-SCHÜTTEL!

Dafür gibts den hier [ein schimpfender blauer Smiley]

Ich benutze ja bekanntlich (fast) keine Smileys. Ich schalte in meinen Beiträgen die Smileys auch immer aus. Mal abgesehen davon, daß ich noch nie ein Smiley-Fan war, gibt es dafür auch einen eher praktischen Grund: Ich neige öfter dazu, Textpassagen in Klammern zu setzen und dadurch ist es mir früher ab und zu passiert, daß Forensoftwaren manche Dinge davon ungewollt in Smileys umgesetzt haben, was einerseits den Text unleserlich machte und andererseits Smileys mit unpassenden Gesichtsausdrücken an unpassende Stellen einfügte. Klammern () dienen für mich eben entweder zur mathematischen Zusammenfassung eines Terms (zum Übergehen des Operationsvorrangs) oder (wie z.B. hier) zum Setzen eines Textes oder Textfragments in Parenthese - und das überschneidet sich leider mit der Funktion zur Darstellung von Smileys.

[freecrac]

und 4. funktioniert das Mainboard auch ohne Treiber - nur lassen sich dann einige Funktionen (allen Voran AHCI (Sata)) nicht benutzen - selbst mein Core i7 startet noch Dos (und auf IDE-Emulation umgestellt, werden auch die Festplatten erkannt)

Sonst kann man für ein SATA-CD-Laufwerk auch einen DOS-Treiber verwenden:
http://www.ibiblio.org/pub/micro/pc-stu ... drom24.zip
http://sourceforge.net/project/download ... a=36853532
http://www.ibiblio.org/pub/micro/pc-stu ... drom24.zip

Dirk