Das ewige Problem Soundausgabe auf neuen Rechnern SB X-fi

[RepaintAndrew]

Bin mit dem Thema schon seit Jahren dran. Leider habe ich immer noch keine Lösung gefunden.
Suche immer noch einen Treiber, der es mir ermöglicht, neuere Creative Karten (in meinem Fall inziwschen SB X-fi) zu verwenden.
Dank Cutemouse und Cd-Rom Treibern gibt es sonst keinerlei Probleme.

Bleibt wie immer das Soundproblem. Klar könnte mir einen alten Rechner für ein Paar Euro besorgen um meine alten Games zu spielen, aber das ist aufgrund arger Platzprobleme momentan nicht möglich.
Alternative tools wie DosBox, ScummVM oder VDM Sound sind zwar ganz nett, aber gerade DosBox kommt selbst bei neueren 3 Ghz Rechnern nur mäßig klar. Besonders bei Wing Commander 3 war dies eine echte Nervenprobe.

Damals auf meinem alten 900 Mhz Rechner habe ich es noch mit viel Mühe hinbekommen, mit einer onboard Pci 128. Hier wurde dann dank der Dostreiber der ISA Port emuliert. Das war aber ein echter Akt.

Habe die Dos Entwicklung in den letzten jahren nicht sehr verfolgt. Ist FreeDos / inziwschen so weit, das neuere Soundkarten auch erkannt werden können, oder habt ihr eine Idee, was ich noch machen kann ?
Würde ggf. eine billige SB PCI 64 / 128 als Zweitkarte meine Probleme lösen ?
Vielleicht hat ja einer der Dos Profis hier eine Idee.

Gruß
RepaintAndrew

[Doctor Creep]

Würde ggf. eine billige SB PCI 64 / 128 als Zweitkarte meine Probleme lösen ?
Vielleicht hat ja einer der Dos Profis hier eine Idee.

Zählst Du auch noch ne SB Live! Value zu den neueren Karten? Diese PCI-Karte habe ich (über CTSYN bzw. SBEINIT.COM) prima unter DOS zum Laufen gebracht, in meinem Hybrid-Silent-PC:

http://www.dosforum.de/viewtopic.php?f=1&t=14&p=14483

Und diese SB hat ja IMO auch einen prima Digi-Sound...

Doc

[RepaintAndrew]

Ja der Rechner ist was feines ^^
Bin also nicht der einzige verrückte, der sich solche Gedanken macht.

Mist, wurde eben in letzter Sekunde überboten bei der SB Live Auktion.
Habe mir nun eine Ensoniq ES1370 ersteigert. Mal gespannt, ob die hochgelobte Karte im
Dosmodus hält, was sie verspricht.

Dann bin ich ja auch mal besonders gespannt, ob das alles so klappt, wie gewünscht.
Ist schließlich ein 3Ghz Rechner mit recht neuen Board.
Ob das heutzutage alles noch passt ??

[Kurt Steiner]

Hallo Andrew,

ich denke bei einem 3 GHz Rechner wirst du definitiv Probleme mit in einigen Spielen bekommen, weil sie einfach zu schnell laufen Wing Comander 1 und 2 zum Beispiel. Die 3 läuft aber denke ich.

Das andere Problem was du lösen musst ist, dass du eine Partition erstellst wo DOS drauf laufen kann !

Ich habe auch mit DOSBox und VMs rumgeobert und habe letztlich mir doch einen alten Rechner aufgesetzt und bin vollkommen zufrieden.

Schaue doch mal, wenn es wegen Platzproblemen ist, nach einen IBM A20, der ist Slim, hat nen 750 MHz Celeron und sollte ganz gut gehen.

Zu meinen alten Dos-Zeiten hatte ich auch ne ES Karte und hat nur Probleme, deswegen habe ich mich schon damals, wie heute, für einen Soundblaster entschieden.

[RepaintAndrew]

Ja vielleicht habt ihr recht. Am besten klappt das noch mit nem alten Rechner.
Schaue mir aber erst mal an, wie die Ensoniq läuft.

Ja ja, über den optimalen PC kann man lange philosophieren.
ggf. lässt sich sonst auch vielleicht noch ein Micro-Atx Board finden mit Isa und P III o.ä.
Unter dem LCD Tv wäre ansich ja auch noch etwas Platz übrig. ^^
Dann würde nur noch ein VGA zu Tv converter fehlen und ein Funkjoypad im Dosmodus. Das wäre die Traumlösung.
Glaube sowas gab es damals für den Gameport nicht, oder ??

