Giter VIP home page Giter VIP logo

joncampbell123 / dosbox-x Goto Github PK

View Code? Open in Web Editor NEW
2.5K 89.0 363.0 619.72 MB

DOSBox-X fork of the DOSBox project

License: GNU General Public License v2.0

HTML 13.42% Shell 1.90% Makefile 0.40% C++ 33.87% Perl 0.11% C 46.01% NSIS 0.01% Objective-C 0.76% CMake 0.29% Assembly 1.51% Logos 0.01% Batchfile 0.02% DIGITAL Command Language 0.07% M4 0.51% Inno Setup 0.23% Roff 0.27% HLSL 0.26% Java 0.18% PowerShell 0.01% Python 0.20%

dosbox-x's Introduction

Welcome to the DOSBox-X project homepage located on GitHub.

Useful links

Table of Contents

Introduction to DOSBox-X

DOSBox-X is a cross-platform DOS emulator based on the DOSBox project (www.dosbox.com).

Like DOSBox, it emulates a PC necessary for running many MS-DOS games and applications that simply cannot be run on modern PCs and operating systems. However, while the main focus of DOSBox is for running DOS games, DOSBox-X goes much further than this. Started as a fork of the DOSBox project, it retains compatibility with the wide base of DOS games and DOS gaming DOSBox was designed for. But it is also a platform for running DOS applications, including emulating the environments to run Windows 3.x, 9x and ME and software written for those versions of Windows. By adding official support for Windows 95, 98, ME emulation and acceleration, we hope that those old Windows games and applications could be enjoyed or used once more. Moreover, DOSBox-X adds support for DOS/V and NEC PC-98 emulations so that you can play DOS/V and PC-98 games with it.

Compared with DOSBox, DOSBox-X focuses more on general emulation and accuracy. In order to help running DOS games and applications, Windows 3.x/9x/ME, as well as for the purpose of historical preservation, testing and continued DOS developments, it is our desire to implement accurate emulation, accurate enough to help make new DOS developments possible with confidence the program will run properly on actual DOS systems. DOSBox-X includes various features for different purposes (some of them ported from other projects), which are implemented as incremental changes since it was forked from DOSBox SVN Daum. DOSBox-X provides many ways to tweak and configure the DOS virtual machine, as we believe a better way to emulate the DOS platform is to give users all the options they need to emulate everything from the original IBM PC system all the way up to late 1990's configuration, whatever it takes to get your game or software package to run. Our goal is to eventually make DOSBox-X a complete emulation package that covers all pre-2000 DOS and Windows 9x based system scenarios, including peripherals, motherboards, CPUs, and all manner of hardware that was made for PC hardware of that time.

Please check out the DOSBox-X homepage for common packages of the latest release for the supported platforms, as well as screenshots of some DOS programs and games running in DOSBox-X. Also see the INSTALL page for DOSBox-X installation instructions and other packages, and the Releases page for archives of all released DOSBox-X versions. For more information about DOSBox-X, such as setting up and running DOSBox-X including its usage tips, please read the user guide in the DOSBox-X Wiki. Steps for building the source code can be found in the BUILD page.

DOSBox-X is completely open-source and free of charge to use and distribute. It is released under the GNU General Public License, version 2. See also the About DOSBox-X page for more information about DOSBox-X's goals and non-goals, along with some links to other projects.

This project has a Code of Conduct, please read it for general information on contributing to or getting support from the project.

Brought to you by: joncampbell123 (Jonathan Campbell)

Notable features in DOSBox-X

Although based on the DOSBox project, DOSBox-X is now a separate project because both have their own separate schedules and development priorities. For example, the main focus of DOSBox is for running DOS games whereas DOSBox-X goes way beyond this. At this time DOSBox-X already has a great number of features that do not exist in DOSBox. Examples of such features include:

  • GUI drop-down menu and built-in graphical configuration tool

  • Save and load state support (with up to 100 save slots + save files)

  • NEC PC-98, AX, DOS/V emulation and Chinese/Japanese/Korean support

  • Fully translatable user interfaces (with language files available)

  • Better support and compatibility with DOS applications

  • Support for more DOS commands and built-in external tools

  • Support for different ways to customize the internal Z: drive

  • Support for CPU types like Pentium Pro, II, III and MMX instructions

  • Support for IDE interfaces and improved Windows 3.x/9x emulation

  • Support for long filenames and FAT32 disk images (DOS 7+ features)

  • Support for pixel-perfect scaling output for improved image quality

  • Support for TrueType font (TTF) output for text-mode DOS programs

  • Support for printing features, either to a real or to a virtual printer

  • Support for starting programs to run on the host systems (-hostrun option)

  • Support for 3dfx Voodoo chip and Glide emulation (including Glide wrapper)

  • Support for cue sheets with FLAC, MP3, WAV, OGG Vorbis and Opus CD-DA tracks

  • Support for FluidSynth MIDI synthesizer (with sound fonts) and MT-32 emulation

  • Support for NE2000 Ethernet for networking features and modem phone book mapping

  • Support for features such as V-Sync, overscan border and stereo swapping

  • Plus many more..

