Seite 1 von 2
Das ewige Problem Soundausgabe auf neuen Rechnern SB X-fi
Verfasst: Mo 3. Mai 2010, 12:44
von 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
Re: Das ewige Problem Soundausgabe auf neuen Rechnern SB X-fi
Verfasst: Mo 3. Mai 2010, 13:40
von Doctor Creep
RepaintAndrew hat geschrieben: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
Re: Das ewige Problem Soundausgabe auf neuen Rechnern SB X-fi
Verfasst: Mo 3. Mai 2010, 22:49
von 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 ??
Re: Das ewige Problem Soundausgabe auf neuen Rechnern SB X-fi
Verfasst: Di 4. Mai 2010, 07:34
von 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.
Re: Das ewige Problem Soundausgabe auf neuen Rechnern SB X-fi
Verfasst: Di 4. Mai 2010, 18:58
von 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 ??
Re: Das ewige Problem Soundausgabe auf neuen Rechnern SB X-fi
Verfasst: Mi 5. Mai 2010, 11:26
von freecrac
Kurt Steiner hat geschrieben: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
Re: Das ewige Problem Soundausgabe auf neuen Rechnern SB X-fi
Verfasst: Mi 5. Mai 2010, 12:15
von 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
Re: Das ewige Problem Soundausgabe auf neuen Rechnern SB X-fi
Verfasst: Mi 5. Mai 2010, 13:04
von freecrac
Locutus hat geschrieben: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
Re: Das ewige Problem Soundausgabe auf neuen Rechnern SB X-fi
Verfasst: Mi 5. Mai 2010, 14:55
von ChrisR3tro
RepaintAndrew hat geschrieben: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.
freecrac hat geschrieben: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.
freecrac hat geschrieben: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.
freecrac hat geschrieben: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.
freecrac hat geschrieben: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
Re: Das ewige Problem Soundausgabe auf neuen Rechnern SB X-fi
Verfasst: Mi 5. Mai 2010, 20:01
von freecrac
Locutus hat geschrieben:RepaintAndrew hat geschrieben: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 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.
freecrac hat geschrieben: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.
freecrac hat geschrieben: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.
freecrac hat geschrieben: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.
freecrac hat geschrieben: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
Re: Das ewige Problem Soundausgabe auf neuen Rechnern SB X-fi
Verfasst: Fr 7. Mai 2010, 04:59
von 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
Re: Das ewige Problem Soundausgabe auf neuen Rechnern SB X-fi
Verfasst: Fr 7. Mai 2010, 09:10
von Doctor Creep
Locutus hat geschrieben: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
Re: Das ewige Problem Soundausgabe auf neuen Rechnern SB X-fi
Verfasst: Fr 7. Mai 2010, 09:33
von Dosenware
Doctor Creep hat geschrieben:
Wenn ich noch ein ISA-Slot mehr hätte
http://www.helmix.at/isaext_idx.htm
Re: Das ewige Problem Soundausgabe auf neuen Rechnern SB X-fi
Verfasst: Fr 7. Mai 2010, 11:33
von ChrisR3tro
@Dr. Creep: Versuch' mal Tyrian. :-)
Re: Das ewige Problem Soundausgabe auf neuen Rechnern SB X-fi
Verfasst: Fr 7. Mai 2010, 12:29
von freecrac
elianda hat geschrieben: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