[freecrac]

Hallo Andrew,

ich denke bei einem 3 GHz Rechner wirst du definitiv Probleme mit in einigen Spielen bekommen, weil sie einfach zu schnell laufen Wing Comander 1 und 2 zum Beispiel. Die 3 läuft aber denke ich.

Beim lesen dieses Beitrages habe ich mir ein paar Gedanken gemacht die wahrscheinlich nicht besonders hilfreich sind, aber trotzdem ein bischen zum Neben-Thema "Rechner zu schnell" passen könnten:
Ganz spontan fallen mir zwei Methoden ein um eigene Anwendungen die zu schnell laufen abzubremsen. Die erste Methode ist es die Ausgabegeschwindikeit durch den Rasterstrahl zu begrenzen. Eine weitere, zwar etwas altbackene Methode die aber sowohl auf neuen sowie auf älteren Rechnern funktioiniert ist es eine Geschwindigkeitsmessung vorzunehmen. Dafür benutze ich eine kleine Routine in der 64 Nops(No operation-Befehle) in einer Schleife mit einem zusätzlichen Register zum zählen der Runden enhalten sind. Die Schleife wird genau eine Sekunde lang ausgeführt. Diesen so ermittelten Wert des Rundenzählers kann man nun als Multiplikator für einen Verzögerungszähler verwenden.

Routine für eine Geschwindigkeitsmessung:

Code: Alles auswählen

; Datei abspeichern mit dem Namen: "SPEED.asm"
; Assemblieren und linken mit MASM 5:
; MASM /Z SPEED.asm,SPEED.obj,,
; LINK /CP:1 SPEED.obj,SPEED.exe,,,

.MODEL SMALL
.386
.CODE
 org 100h
                Cpu86    =   0
                Cpu286   =   4
                Cpu386   =   8
                Cpu486   =  12
                Cpu586   =  16

START:    mov      ax, @DATA
          mov      ds, ax             ; DS auf Daten-Bereich
;-------------------------------------
          call GETCPU                 ; Prozessor-Analyse:    AX=CPU
;-------------------------------------
          call GETSPEED               ; Zählschleife
;-------------------------------------
          call FILE                   ; create a new file
;-------------------------------------
          mov      ah, 4Ch            ; Dos-Rücksprung, Programm-Ende
          int    21h
;---------------------------------------------------------------------------
 org START + ((($-START)/16)*16) + 16
;---------------------------------------------------------------------------
GETCPU:   mov      ax, Cpu86
          xor      bx, bx
          push     bx                 ; Null auf Stack
          popf                        ; Null in Flagregister
          pushf
          pop      bx                 ; zurück nach bx
          and      bh, 0F0h
          cmp      bh, 0F0h           ; wenn gleich, dann 8086
          je  short CPUOK
;-------------------------------------
          mov      ax, Cpu286
          push     7000h              ; dasselbe mit 7000h
          popf
          pushf
          pop      bx
          and      bh, 70h
          jz  short CPUOK
;-------------------------------------
          mov      ax, Cpu386
          mov      edx, esp
          and      esp, 0FFFCh        ; durch vier teilbare Adr.
          pushfd
          pop      ebx
          mov      ecx, ebx
          btc      ebx, 18            ; Bit 18 umdrehen
          push     ebx
          popfd
          pushfd
          pop      ebx
          push     ecx                ; alte Flaggen zurück
          popfd
          mov      esp, edx           ; Stack zurück
          cmp      ecx, ebx           ; wenn gleich dann 386
          jz  short CPUOK
;-------------------------------------
          mov      ax, Cpu486
          btc      ecx, 21
          push     ecx
          popfd
          pushfd
          pop      ebx
          cmp      ebx, ecx           ; wenn ungleich, dann 486
          jnz short CPUOK
;-------------------------------------
          mov      ax, Cpu586         ; sonst Pentium
;----------------------------------------------------------------------------
CPUOK:    mov      bp, ax
          ret                         ; AX=Cpu
;---------------------------------------------------------------------------
 org START + ((($-START)/16)*16) + 16
;---------------------------------------------------------------------------
GETSPEED: cli                         ; Interrupt's verbieten
          xor      ax, ax
          mov      es, ax             ; ES auf Seg.: 0
;-------------------------------------
          mov      di, es:[20h]       ; Vector von INT 8 retten (Offset)
          mov      si, es:[22h]       ;                         (Segment)
