Blueboy, I hate to burst your bubble but having a second (or third, or fourth) core (whether that core be on another chip, or packaged on the same chip) is not going to help any applications that are single threaded, and guess what...yep, that would be DosBox.

DosBox has good company. I don't really know of any mainstream emulator that makes use of threading to increase performance. You see posts on the MAME bulletin board asking the same question and you'd think people would finally get a clue. The reasons are really not hard to fathom - the authors would have write code that attempts to see what instructions it could emulate in parallel on each of the cores, and then carefully coordinate their execution. In essense, you're asking the emulation authors to become chip microcode engineers. Uh, not.

There is far too much still to be done to focus on doing that, and besides, why bother, Moore's Law has given us speedier and speedier chips, so what doesn't work today might work in 2 years without having to radically recode the instruction emulation to use more than one core (a feat, at that). Granted, Moore's Law hasn't been too kind to us lately, because of a shift away from increasing processor speed (notice I didn't say cycles) in favor of using more cores, but things will pick up. Just be patient.

the next version of DOSBox will be faster as well. Maybe somebody would be kind enough to test daggerfall in it for you.

TheScotster wrote:

Blueboy, I hate to burst your bubble but having a second (or third, or fourth) core (whether that core be on another chip, or packaged on the same chip) is not going to help any applications that are single threaded, and guess what...yep, that would be DosBox.

DosBox has good company. I don't really know of any mainstream emulator that makes use of threading to increase performance. You see posts on the MAME bulletin board asking the same question and you'd think people would finally get a clue. The reasons are really not hard to fathom - the authors would have write code that attempts to see what instructions it could emulate in parallel on each of the cores, and then carefully coordinate their execution. In essense, you're asking the emulation authors to become chip microcode engineers. Uh, not.
...

DosBox is great piece of software I'm not questioning that at all.

Just seamed very weird that one core is utterly unused...
This was the first time I noticed that in Task Manager...
Even old win98 progs cause both cores to be used simultaneously and evenly and they are single threaded, aren't they?
And how the hell it ran smoothly under emulated win98 by VMware and both cores were used?

Ok I don't know that much 'bout emulation anyway... Guess I'll just overclock bloody cpu and hope one core will pull it off...
(what an irony, I'm overclocking machine that can run Oblivion on highest settings smoothly for it's grandfather to run decently 😀 )

Blueboyns: as far as I know, software that isn't designed to use both cores, won't use both cores. I tested a few older Windows games and none use both cores.

Also, I have an E6600 and with the new build, I can run any damn DOS game I want at hi-res with maximum detail so if you overclock, you should easily be able to do this too - with ONE c ore.

blueboyns wrote:

Just seamed very weird that one core is utterly unused...

As was explained, it is not 'weird' since almost every commercial Win32 program on the market (with some database and CAD exceptions) has only been programmed for single-thread execution. This means that the programmers did not have to contend with race conditions that can occur in a multi-cpu environment. Now that the multi-core CPUs are becoming mainstream, expect to see more applications/games take advantange of this fact...

Think of it this way. You have a single-threaded digestive system. There is only so much food your digestive system can handle at one time. If I hit you with my Virtualizing Magic Wand ® and give you two heads, now what? Now you can put twice as much food into you dual-mouths - however your digestive system is still single-threaded and can only handle the same amount of food as before. The extra mouth does you no good - since I did not give you two seperate digestive systems...

blueboyns wrote:

Even old win98 progs cause both cores to be used simultaneously and evenly and they are single threaded, aren't they?

No, the old Win98 programs do not cause both CPU cores to be used simultaneously, that is just your imagination at work. 😁 The dispatcher in WinXP just might be switching the program from one core to the other - or the other activity just might be all the device drivers, services and other non-foreground processes being run.

blueboyns wrote:

And how the hell it ran smoothly under emulated win98 by VMware and both cores were used?

I think that you should understand the difference between emulation and virtualization. I'll oversimplify... The 'emulation' that is peformed by DosBox means that the Intel instruction set is run on a software duplicate Intel CPU - which means that DosBox can be executed on any other CPU platform which has a C compiler and SDL library (mainly). This emulation will be slower than virtualization. Products such as VMware, VPC and the WinNT family NTVDM perform virtualization - which means that they require the actual CPU to underlay the virtual environment so that instructions can be passed directly to the actual CPU hardware for execution. This is why those Virtualized CPU environments are faster than the DosBox emulation environment. On the downside, this is why these Virtualized CPU environments are sometimes too fast for an older application/game - they cannot be slowed down as can DosBox. The DosBox code has control over the speed of the emulated Intel CPU - you get to adjust it with the 'Cycles' setting (DosBox also emulates the complete PC, not just the Intel CPU - so more work to be done and thereby slower still)

DosBox might be able to take advantage of dual-CPUs in the future if say the Video emulation threads were thrown to the other CPU core - but then you have synchronization issues to deal with in a big way. Just be happy that CPUs are getting faster. In a few years they will be fast enough that DosBox will be able to handle the most resource intensive late era DOS games, even with single threading.

Hope this helps,

dvwjr

ok thnx for explanation, as I said only solution seams to be overclocking hopefully it'll work

@red_avatar
yes your 6600 has true Conroe core, my 6300 has weaker Allendale core, well I guess I got what I paid for 😀)