While the vast majority of features in DOSBox-X are cross-platform, DOSBox-X does also have several notable platform-dependent features, such as Direct3D output and support for automatic drive mounting on the Windows platform. These features cannot be easily ported to other platforms. More information about DOSBox-X's features can be found in DOSBox-X’s Feature Highlights page in the DOSBox-X Wiki.

DOSBox-X officially supports both SDL 1.2 and SDL 2.0; both 32-bit and 64-bit builds are also supported.

DOSBox-X supported platforms and releases

DOSBox-X is a cross-platform DOS emulator, so all major host operating systems are officially supported, including:

  1. Windows (XP or higher), 32-bit and 64-bit

  2. Linux (with X11), 32-bit and 64-bit

  3. macOS (Mac OS X), Intel and ARM-based 64-bit

  4. DOS (MS-DOS 5.0+ or compatible)

Windows binaries (both 32-bit and 64-bit), Linux Flatpak or RPM packages (64-bit), macOS packages (64-bit) and DOS versions are officially released periodically, typically on the last day of a month or the first day of the next month. Please check out the DOSBox-X homepage and the INSTALL page for the latest DOSBox-X packages on these platforms and further installation instructions. You can also find ZIP packages or Windows installers for all released versions and their change logs in the Releases page. The Window installers are intended to ease the installation process, and they allow you to start DOSBox-X as soon as the installation ends.

For running DOSBox-X in a real DOS system (MS-DOS or compatible), you can find the HX-DOS package that makes use of the freely-available HX DOS Extender. Type DOSBOX-X to run it from a DOS system. There is also the DOS LOADLIN package which can run from within DOSBox-X itself in addition to a DOS system. Note, however, that not all features of DOSBox-X that are supported in other platforms can be supported in the real DOS environment.

Development (preview) builds intended for testing purposes for various platforms are also available from the DOSBox-X Development Builds page.

The full source code is officially provided with each DOSBox-X release, which may be compiled to run on the above and possibly other operating systems too. You can also get the latest development source code from the repository directly. See also the BUILD page for information on building/compiling the DOSBox-X source code.

Compatibility with DOS programs and games

With the eventual goal of being a complete DOS emulation package that covers all pre-2000 DOS and Windows 3.x/9x based hardware scenarios, we are making efforts to ensure that the vast majority of DOS games and applications will run in DOSBox-X, and these include both text-mode and graphical-mode DOS programs. Microsoft Windows versions that are largely DOS-based (such as Windows 3.x and 9x) are officially supported by DOSBox-X as well. Note that certain config settings may need to be changed from the default ones for some of these programs to work smoothly. Take a look at the DOSBox-X Wiki for more information.

Efforts are also made to aid continued DOS developments by attempting to accurately emulate the hardware, which is why DOSBox-X used to focus on the demoscene software (especially anything prior to 1996) because that era of the MS-DOS scene tends to have all manner of weird hardware tricks, bugs, and speed-sensitive issues that make them the perfect kind of stuff to test emulation accuracy against, even more so than old DOS games. But without a doubt we are also making a lot of efforts to test DOSBox-X against other DOS games and applications, as well as PC-98 programs (most of them are games).

We add new features and make other improvements in every new DOSBox-X version, so its compatibility with DOS programs and games are also improving over time. If you have some issue with a specific DOS program or game, please feel free to post it in the issue tracker.

Contributing to DOSBox-X

We encourage new contributors by removing barriers to entry. Ideas and patches are always welcome, though not necessarily accepted.

If you really need that feature or change, and your changes are not accepted into this main project (or you just want to mess around with the code), feel free to fork this project and make your changes in your fork.

As joncampbell123 only has limited time to work on DOSBox-X, help is greatly appreciated:

  • Testing
    • Features of DOSBox-X, such as its commands and functions
    • The normal operation of DOS games and applications
    • Windows 1.0/2.x/3.x & Windows 95/98/ME guest system support
    • Software or hardware emulation accuracy, helped by for example demoscene software
    • Write more unit tests to test various functions (see existing unit tests in tests/)
    • Developments of new DOS software (possibly aided by DOSLIB/DOSLIB2)
  • Bug fixes, patches, improvements, refinements
  • Suggestions, ideas, assistance of other users, and/or general conversation
  • Platform support (Windows, Linux, macOS, DOS, but others are welcome)
  • Documentation, language file translation, and software packaging
  • Notes regarding DOS and Win3.x/9x games, applications, hacks or weird tricks, etc.

See the CONTRIBUTING page for more contribution guidelines. If you want to tweak or write some code and you don't know what to work on, feel free to visit the issue tracker to get some ideas.

For more descriptions on the source code, please take a look at the DOSBox-X source code description page. Information on building on the source code can be found in the BUILD page.

Information about the debugger is also available in the DOSBox-X Debugger page.

See also the CREDITS page for crediting information.

DOSBox-X development and release pattern

In order to make DOSBox-X's development process more smooth, we have implemented a general development/release pattern for DOSBox-X. The current release pattern for DOSBox-X is as follows:

