And what's the unfair part??

Clearly you were annoyed at what you perceived to be criticism aimed at Dosbox. I don't believe that's what Kaminari and TeaRex intended at all. Just an explanation of what they had seen themselves. I felt there was no need for undue hostility, that's all 😀 Everybody respects the work done by the Dosbox developers and those that have helped.

Better use a frontend with some default templates. Adding a config option for upper cycles limits just to avoid your new pc not wasting cpu time is not a highly needed thing.

A frontend would serve no purpose whatsoever. It would not solve the problem anymore than using Dosbox without it. Surely that must be obvious by now 😀

I agree that limiting the upper cycles is not a high priority in comparison to other tasks. But then again, since Dosbox already calculates the maximum cycles available on a constant basis under max mode, then implementing a patch to fix it at an upper level is not likely to be difficult at all. Which is why I felt it was worth suggesting. If I thought it was a real slog to do, then I wouldn't of bothered mentioned it.

Finally, I didn't suggest this idea because I was thinking about my own PC, but because I could see a use of it in creating templates that are flexible to a range of PC's. I do some administration work for a gaming community and could see the use for it myself. As somebody else noted earlier too, there are other possible uses for it.

Pan wrote:

I don't think that was really fair wd. Kaminari and TeaRex were only demonstrating their personal experiences with Dosbox. Nothing wrong with that.

I can speak for myself, Pan.

Best wishes,

> But then again, since Dosbox already calculates the maximum cycles
> available on a constant basis under max mode

Well that's not what is done. It's not like there's some speed testing,
then some cycle value is calculated, which is then used. The cycles=max
setting determines the cycles value depending on previous time slices,
so it might vary a lot.

> then implementing a patch to fix it at an upper level is not likely to be
> difficult at all. Which is why I felt it was worth suggesting.

It's one line. And i still don't see it worth adding a config option for it
if it's just about keeping cpu usage low when upgrading to a new system.
Maybe even the next generation of PCs you buy is far too fast for your
3000-10000 cycles estimation so your cycles=max 10000 is useless anyways.
And i'm sure it is possible to have some templates for cycle values in
some frontends so you can easily updates the values for all your games.

I can speak for myself, Pan.

Sorry.. 😀

Well that's not what is done. It's not like there's some speed testing, then some cycle value is calculated, which is then used. The cycles=max setting determines the cycles value depending on previous time slices, so it might vary a lot.

Yes, but that hardly matters much. At the end of the day, it's just a one-line if statement which determines if the current value calculated if above the maximum.

It's one line. And i still don't see it worth adding a config option for it if it's just about keeping cpu usage low when upgrading to a new system. Maybe even the next generation of PCs you buy is far too fast for your 3000-10000 cycles estimation so your cycles=max 10000 is useless anyways. And i'm sure it is possible to have some templates for cycle values in some frontends so you can easily updates the values for all your games.

It's a bit more than one line because Dosbox would need to read in the configuration data too and also some additional code might be required to allow changing via the command-line. This is on top of the if statement required of course.

It's not about keeping CPU activity low when upgrading to a new system, it's about having a configuration that is portable from machine to machine.

I'm not sure what you mean by my 3000-10000 cycle estimation being wrong on next generation PC's, as far as I know, the Dosbox cycle count should be pretty consistent regardless of the PC used shouldn't it?

It would of course be possible to have two or three sets of configurations of different specifications inside a frontend. But this introduces two problems. Firstly, configuration files would not match as specifically to the system performance as the use of the capped max directive would as there are only so many configuration files you could create. Secondly, there would be no way to automatically check which template should be used for which system, relying on the user themselves choosing the right template for their system. As a third problem too, you could say that if many configurations were produced like this, it would be extremely time-consuming overall.

The capped max directive still seems like the best option to me.

> It's not about keeping CPU activity low when upgrading to a new system,
> it's about having a configuration that is portable from machine to machine.

Ok, cycles capping then... anything else?

What do you mean?

In the cvs you can now use something like "cycles=max limit 10000",
maybe test if that suits your needs.

I downloaded the new CVS and gave it a try. That new option seems to fit the bill perfectly!!

Did you personally implement it?

I guess i won't get a patent for it, but that one line grew to three lines
and the rest is (i think) Qbix's command line class thingie.

I appreciate your effort though. You didn't think it was worth implementing and yet you still did it. That requires special thanks 😀

I wrote the patch to do this a long time ago but it wasn't included.

http://sourceforge.net/tracker/index.php?func … 551&atid=467234

The only thing that had an effect from this patch was already included back then.

Not so, the interval was tweaked, but making it auto adjust to a set limit wasn't(along with stream lining normal_loop and adding cycle stats.)

Yes, there was no apparent need for this (or ignorance toward that)
so you can thank Pan for convincement, and Pan can thank you for
your implementation 😀 Or something like that.

The stream inlining, well on the average we spend way above 10000
cycles in the core before returning to the main loop. So that won't gain
anything (which does not mean it's wrong or bad or something).

I would argue it's cleaner code streamlined. When I tried to convince the first time around, no one was saying what they objected to. Hard to convince when the other party won't converse or elaborate, so I found myself not working on dosbox anymore.

It's quite simple: every change might introduce problems, so if it's not
needed (this is quite subjective by times, yes) it's left as is.
Again this does not imply that anything was wrong with your patches.
Looking through them i learned this and that. But "preferred" speed
updates in this phase of dosbox are by far architectural changes,
like the scaler caches and stuff like that (just my opinion). Once the
dynamic core/derivatives are stable and advanced enough, dosbox
*should* spend most time in the generated code (at the moment it's
at an average of 2/3, the rest 1/3 are dominated by the memory
access functions).

I don't know how your patches behave on non-x86 architectures,
in general the profile-guided optimizations (there was a longer thread
about it recently) seem to be quite appealing for this.