ok thnx for explanation, as I said only solution seams to be overclocking hopefully it'll work

not necessarily, it might be that you "overclocked" Dosboox too much to have it playable. Try to keep an eye on the CPU usage of the CPU Dosbox is running on to make sure that you don't get into the read mark with your cycles. If you cycle Dosbox too much it becomes unplayable.

As Qbix said, next Dosbox will have increased performance. You may also try recent CVS builds before you try to overclock. I doubt that difference between E6300 and E6600 is that big anyway.

To use your DC, I suggest to try an emulator which can fully utilize dual core CPU's: PCSX2. As it can play many commercial games, it's useful feature.

Using multiple cores comes naturally to it, since they have to emulate multiple PS2 cores anyway. Dual Core mode is often even more than 2x faster because it also solver some very sensitive syncing issues with much less overhead than in single thread mode (btw. there is also mode that takes advantage of HT on single core Intel CPU's).

Taking advantage of multiple cores should come naturally to DOSBox in the form of seperate threads for each emulated chip. For example, being seperate processes, DOSBox's MIDI playback using Munt or a virtual synth takes advantage two cpus. The hard nut to crack would be trying to thread one emulated chip. If SDL threading is borked, FM could gain the same advantage as MIDI playback by writing passthrough handling for OPL; letting VDMSound do it. Just like MIDI playback, if the hardware were setup, you could use a real sound card for FM playback as well.

I don't see why they should bother. I'm happy with DosBox on my XP 2800+. (I'll be close to 100% happy when I go Core 2). If you already have a Core 2 and your still not happy with DosBox performance then something is seriously wrong.

They are also some optimizations being worked on for dynamic core that signficantly increases performance that haven't made it into CVS yet so this should decrease the supposed need for multiple processors for DosBox even further.

Just an update 😀
I tried overclocking to 2.01 GHZ it didn't work, still slow.

I tried all possible cycle values gradually increasing and it was still very slow.
Best speed is at 40000 cycles, CPU (that is, half of it) is at approximately 99%

Problem I think is with Dagerfall itself. It's very CPU intensive game since it's practically calculating your every move based on environment variables, your stats and actions, plus when you're in the big city and dozens of npcs starts wandering about, things get a bit problematic for only one core.
(one of suggestions for better speed on 486 machines when it was released was to have little things in inventory of your character so game would have less things to calculate?!)

I didn't have any speed problems running other games.
Maybe someone else can also run it on Core 2 computer and let me know the results. (eg DosFreak) and tell if "something is seriously wrong" with my c2

I think I'll just go and buy used Pentium I for 50 eur and play DOS games as they should be played.

only increase the cycles in dosbox till the one core thats being used reaches near 100% if you increase it past 100% your just decreasing the performance of dosbox and probably wasting electricity.

Okay first time I posted, I glanced over the fact that you used Daggerfall. Daggerfall along with the other Xngine games (Terminator Future Shock and Skynet) have always been slow as hell in Dosbox because they use weird CPU code or something like that (Qbix will be able to explain better).

With the latest beta (0.66 which will be released soon), Xngine games are finally playable. Daggerfall is very fluent now - and even the game Battlespire is (the awful sequel).

With the latest beta (0.66 which will be released soon), Xngine games are finally playable.

hey thanks for the info. i did a little google search after reading your post and found something useful... 😉

> because they use weird CPU code or something like that

self-modifying code, if Daggerfall has a similar engine to the
Terminator games you might want to try the normal core
rather than the dynamic core.

I play Daggerfall in the normal core with 20,000 - 25,000 cycles on my Athlon 64 3500+ and it's very playable. And the Core Duo 6300 is a better CPU.

The next version of D.O.G. i'm building will try to take over the playing of music upon a CD-Rom trough a Hook method for the SDL.dll, the Music drive.
In simple words, DOSBox won't be spending CPU time on playing Audio from the CD, D.O.G. will take it over and therefore will reduce the amount of Cycles used by DOSBox, but increasing the amount of cycles D.O.G. uses.
I'm planning to make D.O.G. force all applications running upon one CPU and DOSBox upon the second, if there are two cores. And by doing this, DOSBox will have one full core to itself, and the other core occupied by all other apps including D.O.G.
I'm also planning other hook thingies, so that wave/Midi play is also handled by D.O.G. and by doing so reducing the load of DOSBox further and making it more or less double threaded.

This feature is still only available for the 0.65 version of DOSBox, not other CVS version, there they use another SDL.dll.

I'm going to release D.O.G. 1.53d this evening, including the Music drive.

Erik.