New DOSBox-X versions are made public at the start (typically on the first day) of each month, including the source code and binary releases. Then the DOSBox-X developments will be re-opened for new features, pull requests, etc. There will be no new features added 6 days before the end of the month, but only bug fixes. The last day of the month is DOSBox-X’s build day to compile for binary releases the first of the next month, so there will be no source code changes on this day including pull requests or bug fixes.

For example, suppose August is the current month - August 25th will be the day pull requests will be ignored unless only bug fixes. August 31st (the last day of August) will be DOSBox-X build day.

This is DOSBox-X’s official release pattern, although it may change later.

Future development experiments

Scattered experiments and small projects are in experiments/ as proving grounds for future revisions to DOSBox-X and its codebase.

These experiments may or may not make it into future revisions or the next version.

Comments are welcome on the experiments, to help improve the code overall.

There are also patches in patch-integration/ for possible feature integrations in the future. We have already integrated many community-developed patches into DOSBox-X in the past.

See also General TODO.txt for some plans of future DOSBox-X developments.

Software security comments

DOSBox-X cannot claim to be a "secure" application. It contains a lot of code designed for performance, not security. There may be vulnerabilities, bugs, and flaws in the emulation that could permit malicious DOS executables within to cause problems or exploit bugs in the emulator to cause harm. There is no guarantee of complete containment by DOSBox-X of the guest operating system or application.

If security is a priority, then:

Do not use DOSBox-X on a secure system.

Do not run DOSBox-X as root or Administrator.

If you need to use DOSBox-X, run it under a lesser privileged user, in a chroot jail or sandbox, or enable DOSBox-X's secure mode with its command-line option -securemode, which disables commands that may allow access to the host system.

If your Linux distribution has it enabled, consider using the auditing system to limit what the DOSBox-X executable is allowed to do.

Features that DOSBox-X is unlikely to support at this time

DOSBox-X aims to be a fully-featured DOS emulation package, but there are some things the design as implemented now cannot accommodate.

  • Pentium 4 or higher CPU level emulation.

    DOSBox-X contains code only to emulate the 8086 through the Pentium III. Real DOS systems (MS-DOS and compatibles) also work best with these CPUs.

    If Pentium 4 or higher emulation is desired, consider using a PC emulator like Bochs or QEMU instead. DOSBox-X may eventually develop Pentium 4 emulation, if wanted by the DOSBox-X community in general.

  • Emulation of PC hardware 2001 or later.

    The official cutoff for DOSBox-X is 2001, when updated "PC 2001" specifications from Microsoft mandated the removal of the ISA slots from motherboards. The focus is on implementing hardware emulation for hardware made before that point.

    Contributors are free to focus on emulating hardware within the time frame between 1980 and 2000/2001 of their choice.

  • Windows guest emulation, Windows Vista or later.

    DOSBox-X emulation, in terms of running Windows in DOSBox-X, will focus primarily on Windows 1.0 through Windows ME (Millennium Edition), and then on Windows NT through Windows XP. Windows Vista and later versions are not a priority and will not be considered at this time. These versions of Windows are not based on DOS.

    If you need to run Windows XP and later, please consider using QEMU, Bochs, VirtualBox, or VMware.

  • Any MS-DOS system other than IBM PC/XT/AT, AX, Tandy, PCjr, and PC-98.

    Only the above listed systems will be considered for development in DOSBox-X. This restriction prevents stretching of the codebase to an unmanageable level and helps keep the code base organized.

    It would be easier on myself and the open source community if developers could focus on emulating their platform of interest in parallel instead of putting everything into one project that, most likely, will do a worse job overall emulating all platforms. However, if adding emulation of the system requires only small minimal changes, then the new system in question may be considered.

    You are strongly encouraged to fork this project and implement your own variation if you need to develop MS-DOS emulation for any other system or console. In doing that, you gain the complete freedom to focus on implementing the particular MS-DOS based system of interest, and if desired, the ability to strip away conflicting IBM PC/XT/AT emulation and unnecessary code to keep your branch's code manageable and maintainable.

    If you are starting a fork, feel free to let me know where your fork is and what system it is emulating, so I can list it in this README file for others seeking emulation of that system. To help, I have added machine and video mode enumerations as "stubs" to provide a starting point for your branch's implementation of the platform. A stub implemented so far is "FM Towns emulation" (machine=fm_towns).

  • Cycle-accurate timing of x86 instructions and execution.

    Instructions generally run one per cycle in DOSBox-X, except for I/O and memory access.

    If accurate emulation of cycles per instruction is needed, please consider using PCem, 86Box, or VARCem instead.

  • Full precision floating point emulation.

    Unless using the dynamic core, DOSBox and DOSBox-X emulate the FPU registers using the "double" 64-bit floating point data type.

    The Intel FPU registers are 80-bit "extended precision" floating point values, not 64-bit double precision, so this is effectively 12 bits of precision loss and 5 bits of range loss (64 to 53 mantissa bits and 16 to 11 exponent bits). This slight loss of precision is perfectly fine considering DOSBox's original goal in supporting DOS games, but may cause problems in other cases that need the full precision.

    It is known at this time that this lack of precision is enough to cause otherwise straightforward comparisons against integers to fail in DOS applications originally written in QBasic or Turbo Basic. There are such DOS games written that check their file size using a floating point compare that will fail in this manner. To run these games, you will need to disable FPU emulation (fpu=false) to force the QBasic/TurboBasic runtime to use software emulation instead.

