„Softwarebremse“ – Versionsunterschied
[gesichtete Version] | [ungesichtete Version] |
Weder notwendig (ging auch unter Single-Task-MSDOS durch IRQs; außerdem kann man durch (Selbst-)Emulation jedes Programm (allerdings nicht nur ein wenig) bremsen) noch hinreichend (geht bei Multikern-CPUs nicht mehr auf diese Weise). Außer müsste "Daher" durch "Dazu" ersetzt werden. |
Markierung: Zurückgesetzt |
||
Zeile 2: | Zeile 2: | ||
== Notwendigkeit == |
== Notwendigkeit == |
||
Früher war alles ganz anders als heute: Zum einen bestand früher die Herausforderung, Spiele hinreichend zu optimieren, damit sie überhaupt spielbar wurden – vorsätzliches Bremsen war fast undenkbar. Zum anderen waren schnellere Rechner meistens inkompatibel zu ihren langsameren Vorgängern. Das Problem, dass eine (compilierte) Software auf sehr unterschiedlich schnellen Rechnern lief, gab es damit nicht. |
|||
Hauptsächlich bei älteren [[Disk Operating System|DOS]]-Spielen wurden häufig Mechanismen angewandt, welche direkt vom Systemtakt abhängig waren. Dies führte dazu, dass ein Programm, welches z. B. für einen [[Intel 80286|286er]] [[Hauptprozessor|Prozessor]] mit 8 MHz geschrieben wurde, bei einer CPU der gleichen Baureihe mit höherer Taktrate entsprechend schneller lief. Bei 16 MHz wäre die Geschwindigkeit doppelt so hoch gewesen, was für die reine Datenverarbeitung wünschenswert ist. Wenn dadurch allerdings auch für die Benutzerinteraktion die gleiche Beschleunigung notwendig ist, führt dies dazu, dass die Programme nicht mehr wie vorgesehen benutzt werden können. |
|||
Das (und vieles andere) änderte sich erst Mitte der 1980er Jahre. |
|||
⚫ | Reichten |
||
Dies führte dazu, dass ein Programm (z. B. [[Digger (Computerspiel)|Digger]]), welches initial für einen [[Intel 8088]]-[[Hauptprozessor|Prozessor]] mit 4,77 MHz geschrieben wurde, auf einer schnelleren CPU entsprechend schneller lief. |
|||
So ist oben genanntes Spiel auf einem fast doppelt so schnellem [[Intel 8086]]-[[Hauptprozessor|Prozessor]] mit 8 MHz (z. B. [[Amstrad PC1512]]) grenzwertig spielbar und selbst auf langsamen 80286-Prozessoren unspielbar (bei 8 MHz mehr als 6x so schnell). |
|||
Moderne Computerprogramme [[Synchronisation#Informatik|synchronisieren]] ihre Ausführgeschwindigkeit, wenn notwendig, |
|||
fast ausnahmslos über systemtaktunabhängige Timer oder Synchronisationsmechanismen des Betriebssystems. |
|||
⚫ | Reichten für die gewünschte Verringerung der Rechenleistung eine [[Turbo-Taste]] anfangs häufig und später noch manchmal aus, um die Abwärtskompatibilität zu gewährleisten, musste aufgrund der Vielfalt an Prozessoren und schnellen Leistungssteigerung zunehmend Softwarelösungen eingesetzt werden. Diese Software belastet die Systemressourcen künstlich und führte damit zu einer Verringerung der Leistung. |
||
Spiele ab Mitte/Ende der 1980er Jahre (z. B. [[Prince of Persia (Computerspiel 1989)|Prince of Persia]] oder [[Microsoft_Flight_Simulator#Flight_Simulator_3.0|FS 3.0]]) passen ihre Geschwindigkeit, wenn notwendig, fast ausnahmslos über systemtaktunabhängige Timer oder Synchronisationsmechanismen des Betriebssystems an. |
|||
Da damalige Programme auf Grund der mangelnden Kompatibilität zu jetzigen Betriebssystemen meist ohnehin nicht lauffähig sind, werden solche Programme [[Emulator|emuliert]], dabei kann für gewöhnlich die gewünschte Taktfrequenz eingestellt werden. |
Da damalige Programme auf Grund der mangelnden Kompatibilität zu jetzigen Betriebssystemen meist ohnehin nicht lauffähig sind, werden solche Programme [[Emulator|emuliert]], dabei kann für gewöhnlich die gewünschte Taktfrequenz eingestellt werden. |
Version vom 11. März 2023, 05:43 Uhr
Eine Softwarebremse ist ein Computerprogramm, das dazu dient, die Ausführgeschwindigkeit anderer Programme herabzusetzen. Softwarebremsen können meist im Grad ihrer Systembremsung angepasst werden.[1]
Notwendigkeit
Früher war alles ganz anders als heute: Zum einen bestand früher die Herausforderung, Spiele hinreichend zu optimieren, damit sie überhaupt spielbar wurden – vorsätzliches Bremsen war fast undenkbar. Zum anderen waren schnellere Rechner meistens inkompatibel zu ihren langsameren Vorgängern. Das Problem, dass eine (compilierte) Software auf sehr unterschiedlich schnellen Rechnern lief, gab es damit nicht.
Das (und vieles andere) änderte sich erst Mitte der 1980er Jahre. Dies führte dazu, dass ein Programm (z. B. Digger), welches initial für einen Intel 8088-Prozessor mit 4,77 MHz geschrieben wurde, auf einer schnelleren CPU entsprechend schneller lief.
So ist oben genanntes Spiel auf einem fast doppelt so schnellem Intel 8086-Prozessor mit 8 MHz (z. B. Amstrad PC1512) grenzwertig spielbar und selbst auf langsamen 80286-Prozessoren unspielbar (bei 8 MHz mehr als 6x so schnell).
Reichten für die gewünschte Verringerung der Rechenleistung eine Turbo-Taste anfangs häufig und später noch manchmal aus, um die Abwärtskompatibilität zu gewährleisten, musste aufgrund der Vielfalt an Prozessoren und schnellen Leistungssteigerung zunehmend Softwarelösungen eingesetzt werden. Diese Software belastet die Systemressourcen künstlich und führte damit zu einer Verringerung der Leistung.
Spiele ab Mitte/Ende der 1980er Jahre (z. B. Prince of Persia oder FS 3.0) passen ihre Geschwindigkeit, wenn notwendig, fast ausnahmslos über systemtaktunabhängige Timer oder Synchronisationsmechanismen des Betriebssystems an.
Da damalige Programme auf Grund der mangelnden Kompatibilität zu jetzigen Betriebssystemen meist ohnehin nicht lauffähig sind, werden solche Programme emuliert, dabei kann für gewöhnlich die gewünschte Taktfrequenz eingestellt werden.
Technik
Es gibt folgende Ansätze für Softwarebremsen:
- Bremsung durch schnelleres Refresh
- Zu Zeiten des 8088, 8086 und 80286 konnte man einen Rechner durch Erhöhung der Refreshrate um bis zu 30 Prozent reduzieren (DMA-Kanal 0). Für etwas zu schnell laufende Programme war dies häufig ausreichend.
- Bremsung durch ein parallel laufendes Program
- Periodisch wird ein kleines Programm aufgerufen, welches CPU-Zeit verbraucht. Ab dem 80286 wurde hierzu meist der Timer der CMOS-Uhr benutzt, der sich auf einen hinreichend hohe Interruptrate (128 Hz bis 32768 Hz) einstellen ließ, um ein gleichmäßiges Bremsen zu ermöglichen. Der Standardtimer mit 18,2 Hz war dazu zu langsam, ein Umprogrammieren ergab meist Komplikationen (Systemuhr lief schneller, Spiele haben ihn meist selbst genutzt).
Die Interrupt-Routine selbst sieht so aus, Wert ist je nach erwünschtem Bremsfaktor und Geschwindigkeit der CPU zu justieren.
push ax mov al, 20h out 020h, al out 0a0h, al sti mov ax, Wert .lbl: dec ax jnz .lbl pop ax iret
Verzögerungsschleifen können ebenfalls zur Verlangsamung eingesetzt werden, müssen aber im Gegensatz zu Softwarebremsen als integraler Bestandteil in das zu bremsende Programm eingebaut werden.
Siehe auch
Einzelnachweise
- ↑ http://www.sierrahelp.com/Utilities/SlowdownUtilities.html Verschiedene Beispiele (engl.)