;-------------------------------------
          mov      es:[20h], OFFSET NEUVEC ; Interrupt-Vector von INT 8
          mov      es:[22h], cs            ; auf neue Routine legen
;-------------------------------------
          mov      al, 36h            ; RUNDE auf 18,2 Hertz (Standard)
          out      43h, al
          xor      al, al
          out      40h, al            ; low
          out      40h, al            ; high
;-------------------------------------
          cmp      bp, 8              ;  32-Bit-CPU ?
          jb  short M16
          jmp  M32
;---------------------------------------------------------------------------
 org START + ((($-START)/16)*16) + 16
;---------------------------------------------------------------------------
M16:      mov      bp, 1              ; Aktiv-Flag = IRQ-Ende wenn 0
          xor      cx, cx             ; Zähler low
          xor      dx, dx             ; Zähler high
          sti                         ; neuen Interrupt 8 starten
;-------------------------------------
S1:       and      bp, bp             ; Auf IRQ-Ende warten
          jnz S1
          mov      bp, 1              ; Für's Zählen IRQ Aktiv-Flag setzen
;-------------------------------------
S2:       inc      cx                 ; Hauptzählschleife
          jnz short S3
          inc      dx
;-------------------------------------
S3:       nop                         ; 64 Nop's
          nop
          nop
          nop
          nop
          nop
          nop
          nop
          nop
          nop

          nop
          nop
          nop
          nop
          nop
          nop
          nop
          nop
          nop
          nop

          nop
          nop
          nop
          nop
          nop
          nop
          nop
          nop
          nop
          nop

          nop
          nop
          nop
          nop
          nop
          nop
          nop
          nop
          nop
          nop

          nop
          nop
          nop
          nop
          nop
          nop
          nop
          nop
          nop
          nop

          nop
          nop
          nop
          nop
          nop
          nop
          nop
          nop
          nop
          nop

          nop
          nop
          nop
          nop
;-------------------------------------
          and      bp, bp             ; auf Timer-IRQ-Ende abfragen
          jnz S2                      ; weiter, wenn Timer-IRQ noch aktiv
;-------------------------------
          mov      RUNDE, cx          ; Zähler low retten
          mov      RUNDE+2, dx        ; Zähler high retten
;---------------------------------------------------------------------------
ANALYS:   cli                         ; Interrupts verbieten
          mov      es:[20h], di       ; alten Interrupt-Vector
          mov      es:[22h], si       ; von INT 8 wiederherstellen
          sti                         ; Interrupts erlauben
          ret
;---------------------------------------------------------------------------
 org START + ((($-START)/16)*16) + 16
;---------------------------------------------------------------------------
M32:      mov      bp, 1              ; Aktiv-Flag = IRQ-Ende wenn 0
          xor      ecx, ecx           ; Zähler
          sti                         ; neuen Interrupt 8 starten
;-------------------------------------
S4:       and      bp, bp             ; Auf IRQ-Ende warten
          jnz S4
;-------------------------------------
          mov      bp, 1              ; Für's Zählen IRQ Aktiv-Flag setzen
;-------------------------------------
S5:       inc      ecx                ; Hauptzählschleife
          nop                         ; 64 Nop's
          nop
          nop
          nop
          nop
          nop
          nop
          nop
          nop
          nop

          nop
          nop
          nop
          nop
          nop
          nop
          nop
          nop
          nop
          nop

          nop
          nop
          nop
          nop
          nop
          nop
          nop
          nop
          nop
          nop

          nop
          nop
          nop
          nop
          nop
          nop
          nop
          nop
          nop
          nop

          nop
          nop
          nop
          nop
          nop
          nop
          nop
          nop
          nop
          nop

          nop
          nop
          nop
          nop
          nop
          nop
          nop
          nop
          nop
          nop

          nop
          nop
          nop
          nop
;-------------------------------------
          and      bp, bp             ; auf Timer-IRQ-Ende abfragen
          jnz S5                      ; weiter, wenn Timer-IRQ noch aktiv
;---------------------------------------------------------------------------
          mov     DWORD PTR[RUNDE], ecx ; Zähler retten
          jmp  ANALYS
;---------------------------------------------------------------------------
;               neue   I R Q - R o u t i n e   für  INT 8
;---------------------------------------------------------------------------
 org START + ((($-START)/16)*16) + 16
;---------------------------------------------------------------------------
NEUVEC:   mov      al, 20h            ; neue IRQ-Routine für INT 8
          dec      bp                 ; Aktiv-Flag löschen
          out      20h, al            ; =EOI
          iret