Origin and history of the DOSBox-X project

DOSBox-X started as a fork of the original DOSBox project sometime in mid-2011. It was started out of a desire to improve the emulator without having to fight with or worry about submitting patches upstream.

As its developers have made it clear, DOSBox's main focus is on DOS games. This is evident by the fact that much of the code is somewhat accurate code with kludges to make DOS games run, instead of focusing on the actual behaviors of real DOS systems.

Jonathan Campbell, the DOSBox-X project maintainer wanted to make various changes to the source code, but many of them were non-game related, and thus were unlikely to be accepted by the DOSBox developers.

Since then, Jonathan Campbell has been modifying the source code over time to improve emulation, fix bugs, and resolve incompatibilities with Windows 95 through ME. He has added options so that DOSBox-X by default can emulate a wider variety of configurations more accurately, while allowing the user to enable various techniques or hacks if needed to run their favorite DOS games or programs. He has also been cleaning up and organizing the code to improve stability and portability where possible.

The original DOSBox project was not written by one programmer. It has been under development since late 2000 with patches, fixes, and improvements from members all over the Vogons forums. Despite not having a major official release since DOSBox 0.74 over 10 years ago, the project is still in semi-active development today in the form of DOSBox SVN. Meanwhile, some of the changes themselves incorporated code from other projects.

Some features and improvements in DOSBox-X also came from another branch of DOSBox known as DOSBox SVN Daum which itself incorporated features from the original DOSBox project, DOSBox-X, and many experimental patches. Although the Daum branch seems to be dead, the features borrowed from it still exists in DOSBox-X. Later on, DOSBox-X also incorporated several features and improvements from other projects such as DOSBox ECE, DOSBox Staging, DOSVAX/DOSVAXJ3, and vDosPlus.

The DOSBox-X project is also helped by its other developers and contributors such as Wengier, aybe, Allofich, and rderooy, who have done significant work to improve the DOSBox-X project, including adding new features, fixing bugs, creating the documentation, maintaining the website, and porting code from other projects.

See also the CREDITS page for crediting of the source code.

Known DOSBox-X forks

  • DOSBox-X Emscripten port (runnable in a web browser) by Yksoft1

    Significant changes are made in order to run efficiently within the web browser when compiled using LLVM/Emscripten. These significant changes require dropping some useful features (including the menus) but are required for performance.

    URL: https://github.com/yksoft1/dosbox-x-vanilla-sdl/tree/emscripten (look for clone URL and use the emscripten branch)

  • DOSBox-X-App (for Windows and macOS) by emendelson

    DOSBox-X-App is a slightly customized version of DOSBox-X, combined with external programs and commands that make it easy to print and create PDFs from DOS applications. It is customized for use with applications, not games.

    URL: http://www.columbia.edu/~em36/dosboxapp.html

  • DOSBoxWP (for WordPerfect for DOS) by emendelson

    DOSBoxWP is a customized version of DOSBox-X targeted for users of WordPerfect for DOS.

    URL (Windows): http://www.columbia.edu/~em36/wpdos/dosboxwp.html

    URL (macOS): http://www.columbia.edu/~em36/wpdos/wpdosboxmac.html

  • Win31DOSBox (Windows 3.1 for 64-bit Windows) by emendelson

    Win31DOSBox aims to be an easy method of running Windows 3.x software for 64-bit Windows systems. The system uses a custom build of DOSBox-X when running Windows 3.1x.

    URL: http://www.columbia.edu/~em36/win31dosbox.html

Support for international language translations and keyboard layouts

Translations

DOSBox-X displays English as the default language, and uses the U.S. code page (437) by default, just like DOSBox.

All messages displayed by DOSBox-X are in English with the default setting. DOSBox-X does support the feature to change the display messages with the use of language files. The language files control all visible output of the internal commands and the internal DOS, as well as the text in DOSBox-X's drop-down menus. If you are a speaker of a non-English language, you are encouraged to create additional language files for use with DOSBox-X by translating messages in DOSBox-X to your language. Other DOSBox-X users can also use these language files for DOSBox-X to display messages in such languages. Language files can be found in the languages directory of your DOSBox-X installation.

Language name Language file
Chinese (Simplified) contrib/translations/zh/zh_CN.lng
Chinese (Traditional) contrib/translations/zh/zh_TW.lng
French contrib/translations/fr/fr_FR.lng
German contrib/translations/de/de_DE.lng
Italian contrib/translations/it/it_IT.lng
Japanese contrib/translations/ja/ja_JP.lng
Korean contrib/translations/ko/ko_KR.lng
Portuguese (Brazilian) contrib/translations/pt/pt_BR.lng
Spanish contrib/translations/es/es_ES.lng
Turkish contrib/translations/tr/tr_TR.lng

