VOGONS


The future of Dosbox development

Topic actions

First post, by kekko

User metadata
Rank Oldbie
Rank
Oldbie

Ok, developers of dosbox are making a great job.
The compatibility with the games and the overall stability are increasing day by day.
So what?
Although the efforts of the authors and of the community, dosbox remains irrevocably slow,
especially with newer dos programs with vesa, protected mode and all.
The question now is:
Which are main bottlenecks in dosbox?
I'm not looking for obvious answers like:
"cpu."
or
"vga emulation."
I'm rather looking for something like:
"code xx in file yy.cpp needs some work"
"the loop xx in file yy.cpp needs to be optimized/rewritten/redesigned"
I'm not writing all this to make controversies; I'm only trying to concentrate the
efforts of dosbox developers community to finally achieve a perfect dos emulation.
What do you think about that?

Reply 1 of 32, by taiken7

User metadata
Rank Member
Rank
Member

The bottlenecks are typically the broad base support,
as well as extensive debug support.
The code has been written to allow a fast turn around
if something breaks or needs addition.

We are using approx 40:1 instructions simulated-real, so expect
Your processor clock-rating/40 speed on *average*.
(Ive seen sims at 12:1 for a few thousand $$$)

A general answer is correct, since unless you reduce the
*average* real to simulated instruction count, you wont notice
a difference.

The largest increase in speed would be to rewrite dosbox
so that it has a seperate image for each possible combination
(eg Ega & SB), and only essential SDL calls are integrated.

Then rewrite the sound/video code into the same simulator
(at the moment its running as 2 virtual machines)

Replace threaded code with Hand crafted loops.
Use a static memory size, locked at startup.

