VOGONS

Common searches


DOSBox-X branch

Topic actions

Reply 1220 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie
delta^1_1 wrote:

How should I submit a patch for inclusion in DOSBox-X?

I've got this old patch that's been sitting around for years. What it does is add support for DOS's legacy CPM entry point -- and I know people who run old programs using this, so it would be really good to get the support added to a public version of DOSBox.

I did send the patch to the original DOSBox developer team, but they didn't seem to be very interested in it (and there hasn't been much activity from them anyway). Maybe it will get a better reception here.

The best way to submit patches is to fork the github repository, commit the change, and then make a pull request. If that cannot be done, feel free to submit a patch. If you submit a patch please make sure to diff it against any recent commit of DOSBox-X to help ensure that it applies cleanly.

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 1221 of 2397, by Myloch

User metadata
Rank Oldbie
Rank
Oldbie

DOSBox-X Git (2017/05/09) taken from emucr website, is it me or mt32 doesn't work even if enabled? Did they change something like the needed roms or roms path maybe? They recently changed some things with roland emulation so probably something went wrong.

"Gamer & collector for passion, I firmly believe in the preservation and the diffusion of old/rare software, against all personal egoisms"

Reply 1222 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie
James-F wrote:
Hi. […]
Show full quote

Hi.

Is there any way to extract the diff between the sblaster.cpp code to implement ESS and proper Filtering into the vanilla DOSBox?
I can create a diff, but I have to know what files are responsible for ESS audio changes.
mixer.cpp, sblaster.cpp, dosbox.cpp?

Thanks!

Not exactly. The changes to sblaster.cpp should be applicable, but all the changes to add filtering are in my rewrite of mixer.cpp. You can try copying the header and cpp file of mixer.cpp from dosbox-x to see if that works.

As a bonus, my mixer.cpp rewrite also fixes possible a/v sync drift that can happen when capturing video if your sound card doesn't quite run at the same rate as the SDL timer.

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 1223 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie
zschni wrote:

Hello, I am totally new here, but I ran into this forum many times before. Yesterday I did not even know, how to compile things from Git, today I successfully installed dosbox-x with sudo checkinstall. I would like to use this software for Extreme Assault mostly, but everything in the application is very and very slow, and in other applications also (Prince of Persia, Mario...) I succesfully wrote the config file, but eh.. so many options comparing to dosbox 0.74. I was messing with the game's 3dfx laucher also, without success, and sadly I do not even understand what the people are talking about, regarding glide support in linux and to compile the dosbox, with openglide and ovl and dll files... 😒
So what I would like to have is more "fps" in the game. I am mostly comfortable with the original dosbox config file, but here... too many options to mess with. My cpu usage on 1 core is never more than 50% when playing.
My PC is like that. Thank you in advance.

Options in DOSBox-X are very numerous but they are all built so that most of the time you can just use the defaults. They exist so that you can compensate for software that needs adjustments to run. One common option is to unmask the Sound Blaster IRQ at startup for DOS programs that use the SB IRQ but are too lazy to unmask it.

DOSBox-X inherits the dynamic core on the x86, but it's sort of bitrotted because of the focus on the normal core to improve accuracy which is why the normal core is default, not dynamic.

For 3Dfx emulation you will need to get ahold of an install package for Windows 95 or Windows 98, install it in a Windows 95 system in DOSBox, then copy the GLIDE directory to your game's DOSBox-X setup. In your dosbox.conf you will need to make sure the GLIDE directory is in the PATH variable so that the game looks there for the GLIDE.OVL file.

The version I use seems to assume a Pentium CPU with MTRR registers, so you will need dosbox.conf to set cputype=pentium, enable MSR registers, and ignore undefined registers, and it will work fine. Use OpenGL acceleration if you can for performance.

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 1224 of 2397, by hail-to-the-ryzen

User metadata
Rank Member
Rank
Member

By logging the RDTSC instruction in dosbox-x (cputype=pentium), verified that the RDTSC instruction is continuously called by UT99 (3dfx mode). However, where cputype is 486, then this instruction is not accessed. A simple text editor shows that timeGetTime() is included in UT99 binary, so a likely possibility is that there are two paths for setting the game speed. The first measures the passage of time by the RDTSC "clock" while the alternate path uses timeGetTime().

The advantage of the latter method is that it is not dependent on RDTSC and a constant rate of cpu cycles. Reported causes of a non-constant rate are power saving features that regulate cpu speed and the use of multiple cores in a modern CPU. A possible disadvantage is a perceived loss of in-game performance.