Keyboard layouts

The fact that DOSBox-X was developed around the U.S. keyboard layout is primarily due to limitations around the SDL1 library which provides input handling. As such when using the SDL1 version and a non-US keyboard, DOSBox-X automatically uses scancodes with the default setting to work around keyboard layout issues. Scancodes are not needed when using non-US keyboard layouts in the SDL2 version. If you find that a keyboard layout is not yet supported by DOSBox-X, in order to add additional layouts for use with DOSBox-X, please see file README.keyboard-layout-handling on how to do so as a developer.

For further information on international support and regional settings of DOSBox-X, such as steps to create DOSBox-X language files or use external keyboard files in DOSBox-X, as well as support for the Euro symbol and country-specific date and time formats, please look at the guide Regional settings in DOSBox-X in the DOSBox-X Wiki. For more information on East Asian (Chinese/Japanese/Korean) language support, see the East Asian language and system support guide page.

dosbox-x's People

Contributors

1abcd avatar alexat avatar allofich avatar aybe avatar cimarronm avatar crawlingchaos avatar crazii avatar dajhorn avatar dalekamistoso avatar dbjh avatar dependabot[bot] avatar dobby233liu avatar ern0 avatar finalpatch avatar frank-deng avatar jaakristioja avatar joncampbell123 avatar jookia avatar koolkdev avatar linkmauve avatar maron2000 avatar martinlindhe avatar maxpat78 avatar nanshiki avatar nmlgc avatar rderooy avatar shane32 avatar torinde avatar wengier avatar yksoft1 avatar

Stargazers

avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar

Watchers

avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar

Forkers

dominusexult uli sjnewbury adityavs crawlingchaos hackwrench thbar roman-murashov violtomte wcp16 efreak joprysko1 dwing4g dajhorn wiltonpyle wbcbz7 heftig nemopohle v00d00m4n timofonic-retro startrail stgiga basic2004 mkoloberdin serialdreams anpage moneytech shane32 theassyrian fromasmtodisasm yksoft1 gridl joefish gsorbier gzqyl nmlgc emtee40 marentis jpcima allofich bighitti sairoutine cristianogds fuel-pcbox zalois benpope82 strikersix23 rfht igorzhitko ccawley2011 polestarworkshop netklamath colinkinloch daniel-trevitz mariobrx jackzhc911 yabgu n1ck1355 logistx-security glowtape hlhtddx driver1998 yuzumsx frank-deng leecher1337 fcccode bestpika connectionmaster lukerancor nomikugg undersn0w jaygarcia gurtejsingh06 fyiuramron nathan8299 mrhso megabobster wdowner windowxdeveloper tetsuya00x stormcraftstudios edwinek proteanthread emupedia mbrukman dankrank motoedy valseverin zvikam tadryanom george8327 simryang katahiromz bp-tags msikma superfury alexkordic asmblur yxmline dboykey

dosbox-x's Issues

"Cycling" by Abaddon: "The end" screen triggers complains about writing ROM area 0xC0000-0xC7FFF

64-bit Linux build.

Apparently while drawing the "The end" screen it seems to be overwriting the VGA BIOS? This is worrisome as in DOSBox-X builds the VGA BIOS is by default 12KB behind the DOSBox private area.
Even in mainline compatible mapping mode, it is seen writing all the way out to C800:0 and indeed seems to trample on DOSBox's private data area.

If the demo does this on real hardware, then I will close as "wontfix" and I recommend that people running the demo use the dosbox.conf to put DOSBox's private area in lower conventional memory instead.

"Jump" by Public NMI: Sound Blaster playback halts because of PIC mask mismanagement

Running this demo in DOSBox-X requires using a few hacks and workarounds because the demo fails to unmask the IRQ associated with the Sound Blaster when starting the first part. Then, it masks the IRQ, and fails to unmask when starting a new part.

Getting the music to keep going requires using the "force DSP auto-init" hack so that playback continues despite not acknowledging the IRQ.

Will close as "wontfix" if this is a bug in the demo, not DOSBox-X.

Microsoft Windows 3.1: Windows can start in Standard Mode until you start in Enhanced Mode

When cputype=386.

Starting Windows in Standard Mode works fine using "WIN /2", until you then start Windows in Enhanced Mode (either automatically or with "WIN /3"). Once Enhanced Mode has been run, Standard Mode is no longer available, Windows complains and says:

Cannot start Windows in standard mode

Make sure you have installed HIMEM.SYS and that you have enough
extended memory for it.

Could this be an issue with XMS emulation?

286 CPU implementation of core

I would like to see 286-level emulation, settable as "cputype=286".

I think the best way to do it is to copy the core_prefetch and core_normal source files and include the same core_normal header files, then, add #defines that for 386 and later enable 386 instructions, else, removes the 386 instructions. Also code to emulate (E)FLAGS so that in the standard Intel test, CPU tests out as 286.

Documentation: How to run Turrican 2 in DOSBox-X

Turrican 2 doesn't work, neither in stock DosBox nor in DosBox-X.

