While working on this, I noticed some interesting things in the benchmarks.

Firstly, the ratio of integer to floating-point performance on the nehemia is very different than the pentiums and the 486. I spent a lot of time scratching my head, trying to figure out why my Doom benchmark scores were so low, and my 3D bench and PC Bench scores were so high. I routinely found that I would get roughly the same FPS in the Doom benchmark as a did in the Quake benchmark, which at first didn't make a lot of sense.After swapping in my pentium III 450 in and out and testing with caches on and off and at different throttle settings, I finally figured out that there is just an inherent speed mismatch between integer and FPU performance on this platform.

Looking over benchmarks with the pentium P55C, K6III+, and other speed adjustable CPUs, I noticed a similar trend. Before 1995 for so, basically no DOS games ever relied heavily on floating point arithmetic for games. For this reason, I think Doom is probably the most reliable benchmark for DOS speed, given that it uses almost exclusively integer math.

With the said, I did find that I could reduce the gap between integer and FPU performance a little bit with the right settings.

A lower clock speed seems to work better, even over a faster clock speed with a higher throttle.
Disabling Branch Prediction seems to hurt FPU performance more than integer performance for some reason.

The opposite is true when IC is disabled. In the 386 range, FPU performance is a tad lower than a real 386. Using the highest FSB I could seemed to help close the gap. The Nehemiah emulates 386 machines almost exactly in FPU and Integer performance with IC disabled.

I also noticed that my particular board didn't like running at 50fsb very much. At a 7x multiplier it was rather stable, but anything less than that would cause the system to hang.

Finally, on my particular board, faster timings with spread spectrum disabled lowered my score just a little bit in MIPS at really slow speed settings, compared to looser timings. Not sure why that is, but this helped me get down to within 5% of the speed of an 8088@4.77mhz, compared to 8% with slower timings.

^^ Glad you like the VIA C3 processors; they're flexible and great for DOS and early Windows. I did the tests you are going through several years ago in conjunction with THROTTLE.EXE and Setmul. I too managed to get a Nehemiah down to IBM XT 4.77 MHz speeds. However, beyond just benchmarks, I did further tests:

1) Using SCROLL.COM (I'd have to double check the exact name), a program designed to scroll text, its behaviour at XT speeds was jerky when using THROTTLE. EXE compared to hardware slowdown using a Turbo switch and multi/ cache disabling on a K6-III+ CPU at XT speeds.

2) Using 386/ 486 demoscene productions slowed with THROTTLE.EXE also produced artefacts compared to the above method, and also on the exact same board slowed down without using THROTTLE.EXE.

So, essentially, I wasn't convinced with THROTTLE. EXE and its method of hooking onto ACPI for slowdown giving equivalent results to other hardware slowdown methods. It can be good enough though, but then you might as well use DOSBox.

j^aws wrote:

^^ Glad you like the VIA C3 processors; they're flexible and great for DOS and early Windows. I did the tests you are going thro […]
Show full quote

^^ Glad you like the VIA C3 processors; they're flexible and great for DOS and early Windows. I did the tests you are going through several years ago in conjunction with THROTTLE.EXE and Setmul. I too managed to get a Nehemiah down to IBM XT 4.77 MHz speeds. However, beyond just benchmarks, I did further tests:

1) Using SCROLL.COM (I'd have to double check the exact name), a program designed to scroll text, its behaviour at XT speeds was jerky when using THROTTLE. EXE compared to hardware slowdown using a Turbo switch and multi/ cache disabling on a K6-III+ CPU at XT speeds.

2) Using 386/ 486 demoscene productions slowed with THROTTLE.EXE also produced artefacts compared to the above method, and also on the exact same board slowed down without using THROTTLE.EXE.

So, essentially, I wasn't convinced with THROTTLE. EXE and its method of hooking onto ACPI for slowdown giving equivalent results to other hardware slowdown methods. It can be good enough though, but then you might as well use DOSBox.

Interesting, I'll have to test that. Can you link to the demos that you used?

I tested a couple of games that run best on an 8088@4.77mhz and had mixed results. Some games that worked on my NEC V20 refused to launch, while others worked pretty much exactly as they should.

mothergoose729 wrote:

j^aws wrote:

^^ Glad you like the VIA C3 processors; they're flexible and great for DOS and early Windows. I did the tests you are going thro […]
Show full quote