;---------------------------------------------------------------------------
 org START + ((($-START)/16)*16) + 16
;---------------------------------------------------------------------------
FILE:     mov      dx, OFFSET SPEEDNAM
          xor      cx, cx
          mov      ah, 3Ch              ; Datei erstellen
          int    21h
          mov      bx, ax
;---------------------------------------
          mov      dx, OFFSET RUNDE
          mov      cx, 4
          mov      ah, 40h              ; Datei beschreiben
          int    21h
;---------------------------------------
          mov      ah, 3Eh              ; Datei schließen
          int    21h
          ret
;---------------------------------------------------------------------------
 org START + ((($-START)/64)*64) + 64
;---------------------------------------------------------------------------
.DATA
 org 0
;---------------------------------------------------------------------------
RUNDE    DW 0, 0                        ; Anzahl der Schleifen-Durchläufe
SPEEDNAM DB "SPEED.tic", 0
;---------------------------------------------------------------------------
.STACK 20h
 end

Hinweis: Es wird eine Datei mit dem Namen "SPEED.TIC" mit 4 Bytes auf dem momentanen Datenträger/Verzeichniss angelegt die den ermittelten Wert der Schleifendurchläufe enthält.
Diese Routine dient nicht dazu die MHZ der verwendeten CPU zu ermittlen, sondern um einen Vergleichswert zwischen den verschieden schnellen CPUs zu ermitteln um damit eine entsprechende Verzögerung zu realisieren.
Auf meinem Core2Quad 9550 mit 2,8 Ghz ausgeführt unter XP enthält die Datei SPEED.TIC folgende Bytes: A5, F4, 78, 00 = entspricht hex 78F4A5 Schleifendurchläufe.

....

Jetzt bin ich am hin und her überlegen wie man damit auch fremde Anwendungen wie z.B. Wing Comander 1 und 2 damit ebenfalls ausbremsen könnte. Für entsprechende Vorschläge wäre ich dankbar.

Dirk

[ChrisR3tro]

Hi freecrac,

nach meiner Erfahrung braucht man bei richtiger Programmierung doch eigentlich die Geschwindigkeit einer CPU gar nicht zu messen oder? Sowas führt erfahrungsgemäß sowieso früher oder später zu Problemen. Zunächst ist im Spiel schonmal die Berechnung der Spielelogik und die Grafikdarstellung zu entkoppeln. Um Objekte mit einer bestimmten Geschwindigkeit zu bewegen richte ich normalerweise einen globalen Timer ein und mache die Berechnung der Logik davon abhängig. Die Darstellung eines Bildes erfolgt dann entweder nach einer festgelegten Framerate oder nach jedem VSYNC.

Was den Slowdown angeht gibt's eine Menge Tools die das im Hintergrund als TSR machen. Um nur einige zu nennen:

- Throttle (mein Favorit)
- Slowdown + CPUCACHE (wenn Throttle nicht ausreicht in Kombination)
- Bremze
- Moslo

Ansonsten komme ich auch schon sehr weit indem ich im BIOS den Cache ausschalte und die CPU runtertakte. Mit Throttle, CPU-Taktung und Cache aus in Kombination konnte ich letztens immerhin ein Spiel zocken was eignetlich für einen 386er ausgelegt war (auf meinem AMD K6-III+ @ 400 mhz). Wing Commander dürfte eigentlich auch kein Problem darstellen. Ob die Methoden ausreichen, um aktuelle CPUs richtig lahm zu bekommen, weiß ich nicht, aber wer will Wing Commander schon auf einem aktuellen PC zocken? Schon allein der Sound dürfte da Probleme machen...

Gruß,
locutus

[freecrac]

Hi freecrac,

nach meiner Erfahrung braucht man bei richtiger Programmierung doch eigentlich die Geschwindigkeit einer CPU gar nicht zu messen oder? Sowas führt erfahrungsgemäß sowieso früher oder später zu Problemen.

Wie sollte es denn damit zu Problemen kommen?

Zunächst ist im Spiel schonmal die Berechnung der Spielelogik und die Grafikdarstellung zu entkoppeln.

Das wäre von Vorteil, aber ist das denn bei den DOS-Spielen in der Regel auch so gemacht worden?

Um Objekte mit einer bestimmten Geschwindigkeit zu bewegen richte ich normalerweise einen globalen Timer ein und mache die Berechnung der Logik davon abhängig. Die Darstellung eines Bildes erfolgt dann entweder nach einer festgelegten Framerate oder nach jedem VSYNC.

