I'd like to see someone with the biggest L2 cache compared to a smaller L2 cache compare DosBox performance. Still even if a P4 was faster than an Athlon at DosBox I still won't touch it with a ten foot pole. AMD all the way!

The only game I've tried that lagged for me was the old Return of Condor Heroes DOS game from Taiwan. I'm using a Pentium M 760 (2.0GHz, 533MHz FSB, 2MB L2 Cache).

I'm not sure what the equivalent would be in P4 but basically the M is Intel's hybrid between the P3 and P4. P3 was a much faster processor than the P4 but had serious heat problems. According to Tom's Hardware (however much you trust it) the M pulls a lot of the speed of the P3 with the better heat management of the P4. There are some conversion kits I think for putting a Pentium M in a PC with a P4 socket.

The Pentium M is a much better chip than the P4 (netburst). The Pentium M is probably what the Mac x86 will be based on.

Go for a chip with a good L1 cache. Which means AMD these days (P4 has a laughable L1 cache, P3 has bad L1 timing, dunno how the M is). Also, sure that your 2.4GHz/1MB Athlon64 is rated 4000+? My laptop has such a chip and is rated 3700+ (not a mobile CPU, a plain desktop one).
Anyhow, I think any L2 cache beyond 512K is enough. Remember that games seldom have more than 512K of actual code, plus some space for the emulators CPU loop, so 640k ought to be enough for anyone. 😉
Oh, and avoid the older Athlon (non-XP, non-64), those can have really bad behaviour with dynamic CPU and self-modifying code.

I have a Pentium-M notebook. Dell Inspiron 9300. I replaced my Athlon 64 eMachines 6805 with this. It has a Dothan 2.13GHz. 64K L1, 2MB L2. The Dothan runs DOSBOX at least as well as my Athlon 64 3000+ (1.8GHz) 1MB L2 did, probably better. I haven't played a lot of DOSBOX lately. But it runs VERY well. It seemed to run quite a few more cycles in Dark Forces with the same DOSBOX conf and version as I was using before. I have a 300MHz clock speed advantage now, which obviously helps so it's hard to say about the caches.

Please understand that AMD's and Intel's caches are very different. AMD uses an exclusive cache architecture which places far more emphasis on the L1 cache and makes the L2 slower. In fact, that's why Barton benefited little. The L2 cache was already big enough for what it needed and only a huge increase in L2 size would have made a big difference. AMD's L1 cache is very fast, but slower than Intel's because a small cache can be made extremely fast FAR more easily.