After launching turrican.bat (which in turn launches t2.exe), the (text-mode) setup starts but the screen is mostly blank, so you cannot see what it detects. After pressing enter on what presumably means "keyboard", the screen switches to VGA and gets garbled

If you need the game files I can provide them for testing

cpu "normal" core modifications to support multitasking page faults properly.

Windows 95 is surprisingly stable now with core=normal, until a page fault in a page fault happens.
This is a problem with DOSBox-X's current design where CPU code does what it does and if a page fault happens at any time during the emulation it relies on recursion and the assumption the page fault will return back. While this is true of DOS games and Windows 3.1, it is NOT true of multitasking OSes like Windows 95. In Windows 95, page fault A can be interrupted by a task switch where page fault B happens, then a task switch resumes A and completes before resuming B. DOSBox's current recursive design doesn't handle that very well, in fact, it loses track of page faults and it can crash from stack recursion when it gets deep enough.

First task: Take the "recursive page fault" code already there, and get it to fully work with the normal core. Also add warning message stating that it's use with core=dynamic is not recommended due to JIT code generation vs C++ exception handling.

The idea is to fix up the trick of throwing a C++ exception when a page fault happens in the code, throwing execution back up to the normal loop where the exception can be emulated without recursion.

We will also need a "testing" function that CPU emulation code can use to test whether a range of memory it's about to work on will cause a page fault, and if it does, throw the same guest OS page fault C++ exception. The idea is that complex CPU emulation functions that work on large blocks of memory (TSS handler for example), can make the page fault exception happen early in the function rather than in the middle of an operation that would cause problems if interrupted.

Third fix is to modify normal core CPU decoding so that the instructions can be safely interrupted by guest page faults. The ideal pattern will be to decode the instruction, carry out memory I/O, and then update CPU state. The idea is not to modify CPU state during the I/O so that the CPU is not left in an inconsistent state should a page fault happen.

If written correctly, REPS string operations will also handle interruptions by page faults and resume properly.

I believe this task is vital to making Windows 95 completely stable within DOSBox-X using core=normal. I don't want to be dependent on core=dynamic to run Windows 95.

DOSBox-X callbacks however will revert to one level of recursion in order to keep INT callbacks sane and maintainable (recursion for a page fault that happens from memory I/O in the callback function, yet one level up revert to non-recursive method).

Panic! demo timing issues

There seem to be minor timing issues with Future Crew Panic! demo that lags the effects behind the music a bit, then the "shadebob" section runs too fast and jumps to the next part with runs too soon (rotating dot objects). That part finishes too early, and the dots just sit there for a good 5 seconds waiting for the next musical cue to become the FC logo.

I tested around a bit with VFRCRATE to see if it was a refresh rate issue. The issue happens no matter what the refresh rate.

"Vicky" demo scrolling text judders back and forth every other frame

http://www.pouet.net/prod.php?which=4136

I noticed that while the rest of the demo is emulated correctly, the text scrolling at the bottom does not scroll smoothly. It appears to jump 2 pixels to the right, then 4 to the left, instead of moving 2 pixels every VGA frame to the right.

It's possible nobody ever noticed it because the judder is not significant enough to distract from the rotating vector objects and moving text in the middle of the screen. Also, when posted to YouTube, the judder becomes text that generally scrolls OK with only occasional hiccups.

I will close as "wontfix" if this issue happens on real hardware (i.e. the Space Pigs made a programming mistake in the scroller and it's not DOSBox-X's fault).

Add option to enable/disable FPU

DOSBox-X currently acts like the FPU is present at all times. What would be useful is a way for dosbox.conf to specify that the virtual machine has no FPU. It was far more common in the early 1990's for 386 hardware NOT to have a FPU.

"Cycling" by Abaddon: audible errors in music playback on 64-bit Linux builds

This only happens on 64-bit Linux builds. Music is perfectly fine on 32-bit DOSBox.

If you ask the demo to run music with Sound Blaster at 20KHz (note the typo as "20Mhz"!), during some parts of the music there are audible playback errors of the STUDIO.STM file, like one of the instruments is being played back too fast. Sometimes at that point in the music, the Sound Blaster support cuts out entirely.

Sound Blaster support cutting out entirely is known to happen on real hardware, so that's not considered part of the bug.

However, if the demo exhibits audible music errors on real hardware, I will close this bug as wontfix.

"Packed file is corrupt" need to provide user assistance with this problem and possible workarounds

It looks like DOSBox-X is not immune to a known problem with pre-1989 DOS executables packed with Microsoft's EXEPACK algorithm. A page in the wiki and a document in the NOTES directory needs to be added to instruct the user on how to deal with this problem.

Microsoft MSDN article
Shikadi page including format and algorithm

EDIT: Oookay, Microsoft's KB article just disappeared into the memory hole, so here's the cause of it: Microsoft's Linker has always offered an /EXEPACK that compresses the EXE contents and adds code to self-decompress before running. This code however relies on the 1MB wraparound, so if the EXE is loaded too low in memory and the A20 gate is enabled, it decompresses incorrectly and fails.