Es genügt wohl nicht immer auf das Ende des Rasterstrahls zu warten um eine Anwendung auf eine bestimmte Geschwindigkeit zu trimmen?

Was den Slowdown angeht gibt's eine Menge Tools die das im Hintergrund als TSR machen. Um nur einige zu nennen:

- Throttle (mein Favorit)
- Slowdown + CPUCACHE (wenn Throttle nicht ausreicht in Kombination)
- Bremze
- Moslo

Ich habe selber noch keines dieser Programme verwendet. Gibt es hierbei Hinweise wie diese Programme arbeiten?

Ansonsten komme ich auch schon sehr weit indem ich im BIOS den Cache ausschalte und die CPU runtertakte.

Auch das habe ich noch nie versucht. Wieviel langsamer werden dadurch moderne Rechner?

Mit Throttle, CPU-Taktung und Cache aus in Kombination konnte ich letztens immerhin ein Spiel zocken was eignetlich für einen 386er ausgelegt war (auf meinem AMD K6-III+ @ 400 mhz). Wing Commander dürfte eigentlich auch kein Problem darstellen. Ob die Methoden ausreichen, um aktuelle CPUs richtig lahm zu bekommen, weiß ich nicht, aber wer will Wing Commander schon auf einem aktuellen PC zocken? Schon allein der Sound dürfte da Probleme machen...

Gruß,
locutus

Ich muss gestehen das es schon eine Ewigkeit her ist das ich ein DOS-Spiel gestartet habe. Ich glaube es war Pinball. Spielen tue ich heute in der Regel nur noch Windows-Spiele. DOS nutze ich nur noch zum Programmieren.

Dirk

[ChrisR3tro]

Wie sollte es denn damit zu Problemen kommen?

Also nach meiner Erfahrung scheitern Geschwindigkeitsmeßroutinen oft daran, daß immer schnellere CPUs rauskommen und irgendwann einfach den Meßbereich sprengen. Das war z.B. unter DOS der Fall beim Turbo Pascal Bug. Ein Beispiel für Windows ist Unreal Tournament (1), was ebenfalls zu Beginn die Geschwindigkeit mißt. Auf schnelleren CPUs läuft das Spiel viel zu schnell weil anscheinend die Meßroutine nicht optimal gelöst ist.

Andererseits stelle ich mir schwierig vor, die Geschwindigkeit einer CPU in einer Schleife zu bestimmen, je nachdem wie intelligent die CPU designt wurde (Pipelines, Befehlsstromoptimierung, Sprungvorhersage etc.) fluktuiert die Geschwindigkeit doch mit der Art des auszuführenden Codes, oder nicht? Weiterhin: Was für ältere CPUs (und unter DOS) kein Thema ist wird spätestens unter Windows mit Prozessoren zum Thema, die ihren Multiplikator dynamisch verändern können (Speedstep etc.). Eine Geschwindigkeitsmessung beim Start eines Programms liegt später vielleicht falsch, weil die CPU aus irgendwelchen Gründen (Akkubetrieb, Wait/sleep states etc.) während des Programmablaufs drosselt.

Das wäre von Vorteil, aber ist das denn bei den DOS-Spielen in der Regel auch so gemacht worden?

Viele ältere Spiele laufen auch auf aktuellen Rechnern in genau der richtigen Geschwindigkeit (z.B. Commander Keen 4). Es gibt natürlich auch ein paar schwarze Schafe, die abgehen wie eine Rakete (Wing Commander) oder den TP-Bug (s.o.) haben. Hier helfen dann echt nur die Brems-Maßnahmen die ich zuvor genannt habe.

Es genügt wohl nicht immer auf das Ende des Rasterstrahls zu warten um eine Anwendung auf eine bestimmte Geschwindigkeit zu trimmen?

Das kommt drauf an was man machen will. Wenn gewährleistet ist, daß das Spiel immer mit derselben Refreshrate läuft kann man die Berechnung der Spielelogik auch vom VSYNC-Signal abhängig machen. Dann ist kein Timer notwendig. Bei älteren Spielekonsolen ist das meines Wissens z.B. so gelöst, daß die Spielelogik an die Refresh rate des Fernsehsignals gekoppelt ist, da hier einfach die Refresh Rate feststeht. Bei PC-Spielen ist das nicht immer so. Gerade moderne Spiele können normalerweise in vielen Auflösungen mit verschiedenen Refresh Rates ausgeführt werden. Das gilt auch für späte DOS-Spiele. Hier funktioniert das Prinzip mit Sicherheit nicht mehr.

