PII 233 zu schnell für ältere Games?

[Wackelpudding]

Hallöchen!
So, nach geraumer Zeit habe ich es endlich geschafft, auf dem Rechner DOS zu installieren sowie einige Spiele. Und hier habe ich das Problem, daß mehrere Spiele einfach nicht starten wollen. Mal wurde ein EMM386-Fehler angezeigt, manchmal passiert gar nix, d.h. die Kiste schmiert ab, bisweilen gibt es Fehlermeldungen; so meldet beispielsweise Monkey Island einen Runtime Error ...

Kann es sein, daß der Prozzi für manche Games zu schnell ist?

[CptKlotz]

Kann es sein, daß der Prozzi für manche Games zu schnell ist?

Ja, davon ist sogar auszugehen. Viele Spiele sind etwas seltsam programmiert. Die haben zu ihrer Zeit die Speerspitze der PC-Technik ausgenutzt, aber es wurde nicht bedacht, daß die Entwicklung natürlich nicht stehen bleibt.

Notorische Kandidaten sind z.B. Wing Commander 1 + 2. Alles, was wesentlich schneller als ein mittlerer 386 ist, läßt die Spiele zu schnell laufen und wenn man keinen derartigen Rechner hat kann man erstmal mit Slowdown-Tools, deaktiviertem Cache usw. herumfummeln. Man darf aber nicht meinen, daß die Spiele flüssig laufen dürften - läut das Spiel auch bei Raumschlachten mit vielen Schiffen flüssig, ist es bei wenig Action schon wieder zu schnell :-)
Ich bin immer noch begeistert von der Atmosphäre, die Wing Commander mit der Technik von 1990 schafft, aber technisch ist das echt kein Meisterwerk - wäre ein Framerate-Limiter soo schwer zu implementieren gewesen?

Dann gibt es noch den bekannten Turbo-Pascal-Runtime-Bug. Bei Programmen, die in Turbo Pascal geschrieben sind, läuft auf zu schnellen Rechnern in Schleifen irgendein Zähler über, so daß es den bekannten "divide by zero"-Fehler gibt. Dieses Problem tritt etwa bei Rechnern oberhalb von 200 Mhz auf, also so in der Kategorie wie Dein Rechner. Bei meinem P200MMX scheint es noch nicht zu passieren, aber das hängt vermutlich von einer Reihe von Faktoren ab.

Das Problem mit Monkey Island kenne ich auch - das scheint aber auch völlig seltsame Ausprägungen zu haben. Früher auf meinem 486 DX2/50 stürzte das Spiel mit einem "divide by zero" ab, aber mit Adlib für Audio war dieser Effekt weg.
Auf meinem viel schnelleren P200MMX habe ich das Problem gar nicht. Keine Ahnung, ob ich eine andere Version des Spiels habe als früher oder woran das liegt - manchmal sind solche Probleme wirklich unergründlich.

Wenn Du ein Speed-Problem hast, ist der einfachste Weg, im BIOS mal den CPU-Cache abzuschalten. Das sollte dem Rechner-Speed ganz ordentlich "einen auf den Deckel" geben. Ist natürlich ein wenig umständlich.

Ansonsten gibt es Software-Tools für den Zweck, die aber unterschiedlich gut sind.

-MoSlo (sehr bekannt, scheint aber gerne für ruckeliges Scrolling zu sorgen)
-Bremze (scheint recht gut zu funktionieren, per Hotkey steuerbar während ein Spiel läuft - leider nicht Freeware)
-Slowdown 3.10 (funktioniert auch gut, mag aber anscheinend keinen EMM386, wobei QEMM geht)
-Throttle (nutzt besondere Funktionen bestimmter Chipsätze, funktioniert aber nicht auf jedem Board - soll eine sehr elegante Methode sein).

Zu obigen Äußerungen denke Dir bitte ein "bei mir" dazu - meine Erfahrungen sind vielleicht nicht allgemeingültig und meine Erinnerung mag mich auch täuschen :-)