The basic problem is that early versions of the Microsoft Linker and /EXEPACK had a bug with the 1MB realmode wraparound whenever the A20 gate is enabled, and the base segment the EXE segment is loaded to a location below 64KB from start of conventional memory.

Remedies I'd like to add:

  • DOSBox-X code (when enabled) to detect EXEPACK executables
  • Option on how to deal with them. a) do nothing b) tell EXE loader to force memory allocator to pick segment above 64KB (but possibly leaving a memory hole below the EXE image) c) automatically disable the A20 gate to try and sidestep the bug d) instruct EXE loader to unpack the EXEPACK data directly from DOSBox native code, then execute the unpacked code.

For obvious reasons the default should be "unpack the EXEPACK data directly" for the DOSBox gamers who have old games possibly affected by the EXEPACK problem.

emm386+virtual 8086 mode: "insufficient XMS memory", Windows 3.1 can't start, DOS32a causes infinite exception loop

If ems=emm386 and the virtual 8086 mode monitor is active, DOS4GW will always complain about insufficient XMS memory (even though MEM.EXE shows there's plenty). Windows 3.1 will refuse to start. DOS32a will attempt to start but will immediately go into an infinite V86 exception loop that crashes DOSBox.

DOSXNT-based programs like Microsoft's C compiler (CL.EXE) also crash badly.

The DOS4GW issue prevents games based on them (like DOOM) from running.

The EMS virtual 8086 mode is intended to mirror the EMS/VCPI provided by EMM386.EXE in MS-DOS, which normally allows DOS4GW to run and Windows 3.1 to boot.

CWSDPMI-based DOS programs (like Quake, or the VCPI memcpy routine in HEXMEM16) do not seem to be affected by this problem and they run just fine from DOSBox's EMS/v86 mode.

machine=pcjr unusable, "E_Exit: Unable to map ROM region as ROM"

If machine=pcjr and "mainline compatible bios mapping=true", DOSBox-X will crash with this error.
Does not occur if machine=tandy.

I consider this a bug because "mainline compatible bios mapping=true" is supposed to mean "create the ROM BIOS area in the same layout as the original DOSBox project in case our dynamic method creates problems with picky games".

Builtin command MEM.EXE does not work when cputype=8086

The builtin MEM.EXE binary does not work when cputype=8086. It appears to use 80186 instructions.

Solution is to 1) remove MEM.EXE from the Z directory if cputype=8086 and 2) possibly provide our own builtin command that uses native code.

Why disney=true? It might make more sense to allow parport=disney instead.

We could eliminate some possible I/O overlap and conflict if we were to adapt the code so that, instead of just saying disney=true, you could control which parallel port to attach it to (and what model), like this:

parport1=disney

A stereo LPT dac (dual mono) config could be:

parport1=disney speaker=left
parport2=disney speaker=right

At the same time, for compatibility with mainline DOSBox, DOSBox-X would still support handling disney=true as a signal to put a Disney Sound Source on LPT1.

Need to document: Windows 3.0 EGA/VGA drivers do not work with cputype=8086

If you try to run Windows 3.0 with EGA/VGA drivers and cputype=8086 you will get a crash on startup. According to Wikipedia Windows 3.0's EGA/VGA drivers actually contain 80186 instructions that are not recognized by the 8086. So it needs to be noted that the user should either select CGA or other video modes, or copy EGA/VGA drivers from Windows 2.x to obtain full functionality.

This is a documentation task.

GOOD LORD!! Windows 3.1 KRNL286.EXE is using CMOS reset type 0x09 (block move return)

Okay, so apparently, if we want to support Windows 3.1 and cputype=286, we have to emulate an undocumented form of the CMOS reset type 0x09, the "INT 15h block move" return status.

For whatever reason, someone at Microsoft thought they could be so clever if they jumped back to real mode by setting the CMOS reset byte to 0x09, then building a return stack frame as if the BIOS returning to real mode from INT 15h block move syscall.

Unfortunately nobody has any documentation on what this return code status is supposed to do. Probably for good reason, it's for the BIOS to use, not for the OS.

Here's what I can figure out so far:

The "reset vector" for type 0x09 becomes the stack pointer to load (SS:SP) instead of where to jump to. Then, somehow, the stack pointer is used to unload the stack for return (POP, POPA, IRET, etc.). Exactly in what order is unknown, except that I recognize the return adress on the stack frame at SS:SP+0x14. I'm guessing that Windows 3.1 expects the BIOS to pop two segment registers (2_2) (which ones??) then use POPA (8_2), then IRET (3*2). That's 4+16+6 = 26 = 0x1A bytes.

Snapshot of SS:SP
0929:00DE 29 09 29 09 78 00 EC 35 00 00 F2 00 29 09 00 00 ).).x..5....)...
0929:00EE 00 00 29 09 13 0C 54 0D 46 30 CF 35 70 2C 40 35 ..)...T.F0.5p,@5

Ick.

MSD (Microsoft Diagnostics) keyboard input doesn't work when machine=pcjr

Possibly related to NMI-based keyboard emulation, not sure.
Program does not respond to any keyboard input when machine=pcjr, though if mouse emulation is enabled, it will respond to the mouse.