Then write a windows low-level driver to give clean fast access
to memory and disk (one for windows 95/98, one for ME, one for XP/NT, one for the mac's, one for ...)

Then finally use a "profiler" to figure out the last loops that dosbox
spends too much time in, and optimise those to be inline assembly.

In 5 years... does anyone care? Processors are 4 times faster.
(And then someone points out an instruction you 'missed',
or a feature they *need* ...)

This is a hobby, not a job.

p.s. I've noted the biggest increase in speed is from a *real* OS,
Linux. Try it sometime.

p.p.s To answer the exact question you asked, the problem is
under what test conditions do you define "slow".
Answers like Protected Mode game dont count, we need
something like game X, calls int21 every 100ms and generates
a page fault every 2seconds.

Reply 2 of 32, by HunterZ

User metadata
Rank l33t++
Rank
l33t++

When it comes to speed of emulation, I'm starting to think that maybe the DOSBox devs shouldn't worry too/ much about it (not that they are) and work on compatability instead. By the time DOSBox is fully compatable with > 95% of DOS games (including those using VESA and other advanced stuff), PCs will be fast enough to emulate a DOS box at a fast enough speed to run those games anyways.

If you just look at clock speed (yes, I know it's a terrible metric): most (if not all) DOS games will run great on a 200MHz system. 200MHz * 40 = 8GHz. Not that far off from where we are now, really.

What I think would be really helpful would be for the devs to take a break from actual development and go back and add comments to the code and draw up some design docs (e.g. on the structure and flow of the DOSBox code) to help other hobbyist software developers to figure out how the thing works. That way, the DOSBox devs would probably get significantly more coding-level support from the community and we would see DOSBox improve and evolve at a much faster rate..

Reply 3 of 32, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

I'm with HunterZ.

Who cares if protected mode games run slowly under DosBox? Generally most protected mode games run fine under NT4/2K/XP with VDMSOUND or real DOS or they are starting to have their own ports to newer operating systems.

Documentation should be key so that we can get more coders into the project.

As for DosBox emulating video.

How much overhead does video processing take up in DosBox? Would it be feasible to pass the burden to the host CPU/video card? I'm aware that a host based driver would be required for each operating system but it may be worth it especially if we want higher resolutions and glide support.

How To Ask Questions The Smart Way
Make your games work offline

Reply 4 of 32, by taiken7

User metadata
Rank Member
Rank
Member

The SDL libraries offer plenty of inline assembly optimised routines,
so graphics processing is reasonably well implemented.
(There is a fair bit of indirection though).

To answer the documentation side (this is my personal view),
If you don't know GPROF is a Profiler, DOXYGEN is code-documentation,
then you probably arent going to code to the levels demanded by users
and required by dosbox.

Reply 5 of 32, by zbiggy

User metadata
Rank Newbie
Rank
Newbie

The users of DosBox should have possibility to disable CPU emulation, DOS emulation and graphics card emulation. Most games works for me in WinXP, but without sound. The only thing form dosbox I need is sound card emulation. The rest only hogs my system. I know about VDMSound, but this project is dead now and don't looks to get up. VDMS is great because I can choose which kinds of emulation need, however is old now and lacks some cards emulation like MT-32, GUS, MIDI in UART mode. DosBox should be modular, and bottlenecks problem will be resolved.

Reply 6 of 32, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

dosbox will keep the cpu emulation as that is one of it's core design things.
full cpu emulation has always been a goal. not a module that can be disabled. It has been done that way to be truly cross-platform.
(and due to the lack of good virtualisation calls in ms windows)

Water flows down the stream
How to ask questions the smart way!

Reply 7 of 32, by mirekluza

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator
zbiggy wrote:

The users of DosBox should have possibility to disable CPU emulation, DOS emulation and graphics card emulation.

You are basically saying: write me a new program (something like VDMsound). That "disabling" you are speaking is not something which could be easily done, just if programmers were not too lazy to add options for it ... The whole architecture would have to be rewritten (basically it would be another programm). At the moment the DOSBOX emulation is self contained. That "switching off" of CPU/graphic emulation would mean necessity to switch between native and emulated environment...
It can be done. For example Virtual PC (PC version) uses native processor if possible. However the only free attemp on something like that failed (or more precisely scaled down radically - I mean Plex86). There is only DOSEMU in Unix/Linux (for some reason it is not possible to port it to Windows). Search forum. These things were discussed before.

If you want an improved sound card emulator in Windows, go on with VDMsound (sources are available - anyone can go on with development).

Mirek

Reply 8 of 32, by zbiggy

User metadata
Rank Newbie
Rank
Newbie
mirekluza wrote:

You are basically saying: write me a new program (something like VDMsound). That "disabling" you are speaking is not something which could be easily done, just if programmers were not too lazy to add options for it ... The whole architecture would have to be rewritten (basically it would be another programm). At the moment the DOSBOX emulation is self contained. That "switching off" of CPU/graphic emulation would mean necessity to switch between native and emulated environment...
It can be done.

This topic has name: "The future of Dosbox development" not "presence" so do not expect to do this for today. Come back to this post after 10 years since now and tell me if DosBox from year 2015 is the same as current 0.63 version (with of without my ideas). I browsed DosBox sources and know that this is hard job to do. If dosbox have to be portable it can have drivers for every processor architecture. The Intel one would be simply pass-thru with bad command filter to protect windows from hanging. The same is for graphics.

mirekluza wrote:

If you want an improved sound card emulator in Windows, go on with VDMsound (sources are available - anyone can go on with development).

I was at VDMS before. This is dead project. The sources are at CVS. But not anyone can go on with development - the source code is junky. If you are so clever try to download them and compile in MSVC without changing sources. If everything compiles without errors let me know how you done that. Till now nobody on forum answered to question about correct compilation of VDMS. Since yesterday I am sitting and cleaning up sources of VDMS and have now working only modules part. This is not funny, such comment made me angry. The live is not so easy as it looks.

Reply 9 of 32, by eL_PuSHeR

User metadata
Rank l33t++
Rank
l33t++
zbiggy wrote:

The users of DosBox should have possibility to disable CPU emulation, DOS emulation and graphics card emulation. Most games works for me in WinXP, but without sound. The only thing form dosbox I need is sound card emulation. The rest only hogs my system. I know about VDMSound, but this project is dead now and don't looks to get up. VDMS is great because I can choose which kinds of emulation need, however is old now and lacks some cards emulation like MT-32, GUS, MIDI in UART mode. DosBox should be modular, and bottlenecks problem will be resolved.

Zbiggy. I understand your point. But as Qbix has stated above, that isn't DOSBox goal, whether it likes you or not. For what you want to do, you already have applications like VirtualPC.
On the other hand, I understand your frustration in trying to compile VDMSound after a lot of hard work, specially if the project seems now dead and no one jumps in for lending you a helping hand. But it isn't our fault, either. 😎

Reply 10 of 32, by fish

User metadata
Rank Newbie
Rank
Newbie

Several thoughts.

1) I don't think making every thing host OS dependent is not the way to go. VDMSound's big drawback is that with the advent of 64 bit computers and windows versions over the next years it will become more or less unusable to most users. DOSBox is a kind of legacy support. It would be quite an irony to model legacy support in a way that makes the software itself a legacy soon. If you can't make it cross-platform, it's not worth the effort unless you get paid. I won't pay, sorry. I might donate sometime, I won't pay though.

2) I'm not of the opinion that only experts should try and develop DOSBox enhancements. Currently I'm looking for ways to develop modules in a way users can integrate them into a dosbox binary that they downloaded.