Ich habe selber noch keines dieser Programme verwendet. Gibt es hierbei Hinweise wie diese Programme arbeiten?

Throttle arbeitet nur mit manchen Chipsätzen zusammen, da es sich irgendwelche Stromsparmechanismen zu nutze macht. Genaueres findest du auf der Homepage.

Eine wirklich detaillierte und genau Erläuterung verschiedener Ansätze wie du CPUs unter DOS ausbremsen kannst, findest du in der Anleitung zu Slowdown. Die Anleitung findest du im Downloadarchiv des Programms.

Auch das habe ich noch nie versucht. Wieviel langsamer werden dadurch moderne Rechner?

Moderne Rechner werden wahrscheinlich nicht annähernd langsam genug für z.B. Wing Commander. Aber einen Mittelklasse Pentium (I) konnte man mit der Methode schonmal auf 486er- oder 386er-Niveau drücken.

Ich merke allerdings gerade, daß wir hier leicht vom Thema abschweifen. Nun also zurück zu "SB X-fi unter DOS"... Meine persönliche Meinung hierzu: PCI-Sound unter DOS funktioniert nicht. :-) Für ein kompatibles PC-System was möglichst viele DOS-Spiele mit Sound abspielen soll führt an ISA-Sound von Creative (leider) nichts vorbei.

Gruß,
locutus

[freecrac]

Wie sollte es denn damit zu Problemen kommen?

Also nach meiner Erfahrung scheitern Geschwindigkeitsmeßroutinen oft daran, daß immer schnellere CPUs rauskommen und irgendwann einfach den Meßbereich sprengen.

Mhm, das kann ich gar nicht verstehen. Wie man am Ergebniss für meinen Core2Quad 9550 mit 2,8 Ghz von "hex 0078F4A5" von meiner Messroutine erkennen kann ist dort noch sehr viel Platz im Wertebereich nach oben vorhanden.
Würden dort noch mehr Befehle in der Messschleifen enthalten sein, dann würde auch das Ergebniss von der Anzahl der Schleifendurchläufe sogar noch geringer ausfallen.

Das war z.B. unter DOS der Fall beim Turbo Pascal Bug.

Das hat jetzt aber nichts Spezielles mit der Geschwindigkeit der CPU zu tun, sondern ein "Division by zero"-Error ist ein schwerwiegender Programmierfehler der bei jeder x86-CPU auftreten kann, wenn man den Divisor auf Null beläßt und damit ein Divisions-Befehl ausführen läßt.
Dann stürzt ein DOS-Rechner ab oder im PM gibt es ein Exception-Fehler. Eine Ausnahme war der Pentium mit dem DIV-Bug den man mit einem BIOS-Update beheben konnte.
Warum man die CPUs so gebaut hat das eine Division durch Null zu einem Fehler führt und nicht einfach nur gar nicht geteilt wird, ist mir bis heute ein Rätsel geblieben. Bei der Multiplikation mal Null gibt es ja auch keinen Fehler.

Ein Beispiel für Windows ist Unreal Tournament (1), was ebenfalls zu Beginn die Geschwindigkeit mißt. Auf schnelleren CPUs läuft das Spiel viel zu schnell weil anscheinend die Meßroutine nicht optimal gelöst ist.

Das ist ein anderes Problem. Die modernen CPUs bringen so Einiges an Optimierung mit, so das ein Vergleich der MHZ zu älteren CPUs nicht wirklich sinnvoll ist. Meine Routine misst nur die Abarbeitung von NOP-Befehlen, besser wäre es jedoch ein Gemisch aus verschiedenen Befehlen zu messen, also nicht nur reine Integer-Befehle, sondern auch die von anderen Komponenten wie etwas die SIMD-Einheiten und den RAM-Zugriff.

Andererseits stelle ich mir schwierig vor, die Geschwindigkeit einer CPU in einer Schleife zu bestimmen, je nachdem wie intelligent die CPU designt wurde (Pipelines, Befehlsstromoptimierung, Sprungvorhersage etc.) fluktuiert die Geschwindigkeit doch mit der Art des auszuführenden Codes, oder nicht?

Ja genau so ist es.

Weiterhin: Was für ältere CPUs (und unter DOS) kein Thema ist wird spätestens unter Windows mit Prozessoren zum Thema, die ihren Multiplikator dynamisch verändern können (Speedstep etc.). Eine Geschwindigkeitsmessung beim Start eines Programms liegt später vielleicht falsch, weil die CPU aus irgendwelchen Gründen (Akkubetrieb, Wait/sleep states etc.) während des Programmablaufs drosselt.