In testing, the cpuspeed parameter was not used at the commandline to run UT99. However, this was tested on a modern CPU in 3dfx mode. Reducing the cpuspeed, such as cpuspeed=1000 on a 2000 Mhz cpu, resulted in a very fast game speed. In this case, the parameter value overrides the value calculated by UT99 and sets a slower cpu cycle rate than the real cpu cycle rate (1/2 in this example). Since the RDTSC instruction reports the real cycle rate, in-game runs at 2x the intended "game clock".

Reply 1225 of 2397, by Scali

User metadata
Rank l33t
Rank
l33t
hail-to-the-ryzen wrote:

By logging the RDTSC instruction in dosbox-x (cputype=pentium), verified that the RDTSC instruction is continuously called by UT99 (3dfx mode). However, where cputype is 486, then this instruction is not accessed. A simple text editor shows that timeGetTime() is included in UT99 binary, so a likely possibility is that there are two paths for setting the game speed. The first measures the passage of time by the RDTSC "clock" while the alternate path uses timeGetTime().

That makes sense, since RDTSC was only introduced with the Pentium.

The advantage of the latter method is that it is not dependent on RDTSC and a constant rate of cpu cycles. Reported causes of a non-constant rate are power saving features that regulate cpu speed and the use of multiple cores in a modern CPU. A possible disadvantage is a perceived loss of in-game performance.

hail-to-the-ryzen wrote:

In testing, the cpuspeed parameter was not used at the commandline to run UT99. However, this was tested on a modern CPU in 3dfx mode. Reducing the cpuspeed, such as cpuspeed=1000 on a 2000 Mhz cpu, resulted in a very fast game speed. In this case, the parameter value overrides the value calculated by UT99 and sets a slower cpu cycle rate than the real cpu cycle rate (1/2 in this example). Since the RDTSC instruction reports the real cycle rate, in-game runs at 2x the intended "game clock".

