look at your spamfolder then.

> I'm sure a lot of apps will use this rather obvious technique
> to distinguish between 287, 387 and 486 math unit.

all my games like the fpu more or less, so they
don't seem to care too much about exact knowledge
about different fpu types

wd

Any older games would be written to the 8087 which was pretty compatible with the 80287 in terms of upwards compatibility.

The 387 is a completely different beast though. It was mostly compatible with earlier chips but has a few significant difference that could cause problems in some cases - infinity handling being one of the more important ones. 387 (and later) only has one of the two infinity modes implemented on 8087 and 287. This was due to a changes in the final form of the IEEE numeric specs. 8087 and 287 were designed prior to this spec being finalized.

From an instruction POV, 387 and 486 math unit are quite similar - *HOWEVER* - the first edition of the Intel 486 hardware ref had a small circuit design that was supposed to enable the 486 to mimic 386/387's exceptions and interrupt behavior.

Sadly, the circuit design Intel printed in the first 486 hardware ref was in fact BOGUS and didn't work right. Millions of 486 machines from a myriad of vendors were produced that incorporated this flawed circuit design. Some vendors (ex IBM) produced broken machines (250,000 bad ValuePoints that I personally an aware of) and correct machines (the PS/2's). It all depended on the particular design group. Some 486 machines from some vendors (ex Gateway) got this exception wiring so badly done that it was physically impossible to get some exceptions on their boxes because they didn't bother to hook the pin on the 486 up to anything! Just left it floating.

NPX using apps that came along during the 486 and later eras, unless they were doing the most mundane exceptions masked stuff, often had to sift through chip/NPX combinations to see if somthing was going to be permissible on the particular hardware.

If an app runs exceptions masked and takes all default results from the math unit, its probably not going to have an issue. If it needs to enable some NPX exceptions, then its gotta triage through much more configuration specific things.

Its really a miracle any PC (particularly B1-step 386's and any version 486) even booted at all given all scads of errata workarounds necessary in BIOS and various OS's to compensate for their myriad hardware bugs.

Don't forget the purpose of the dosbox project: to provide a way to run old dos games - nothing more.
I can't remember any dos game that required a coprocessor and it wouldn't have been the best idea for any game designer to do so, since the fpu was an addon until the arrival of the 486 and unlikely to find on any gamers pc...

Markus - I can think of one set of games that are an exception to this in particular, though it did not Require a coprocessor, Falcon 3.0, and its add-ons required a math-coprocessor in order to use its "Realistic" Flight Model.

Markus wrote:

Don't forget the purpose of the dosbox project: to provide a way to run old dos games - nothing more.
I can't remember any dos game that required a coprocessor and it wouldn't have been the best idea for any game designer to do so, since the fpu was an addon until the arrival of the 486 and unlikely to find on any gamers pc...

Quake, which is a DOS game requires a FPU. Many other FPS games, such as Dark Forces runs much faster with a FPU.

I just tried Falcon, it's playable with dosbox, but I doubt someone will ever seriously play it nowadays - it just looks too ancient compared to newer flight-simulators.
While it's still the same fun to play e.g. Space Quest and the like, you're spoiled once you have played a flight sim with 3d.

Quake isn't the best example either - who wants to play the dos version, when there are opengl versions? (You can even get the same old feeling with rendering set to GL_NEAREST and resolution to 320x200;-)
Dark Forces may run faster with fpu, but I've played it once on my old 286 without one and wasn't missing any additional speed. And don't think, it will run automatically faster on dosbox, if there is an emulated fpu.

And there aren't those many other FPS games, look at this:
http://www.mobygames.com/attribute/sheet/p,2/attributeId,115.

Mindscapes's USS Ticonderoga claims to want a 486DX on the box packaging.

Feh, Markus, I find that sentiment a little insulting I am a big Falcon 3.0 enthusiast. Yes, I like it more than Falcon 4, due to the infinately greater replayability. I've yet to find another Combat Flight Sim that offers Four different flyable jets, seven theatres of operations, accurate physics, and proper squadren/wingmate controls, all of which can run under Linux on a PIII/600. Yes, Falcon 3.0 is playable under Dosbox, but it feels like when you select "High Fidelity" Flight Model it is falling back to the Complex Flight Model, but then again, I never owned a 486DX, or a 387, so I can't really attest to the differences, but Falcon3 will fall back if it doesn't detect the Coprocessor.

OK, then I might have been wrong. And don't get upset because I dislike Falcon 3.0.
Here's a challenge: start Falcon AT on your PIII in pure dos, start with colonel rank and try to survive at least ten seconds;-)

'Fraid that'd be a tad difficult, due to the fact that I've got Linux on this bad boy, and don't have a copy of AT. 😀 I almost grabbed a copy for $2 at a second hand bookshop near Dallas when I was visitting there once about four years ago.