Uff, mit dieser Problematik habe ich mich noch gar nicht beschäftigt. Ich lasse meine CPUs immer auf hochtouren fahren wenn es geht, jegliches Powermanagment schalte ich immer ab.

Das wäre von Vorteil, aber ist das denn bei den DOS-Spielen in der Regel auch so gemacht worden?

Viele ältere Spiele laufen auch auf aktuellen Rechnern in genau der richtigen Geschwindigkeit (z.B. Commander Keen 4). Es gibt natürlich auch ein paar schwarze Schafe, die abgehen wie eine Rakete (Wing Commander) oder den TP-Bug (s.o.) haben. Hier helfen dann echt nur die Brems-Maßnahmen die ich zuvor genannt habe.

Es genügt wohl nicht immer auf das Ende des Rasterstrahls zu warten um eine Anwendung auf eine bestimmte Geschwindigkeit zu trimmen?

Das kommt drauf an was man machen will. Wenn gewährleistet ist, daß das Spiel immer mit derselben Refreshrate läuft kann man die Berechnung der Spielelogik auch vom VSYNC-Signal abhängig machen. Dann ist kein Timer notwendig. Bei älteren Spielekonsolen ist das meines Wissens z.B. so gelöst, daß die Spielelogik an die Refresh rate des Fernsehsignals gekoppelt ist, da hier einfach die Refresh Rate feststeht. Bei PC-Spielen ist das nicht immer so. Gerade moderne Spiele können normalerweise in vielen Auflösungen mit verschiedenen Refresh Rates ausgeführt werden. Das gilt auch für späte DOS-Spiele. Hier funktioniert das Prinzip mit Sicherheit nicht mehr.

Ja das kann ich mir denken. Ich habe Vesamodi bis 160hz Refreshrate auf meinen 19"-CRT-Monis(96khz) verwendet. Allerdings habe ich damit noch kein Vergleichstest etwa mit Bildmodi von 60hz vorgenommen.

Ich habe selber noch keines dieser Programme verwendet. Gibt es hierbei Hinweise wie diese Programme arbeiten?

Throttle arbeitet nur mit manchen Chipsätzen zusammen, da es sich irgendwelche Stromsparmechanismen zu nutze macht. Genaueres findest du auf der Homepage.

Eine wirklich detaillierte und genau Erläuterung verschiedener Ansätze wie du CPUs unter DOS ausbremsen kannst, findest du in der Anleitung zu Slowdown. Die Anleitung findest du im Downloadarchiv des Programms.

Da werde ich gleich mal reinschauen.

Auch das habe ich noch nie versucht. Wieviel langsamer werden dadurch moderne Rechner?

Moderne Rechner werden wahrscheinlich nicht annähernd langsam genug für z.B. Wing Commander. Aber einen Mittelklasse Pentium (I) konnte man mit der Methode schonmal auf 486er- oder 386er-Niveau drücken.

Ich merke allerdings gerade, daß wir hier leicht vom Thema abschweifen. Nun also zurück zu "SB X-fi unter DOS"... Meine persönliche Meinung hierzu: PCI-Sound unter DOS funktioniert nicht. Für ein kompatibles PC-System was möglichst viele DOS-Spiele mit Sound abspielen soll führt an ISA-Sound von Creative (leider) nichts vorbei.

Gruß,
locutus

Das hatte ich schon befürchtet. Herzlichen Dank für deine Hilfe.

Dirk

[elianda]

Nochwas zu der Speed Testschleife: Da CPUs bis 486er keinen integrierten Timer haben wie die Pentium und besser CPUs bleibt einem leider nichts weiter übrig als eine solche Schleife zu machen, um den Bezug zwischen Takt und wirklicher Zeit herzustellen. Ab Pentium löst man das normal über den CPU-TImer.
Aber wie Du auch schon schriebst sind NOPs ungünstig. Es kann sein, dass bei neueren CPUs die NOPs gleich am Anfang der µCode Konversion herausgeworfen werden, so dass man im Prinzip die Geschwindigkeit des L1-Caches misst.
Irgendetwas, das Recheneinheiten belastet, womoeglich noch mit Abhängigkeiten sollte das ganze stabiler gegen Architekturunterschiede machen.
z.B. irgendwie sowas, dass man n Ergebnisse 'parallel' berechnet und am Ende mit der Summe des Ergebnisses weiterrechnet. Dort wo die Summe gebildet wird, muss die CPU auf alle Ergebnisse warten...
Vielleicht kann man das n sogar über die CPU-Identifikation mit den verfügbaren Pipelines korrelieren, z.B. n=P+1