There was a time when RDTSC reported the actual cycles that a CPU executed. In the Pentium-days, there was no power saving yet, so the clock speed was fixed.
When power saving was first introduced, initially RDTSC still reported the actual cycles. Since that caused problems with unsuspecting software, which tried to use it as a clock signal (it's not, it was meant to be a debugging tool, to measure performance at the instruction level).
So eventually RDTSC was redesigned so that the speed was constant, regardless of the CPU clocking down or up (which means you lost the performance measuring capability).
UT99 is most probably in the 'unsuspecting software' category, which assumes RDTSC runs at a constant clock speed.
Technically it's not incorrect to have the RDTSC not matching the actual clock speed.
However, when you're emulating a Pentium, it is.

I'm not sure what you mean exactly though... UT99 probably measures the actual frequency of RDTSC once at startup. So if the game speeds up or slows down when you change the emulator's clock speed while the game is already running, that is expected behaviour. If the game is the wrong speed when you select a different clock speed before starting the game, but then don't change it, that may be a bug in the emulator (or a bug in the detection routine of UT99, which was likely only tested on real Pentium systems in a given clock speed range).
If you are talking about changing the clockspeed of the host machine, affecting the emulator's speed (assuming the host machine is still running fast enough to handle the emulation of the target machine), then that too would be a bug in the emulator.

Last edited by Scali on 2017-06-12, 11:50. Edited 1 time in total.

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 1226 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

I think you're referring to the time where RDTSC became unreliable as a clock source because it would count slower when the CPU went into power saving mode. I've heard it referred to as SpeedStep mode, or something like that. Neither DOSBox nor DOSBox-X emulate that.

But, RDTSC is emulated using the cycles count because it's supposed to count CPU cycles. So yes, changing the cycles count mid-game will do that.

DOSBox-X has a "realtime" meter to show emulation speed relative to realtime. Enable that, and it should indicate in the titlebar if the emulation is falling behind realtime.

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 1227 of 2397, by hail-to-the-ryzen

User metadata
Rank Member
Rank
Member

UT99 likely relies on the CPUID opcode to detect a Pentium like CPU with RDTSC for the game clock (path 1) or instead a 486 like CPU with a presumed timeGetTime() game clock (path 2).

Since path 1 (RDTSC) is dependent on a fixed number of cycles in emulation, therefore the non-fixed rate of cycles=max is best paired with path 2 for a reliable game clock. The advantage here is that emulation optimizes for the maximal cpu cycle rate. The question is whether a user can choose a fixed cycle count that is comparable to cycles=max.

Another case is in a modern Pentium like system where the RDTSC dependent clock is reportedly unreliable, such as in the above example where the CPU has power saving features. This will lead to the game running at an incorrect speed, much like setting cpuspeed to an inaccurate value. In this case, path 2 is expected to provide a reliable clock and run UT99 at the intended game speed.

Reply 1228 of 2397, by Scali

User metadata
Rank l33t
Rank
l33t

Isn't the solution then simply to force DOSBox-X to use a 486-like CPU? That is, disable the CPUID (and RDTSC) instruction.

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 1229 of 2397, by hail-to-the-ryzen

User metadata
Rank Member
Rank
Member

Confirmed that UT99 v400 and v428 work with the path 2 game clock. However, later versions are dependent on RDTSC and are not expected to run on a 486 cpu.

In this case of path 2, the UT99 log will show that the timestamp is not supported. Presumably, a timestamp parameter value is first estimated for a decision on which path to use, and probably around where the cpu features (cpuid) are identified and written to the log file.

Reply 1230 of 2397, by Scali

User metadata
Rank l33t
Rank
l33t
hail-to-the-ryzen wrote:

However, later versions are dependent on RDTSC and are not expected to run on a 486 cpu.

One can argue however that if the code depends on RDTSC and cannot handle changes in frequency, that the problem is in the application, and not in the emulator. After all, the same thing happens on real hardware.
The solution is the same on both hardware and emulator: don't change the frequency.

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 1231 of 2397, by SooperWill99

User metadata
Rank Newbie
Rank
Newbie

I am having a major problem with running DOSbox-X: the S3 drivers seem to crash and close the program, which prevents any version of Windows from being usable. This apparently was a bug before, but I tried builds after it was supposedly fixed and it still happens. Can someone figure out what's going on? Is there a setting I need to use?

Reply 1232 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

Try the latest commit. I thought I could factor out some code, but it seems that when devices respond to MMIO they're given the VIRTUAL memory address, and I had to revert.

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 1233 of 2397, by Farooq

User metadata
Rank Newbie
Rank
Newbie

TheGreatCodeholio

Me and friend have encountered problem of impossibility to mount large DVD iso images (X-Files 3,6 gb, Tex Murphy Overseer 4,6 gb, etc) in Windows+dosboxDaum forc. I mean inside it using the only program that we were lucky to install without errors - Virtual Clone Drive. Editing config with imgmount and mount threads doesnt help as it supports only 700 mb size images. Menu CD section doesnt work.

Is it possible to mount large DVD iso images via Dosbox-X? If it is impossible currently can you please upgrade new build with this feature? Something like Virtual PC or PCem have with mounting ISO files from host computer. Really Dosbox lacks this feature very much.

Is it possible somehow to mount 8gb NTFS HDD to Dosbox-X+Windows95?

Last edited by Farooq on 2017-07-22, 19:06. Edited 2 times in total.

Reply 1234 of 2397, by SooperWill99

User metadata
Rank Newbie
Rank
Newbie

Okay, I've got Windows 98 working. Turns out the issue wasn't related to S3 drivers - I had to set the core to normal.
However, I have a few issues:
1. 2D games and apps work mostly fine (except for maybe one game which runs slightly choppy), but there seems to be performance issues with 3D. Hercules is an example of this - the game runs at a smooth speed until the first level (which has 3D graphics, unlike the main menu), where the framerate gets choppy from 2-3 frames per second, and also seems to run slightly slower judging by the timing of some sound effects, and it makes the game almost unplayable at times, and I haven't been able to get past the first level yet due to one particular swinging part that's much more difficult with the bad performance. However, at the top of the level cliff, the game's performance runs significantly better (probably since there isn't much 3D graphics). As well as this, a Game Boy Color emulator, VGBC, runs incredibly slowly. My actual computer's specs aren't bad, and DOSbox-X doesn't use that much CPU, so that doesn't seem to be the issue. I have attached my configuration below if I missed something obvious - DOSbox-X's default settings are very bad for Windows 98, so I had to tweak some options.
2. Another game has a graphical issue where all its sprites' transparency is just displayed as black, so every sprite is inside a visible black box. The game is still playable, but I would like to play it as it was meant to be played.
3. LEGO Island just seems to show graphical corruptions before seemingly bringing Windows 98 to a black screen of death. It's impossible to exit the application, and the only thing you can do is close and re-open DOSBox-X.
4. When booting up, the Windows 98 startup screen is vertically stretched, with the bottom half of the screen not visible due to the image being stretched. It also uses a weird resolution. The same problem is present at the "It's now safe to turn off your computer." screen.
5. I can't figure out to connect to any internet. I have WinPcap installed, and I have set the network to 1, but Windows 98 doesn't seem to detect anything - it just tells me to hook up to a modem. I think I've set a modem, but I'm not sure. Also, when I go into Control Panel and try to add new hardware, it tells me that "Internet Connection Sharing" and "Standard IDE/ESDI Hard Disk Controller" aren't functioning properly. Internet isn't my top priority, but I would like to be able to use it to get a truly "complete" Windows 98 experience.