I have offered documentation support and I will, sooner or later, deliver.

I am interested in taking Qbix' idea of turning the debugger functions into a full-fledged cheat utility like Game Wizard used to be.

I have been and will be interested in a virtual-com2-to-virtual-com2-over-real-TCP/IP tunnel addon which will allow transparent connection to remote DOSBox Players over a simulated serial nullmodem connection.

This will need some friendly user interface which could either be provided by add-on virtual programs or by making a GUI window in the host OS, which has several drawbacks.

I know DOSBox already has its own IPX tunnel. Still, I am interested in such a project.

Which means, if I find the time to do it, I'm gonna try. I'm not sure if this is really what I am capable of. We will see.

I would not want the core programmers to tasks like the Add-Ons I described above. I would not want them lean back and document either. They're experts in other essential parts of the project after all.

I think, documentation of key functions like
MSG_Add(const char * _name, const char* _val)
class BOOT : public Program -> void Run(void)

etc

together with documentation of a standard add-on interface would enable programmers with little knowledge of the inner workings of DOSBox to provide neat tools that make DOSBox even more enjoyable.

The Sole Survivor.
Find me on efnet #oldgames

Reply 11 of 32, by Snover

User metadata
Rank l33t++
Rank
l33t++

It would be nice to see modularisation of the DOSBox components, building the various things into their own separate dll/so file and sorting by functionality to allow for additional plugins to be created more easily that could just hook into a DOSBox API.

Yes, it’s my fault.

Reply 12 of 32, by Freddo

User metadata
Rank Oldbie
Rank
Oldbie
fish wrote:

1) I don't think making every thing host OS dependent is not the way to go. VDMSound's big drawback is that with the advent of 64 bit computers and windows versions over the next years it will become more or less unusable to most users. DOSBox is a kind of legacy support. It would be quite an irony to model legacy support in a way that makes the software itself a legacy soon. If you can't make it cross-platform, it's not worth the effort unless you get paid. I won't pay, sorry. I might donate sometime, I won't pay though.

I totally agree. Windows XP 64 bit that will be released later this year do not have support for 16-bit code and as such it won't be able to run DOS games at all, so VDMS will, unfortunally, become obsolete.

Reply 13 of 32, by fish

User metadata
Rank Newbie
Rank
Newbie

Part of it is possible right now. I think you can easily add constants to the language file if you export it with the config command and load it via the config file.