Ach ja, DOSBox ist natürlich auch noch eine Überlegung wert. Ich zocke eigentlich lieber mit echter Hardware, aber für manche Problemkandidaten (oder Spiele, die wirklich für uralte 8088-Maschinen geschrieben sind) sind die frei einstellbaren "Cycles" von DOSBox bestimmt nützlich.

Erfahrungen anderer Leute mit diesen und anderen Slowdown-Tools interessieren mich übrigens auch :-)

[Wackelpudding]

Hallo und erst einmal herzlichen Dank für Deine ausführliche Antwort, CptKlotz!

Ich habe zwar auch schon daran gedacht, den Cache zu deaktivieren, befürchte aber, daß die Systemleistung dabei doch zu sehr in den Keller geht. Vermutlich werde ich es eher mit einer CPU-Bremse versuchen, da findet sich bestimmt was. Ich muß noch mal das Mainboard checken, inwieweit ich die CPU vielleicht runtertakten kann.

Und wenn gar nichts hilft, kann ich Monkey Island ja immer noch via ScummVM zocken ... hach, das waren noch Zeiten, ich glaube, ich habe sogar noch die Codescheibe!

Wie auch immer, ich werde das Problem mal mit, wie gesagt, einer CPU-Bremse und eventuellem Heruntertakten angehen und die Ergebnisse dann hier posten!

Wie gesagt, schönen Dank nochmal und gute Nacht!

Edit:
Ich kann mich noch daran erinnern, daß es mit QEMM früher gerade in der Verbindung mit Win 3.11 diverse Probleme, meist in Form von Totalabstürzen, gab, was auch abhängig von der installierten Software war bzw. hatte ich seinerzeit den Speicher immer im STEALTH-Modus optimiert. Nun habe ich nicht vor, Win 3.11 zu verwenden - kann von daher die Verwendung von QEMM unter DOS empfohlen werden? Und wenn ja, dann mit oder lieber doch ohne STEALTH?

[elianda]

Hallo und erst einmal herzlichen Dank für Deine ausführliche Antwort, CptKlotz!

Ich habe zwar auch schon daran gedacht, den Cache zu deaktivieren, befürchte aber, daß die Systemleistung dabei doch zu sehr in den Keller geht. Vermutlich werde ich es eher mit einer CPU-Bremse versuchen, da findet sich bestimmt was. Ich muß noch mal das Mainboard checken, inwieweit ich die CPU vielleicht runtertakten kann.

Wie auch immer, ich werde das Problem mal mit, wie gesagt, einer CPU-Bremse und eventuellem Heruntertakten angehen und die Ergebnisse dann hier posten!

Was meinst Du genau mit "daß die Systemleistung dabei doch zu sehr in den Keller geht" ?
Bei Monkey Island gilt, entweder das Spiel laeuft oder nicht. Der Bereich ist halt ca. 286er bis schneller Pentium. Mit Cache deaktivieren trifft man den Bereich.
Weiterhin gilt im allgemeinen, dass Hardware basierte Verlangsamungen wesentlich kompatibler sind als Software Bremsen und dabei nicht einmal Speicher kosten. Das gilt fuer Cache deaktivieren und Stromsparmechanismen einsetzen (throttle).
Wenn man wirklich Angst davor hat, dass das Spiel dann zu langsam laeuft, kann man immernoch ein Programm nutzen, wo man den Slowdown wieder abstellen kann, wenn man im Spiel ist. Ich finde diese Angst vor zu wenig Rechenpower aber vollkommen unbegruendet, weil viele Spiele nicht besser laufen, sobald man eine bestimmte Grenze an verfuegbarer CPU-Leistung ueberschritten hat.
Ausserdem sind viele Spiele die so ein Geschwindigkeitsproblem haben fuer keine schnelleren Rechner als z.B. ein 486DX2-66 gedacht. Dein P2 233 MHz ist Groessenordnungen schneller.