By the way, I'm using the Windows build from February 19, 2016, since Windows binary development has unfortunately been discontinued and I don't know how to compile any code for later versions.

Attachments

  • boot_095.png
    Filename
    boot_095.png
    File size
    30.72 KiB
    Views
    1651 views
    File license
    Fair use/fair dealing exception

Reply 1235 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

- It sounds like Windows 98 is using a software 3D rasterizer. The game may be expecting to render 3D atop the 2D, or something like that. I'm not sure the 3Dfx emulation can do that.
- The S3 emulation is complete as far as I know except that nobody bothered to implement BitBlt with color-key transparency, which is why sprites have boxes around them.
- Perhaps you're running the Lego game with dynamic core, which I haven't bothered to maintain because the changes underneath don't work well with it. Try running with normal core, to see if it works (but slowly).
- Try disabling aspect ratio correction, or any renderer that involves stretching.
- It sounds like whoever you got the Win32 build from did not compile in winpcap support and NE2000 emulation.
- You *can* compile win32 from the SLN and VCPROJ files in the repo. Just be aware that I do not personally care about those files when I develop under Linux, though others are free to submit patches to keep them working. As far as I know, they should work with VS2015.

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 1236 of 2397, by SooperWill99

User metadata
Rank Newbie
Rank
Newbie

Thanks for the reply, although I'm still not sure what to do about 3D games such as Hercules. The game does have both 2D (for sprites) and 3D graphics (for the environment) but I don't think this is using 3DFX in this case. I've also run DXDIAG, and when I try the 3D test, the cube moves slowly and choppy as well. So I don't think the 2D + 3D rendering is the problem.
As for LEGO Island, I am running it in normal mode, unfortunately, as dynamic core will cause Windows 98 to close immediately as it starts, which was my previous issue. So maybe LEGO Island is using something that isn't emulated right on startup? I've tried starting the game in both 256 and 16-bit colors and the same thing happens. 😢
For the network issue, the build I got was from GitHub, in the releases page. As I said, it's from February 19, 2016. So I can't tell if it's accidently missing network functions or not. Or maybe I need to add something manually to hook it up to the network.
Finally, for the transparency issue with sprites, I hope that color-key transparency gets added soon.
I've tried building the newest version with Visual Studio 2015, but it has a lot of errors. 😠 Someone before said they had the same problem, and weren't able to properly resolve the issue, and it wasn't easy to. Is it supposed to build correctly?

Reply 1237 of 2397, by HuckleCat

User metadata
Rank Newbie
Rank
Newbie

I have been using DosBox-Daum for awhile and have now switched to Dosbox-X. For the life of me, I cannot seem to fix these issues-

First - Forcing 2x Scaling once in any game. It's like it was never on.

Second - Scaling when in fullscreen.

It seems like it just demands to stay in surface, even when I have changed the config to either ddraw and also overlay. When I move ddraw.dll to the install folder, it just crashes. (Do I need a specific version?)

In Daum it has worked fine, but with DOsbox-X I'm stuck with a tiny window, or fullscreen with a tiny game in the center.

I'm using the latest 64 bit build from EmuCR of Dosbox-X. I'm pretty much going with it's default settings in the conf file, but have made sure that output=ddraw, or overlay. Also have made sure that aspect=true, and that the scaling was forced.

No matter what, I'll run it, and it will simply switch back to surface, or crash, and restart in surface.

I'm running Win10, or X, or whatever it's called now. "Latest Microsoft OS". I also have the latest directx runtime drivers installed, as well as my latest vidcard drivers. (AMD)

I just tried out the latest build of DosBox ECE, and it's also working fine.

Is this likely a bad build of Dosbox-X? I do like that GUI, even if it isn't really all that needed.

Reply 1238 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

HuckleCat

I'm aware there are scaling bugs, especially on the Windows side, but I'm not quite sure how to fix them.

https://github.com/joncampbell123/dosbox-x/issues/96

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.