DOSBox ECE (Enhanced Community Edition) – de

Hier könnt ihr meine jeweils aktuellen Builds von DOSBox für Windows und Linux herunterladen.

DOSBox emuliert einen alten DOS-PC und ist meiner Meinung nach der Emulator für PC-Spiele die noch MS-DOS als Betriebssystem voraussetzen. Die letzte offiziell veröffentlichte Version ist 0.74, die aber bereits Mitte 2010 herauskam. Seither wurde DOSBox zwar kontinuierlich weiter entwickelt, aber keine offizielle Version mehr freigegeben, alle Änderungen werden nur noch als Quellcode z.B. auf SourceForge, zum Download angeboten.

Da ich DOSBox oft und gerne nutze erstelle ich meist zeitnah nach Veröffentlichung einer neuen Version auf SourceForge eine unangetastete Version und eine, die diverse Patches mit Verbesserungen enthält, die von verschiedenen Usern im DOSBox-Forum auf vogons.org erstellt wurden. Aus diesem Grund habe ich diese Version “Enhanced Community Edition”, kurz ECE genannt. In der VOGONS-Community bekommt Ihr auch Hilfe, wenn ihr ein Problem mit oder eine Frage zu DOSBox habt.

Aktuell unterscheidet sich die ECE durch folgende Features vom normalen DOSBox:

Eine kurze Übersicht über die integrierten Patches findet Ihr auch in einer Textdatei im entsprechenden Download. Ältere Versionen findet Ihr im Ordner “archive“:


46 Kommentare

  1. wo kann man eine übersicht zu den benötigten abhängigkeiten unter linux finden? dosbox habe ich zwar installiert, ece lässt sich aber nicht starten.

    1. Das sollte mit dem Befehl “ldd” gehen, die genaue Syntax habe ich gerade nicht im Kopf, aber ich meine dass es genügt den Pfad zur Binary dahinter anzugeben.

      Funktioniert denn das normale DOSBox? Die einzige Abhängigkeit, die mit ECE neu dazu kommen sollte wäre eigentlich Fluidsynth, alles andere sollte statisch in der Binary enthalten sein.

      1. danke, das problem liegt glaube ich daran: dosbox in der repo ist nur noch 64bit, ece ist wahrscheinlich 32bit, daher fehlen da noch einige abhängigkeiten.

        libSDL-1.2.so.0 => not found
        libpng12.so.0 => not found
        libSDL_net-1.2.so.0 => not found
        libfluidsynth.so.1 => not found

        wird es in absehbarer zeit ev auch eine 64bit ece version geben?

          1. interessant, zumindest mit der repo hat man jedoch keine wahl, außerdem ist die info einfach viel zu versteckt.

            von der geschwindigkeit mit 64bit kann ich nicht klagen (rechner ist 5 jahre alt). habe bei rechner alles auf auto und svga_s3 und benutze immer die höchste mögliche auflösung – ein direkter vergleich wäre mal spannend…

            lang lebe 32bit 😉

  2. Es wäre toll, wenn man den Speicher (mem auf >64 MB stellen könnte (z.B. wie bei der Daum Version auf 512). Dann würde Win9x besser laufen. Danach bitte noch einen Patch, damit man
    CD-Images unter WIn 9x mounten kann…

    Zuletzt bitte eine Menu-Leiste zum schnellen konfigurieren….

    Ich glaube, dann ist es perfekt.

    Und natürlich vielen vielen Dank für die bereits super tolle Version.

    1. Das sind zwar lauter sinnvolle Features, aber ich konzentriere mich bei DOSBox ECE eher darauf, die Sound, Optik und Steuerung von DOS-Spielen zu verbessern. Ich bin auch kein Entwickler, ich kann also auch nur implementieren, was bereits als funktionierender Patch vorliegt.

      Wenn Du DOSBox hauptsächlich dazu nutzt, Windows 9x darin laufen zu lassen, solltest Du Dir mal DOSBox-X anschauen, der Autor hat da viel dran getan damit Windows so gut wie möglich nutzbar wird. Oder PCem, das inzwischen auch gerne dafür genutzt wird und recht viel Möglichkeiten bietet.

      Danke für das Lob, nichts zu danken!

      1. Ich glaube, dass deine Version so ziemlich die schnellste möglichkeit ist, 3D Apps unter WIndows 9x auszuführen. Das einzige Problem ist dass der Hauptspeicher auf <64MB beschränkt ist. Würde sich das aus Dosbox-X implementieren lassen? DOsbox-Xist gerade bei der Voodoo-Emulation brutal langsam (im Vergleich)

          1. hat leider nicht funktioniert. Bereits in der Konsole kann man lesen: 255 is outside the allowed range1-63 for variable: memsize. It has been set to the closest boundary:63
            Vermutlich wird an irgendeiner Stelle im Programm abgefragt, ob der wert >63 ist und dann automatisch zurückgesetzt … ganz unabhängig davon, ob es mit deinen Code-änderungen von WIndows als RAm erkannt würde

          2. Vielen Dank, Leider geht auch die neue Version (noch) nicht. Einfach mal “”mem” in die Konsole eingeben. Unter XMS wird dann max. 63 MB angezeigt bzw weniger als 63, wenn man z.B.150 als memsize eingibt. bei 255 ists wieder 63. Ich denke, das hat was mit einer internen festen EInstellung zu tun immer 0-63, 64-127 entspricht dann wieder 0-63 … u.s.w

            bei dosbox-x wird auch mit “mem” der eingestelllte XMS Wert angezeigt.

        1. Leider hilft es auch nichts, EMS oder XMS zu deaktivieren.
          Es ist zwar möglich, wenn man nur EMS=True setzt zu erreichen, dass man >64 MB EMS Speicher in DOS bekäme. Ob man den dann wirklich aht ist unbekannt, “mem” Befehl zeigt es so aber an.

          In Windows wird dieser Spreicher aber sowieso nicht erkannt. Egal was man macht, mehr als 64MB werdens nicht.

        2. Der neue Patch funktioniert. WIndows erkennt den zusätzlichen Speicher und scheint ihn auch zu nutzen. 3dMax99 Benchmark scheint aber ein bisschen langsamer zu laufen (overhead wegen größerem Speicher?). Das muss man aber noch etwas mit anderen Programmen gegentesten. Ansonsten könnte ich mir den Patch auch in “normalen” ECE Version gut vorstellen.

  3. Die Midi Devices lassen sich echt prima leicht austauschen. Ich hab mir dafür einfach n paar batchfiles angelegt die bei Bedarf aus der für jedes Spiel manuell individuell angelegten start.bat aufgerufen werden, zusätzlich zu evtl. nötigen anderen Sachen. (z.B. MT32 für Monkey Island oder GM mit Soundfont für Doom) 🙂 Was mir noch fehlen würde wären filter wie bei der Daum Variante. Passt aber vermutlich nicht zum Pixel perfect patch…

  4. Hallo ich habe gerade die Version 4068 heruntergeladen und bei Dune 2 MT32 eingestellt leider klingt es garnicht nach MT32.
    Gibt es noch etwas zu beachten beim Setup?

        1. Wenn es mit MUNT geht, hast Du in DOSBox noch den falschen Miditreiber ausgewählt, der steht dann noch auf “default” oder “win32”. Du musst in der conf-Datei in der Sektion Sektion [midi] die Zeile “mididevice=default” (oder “mididevice=win32”) in “mididevice=mt32” ändern und der Wer in der Zeile “mt32.romdir” muss den Pfad enthalten, in dem die Steuerungs-Roms (MT32_PCM.ROM, MT32_CONTROL.ROM, etc.) abgelegt sind, z.B. “mt32.romdir=C:\DOSBOX\MT32”.

  5. Hallöchen, ich habe eine Frage zum integrierten MUNT. Wie konfiguriere ich das per D-Fend Reloaded? Aktuell lass ich den externen Emulator laufen. Kann ich den getrost löschen? Und basiert der integrierte Emulator auf der aktuellen Version (2.20)?

    1. Hi! Ich kenne D-Fend Reloaded nicht, deswegen kann ich Dir da leider nicht weiterhelfen. Das einzige Frontend, von dem ich weiß dass es ECE zumindest teilweise unterstützt, ist DBGL ab Version 0.82 (http://members.quicknet.nl/blankendaalr/dbgl/#changelog). Falls Du in DBGL benutzerdefinierte Optionen angeben kannst, wäre das der einzige Weg, die Optionen kannst Du ja aus einer conf-Datei rauskopieren. Wenn Du den externene Emulator nur wegen DOSBox nutzt, kannst Du den deinstallieren, der integrierte MT32Emu nutzt die aktuelle Version 2.2.0. Es gibt aber keine grafische Oberfläche wie beim externen MUNT, bestenfalls sind Anzeigen des MT32 im DOSBox Staus-Fenster zu sehen!

      1. Super, danke! Werde glaub ich jetzt ohnehin auf DBGL umsteigen. Im Gegensatz zu D-Fend Reloaded scheint hier noch aktiv entwickelt zu werden. Eine Frage noch zur Pixel-perfekten Ausgabe: Dazu Ascept Ratio an oder aus? Aus, oder? Und worin liegt genau der Unterschied zwischen surfacepp, surfacenp und surfacenb?

        1. Der Unterschied zwischen den einzelnen Einstellungen ist die GEnauigkeit der Skalierung: “surfacepp” wird das Bild exakt skaliert, was aber auch zur Folge hat dass man in den meisten Fällen schwarze Ränder um das Bild hat, gerade mit 16:9-Monitoren. “surfacenp” versucht einen Kompromiss zwischen Genauigkeit und maximaler Ausnutzung des Bildschirm zu finden. Und “surfacenb” entspricht in etwas der Einstellung “opneglnb”, dabei werden mehr Ungenauigkeiten in Kauf genommen.

          Aspect Ratio sollte übrigens aktiviert sein.

  6. DOSBox ECE gefällt mir immer besser 😀 Ich mag besonders dass du nicht jeden patch integrierst, sondern die, meiner Meinung nach, wichtigsten Die das Bild und den Ton verbessern. Der pixel perfect patch gefällt ist sehr gut.

  7. Ich habe da eine Frage. Gibt es eine Möglichkeit, im prompt z.b. von mt-32 auf fluidsynth umzuschalten, und umgekehrt? Also anstelle vom editieren in der config Datei?

  8. Das hast du gut gemacht, es funktioniert bei mir super! Ich habe es ganz leicht angepasst, so dass es portabel funktioniert, aber die Spiele sehen gut aus mit dem pixel perfect patch und klingen toll mit dem MUNT emulator.

    1. Hey, danke Phil! Aber der Danke gebührt eigentlich denen, die die ganzen Patches gebastelt haben, die ich in DOSBox ECE vereine. Was genau meinst Du mit “angepasst” in Bezug auf die Portabilität? DOSBox (ECE) ist eigentlich von Haus aus portabel.

      1. Ach nur so kleine Dinge, wie z.b. die config Datei von C:\Users\xxx\AppData\Local\DOSBox kopieren und in dosbox.conf umbenennen. Und ich hab mir was in AUTOEXEC reingetan dass er relativ ein Verzeichnis mountet.

    1. Das könnte man prinzipiell alles tun und einbauen. Aber leider nicht ich. Gleich vorweg: Ich bin kein Entwickler und habe keine Ahnung von C++. Ich habe mir nur ein paar zueinander kompatible Patches rausgepickt, die Spiele in DOSBox optisch und akustisch aufwerten und die in DOSBox implementiert. Aber wenn zwei Patches z.B. den gleichen Code editieren würden, könnte ich sie nicht implementieren, weil dann neue Funktionen geschrieben werden müssten die alles beinhalten, was beide Patches erreichen wollen.

      Dass ich nicht DOSBox-X als Grundlage nutze hat 2 Gründe: Zum einen hat es mir viel zu viele Funktionen, die ich für meine Zwecke (DOS-Spiele) für unnötig halte, weil sie eher auf eine akkurate Hardwareemulation mit dem Ziel, Windows in DOSBox laufen zu lassen, ausgelegt sind. Zum anderen, und das ist das endgültige KO-Kriterium, ist DOSBox-X auf die Optimierung des normalen CPU-Cores ausgelegt, der dynamische CPU-Core funktioniert unter Umständen in DOSBox-X nicht immer so gut wie im normalen DOSBox, weil der Entwickler den betreffenden Code nur unregelmäßig, wenn überhaupt noch, von letzterem übernimmt. Und gerade von diesem dynamischen Core profitieren sehr viele Spiele in DOSBox enorm!

      Savestates wären in der Tat eine feine Sache, das Problem an diesen ist aber dass es nicht einen universellen Savestate-Patch gibt, sondern dass der immer genau zur verwendeten DOSBox-Version passen muss. Genauer zur darin emulierten Hardware, denn so ein Savestate besteht neben eines gespeicherten Auszugs des Hauptspeichers auch aus dem gespeicherten Status der aktuell laufenden Hardware. Ein Beispiel: Wenn jemand den MT32-Emulator in DOSBox ECE nutzt, muss auch dessen Status zum Zeitpunkt der Erstellung des Savestates mitgespeichert werden. Das gleiche gilt für die 3Dfx-Option, Fluidsynth, etc. Und da kommt jetzt wieder das anfängliche Dilemma zum Tragen: Ich bin kein Entwickler und kann nicht selbst so einen Patch erstellen. Und da es bisher auch niemand anders getan hat (der Quellcode wäre ja vorhanden), gibt es eben bis heute keine Savestates in DOSBox ECE. 🙁

      1. Das mit den Cores bei Dosbox-X wusste ich gar nicht. Irgendwie dachte ich immer, dass Dosbox-X dem „normalen“ Dosbox in jeder Hinsicht überlegen ist, gerade was Soundkarten-Emulation angeht, ist das auch sicherlich der Fall. Die Gravis Ultrasound klingt dort bspw. deutlich besser. Hast du Dosbox einfach nach den Anleitungen unter https://www.dosbox.com/wiki/BuildingDOSBox kompiliert?

        1. DOSBoy-X geht halt über einen reinen Spieleemulator hinaus, opfert dafür aber eben teilweise die Performance, die gerade Spiele oft brauchen.

          Ja, genau die Anleitung habe ich anfangs befolgt. Inzwischen habe ich mir Scripts gebastelt, die das ganze halbautomatisch machen, also Checkout der SVN-Revisionen, Patches und andere Änderungen anwenden, kompilieren und Archive erstellen und das in Google Drive stellen.

Kommentar hinterlassen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.