^^ Glad you like the VIA C3 processors; they're flexible and great for DOS and early Windows. I did the tests you are going through several years ago in conjunction with THROTTLE.EXE and Setmul. I too managed to get a Nehemiah down to IBM XT 4.77 MHz speeds. However, beyond just benchmarks, I did further tests:

1) Using SCROLL.COM (I'd have to double check the exact name), a program designed to scroll text, its behaviour at XT speeds was jerky when using THROTTLE. EXE compared to hardware slowdown using a Turbo switch and multi/ cache disabling on a K6-III+ CPU at XT speeds.

2) Using 386/ 486 demoscene productions slowed with THROTTLE.EXE also produced artefacts compared to the above method, and also on the exact same board slowed down without using THROTTLE.EXE.

So, essentially, I wasn't convinced with THROTTLE. EXE and its method of hooking onto ACPI for slowdown giving equivalent results to other hardware slowdown methods. It can be good enough though, but then you might as well use DOSBox.

Interesting, I'll have to test that. Can you link to the demos that you used?

I tested a couple of games that run best on an 8088@4.77mhz and had mixed results. Some games that worked on my NEC V20 refused to launch, while others worked pretty much exactly as they should.

Yes, I could get the names of these demos, but you'll have to wait until the weekend or so, as I have them stored in one of my test hard drives in storage. It's a collection of around a dozen demoscene productions that are tricky to run on real hardware which I downloaded from Pouet.net. There was a large percentage from this collection that had corrupted graphics whilst alternative slowdown to Throttle ran them correctly. Pretty much how you describe your experience compared to the NEC V20.

As mentioned earlier, I have my test suite of demoscene productions downloaded from Pouet.net. I'm just reading off the hard drive, so these are names of zipped files - I've enclosed the executable names in brackets:

ambience (ambience.exe)
cd2-tm (cd2.exe)
clx_xtal (xtal.exe)
copper (copper.exe)
copperfa (dentrocf.exe)
dowhack (do.exe)
gbu_sp (gbu.exe)
kuk2src (kukoo2.exe)
logus-t5 (logus-t5.exe)
luminati (luminati.exe)
pls_sunf (sunflow.exe)
timeless (timeless.exe)

So that's a dozen demos that are tricky to run on real hardware and my goal was to run them all without artefacts or issues on the same PC. I can't remember offhand which ones ran normally with hardware slowdown tricks and failed with Throttle.exe, but the demos would be from the above set. You should be able to find them with the supplied names from Pouet.net. Let us know how you get on.

Wow, that idea is a handful! Copper is especially tough, it needs an old CRT display with some very specific VGA. And if you need some more challenge, try Optic Nerve! I could start it a few times on various hardware but it's rare and even if you can start it once there's no guarantee that it'll run next time, on the very same hardware...

At pouet they accused some twisted way of loading that needs its data file in subsequent clusters - I dunno, I've seen it not working anymore without any change on the drive it had loaded correctly a few minutes earlier...

At the moment I know no build here I could run it. And the cherry on the top of the cake, it runs under Dosbox.

j^aws wrote:

As mentioned earlier, I have my test suite of demoscene productions downloaded from Pouet.net. I'm just reading off the hard dri […]
Show full quote

As mentioned earlier, I have my test suite of demoscene productions downloaded from Pouet.net. I'm just reading off the hard drive, so these are names of zipped files - I've enclosed the executable names in brackets:

ambience (ambience.exe)
cd2-tm (cd2.exe)
clx_xtal (xtal.exe)
copper (copper.exe)
copperfa (dentrocf.exe)
dowhack (do.exe)
gbu_sp (gbu.exe)
kuk2src (kukoo2.exe)
logus-t5 (logus-t5.exe)
luminati (luminati.exe)
pls_sunf (sunflow.exe)
timeless (timeless.exe)

So that's a dozen demos that are tricky to run on real hardware and my goal was to run them all without artefacts or issues on the same PC. I can't remember offhand which ones ran normally with hardware slowdown tricks and failed with Throttle.exe, but the demos would be from the above set. You should be able to find them with the supplied names from Pouet.net. Let us know how you get on.

Thank you, I'll give it a try. I have gone through all the speed profiles I am likely to find useful. One of questions I want to answer is how effective is throttle in games and how does it compare to software slow down. These demos will help with that.

alvaro84 wrote:

Wow, that idea is a handful! Copper is especially tough, it needs an old CRT display with some very specific VGA. And if you need some more challenge, try Optic Nerve! I could start it a few times on various hardware but it's rare and even if you can start it once there's no guarantee that it'll run next time, on the very same hardware...

At pouet they accused some twisted way of loading that needs its data file in subsequent clusters - I dunno, I've seen it not working anymore without any change on the drive it had loaded correctly a few minutes earlier...

At the moment I know no build here I could run it. And the cherry on the top of the cake, it runs under Dosbox.

Yeah, demos by their nature do things that are weird. It is an interesting perspective on compatibility, but not the end-all-be-all.

Still, I have an Ezra CPU and addition to my Nehemiah, with the former being able to hit all the 486 speed points. It will be interesting to compare different slow down techniques.

Hey,

Glad to hear about your success with the VIA build. I was happy to offer what advice I could but I was basically just passing on the knowledge shared with me by j^aws and Gerwin. I am grateful to them both for their experimentation and sharing their knowledge and also especially appreciative to Gerwin for his SetMul program.

As j'aws pointed out, throttle.exe as a slowdown method isn't comparable to downclocking and toggles available by SetMul and I usually leave it off the table when discussing these type of builds. It's really not much different than adjusting clockcycles in DOSBOX. I'm happy with the speeds of Ezra-T - it tops out at about the same performance as my K6 and is more flexible.

The Nehemiah is a nice pop-in if you want flexible low to mid tier Pentium II/III speeds and also it can go slower than the Ezra... to 286-ish speeds. About that.. I had the same experience with 50mhz FSB on the Nehemiah. I'll copy paste my old post about it...

None of the settings in my BIOS took the Ezra any slower than the benchmarks I posted earlier (386DX-25/33)... but I just tested […]
Show full quote

None of the settings in my BIOS took the Ezra any slower than the benchmarks I posted earlier (386DX-25/33)... but I just tested my Nehemiah and at 66x4 with caches disabled I get...

3.87 in SpeedSys, 4.6 3DBench and 1.1 in PCPBench ! Sadly the with the Nehemiah the system will freeze up if I try and set the FSB to 50mhz... though perhaps if I do that with DIP switches rather than in software it will boot up. This has to be 286 territory, no?

Edit: The lowest the system on a 50mhz FSB is 500mhz (50x10) with caches disabled. That gives me slightly lower scores than 66x4 with...

3.36 SpeedSys, 4.2 3DBench. PCPBench won't go lower than 1.1FPS. Also Landmark says it is running like a 21Mhz AT and the System Information CPU Benchmark is 8.5

Yeah I wasn't able to go lower than 50x10 but this was still slower than 66x4. I don't remember if I tried having the DIPs set to the 'hidden' 50mhz FSB option and if that made any difference.

When I first tried the CPU I was able to complete benchmarks at 4.5x with 50mhz bus speed. I don't remember what the speed was. I estimate it was probably in the 20's for DOOM FPS, but I can't remember. It wasn't stable.

After that brief honeymoon period though, I wasn't able to get to run at anything less than a 7x multiplier. With BP disabled it ended up being about the same as a 4.0X66, so I haven't found the 50mhz bus to be very useful.

I am still optimistic though. For classic era DOS games, I don't think there are that many speed sensitive games, without patches, that will run too slow at 386DX40 speeds, but will run too fast at 486DX4 100 speeds, and also won't run very well when throttled to 486 speeds. I could be wrong on that, but I expect the slice of games that fall under that category is very, very small.

Yeah, I didn't do as much extensive testing with the Nehemiah but I remember with the K6 it was a from a 486 DX33-ish speed straight to a Pentium and there are definitely games that are ideal for the DX-2 66mhz while a Pentium is too fast. Such games aren't unplayable on a DX-33 just noticeably less than ideal so it is an important speed-point that I go for. Performance-wise this is about 25 FPS in Doom... but of course GPU varies this. This leads something else we've discussed but not in depth.

When I play Might and Magic III: Isles of Terra on either K6 or Ezra at their slowest speeds - which I think was about a 386DX-25 if I'm remembering correctly -- many of the NPC animations moved way too fast. I never got someone to test this game on a real 386DX but I don't imagine it would've ran too quickly on this hardware back then. What it came down to is that even with this slow CPU speed the real 386 would've been running the graphics through an ISA bus... whereas I was running it through a PCI or AGP on a Voodoo 3... that makes a difference.