Intel uses an inclusive design which places huge emphasis on the L2 cache and makes the L1 very small but crazy fast. Intel's caches are a LOT faster than AMD's. Intel's L2 cache has incredible speed characteristics. INCREDIBLE. It's 2x wider than a A64 L2, 4x AXP. 256-bit vs 128-bit on A64 (remember though, A64 needs L2 a lot less than Intel's chips). It also has incredibly low latency. Whether this has a direct impact on performance, probably, but how much? Who knows.

Pentium-M is a very refined P3-ish chip. It uses the P4 bus and has lots of P4-ish tweaks, like SSE2 and better SIMD performance in general than P3. It also has 2x the L1 cache of P3, and the cache is better designed for SSE operations. Obviously the massive 2MB L2 cache is a booster. All it really shares with P3 I believe is the skeletal design (it's a rebuilt core like P3), but the x87 FPU may be very similar. It's perclock performance is extremely similar to Athlon64, and it does that without an ondie memory controller.

Good P-M analysis. P-M is a monster.
http://www.cpuid.org/PentiumM/index.php

He also did a good writeup on K8.
http://www.cpuid.org/K8/index.php

Yeah, that's been my experience with my 2GHz Dothan. I moved to this computer from a 1.1GHz Celeron copper core (before Tualatin) so the DOSBox difference for me is just night and day. I've been pretty blown away.

How is the Inspiron 9300 by the way? I was looking at it for a while, but went with a Gateway M460TX because of its better battery life. Basically it mean't a 2GHz processor instead of a 2.13GHz, but the rest of it is pretty solid.

It's a nice laptop. Especially if you get it with one of the crazy fatwallet.com Dell coupon deals. $600 off $1699 is what I got, 🤣. Free (cheapo) printer and 512MB upgrade too.

I actually ordered it with a 1.6 Dothan from Dell. I did this because I had discovered a overclock trick where you can buy a Dothan 400FSB off eBay and do a simple pinmod to trick the board into running it at 533FSB. And from the success rates I've read, 1.6->2.13 is almost a guaranteed OC. And it was. Hhehehe.
http://www.notebookforums.com/showthread.php?t=76096

I also bought 2GB DDR2 from Newegg for ~$250 total. Dell wanted $1000 for the same amount!

The 6800 go is a fantastic graphics chip. The 17" widescreen is really great if you use your note a lot. I went with the non-glossy 1440x900 screen cuz 1920x1200 was too high for me, and the glossy screens are ridiculously glare ridden. The subwoofer adds some good midrange to the speakers (lol!). It has DVI video out if you want to hook up a good LCD. Overall it's a fantastic machine, especially for the $1600 I paid total.

My eMachines 6805 was the same as the Gateway 7422 series I believe. It had a Radeon 9600 64MB and A64 3000+. Great machine, but it suffered from a annoying screen backlight flicker that nobody can really figure out. My dad is using that machine now. To sorta fix the backlight flicker I hot glued the crap out of the wires that lead to the backlight power inverter. The flicker seems to be caused by those wires being loose.

I actually had also considered the Gateway M505 machine before I got the eMachines. I would have gotten that one if the eMachines hadn't been $200 cheaper.

It's too bad that we can't figure out a good way to benchmark DOSBOX. It's really tough to do because you need to maximize the cycles for each CPU and it's not really easy sometimes to do that.... I can say though that I think the P-M is on par with A64. I'm sure that means that AXP is behind them both as A64 is an optimized AXP basically. P4 probably stinks at it per clock, but P4 of course is crazy high clocked.

`moe` wrote:

Also, sure that your 2.4GHz/1MB Athlon64 is rated 4000+? My laptop has such a chip and is rated 3700+ (not a mobile CPU, a plain desktop one).

His processer is probably rated at 4000+, it's probably a socket 939 processer, your's on the other hand may be a socket 754. For example a socket 754 3000+ is rated at 2.0Ghz while a socket 939 3000+ is rated at 1.8 Ghz. FYI I own a 3200+ which comes stock @ 2.0Ghz but is over clocked to 2.4 Ghz, making it the performance equivalient of a 3800+(and clockwise a 4000+ but the 1mb of cache makes that processer run faster obviously. 😉 )

Anyhow I find I can tromp almost anything with this setup, the only thing that doesn't work well are games like blood and duke3d, ect. They run about the same on this cpu as they did on my old xp 2000+ so eh. It's strange however because if I run Quake in Dosbox(yea, yea I know theres no need too...) I get a better framerate then blood. 😒

DosFreak wrote:

I'd like to see someone with the biggest L2 cache compared to a smaller L2 cache compare DosBox performance.

This may sound obvious, but is there a simple "benchmark" we could use to compare two CPUs running the same program under DOSBox? I've tried to compare my older computer with the new one using some games, but all tests were based on me perception of game speed vs. number of cycles.

Does anyone know any game sequence that we could easily run in order to compare DOXBox performance, so we could test our own CPUs and publish the results here? Would a synthetic benchmark be better? Any ideas?

DosFreak wrote:

AMD all the way!

Sure 😁

Preliminary parameters for DosBox benchmark:

1. Dosbox.conf set to default values unless specified otherwise.
2. Host system at 95% processor usage.
3. No background programs loaded or other system activity.
4. Compile a list of games with internal benchmarks, preferably ones that require little setup, ex: Doom 1 timedemo or Quake 1 requires little intervention, whereas Duke3D has no default demo mode.
5. Should sound/other things be loaded? I say yes. We are benchmarking DosBox to determine optimal processor for gameplay usage...not to determine how l33t our graphics cards are. So load as many features as the game allows to determine what the optimal featureset for your processor is.

Don't give that much value to "CPU usage in %", since that's notoriously inaccurate on all OSes.

My 2 suggestions:
1) On Sourceforge, you'll find a patch from me that tells you how fast dosbox runs internally by comparing real time with the number of emulated timer ticks. That's as accurate as it can get: if they are equal (output is "100%"), dosbox is not overclocked. My patch outputs every 16 seconds, thus it doesn't take any noticeable performance away from dosbox. Increase cycles as long as you get "100%" output. Note, however, that you'll often see a variance. Some parts of a game might get "100%", while others can get "98%" (meaning internal timing is 2% behind real time, dosbox is slightly overclocked) or even worse, that's quite common. Decide on a specific game sequence that you test, or tune cycles for the worst part.
2) Tune cycles until you get sound dropouts. I favour this method by now, since it measures real-world performance. I am willing to play as long as sound is continuous. Compared to the above method you'll find that you can "overclock" dosbox to 95% of real-time until sound starts to drop out. As far as I can tell, even though it is slightly overclocked, emulation speed is indeed faster than with a "100%" measurement.

Yeah so....

Before benchmarking run software with audio turned on and verify sound quality.

Is there any way that DosBox can "notice" these sound problems? is there any way to control the flow of data to the virtual sound card? Say...if DosBox notices a drop in sound data it modifies the CPU cycles to try to fix the issue or say keep the flow of data to the sound card at a constant value?

Should moe's patch be included in the official DosBox? I've played around with it briefly before and it's better than the current method.

Well, SDL should notice sound dropouts ("buffer underrun"), but I think it's a bad idea to tune cycles based on that, since if that happens, it's already too late. Moreover, SDL doesn't tell DosBox about these dropouts.

I think my patch could form a base for a less intrusive auto-adjust, but I think there's an even better solution: It _should_ be possible to run dosbox cycle-less with little modification (still thinking about that one - I'm not sure if I am right).

Moe, would this idea of yours mesh with the need to be able to run some games at certain speeds, or would the current "constant cycles" method still need to be available?

Well, yes of course, it would have to be able to restrict cycles like it's done now. When SDL-OpenGL-HQ is running fine, I will probably go and see if I had a bright idea or am thinking rubbish 😉