There is no vanilla DOSBox for the pi....at least not one that is supported by these forums,

I never said "Pi" anywhere in my post. So what are you talking about? I said my "Ubuntu box" and by vanilla, I meant the version you get with
# sudo apt-get install dosbox

Even when I copied fastdosbox-CVS.conf over to my dosbox.conf, FastDosbox was still 2-5x faster. I'm surprised there's not more talk about it around here.

I wonder if people are paying $1 to have the dynamic core turned on for them...

slacka wrote:

I never said "Pi" anywhere in my post. So what are you talking about?

It's there in the URL:
fastdosbox-for-raspberry-pi-raspbian-and-risc-os

Pickle wrote:

I wonder if people are paying $1 to have the dynamic core turned on for them...

I think you're right... there's barely any noteworthy changes in the source code, besides making the default core "dynamic" instead of "auto".

jmarsh wrote:

Pickle wrote:

I wonder if people are paying $1 to have the dynamic core turned on for them...

I think you're right... there's barely any noteworthy changes in the source code, besides making the default core "dynamic" instead of "auto".

But if that's true, why then is it so much faster on benchmarks like topbench even when I use the fastdosbox-CVS.conf setting in my dosbox.conf? If fastdosbox only changed configuration options, they would run at the same speed. I benched it against both DosBOX .74 and DOSBox SVN Daum.

Try your benchmarks again when 0.74 has settings of core=dynamic cycles=max. This so-called fast build could simply be using dynamic core and max cycles with the default core=auto cycles=auto settings regardless of the CPU being in real or protected mode.

slacka wrote:

But if that's true, why then is it so much faster on benchmarks like topbench even when I use the fastdosbox-CVS.conf setting in my dosbox.conf? If fastdosbox only changed configuration options, they would run at the same speed.

Those two statements are contrary to each other. If you can take the default .conf file generated by fastdosbox and get a speed up when using it with regular dosbox, obviously the speed up is simply because of different settings and not code changes.

jmarsh wrote:

slacka wrote:

But if that's true, why then is it so much faster on benchmarks like topbench even when I use the fastdosbox-CVS.conf setting in my dosbox.conf? If fastdosbox only changed configuration options, they would run at the same speed.

Those two statements are contrary to each other. If you can take the default .conf file generated by fastdosbox and get a speed up when using it with regular dosbox, obviously the speed up is simply because of different settings and not code changes.

I copied the setting from fastdosbox-CVS.conf and pasted them into my Dosbox's dosbox.conf. I then benchmarked DosBOX vs fastdosbox. fastdosbox was still faster on some benchmarks. Why is this so difficult for people here to comprehend? And yes ripsaw,I was using core=dynamic cycles=max, because those are the setting that were copied out of fastdosbox-CVS.conf. Same settings, so it should be a fair benchmark comparison, right?

In addition, I ran
# apt-get source dosbox

Then performed a diff with fastdosbox's source. There are countless changes, especially in the CPU core. With all the negative comments without facts behind them, It's clear no one else here has either 1) benchmarked it or 2) looked at the source. Otherwise we be having a much more interesting discussion around all the many changes in paging.cpp and callback.cpp along with a few in core_dynrec.cpp.

jmarsh wrote:

I think you're right... there's barely any noteworthy changes in the source code, besides making the default core "dynamic" instead of "auto".

Moreover, that web site from OP states that the emulation is at 386/DX speed, which is not consistent with the speed-up claim. I believe there is also a patch in the patches subforum for ARM dynrec code.

truth5678 wrote:

jmarsh wrote:

I think you're right... there's barely any noteworthy changes in the source code, besides making the default core "dynamic" instead of "auto".

Moreover, that web site from OP states that the emulation is at 386/DX speed, which is not consistent with the speed-up claim. I believe there is also a patch in the patches subforum for ARM dynrec code.

My original post was referring to the 1.6 Ubuntu build. Not the old 1.5 Pi build that people keep bringing up. The 386/DX speed is when it's running on a lowly $25 ARMv6 board. I don't know DosBOX compares on this hardware, although this site says FastDosBox runs much better than normal DosBOX on a Pi.
http://www.codingepiphany.com/2013/06/29/fast … ith-fastdosbox/

Besides, my benchmarks were done on an x86 Ubuntu box. I don't see how an older Pi version's performance is relavent.

How do all these "believers" and "thinkers" that fastdosbox is just a config tweak, explain this:
http://pastebin.com/GWeu985r

That link shows very few changes to the source code and many of the lines are identical in source. When creating a diff file, it is important to identify changes resulting from empty spaces and lines in the code. The diff command will show a difference from empty spaces and lines. The several changes are slight modifications (and M-HT has already written ARM dynrec code as shown here: Dynrec - ARM backend update).

The ARMv7 dynrec code has already been submitted by M-HT about a year ago.

The reason why no one believes you is because it's very hard to quench more speed out of dosbox. I'll try myself with that source but I'm not hopeful...
Likely explanations that haven't come up yet:
- Try with DOSBox SVN
- make sure both builds are on the same arch (32bit vs 64bit)
- if fastdosbox was built as 64bit then maybe THERE are optimizations for the 64bit dynrec core

@Dominus
I already tested with SVN Daum. Did you have a particular one i mind?

When using the same configs, many benchmarks were similar, but fastdosbox still managed to consistently win on MIPS.COM and topbench. The results were as follows:
FastDosbox > DOSBox SVN Daum w/ FastDosbox config > vanilla DOSBox 0.74

I did all my testing and compiling on a 32-bit Ubuntu box. I don't have Linux installed on a 64-bit PC.

Best would be if you could just grab Dosbox svn and test with that. Because SVN has lots of fixes but isn't overburdened as Daum's "fork"

slacka wrote:

In addition, I ran
# apt-get source dosbox

Then performed a diff with fastdosbox's source. There are countless changes, especially in the CPU core.

There really aren't, if you ignore whitespace changes (and compare against say, dosbox SVN r3783 since fastdosbox is missing a lot of more recent bugfixes).

With all the negative comments without facts behind them, It's clear no one else here has either 1) benchmarked it or 2) looked at the source. Otherwise we be having a much more interesting discussion around all the many changes in paging.cpp and callback.cpp along with a few in core_dynrec.cpp.

The only person making up facts is you; those three files are functionally identical to older dosbox code. You can tell just by looking at the file modification dates: callback.cpp is dated 2012 and paging.cpp is dated 2011.
fastdosbox doesn't even have the MEM_BlockWrite/MEM_BlockRead patch that greatly improves disk I/O speed and stands out as obvious low-hanging fruit if you run dosbox while profiling.

How do all these "believers" and "thinkers" that fastdosbox is just a config tweak, explain this:
http://pastebin.com/GWeu985r

There is nothing in there that could be considered as a new optimization.

one possibility for some optimization is using the gpu to do the scaling, for instance in my pandora build I render with no scaling and use the 2d hw scaler to fill the screen. This helps get a bit more speed, but doesnt seem to be the complete answer to the speed up claims.

Per Dominus's suggestion, I finally got around to building the latest SVN and it looks like that's where the speed up in certain tests was coming from. Sorry if I got anyone's hopes up.

The original link said that its speed was due to dynrec.