[Doctor Creep]

Meine persönliche Meinung hierzu: PCI-Sound unter DOS funktioniert nicht. Für ein kompatibles PC-System was möglichst viele DOS-Spiele mit Sound abspielen soll führt an ISA-Sound von Creative (leider) nichts vorbei.

Wenn ich noch ein ISA-Slot mehr hätte, würde ich mir auch noch ne ISA-Soundblaster einbauen. Allerdings bin ich *sehr* angenehm überrascht wie kompatibel die o.g. Lösung über CTSYN bzw. SBEINIT.COM mit der PCI SB Live! ist. Auch mein "Bootintro" Warlock funktioniert wie gesagt damit soundmässig problemlos.

http://www.dosforum.de/viewtopic.php?f=2&t=3948&start=0

Wenn ich mir es recht überlege, hab ich bis jetzt alle DOS-Games in puncto Sound zum Laufen gebracht. Welche gelten denn diesbezüglich als besonders zickig?

Doc

[Dosenware]

Wenn ich noch ein ISA-Slot mehr hätte

http://www.helmix.at/isaext_idx.htm

[ChrisR3tro]

@Dr. Creep: Versuch' mal Tyrian. :-)

[freecrac]

Nochwas zu der Speed Testschleife: Da CPUs bis 486er keinen integrierten Timer haben wie die Pentium und besser CPUs bleibt einem leider nichts weiter übrig als eine solche Schleife zu machen, um den Bezug zwischen Takt und wirklicher Zeit herzustellen. Ab Pentium löst man das normal über den CPU-TImer.
Aber wie Du auch schon schriebst sind NOPs ungünstig. Es kann sein, dass bei neueren CPUs die NOPs gleich am Anfang der µCode Konversion herausgeworfen werden, so dass man im Prinzip die Geschwindigkeit des L1-Caches misst.
Irgendetwas, das Recheneinheiten belastet, womoeglich noch mit Abhängigkeiten sollte das ganze stabiler gegen Architekturunterschiede machen.
z.B. irgendwie sowas, dass man n Ergebnisse 'parallel' berechnet und am Ende mit der Summe des Ergebnisses weiterrechnet. Dort wo die Summe gebildet wird, muss die CPU auf alle Ergebnisse warten...
Vielleicht kann man das n sogar über die CPU-Identifikation mit den verfügbaren Pipelines korrelieren, z.B. n=P+1

Damit bekäme man ganz gewiss genauere Messergebnisse. Aber Ich frage mich in wie weit man eine so hohe Genauigkeit denn überhaupt benötigt und unter welchen Anforderungen das wichtig wäre. Mit welcher Ungenauigkeit haben wir es denn überhaupt zu tun?

Auganspunkt meiner Messroutine war eine Anwendung wo man einen Auswahl-Balken innerhalb eines Menüs über die 4 Cursortasten bewegen konnte, um damit bestimmte Menüpunke zu erreichen. Auf schnelleren Rechnern führte die dort vorherige fixe Verzögerung dazu, das man das Menü nicht mehr sinnvoll benutzen konnte, weil der Balken sich erheblich zu schnell bewegte. Mit der Messroutine zusammen lieferte diese eine ungefähre Größenordnung für eine halbwegs adepuate Verzögerung, um das Menü wieder nutzbar zu machen. Es kam mir zwar so vor als wenn die Bewegung durch das Menü auf unterschiedlich schnellen Rechnern leicht varierte, doch das lag innerhalb eines Tolleranzbereiches und korrelierte mit den feinmotorischen Reflexen die enstprechenden Tasten zu drücken um durch das Menü zu navigieren.

Ein völlig anderen Ansatz ist es die gesamte CPU-Geschwindigkeit quasi zu drosseln indem man z.B. den Cache abschaltet. Ich habe mir jetzt mal einen groben Überblick darüber verschafft welche Verfahren hierbei geeignet sind.
Für meine eigenen Anwendungen möchte ich allerdings nicht auf die volle CPU-Power verzichten wollen, da es ja immer Möglichkeiten gibt einen bestimmten Part zu verzögern, wenn andere Bereiche völlig ungebremst ihre Aufgaben erledigen.

Dirk