Robin4 wrote:

jesolo wrote:

It might have been a different story if Intel had released something like an "80288" CPU (with an 8-bit external data path).

Maybe this is a good opportunity for someone here on Vogons, who has a turbo XT, an NEC V20, V30 & a 6 or 8 MHz 286, to benchmark these CPU's, using some of the popular benchmark programs?

Which benchmarks to run?

I would guess some benchmarks that tests integer performance.
Perhaps Landmark Speed 2.0, Norton Sysinfo 6.0, NSSI 0.60?
However, some of these might not run on an XT. So, older versions of the above or older benchmark programs might be required.

This is purely as a matter of interest. I think it is already clear that a V20 will not outperform an AT 286.

I'm sure that System Information from Central Point does run on XT class machines, too.
It was installed on the XT clone I got. CheckIt! does also have a benchmark ability.
I think it uses the original IBM PC as a reference. My clone got a score of 99%.

And The Oldskool PC Benchmark: https://dosbenchmark.wordpress.com/

Last I tried topbench the results didn't line up with results from all the other benches I've run.

awgamer wrote:

Last I tried topbench the results didn't line up with results from all the other benches I've run.

As you can read on the topbench site, most early benchmarks are severely flawed.

The old benchmarks match up speed better in dosbox than topbench.

I'm confused now. 😕

awgamer wrote:

The old benchmarks match up speed better in dosbox than topbench.

How is DOSBox any kind of indication of speed?
It doesn't even try to make different instructions take different amounts of time. All instructions are 'one cycle'. Which is completely unrepresentative of how a real CPU works.
Try PCem, it's not super-accurate, but at least it tries to match every individual instruction to a certain amount of cycles, based on actual CPUs.

old benchmarks shows dosbox set at x cycles equal to pc/xt speed, run old 8088 games and they play at a reasonable speed. topbench show dosbox set at y cycles equal to pc/xt speed, run old 8088 games and their speed is off.

awgamer wrote:

old benchmarks shows dosbox set at x cycles equal to pc/xt speed, run old 8088 games and they play at a reasonable speed. topbench show dosbox set at y cycles equal to pc/xt speed, run old 8088 games and their speed is off.

Well, DOSBox' speed is off, that's the problem. In DOSBox, instructions like mul and div are the same speed as simple instructions like add/sub. On a real 8088, add/sub are orders of magnitude faster than mul/div.
DOSBox is so horribly inaccurate that even trying to bring it up in any performance-related scenarios is useless.
Many early benchmarks are equally inaccurate, and only test a very small subsection of the system's performance (eg Norton SI only tests a mul and a div, nothing else). So in some cases they might cancel eachother out, but two wrongs don't make a right.

Try PCem as I said, you'll see very different results.
Better yet, try real hardware.

You, Scali, hit the nail!

Last time I tried it pcem was 20% or so faster than it should be for xt, as a result one can get a more accurate result with dosbox because of its finer grain cycle setting where pcem only gives you presets.

awgamer wrote:

Last time I tried it pcem was 20% or so faster than it should be for xt, as a result one can get a more accurate result with dosbox because of its finer grain cycle setting where pcem only gives you presets.

Depends on what you mean by 'accurate'...
DOSBox allows you to accurately tune the speed, so if it's the speed of a game you want to control, then yes, you can do that more accurately.
However, if you are talking about how accurately DOSBox is actually emulating the hardware (and this is the case we're talking about with benchmarks... because benchmarks aren't representative for your game of choice), then the answer is: none.
There is software out there which can't be emulated accurately by DOSBox, because DOSBox makes some parts run much faster than on real hardware, while it makes other parts run much slower than on real hardware. So no matter how you try to adjust DOSBox' speed, you'll never get anything resembling the performance on real hardware (there are some demo captures on YouTube, where every part had to be captured separately in DOSBox, because they each required different speed settings. Then these parts were edited back together to create a video that resembles the demo on real hardware).

Accurately as I've described, games playing around the right speed vs not. Team DOSBox rarrrr!

awgamer wrote:

Accurately as I've described, games playing around the right speed vs not.

As I say, DOSBox can't play certain software, including games, accurately.
Especially with more complex stuff, such as 3d calculations in flight simulators etc, DOSBox is very inaccurate.
For a simple game like Commander Keen it won't matter as much. The speed is more or less constant throughout the game.

Which flight sims are you referring to that aren't working on DOSBox?

I remember my Dad and I upgrading his Olivetti M24 by replacing the 8086 CPU with a NEC V30. One of the most noticeable improvements was the fact that certain extra in-game animations would be active on the V30, which were disabled on the 8086.

I noticed this in Space Quest III and the <=16 color version of Monkey Island 1. For instance, in the SCUMM Bar scene of the latter game, a pirate would constantly be swinging back and forth on the chandelier hanging from the ceiling, when the game was running with the V30 installed. Before the upgrade, the chandelier would be hanging still without a pirate.

Apparently, these games had detection algorithms in them to enable certain details only in 286+ systems, presumably because enabling those extra animations would result in unacceptable performance on older machines. I wonder if those algorithms were simply based on the checking of the timing of a delay loop or if they checked if the CPU supported certain newer instructions or opcodes that the 8088 and 8086 CPUs lacked. The 80286 CPUs did not yet support the CPUID instruction, so that detection method was not yet available.

I guess an easy way to find out is if someone here with a V20 system could start up Monkey Island 1 on it and enter the SCUMM Bar. After all, I'm pretty sure that a 4.7MHz v20 would still be slower than an 8MHz 8086, like the one in our M24. If an opcode check was used, the extra animations would also be enabled on a V20. If a delay loop was used, A V20 would presumably still not meet the timing threshold, so the extra animations would still be absent. The SCUMM Bar scene is at the beginning of the game, so it's easy to test quickly without having to spend a long time to play through it first. Although I can imagine much more boring science experiments than replaying such an enjoyable game. 😉

By the way, I found this interesting article on CPU detection algorithms for older (pre-CPUID) CPUs: http://www.drdobbs.com/database/cpuid-algorit … -wars/184410005

Thanks for the link! I just asked Wayback to make a backup. 😁