I will close this bug as "wontfix" if there is evidence MSD.EXE has the same problem on real PCjr hardware.

286 reset vector support

DOSBox-X supports reset by keyboard controller and port 92h. What it doesn't support (but should) is the "reset vector" trick. A specific value is written to CMOS nonvolatile RAM and then the processor is reset. The BIOS detects the specific value, and instead of fully resetting the system, directs CPU execution to a realmode vector stored in the BIOS data area.

For cputype=386 and cputype=486, we will also want to emulate the well known hack where the program turns off A20 then uses the reset trick. On real hardware, the A20 gate causes the CPU to execute the undefined area of RAM below the BIOS at 0xFFEFFFFF which is most likely 0xFF (invalid opcode) so the program's Invalid Opcode exception handler is executed instead right after reset (so that it can grab the ID register from of EDX to obtain stepping information). This trick originated on PC hardware where the A20 gate was external to the CPU, rather than later 486/Pentium processors with A20 as one of the pins for the CPU to emulate internally.

In addition to Windows 3.1 Standard Mode (if it were run on a 286 processor), some 1994-ish demoscene productions I've found might actually work if this is implemented. The demoscene production in question causes DOSBox to act as if CPU reset was initiated.

Windows 3.1 would use it on a 286-class processor to return to real mode. The demoscene entry (I think) may be using it to detect the CPU stepping ID, see: http://www.rcollins.org/ddj/Nov96/Nov96.html.

The RESET test program in DOSLIB could also carry out it's test in DOSBox-X when this is implemented.

Update CGA emulation to support hardware trickery in "8088 MPH" demo

Either directly within DOSBox-X or as a fork, I would like to see cycle accurate emulation of an IBM 5150.

If it can run demos like "8088 MPH" then it's accurate enough.

Probably not going to happen for quite awhile.

At the time of entering this, the demo not only complains about CPU speed but also some parts drive the CGA video emulation crazy!

The reason I suggest a fork is that the changes to accomplish this might be substantial enough that modifying the code to do it might break the code. It might be better to have a fork where all but 8088+CGA/MDA emulation is removed and everything is modified to emulate the IBM 5150 as closely as possible.

BUILD: MSVC 2013 needs <algorithm>

MSVC2013 needs include <algorithm> to define std::min and std::max, which is missing in disney.cpp

Here's a diff to make it build

diff --git a/src/hardware/disney.cpp b/src/hardware/disney.cpp
index 9d2418b..81f47ca 100644
--- a/src/hardware/disney.cpp
+++ b/src/hardware/disney.cpp
@@ -18,6 +18,7 @@


 #include <string.h>
+#include <algorithm> // for std::min and std::max
 #include "dosbox.h"
 #include "inout.h"
 #include "mixer.h"

Also, the different uses of min/max could be unified (ide.cpp uses a custom macro MIN and MAX for example, and debug/debug_win32.c also defines its own version of min() ...)

Early demoscene problems with Sound Blaster/GUS IRQ reception

Some early demos are having problems responding to the Sound Blaster IRQ properly and music eventually quits. I'm uncertain whether the demo's Sound Blaster support is simply crap or if there is something yet missing from DOSBox's PIC emulation that needs to be fixed.

Typical issues:

  • losing the IRQ if the DOS machine is "too slow" (cycles count too low) (Extreme "Lunatic")
  • failing to unmask the IRQ for some reason (Public NMI "jump")
  • losing IRQ 5, but for some reason having no problem with IRQ 7 (several demoscene productions 1992-1993).

error compilation Ubuntu 14.04

Hello,

I tried to compile dosbox-x on Ubuntu but I obtain this error:

$make
....
Making all in gui
make[3]: entrant dans le répertoire « /home/legluondunet/Bureau/Dosbox-X/dosbox-x05022015/src/gui »
g++ -DHAVE_CONFIG_H -I. -I../.. -I../../include -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -g -O2 -std=gnu++11 -Wall -mmmx -msse -msse2 -D_FILE_OFFSET_BITS=64 -Wno-strict-aliasing -MT midi.o -MD -MP -MF .deps/midi.Tpo -c -o midi.o midi.cpp
In file included from midi.cpp:131:0:
midi_timidity.h:16:21: fatal error: SDL_net.h: Aucun fichier ou dossier de ce type
#include "SDL_net.h"
^
compilation terminated.
make[3]: *** [midi.o] Erreur 1
make[3]: quittant le répertoire « /home/legluondunet/Bureau/Dosbox-X/dosbox-x05022015/src/gui »
make[2]: *** [all-recursive] Erreur 1
make[2]: quittant le répertoire « /home/legluondunet/Bureau/Dosbox-X/dosbox-x05022015/src »
make[1]: *** [all-recursive] Erreur 1
make[1]: quittant le répertoire « /home/legluondunet/Bureau/Dosbox-X/dosbox-x05022015 »
make: *** [all] Erreur 2

I already installed sdl2-net-dev package:

$ locate SDL_net.h
/usr/include/SDL2/SDL_net.h

Thank you for your help.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.