Weiterhin als Tipp: Die meisten P2s koennen auch x2 als Multiplikator, also 133 MHz. Dabei sind sie aber trotzdem noch wesentlich schneller als ein gleichgetakteter P1. Vor Allem mit der FPU.

Edit:
Ich kann mich noch daran erinnern, daß es mit QEMM früher gerade in der Verbindung mit Win 3.11 diverse Probleme, meist in Form von Totalabstürzen, gab, was auch abhängig von der installierten Software war bzw. hatte ich seinerzeit den Speicher immer im STEALTH-Modus optimiert. Nun habe ich nicht vor, Win 3.11 zu verwenden - kann von daher die Verwendung von QEMM unter DOS empfohlen werden? Und wenn ja, dann mit oder lieber doch ohne STEALTH?

Hier gilt wie bei so vielem, erstmal einlesen, was man da genau macht, wenn man Stealth aktiviert.
Die allermeisten Instabilitaeten bei QEMM kommen eher dadurch, dass die Nutzer ohne genaues Wissen irgendwelche Features aktivieren...
Wenn Du Stealth nicht benoetigt, lass es aus. Wenn Du Win 3.11 doch nutzen willst, dann lass auch die QEMM Win 3.11 Treiber mit laden fuer den 386 enhanced Modus. Fuer Win 3.11 ist QEMM sowieso nur zu empfehlen, wenn man die zusaetzlichen Features wie Magna RAM usw. nutzt.

Fuer eine simple Konfiguration nutzt Du RAM AUTO. Sonst Optimize ohne Stealth.
Wenn Quickboot nicht geht, schalt es im QEMM Setup aus.
Man vergisst gerne, dass viele besonderen Features bei QEMM mit dem Chipset zusammenspielen muessen. Das geht meistens bei den normalen 386er, 486er und aelteren Pentium Chipsaetzen gut. Hat man irgendetwas moderneres muss man mit den Inkompatibilitaeten leben. Man hat sie sich ja selbst eingebaut.
Da zu Zeiten des P2 DOS schon kein Thema mehr war, ist auch nicht zu erwarten, dass irgendeine Applikation dafuer noch getestet wurde.

[DOSferatu]

Technische Information zu dem Problem - falls es jemanden interessiert:

Ja, den Fehler bei Monkey Island 1 kenne ich auch. Es ist übrigens derselbe Fehler wie der von Pascal Programmen (die die Unit CRT benutzen). Monkey Island 1 wurde offensichtlich in Borland C geschrieben und die hatten für diesen "Timertrick" dieselbe Idee wie in der CRT-Unit von Pascal.
Das Ganze funktioniert so: Zu Anfang läuft eine Schleife durch, die in Verbindung mit dem Ticker testet, wie schnell der Rechner ist. Der Wert darin ist aber wohl nur 16 Bit oder so - ist der Rechner zu schnell, gibt es einen Überlauf, der nicht abgefangen wird. Bei der folgenden Division (je nachdem, wie da gearbeitet wurde), wird entweder durch 0 geteilt oder das Ergebnis ist zu groß für das Zielregister. In beiden Fällen löst die CPU den INT0 aus, der vom Programm als "Runtime Error 200"(Pascal) oder "error 6001: integer divide by zero" ( C) ausgegeben wird.

