(14.10.2011, 22:02)Crystal schrieb: Jetzt muss ich mal schauen, was passiert, wenn ich meinen Patch über die GG-Version laufen lasse, ob der Druide dann verschwindet oder nicht.
Der Druide ist zwar noch da, aber jetzt krieg ich mit der V1.12 eine ausführliche und kryptische Fehlermeldung, woran sich jemand gewieftes dransetzen kann.
Code:
Error [35]: Unexpected Interrupt=00CC in RIVA.EXE at 01FF:2009
code=0000 ss=00A8 ds=7C00 es=0000
ax=1509 bx=0100 cx=00A9 dx=FF00 sp=003B bp=BB86 si=0031 di=0000
14.10.2011, 22:23 (Dieser Beitrag wurde zuletzt bearbeitet: 14.10.2011, 22:24 von Rabenaas.)
(14.10.2011, 22:05)Zurgrimm schrieb: Was macht das Programm denn, d.h. woran liegt der Bug nun?
Das ist ein DOS extender, so wie DOS/4GW. Es erweitert die Funktionalität von DOS so, dass die besonderen Features eines 386 (Protected Mode) zur Verfügung stehen. DOS ist ja eigentlich auf den 8086 (Real Mode) abgestimmt.
Wie das genau funktioniert (immerhin ist DOS/4GW mit der RIVA.EXE verbunden), weiß ich jetzt auch nicht. Vielleicht kann Luigi das genauer erklären, wenn er wieder da ist. Jedenfalls scheint HX besser mit der DosBox klar zu kommen, als seine Konkurrenten.
Andere Idee: Riva ist so programmiert, dass es erkennt, wenn es unter Windows startet, und HX bildet Teile von Windows DOS-Modus nach.
Jedenfalls handelt es sich um Probleme mit dem Speichermanagement innerhalb der DosBox.
14.10.2011, 22:37 (Dieser Beitrag wurde zuletzt bearbeitet: 14.10.2011, 22:39 von Crystal.)
(14.10.2011, 21:36)Luigi schrieb: Und Taadaa
Spiegelbug mit DOSBOX0.74 und Pergors Spielstand tritt nicht mehr auf!!
also DPMI-Host HDPMI
und Dosextender DOS32A
xms auf 0, da man DOS32A zwingen muss den DPMI-Host zu benutzen anstatt XMS
Man braucht sogar nicht zwingend auf DOS32A auszuweichen, mit DOS4GW bekomme ich bei gestartetem HDPMI32 ebenfalls keine Druiden mehr. Weder mit cheshires Dreiergruppe noch mit meiner Sechsergruppe.
15.10.2011, 01:07 (Dieser Beitrag wurde zuletzt bearbeitet: 15.10.2011, 16:05 von Luigi.)
(14.10.2011, 22:23)Rabenaas schrieb:
(14.10.2011, 22:05)Zurgrimm schrieb: Was macht das Programm denn, d.h. woran liegt der Bug nun?
Das ist ein DOS extender, so wie DOS/4GW. Es erweitert die Funktionalität von DOS so, dass die besonderen Features eines 386 (Protected Mode) zur Verfügung stehen. DOS ist ja eigentlich auf den 8086 (Real Mode) abgestimmt.
Wie das genau funktioniert (immerhin ist DOS/4GW mit der RIVA.EXE verbunden), weiß ich jetzt auch nicht. Vielleicht kann Luigi das genauer erklären, wenn er wieder da ist. Jedenfalls scheint HX besser mit der DosBox klar zu kommen, als seine Konkurrenten.
Andere Idee: Riva ist so programmiert, dass es erkennt, wenn es unter Windows startet, und HX bildet Teile von Windows DOS-Modus nach.
Jedenfalls handelt es sich um Probleme mit dem Speichermanagement innerhalb der DosBox.
Du hast definitiv Recht.
Der Fehler tritt selbst dann nicht mehr auf, wenn HDPMI32 nicht als DPMI-Host genutzt wird.
Er muss nur installiert sein! Das alte msd.exe von MS meint auch, dass es unter Windows3.11 läuft, wenn HDPMI32 installiert ist.
Ich benutze DOS32a. Dos32a hat aber die Eigenart, dass es, wenn möglich XMS-Speicher nutzt und nicht
einen vorhandenen DPMI-Host.
Im Gegensatz zu Dos4Gw dass den HDPMI32 als Host benutzt.
Ob der HDPMI32 Host genutzt wird ist ganz leicht herauszufinden.
STRG-ALT-Entf
Dos32a und ich glaub auch Dos4GW als DPMI-Hosts brechen nicht ab.
HDPMI32 bricht die Anwendung/Riva ab.
an meiner DOSBOX.conf sieht man folgendes:
getuned auf maximalen konventionellen Speicher und mit DOSIDLE sinkt die CPU-Auslastung im Ruhezustand auf NULL.
Unbedingt beachten: Cycles fix einstellen, ich hab 66666 eingestellt.
bei Cycles=auto bzw. max ist in Verbindung mit DOSIDLE absolut "tödlich"
und mit
dos32a.exe riva
das Spiel starten
Wie schon geschrieben:
Es ging mir nie um Fehlerbehebung, sondern nur um Speicher-/Performance-Tuning.
Performance ist eigentlich nicht ganz richtig, mich hat einfach nur die Vollauslastung der CPU bzw. eines CPU-Kernes gestört.
(15.10.2011, 01:07)Luigi schrieb: Performance ist eigentlich nicht ganz richtig, mich hat einfach nur die Vollauslastung der CPU bzw. eines CPU-Kernes gestört.
Eine geringe CPU-Auslastung bedeutet bei Laptops auch noch längere Akkulaufzeiten. Ab demnächst nicht mehr ohne.
Wow, super Lösung! Wenn das gesamte Spiel damit durch läuft (ich gehe mal davon aus, die Tester testen das sicher noch mal) dann ist die Lösung dieses Bugs ja gleichzusetzen mit der Lösung des Rätsels um den Sphärenriss! (na wenn das kein Kompliment ist ;>)
Falls es wieder allen Erwartens lizenzrechtliche Probleme geben sollte hat DOSBox auch CWSDPMI an Bord wobei ich da gehört habe das das allerdings nicht ganz rund läuft und einige Macken hat und HDPMI32 die bessere Wahl ist.
(15.10.2011, 07:20)Calesca schrieb: Könnte jetzt jemand einer völlig Unbedarften erklären, was nun das Problem und was sie Lösung ist? Also, in verständlichen Worten, wenn es geht.
Ich, also...wenn Du.. und dann in Riva...und äh ...nein.
(15.10.2011, 07:20)Calesca schrieb: Könnte jetzt jemand einer völlig Unbedarften erklären, was nun das Problem und was sie Lösung ist? Also, in verständlichen Worten, wenn es geht.
Das hatte ich so ähnlich ja oben auch gefragt. Ich denke der Kernsatz für den Laien ist dieser:
(14.10.2011, 22:23)Rabenaas schrieb: Jedenfalls handelt es sich um Probleme mit dem Speichermanagement innerhalb der DosBox.
15.10.2011, 13:01 (Dieser Beitrag wurde zuletzt bearbeitet: 15.10.2011, 13:03 von Rabenaas.)
Vermutlich läuft es so: Für den Spiegelkampf gibt es eine Routine, die die Werte der Helden von einem Teil des Speichers in einen anderen kopiert (und damit die Spiegelgegner erschafft), und die auch nur für den Spiegelkampf verwendet wird. Diese macht irgendeine Annahme, welche die DosBox nicht erfüllt. Durch das Programm von Luigi wird der Kopiermechanismus durch einen anderen (für eine Windows-Umgebung gedachten) ersetzt, der funktioniert.
Warum einige Spielversionen keine Probleme bereiten, und andere schon, erklärt diese Theorie aber nicht.
15.10.2011, 13:40 (Dieser Beitrag wurde zuletzt bearbeitet: 15.10.2011, 13:41 von Crystal.)
(15.10.2011, 13:01)Rabenaas schrieb: Vermutlich läuft es so: Für den Spiegelkampf gibt es eine Routine, die die Werte der Helden von einem Teil des Speichers in einen anderen kopiert (und damit die Spiegelgegner erschafft), und die auch nur für den Spiegelkampf verwendet wird.
Und genau das wird auch die passende Erklärung für Ivan und Jochen sein, damit die beiden die Problematik auch ohne den verschollenen Source-Code nachvollziehen können.
Andersrum gesagt: Hätte man es in Schick und Schweif ebenfalls mit gespiegelten Gegnern zu tun gehabt, würde man für diese beiden Spiele vermutlich ebenfalls HDPMI32 benötigen.
(15.10.2011, 13:01)Rabenaas schrieb: Vermutlich läuft es so: Für den Spiegelkampf gibt es eine Routine, die die Werte der Helden von einem Teil des Speichers in einen anderen kopiert (und damit die Spiegelgegner erschafft), und die auch nur für den Spiegelkampf verwendet wird. Diese macht irgendeine Annahme, welche die DosBox nicht erfüllt. Durch das Programm von Luigi wird der Kopiermechanismus durch einen anderen (für eine Windows-Umgebung gedachten) ersetzt, der funktioniert.
Warum einige Spielversionen keine Probleme bereiten, und andere schon, erklärt diese Theorie aber nicht.
Das ist jetzt nur was Spezielles für Raabenaas um seine Theorie zu bestätigen, aber sonst völlig sinnlos und blödsinning!
bei Quemm gab es auch den Befehl device.com und mit dem hab ich mal probiert den Emm386.exe(Windows98SE) in der Dosbox zu laden.
Es haut hin. Dosbox ist dann im V86-Mode und nicht mehr Real-Mode und die ganze Speicherverwaltung läuft dann mit Emm386.exe als VCPI-Server???
Mit Pergors Spielstand tritt in dieser Konfiguration auch kein Spiegelbug mehr auf.
... xms=1
ems=0
umb=1
keyboardlayout=auto
[ipx]
# ipx: Enable ipx over UDP/IP emulation.
ipx=false
[autoexec]
# Lines in this section will be run at startup.
# You can put your MOUNT lines here.
mount c d:\dos
imgmount d D:\CD-Images\DSA\960927_1053.cue -t iso
c:
cd dos loadhi dosidle
device emm386.exe noems
# loadhi hdpmi32 -r
cd ..
cycles=66666
...
(15.10.2011, 01:07)Luigi schrieb: Performance ist eigentlich nicht ganz richtig, mich hat einfach nur die Vollauslastung der CPU bzw. eines CPU-Kernes gestört.
Eine geringe CPU-Auslastung bedeutet bei Laptops auch noch längere Akkulaufzeiten. Ab demnächst nicht mehr ohne.
Dieses alte DosIdle funktioniert bei mir in der Combo Riva, Dosbox, Dos32a und HDPMI32 ideal.
15.10.2011, 15:37 (Dieser Beitrag wurde zuletzt bearbeitet: 15.10.2011, 15:38 von Crystal.)
Um Luigis Lösungsvorschlag mit HDPMI32 nachvollziehen zu können, hier die modifizierte Config der Neuauflage:
Erstmal von hier die Runtime der V2.17 (release candidate) downloaden und alle Dateien des BIN-Unterverzeichnisses in das c:\dosgames\dsa3-Verzeichnis entpacken.
Danach im c:\dosgames-Verzeichnis die dosboxDSA3.conf mit dem windowseigenen Editor öffnen und den Autoexec-Abschnitt wie folgt ändern, damit die Neuauflage von Riva automatisch mit gestartetem HDPMI32 hochfahren kann.
Code:
[autoexec]
# Lines in this section will be run at startup.
# You can put your MOUNT lines here.
echo off
mount c C:\DOSGAMES\DSA3\ -ioctl
imgmount d C:\DOSGAMES\dsaschatt\960927_1053.cue -t cdrom
c:
hdpmi32 -r
Speichern nicht vergessen und anschließend wieder auf das DSA3-Icon klicken, das bei euch auf dem Desktop oder in der Schnellstartleiste angelegt wurde. Der Spiegelkampf wird bei mir unter XP korrekt dargestellt, keine Druiden mehr vorhanden.
Anmerkung: Mit eingeschaltetem ECHO ON habe ich mir anzeigen lassen, dass der C:-Mountbefehl zuletzt gesetzt wird, weshalb die Zeilen im Autoexec-Abschnitt erstmal ins Leere gegriffen haben.
Abhilfe schafft ein zusätzlicher C:-Mount, den ich oberhalb des IMGMOUNT-Befehl gesetzt habe. Laufwerk C wird zwar doppelt angemeldet, aber das macht nichts.
Die Zeile, in der das c: alleine steht, ist wichtig, weil DOSBox beim Hochfahren auf das virtuelle Laufwerk Z: zeigt. Damit HDPMI32 im Riva-Verzeichnis gefunden und geladen werden kann, muss man daher in der Conf der DOSBox erstmal sagen, dass es zuvor das Laufwerk wechseln soll, bevor es HDPMI32 aufruft.
Ich habe das jetzt zur Info mal aufgeschrieben, damit auch die Schick- und Schweif-Tester das mal eben checken können, ob der Spiegelkampf damit problemlos möglich ist. Insbesondere Pheonix und Boneman möchten das mal testen, ob auch Windows 7 damit klarkommt.
Natürlich auch für Pergor und Boomer gedacht, damit sie es unter Vista testen können.
(15.10.2011, 15:37)Crystal schrieb: Um Luigis Lösungsvorschlag mit HDPMI32 nachvollziehen zu können, hier die modifizierte Config der Neuauflage:
Erstmal von hier die Runtime der V2.17 (release candidate) downloaden und alle Dateien des BIN-Unterverzeichnisses in das c:\dosgames\dsa3-Verzeichnis entpacken.
...
Hallo,
entschuldige bitte, ich habe die HXRT-Runtime 2.16 (stable) benutzt!
Das Programm HDPMI32.exe hat in diesem Package die Version 3.17.
(15.10.2011, 15:37)Crystal schrieb: Erstmal von hier die Runtime der V2.17 (release candidate) downloaden und alle Dateien des BIN-Unterverzeichnisses in das c:\dosgames\dsa3-Verzeichnis entpacken.
Mein Virenscanner (Avira) meldet den Trojaner TR/Monder.81920.1 in der DKRNL32.DLL. Ich schätze mal, das ist ein Fehlalarm, hätte das aber gern nochmal von jemandem explizit bestätigt.
15.10.2011, 16:07 (Dieser Beitrag wurde zuletzt bearbeitet: 15.10.2011, 16:11 von Obi-Wahn.)
Beir mir auch. Allerdings was anderes.
Code:
Beginne mit der Suche in 'C:\Users\Obi-Wahn\Downloads\HXRT216.zip'
C:\Users\Obi-Wahn\Downloads\HXRT216.zip
[0] Archivtyp: ZIP
--> BIN/DUSER32.DLL
[FUND] Enthält Erkennungsmuster des Rootkits RKIT/Agent.41984.1
--> TEST/ENUMMODE.EXE
[FUND] Ist das Trojanische Pferd TR/Crypt.XPACK.Gen
Ah, okay die andere Datei. bei der Version 2.17 gibts die gleiche Meldung, wie bei Boneman.
(15.10.2011, 15:37)Crystal schrieb: Erstmal von hier die Runtime der V2.17 (release candidate) downloaden und alle Dateien des BIN-Unterverzeichnisses in das c:\dosgames\dsa3-Verzeichnis entpacken.
Mein Virenscanner (Avira) meldet den Trojaner TR/Monder.81920.1 in der DKRNL32.DLL. Ich schätze mal, das ist ein Fehlalarm, hätte das aber gern nochmal von jemandem explizit bestätigt.
Verdammt, das wollte ich gerade schreiben! Ist ein Fehlalarm den ich auch habe.
Ich benutze auch Avira und ich hab denen schon vor 3 Jahren das als "False Positive" gemeldet.
Aber sie haben nichts gemacht.
Von dem ganzen Package brauchst du sowiso nur hdpmi32.exe.
(15.10.2011, 16:03)Boneman schrieb: Mein Virenscanner (Avira) meldet den Trojaner TR/Monder.81920.1 in der DKRNL32.DLL. Ich schätze mal, das ist ein Fehlalarm, hätte das aber gern nochmal von jemandem explizit bestätigt.
![[Bild: kaesetoast.png]](https://www.crystals-dsa-foren.de/images/smilies/kaesetoast.png)