Having users compile their special build of DOSBox may be feasible for the developer but not for the user. This would require the developer to offer DOSBox builds with every combination of add-on options anew. It would also be a horror to maintain and update as better versions of the "core" projects are released over time.

The Sole Survivor.
Find me on efnet #oldgames

Reply 14 of 32, by Snover

User metadata
Rank l33t++
Rank
l33t++

I am personally rather perplexed by this removal of 16-bit code execution. Certainly we need to move away from 16-bit code (no new programs are running with 16-bit code), but I'm not sure why 16-bit support would be completely removed. I assume that this would mean that NTVDM/WOWEXEC would be completely gone; this also means that lots of older Windows games (any Windows Sierra game, for example) would be completely unusable under XP64. For what gain?

Yes, it’s my fault.

Reply 15 of 32, by fish

User metadata
Rank Newbie
Rank
Newbie

windows has a history of incomplete legacy support. No memmaker in the default installation of windows 95. No Win 2.x App in any windows higher than 3.11, which itself did not run every 2.x and 3.0 app.

The Sole Survivor.
Find me on efnet #oldgames

Reply 16 of 32, by oneirotekt

User metadata
Rank Member
Rank
Member

If you just look at clock speed (yes, I know it's a terrible metric): most (if not all) DOS games will run great on a 200MHz system. 200MHz * 40 = 8GHz. Not that far off from where we are now, really.

I agree that compatibility is more important long-term than speed, but CPU speeds are leveling off quite steeply these days, and the chip engineers seem to be running up against some hard limits. 8GHz machines might not happen for quite a while or at all, so we can't rely on time to solve all our problems. Hopefully a bit of emulation code optimization is still possible, so DOSBox can meet Moore's Law halfway should it taper off.

Everything I've heard about implementing the "native x86 support" idea makes it sound really non-trivial and non-cross-platform-friendly. I'd love to be able to run games like Syndicate Wars at full speed on my 1GHz but not at the expense of long-term portability.

It would be nice to see modularisation of the DOSBox components, building the various things into their own separate dll/so file and sorting by functionality to allow for additional plugins to be created more easily that could just hook into a DOSBox API.

I think this would be a good move regardless of where else the project goes. And quality documentation might open up development to a wider community... not everybody who can write good code has the godlike knowledge of ancient hardware that Qbix / Harekiet / Canadacow et al have.

Reply 17 of 32, by HunterZ

User metadata
Rank l33t++
Rank
l33t++
Snover wrote:

I am personally rather perplexed by this removal of 16-bit code execution. Certainly we need to move away from 16-bit code (no new programs are running with 16-bit code), but I'm not sure why 16-bit support would be completely removed. I assume that this would mean that NTVDM/WOWEXEC would be completely gone; this also means that lots of older Windows games (any Windows Sierra game, for example) would be completely unusable under XP64. For what gain?

Probably because executing 16-bit code would probably require emulating an obsolete memory architecture at the very least (does AMD64 support "real mode" 16-bit memory architecture and x86 instructions still, for example?).

Screw M$ - DOSBox is getting to where it can run Win 3.x anyways, so it'll be able to handle those Sierra games. Maybe the ScummVM team will eventually suck up the open-source AGI/SCI/whatever projects and add support for those games too.

Reply 18 of 32, by collector

User metadata
Rank l33t
Rank
l33t

In Windows x64 WOWEXEC has been replaced with WOW64, which allows Windows to run 32 bit code the way WOWEXEC is used to run 16 bit in current Windows. Windows x64's lack of support for 16 bit code is why I am anxious for full Win 3x support in DOSBox. There would be few things that I would want to run that I couldn't with DOSBox if it had full 3x support at 256 colors.

Reply 19 of 32, by fish

User metadata
Rank Newbie
Rank
Newbie

Have you tried simply copying over the wowexec file? Sounds stupid, may be so, but I remember getting quite interesting results doing so with some win3x system files to win95, 95 files to NT...

The Sole Survivor.
Find me on efnet #oldgames