Daß der Fehler bei Monkey Island 1 abhängig von der verwendeten Soundhardware ist, läßt sich einfach erklären: Wählt man für die Musik PC-Speaker, tritt der Fehler nicht auf, bei Adlib schon.
Das Problem ist, daß ältere Soundkarten erwarten, daß nach Zugriffen auf ihre Ports jeweils eine kurze Wartezeit einzuplanen ist, bevor ein neuer Zugriff erfolgt (technische Gründe). Für diesen Zweck wurde dann wohl auch dieser DELAY Befehl (in Pascal heißt er DELAY, in Borland C weiß ich's nicht) benutzt. Der PC-Speaker braucht diese Wartezeiten nicht, daher tritt der Fehler dort nicht auf, den ich jetzt beschreibe:

Was nun passiert, ist das: Normalerweise bricht Monkey Island 1 ja schon ab, wenn man einen zu schnellen Rechner hat (bei dieser Testschleife). Patcht man nun aber die MONKEY.EXE (d.h. man patcht eine Zeitschleife rein, die bei zu hohen Werten die Division überspringt oder einen Dummy-Wert reinschreibt), funktioniert das DELAY nicht mehr richtig. Das bewirkt, daß Monkey Island 1 zwar läuft, der Adlib Sound jedoch nicht richtig funktioniert, irgendwann in wilde Töne ausartet oder die Musik abbricht (manchmal bleibt sie mit einem Dauerton hängen).
Der Fehler tritt EBENFALLS auf, wenn man durch Drücken der Turbo Taste (um den "Turbo" zu DEaktivieren - ja, sowas hatten die Rechner mal, es ist aber nicht wirklich ein Nachbrenner drin...) und/oder mit einem speicherresidenten Rechnerrunterbremsprogramm (das Wort steht bestimmt nicht im Duden...) den Rechner gerade so weit herunterbremst, daß Monkey Island 1 ganz knapp am DIV0 Fehler vorbeigeht. Dann sind die Werte für das Delay wohl immer noch ein wenig zu klein.

[u[Für Pascal-Programmierer gilt daher:[/u]
- Entweder die Unit CRT gänzlich vermeiden (man kann den Kram eigentlich auch selbst programmieren, wenn man will).
- Wenn man CRT benutzen will: Das Programm tppatch.exe von Andreas Bauer benutzen (die erzeugte *.exe mit tppatch.exe bearbeiten, also tppatch.exe meinprog.exe) - keine Sorge, wenn nichts zu patchen ist, wird nicht gepatcht - UND dann natürlich NICHT den Befehl Delay benutzen (der dann nicht mehr richtig arbeitet), sondern einen eigenen Delay schreiben, falls benötigt.
- Habe auch mal gehört, jemand hätte eine alternative Unit CRT programmiert.

Ich selber benutze die Unit CRT seit Jahren nicht mehr. Unter anderen, weil ich sowieso immer alles direkt in den Textmode-Speicher schreibe - und auch, weil einige meiner Programme sowieso im Grafikmode laufen...

Ich schaffe es einfach nicht, mich kurz zu fassen...

[elianda]

Noch als Ergaenzung:
Wenn man selbst Turbo Pascal programmiert ist das alles nicht so wild. Denn die Quelltexte von der crt Unit sind dort dabei (zumindest bei mir) und man kann diesen entweder selbst anpassen oder einen angepassten kompilieren. Das ganze kann man dann wieder in die tpp Datei reinpacken. Das stimmt dann entsprechend auch auf schnelleren PCs.

Problematisch wird es, wenn man vorhandene binaries patchen will. Wie DOSferatu schon schrieb, wird meistens ein Dummy Wert eingesetzt, wodurch das Programm zwar laeuft aber alle Zeitschleifen trotzdem keine korrekten Zeitverzögerungen bewirken. Bei einigen Programmen ist das egal, ob sie z.B. 1ms oder 100ms warten.

Leider gibt es aber Programme, die ihr Zeitverhalten auf einem korrekten Delay Wert aufbauen. Dort ist es dann so, dass man am besten gar nicht patcht, sondern den Rechner langsamer macht. Auf dem langsamen Rechner wird mit der Original programmroutine zur Zeitbestimmung eine korrekte Referenz bestimmt, wodurch die Laufzeit des Programms dann wieder stimmt. Hier gilt auch, desto langsamer man den Rechner macht, desto genauer wird das Delay. (ok langsamer als ein XT sollte man nicht werden).

Eine korrekte Loesung fuer einen schnellen PC waere sehr aufwendig und sicher auch speziell fuer die jeweilige Binary. Man könnte sowas auch in einem Emulator abfangen (virtual Traps), jedoch sind diese Programme offt mit Hardwareansteuerung verbunden, wo einem eine Emulation nichts hilft. Soundausgabe ist auch nur eine Hardwareansteuerung.

[Wackelpudding]

@Elianda
Ich befürchte, daß sich der Rechner dann wirklich lediglich auf dem Niveau eines 286ers bzw. eines schwachbrüstigen 386ers befindet, sobald ich den Cache deaktiviere. Wie gesagt, ich muß mal sehen, inwieweit sich das Board runtertakten läßt. By the way, gestern habe ich noch bei Ebay einen Pentium1-Rechner für 1 Euro erworben, da läßt sich dann bestimmt schon was machen ...

QEMM werde ich dann installieren, aber auf STEALTH verzichten.

@DOSferatu
Danke für die Erklärung, war für mich sehr interessant und lehrreich.

Nochmals vielen Dank für Eure Antworten, ich melde mich dann, wie's mit dem Runtertakten bzw. mit dem "neu" erworbenen P1-Bigtower aussieht!

[CptKlotz]

@Elianda
Ich befürchte, daß sich der Rechner dann wirklich lediglich auf dem Niveau eines 286ers bzw. eines schwachbrüstigen 386ers befindet, sobald ich den Cache aktiviere. Wie gesagt, ich muß mal sehen, inwieweit sich das Board runtertakten läßt. By the way, gestern habe ich noch bei Ebay einen Pentium1-Rechner für 1 Euro erworben, da läßt sich dann bestimmt schon was machen ...

Ich denke, du wirst ohne Cache irgendwo auf mittlerem 486-Niveau landen. Zumindest ist das bei meinem P200 so, der ja nicht viel langsamer als Dein P-II ist.

Für Monkey Island und ähnlich genügsame Spiele sollte das sehr komfortabel ausreichen.

@DOSferatu:

Bei Monkey Island trat der Fehler bei mir immer dann auf, wenn ich *nicht* Adlib benutzt habe und kaputte Adlib-Wiedergabe hatte ich auch nie (wenn meine Erinnerung mich jetzt nicht täuscht). Auf dem eigentlich irre schnellen P200 passiert es, wie gesagt, gar nicht - vielleicht ist meine Version ja schon gepatcht.

[Wackelpudding]

So, da bin ich wieder! Ich habe nun einen P133 verbaut und diesen auf 90 MHz runtergetaktet. Leider bekomme ich beim Starten von Monkey Island immer noch die Fehlermeldung:

run-time error R6003
- integer divide by 0

Rufe ich das Spiel mit "monkey r" auf, startet es allerdings, nur höre ich dann keinen Sound! Was kann ich noch tun?

[CptKlotz]

Rufe ich das Spiel mit "monkey r" auf, startet es allerdings, nur höre ich dann keinen Sound! Was kann ich noch tun?

monkey a für Adlib funktioniert nicht? "R" ist nur sinnvoll, wenn Du einen Roland-LA-Synthesizer wie MT-32, CM32-L, LAPC-I usw. hast.

Es kann aber sein, daß das Spiel Adlib von selbst erkennt. Dann wird der Parameter wohl keinen Unterschied machen.

[Wackelpudding]

Beim Versuch, mit "monkey a" zu starten, kommt wieder der Runtime-Error ...

Edit:
Mit "monkey g" startet das Spiel, aber aus den Lautsprechern kommt lediglich ein schnarrendes Geräusch.

[philscomputerlab]

Oho das Thema passt ja genau zu meinem (jetzt fertigem) "slowdown" Projekt...

Ganz simpel gesehen hat man es mit zwei Arten von Maschinen zu tun:

1. Du hast einen PC wo sich Cache auf dem Mainboard befindet
2. Du hast einen PC wo sich kein Cache auf dem Mainboard befindet

1. Findest du bis max. Super Socket 7
2. Findest du ab Slot 1

Die zwei wichtigsten Dinge die einfluss auf die Performance beim "herunterbremsen" haben ist der Cache und der FSB. Die Taktfrequenz von der CPU macht fast gar nichts aus.

Wenn dein Board kein Cache hat (weil der Cache auf der CPU ist), dann kannst du leider L1 und L2 Cache nicht getrennt deaktivieren. Du hast entweder beide an (Sehr schnell) oder beide aus (Sehr langsam).

Bei einem Slot 1 system wirst du mit 66 MHz FSB ~ einen 286er bekommen. 100 MHz ist eine langsamer 386 SX und 133 MHz FSB (440BX chipset im overclocking mode) ein guter 386 SX. Speicher timings haben auch etwas Einfluss auf die Performance. Das passt ganz prima fuer viele Spiele, allerdings wirst du einige finden die zu langsam sind...

Wenn dein Board Cache hat (z.b. ein Super Socket 7 Board mit 512KB Cache) kannst du den L1 Cache abdrehen und der L2 Cache werkelt weiter. Je nach FSB und CPU (Intel oder Cyrix oder K6) bekommst du einen schnellen 386 oder sogar einen 486 DX2.

Hier eine Tabelle mit ein paar 3D Bench resultaten:

Pentium Werte fehlen mir noch, ich habe jetzt die CPU (Pentium 200 nicht MMX) aber zur Zeit keine Lust zum testen...



So oder so wirst du immer Leistungs "Loecher" haben die du nicht abdecken kannst. So oder so hat man idealerweise mehrere PCs.

Ich empfehle einen 486 weil du hier extrem viele Optionen hast. L1 und L2 Cache sind waehlbar und ein Turbo button ist auch da! Pentium ist auch gut, besonders wenn ein Turbo Button da ist.

Slot 1 wird es schon schwierig weil die Kiste entweder sehr langsam ist oder sehr schnell.

Ich empfehle also ein Slot 1 system for SVGA Spiele wo jede Leistung zaehlt und ein 486 oder Pentium system mit Turbo button weil du hier sehr flexibel die benoetigte Leistung "anpeilen" kannst.

Viele Spiele funktionieren uebrigens ohne Probleme auf schnellen Kisten. Prince of Persia rennt prima auf einem Phenom II

[philscomputerlab]

Habe jetzt den Pentium 200 (NICHT MMX) getested und die Daten in die Tabelle aufgenommen.

Man sieht hier wunderbar wie die CPUs schoen mit dem FSB skalieren wenn der L2 Cache aktiviert ist.

Sind beide Caches deaktiviert, hat der FSB kaum einen Einfluss.

Ohne L1 Cache ist AMD die langsamste CPU, Intel in der Mitte und Cyrix am schnellsten obwohl mir fuer Cyrix noch ein 100 MHz FSB wert fehlt. Schaue mich derzeit nach einen anderen Cyrix CPU um und werde diese Werte nachliefern

[drzeissler]

schon ein wenig älter aber dennoch interessant.

Können wir 386/486/586 noch mal kurz unter dem Aspekt "Turbo-Button" und L1/L2 Cache beleuchten.
Ich war gestern Abend bei jemand der einen 386/40 am Start hat. Das Teil hat auch einen Turbo-Button.

Da ich im Moment weder einen 386/486 noch einen langsamen Pentium habe, fehlt mir was beim
echten Dosgaming. Der Celeron433 ist zwar für SVGA und die V3-3000 auch recht OK, aber für echtes
Dosgaming 1992-1997 fehlt da was.

Bei dem Turbo-Button gab es doch auch unterschiedliche Varianten?

Ich brauche was, das keine Ruckler verursacht und "nur" den Rechner bremst, denn er soll WC1 genauso
können, wie Duke3d(lowres)

Danke
Doc

[matze79]

Turbo Button Implentation bei PII hängt ziemlich vom Hersteller ab und der Methode die er verwendet.
Ein PII Brett was ich mal hier hatte war bei Turbo Button etwa auf 386DX-33 Niveau.