athlon-power wrote on 2021-02-12, 03:15:

why wouldn't the developers code in support for copros?

I believe the short answer to that is that, prior to the 486DX and later CPUs that included a floating point unit, one would have had to pay extra to get that functionality . Outside of people working with specific applications (CAD, 3D modeling, certain scientific/research applications, maybe spreadsheet power users, etc), there was practically no one who actually had a an x87 co-processor installed . Consequently, from a developer's point of view, it made very little sense to devote resources to code/optimize for a piece of hardware that hardly anyone had .

darry wrote on 2021-02-12, 03:26:

athlon-power wrote on 2021-02-12, 03:15:

why wouldn't the developers code in support for copros?

I believe the short answer to that is that, prior to the 486DX and later CPUs that included a floating point unit, one would have had to pay extra to get that functionality . Outside of people working with specific applications (CAD, 3D modeling, certain scientific/research applications, maybe spreadsheet power users, etc), there was practically no one who actually had a an x87 co-processor installed . Consequently, from a developer's point of view, it made very little sense to devote resources to code/optimize for a piece of hardware that hardly anyone had .

But i've heard that SimCity can benefit from a copro if its installed

And few games add a math co speedup option. Falcon 3.0 comes to mind. It had better graphics. But yes Quake was the "killer" app for all no integrated Co-PRO computers.(Really only for Pentium) ... Well it killed Cyrix in the process. 😁

But yes, 8088 8086 286 had then for scientific and professional use only. even 386.

PS. Yes simcity tooo....

Short answer money
If you set your system requirements too high you exclude too many people and limit your sales/profit.
Good number of machines didn't have any FPU capability so you optimise your code around that limitation. Now you have to ask is it worth investing more time into adding support for limited users.
SimCity and Falcon 3.0 did, everyone else played it safe and just relied on clock speed.
Good chance anything that has minimum requirement of a DX chip is using FPU

You can see the same thinking with 3D graphics
Software rendering is the base standard, more and more games started to include hardware acceleration as it became more widespread. Graphics also have the bonus of been more sexy , a game with good looking screenshots sells better then a bullet point saying runs better with co-pro installed

I think that support for FPU also depends on the tools used to create the game.
See eg. Scorched Earth - mostly written in Borland C++, which means that FPU support is added automagically if only there are any floating-point variables.
On the other hand, there are games written mostly (or exclusively) in Assembler - in this case adding FPU option would require extra work.

I also wondered as to why developers didn't support them.
I assume they were either too lazy or to ignorant.

Back in the mid-80s, many floating-point emulators existed.
They usually came in TSR form and targeted 286+ PCs.

Software usually wouldn't even tell real 8087 and emulated one apart.

Well, maybe, they didn't include floating-point support because of overhead reasons.

Turbo-Pascal and many othet compilers had FPU support.
They also included floating-point emulation code, in case no real FPU was found.

Because math co-pros cost like $2000+ back in the day.
They were nearly as much as an entire computer.

No developer wants to lock people out of a game for not having a $2000 piece of equipment with limited functionality and little or no real-world use in games.
*cough*RTX*COUGH*

Come to think of it...

Even with an FPU, floating-point instructions are slower than integer instructions, right?
Floating-point is only good when precision is important.
And games weren't about precision, games were about speed - so it was all based on simplified, integer-only math.

Grzyb wrote on 2021-02-12, 22:48:

Come to think of it... […]
Show full quote

Come to think of it...

Even with an FPU, floating-point instructions are slower than integer instructions, right?
Floating-point is only good when precision is important.
And games weren't about precision, games were about speed - so it was all based on simplified, integer-only math.

Yes and no,
"In computing, floating-point arithmetic (FP) is arithmetic using formulaic representation of real numbers as an approximation to support a trade-off between range and precision. For this reason, floating-point computation is often found in systems which include very small and very large real numbers, which require fast processing times. A number is, in general, represented approximately to a fixed number of significant digits (the significand) and scaled using an exponent in some fixed base; the base for the scaling is normally two, ten, or sixteen. A number that can be represented exactly is of the following form:"

floating point math can be faster than an interger based operations when dealing with very big numbers, the issue is size of numbers your adding up ect if im understanding it correctly. ALU's could do floating point math but they couldn't do it fast, and it took alot longer to process those numbers on an ALU than on an FPU. So if you had to work with very large numbers an FPU was always faster, it just wasn't needed for alot of things back then in games because they wern't dealing with significant numbers and the ALU could do the math acceptably, but once games got complex enough they swapped over. I'd image Quake forced to run its math on ALU only would be slow, likely would make a powerpoint have a higher framerate.

candle_86 wrote on 2021-02-12, 23:01:

I'd image Quake forced to run its math on ALU only would be slow, likely would make a powerpoint have a higher framerate.

Joke's on you, somebody's already forced Quake to run on an ALU. It actually runs quite well, very smooth gameplay, I think the ALU is actually better for Quake than an FPU.

Don't believe me?
https://www.youtube.com/watch?v=Tn9wRCEZ9E0

Anyways, what I'm getting from here is that they were too expensive and developers didn't want to waste time adding support for a feature that would most likely not be used. I wonder if there's any mods that allow games like DOOM to take advantage of a math copro. If somebody can force Quake to run on an ALU, somebody can force DOOM to use a decicated copro.

I remember a text file called the 'co-processor faq' which used to be distributed on Usenet. Did anyone here save a copy? It explained all of this stuff in great detail.

athlon-power wrote on 2021-02-13, 02:24:

Joke's on you, somebody's already forced Quake to run on an ALU. It actually runs quite well, very smooth gameplay, I think the […]
Show full quote

candle_86 wrote on 2021-02-12, 23:01:

I'd image Quake forced to run its math on ALU only would be slow, likely would make a powerpoint have a higher framerate.

Joke's on you, somebody's already forced Quake to run on an ALU. It actually runs quite well, very smooth gameplay, I think the ALU is actually better for Quake than an FPU.

Don't believe me?
https://www.youtube.com/watch?v=Tn9wRCEZ9E0

Anyways, what I'm getting from here is that they were too expensive and developers didn't want to waste time adding support for a feature that would most likely not be used. I wonder if there's any mods that allow games like DOOM to take advantage of a math copro. If somebody can force Quake to run on an ALU, somebody can force DOOM to use a decicated copro.

Well, you could ask the guy who did some of the heavy coding for Quake (Michael Abrash), or short on that, read relevant passages from his book regarding fixed point math, vintage floating point hardware and old game engines ->

https://www.jagregory.com/abrash-black-book/# … r-real-time-3-d

This is from Michael Abrash’s black book on 3D programming, and he outlined why Quake uses an FPU instead of ALU/fixed point math. The argument boils down to something like this:

- FPUs are getting cheap/free once you get to the 486DX

- The FPU in the Pentium is finally fast enough to be useful for real-time use thanks to its pipelined design (this is probably the more important point).

- Fixed point math libs are generally a pain to work with - the fixed radix/mantissa setup is based on specific needs and can be a cause of weird bugs. If you are good with the heavy math and can shoehorn one in place for a game engine (which is done on hardware without FPUs or ones where the FPUs aren’t performant like the Nintendo 64/PSOne/Nintendo DS ports of Quake/Quake 2, so no surprise that it’s done) it’ll probably work and work well. But that’s only if someone is being paid to deal with constrained hardware. That’s probably the original assumption for games like Wolf3d/Doom when their target is either a 386DX or 486SX (where the presence of an FPU cannot be guaranteed).
Of course, the Doom source is out for years now. Someone likely did recompile/port Doom to use an FPU. Not sure if you’ll see much difference in performance if you send it to the FPU, though. Once you get to a Pentium II with fastvid MTRR support and a solid GPU, most DOS versions of doom will run at hundreds of FPS per second already even with the ALU.

- If the PC industry is going to offload the rendering pipeline from the CPU to dedicated hardware, the 3D hardware will use floating point instead of whatever fixed point math setup you have (although OpenGL ES 1.x does have a fixed-point math profile for hardware without hardware FPU support).

That being said, using the integer/ALU for game rendering instead of depending on an FPU is...surprisingly long-lived. The Nintendo GameCube/Wii used integer math for GPU stuff..which was one of the reasons why Dolphin (The NGC/Wii emulator) abandoned DirectX9 for rendering in current releases.

https://dolphin-emu.org/blog/2014/03/15/pixel … ssing-problems/

athlon-power wrote on 2021-02-13, 02:24:

Joke's on you, somebody's already forced Quake to run on an ALU. It actually runs quite well, very smooth gameplay, I think the […]
Show full quote

candle_86 wrote on 2021-02-12, 23:01:

I'd image Quake forced to run its math on ALU only would be slow, likely would make a powerpoint have a higher framerate.

Joke's on you, somebody's already forced Quake to run on an ALU. It actually runs quite well, very smooth gameplay, I think the ALU is actually better for Quake than an FPU.

Don't believe me?
https://www.youtube.com/watch?v=Tn9wRCEZ9E0

Anyways, what I'm getting from here is that they were too expensive and developers didn't want to waste time adding support for a feature that would most likely not be used. I wonder if there's any mods that allow games like DOOM to take advantage of a math copro. If somebody can force Quake to run on an ALU, somebody can force DOOM to use a decicated copro.

I played with the noFPU Quake last year and it runs like sh!t 🤣

This is the thread:
Quake without FPU

Grzyb wrote on 2021-02-12, 22:48:

Come to think of it... […]
Show full quote

Come to think of it...

Even with an FPU, floating-point instructions are slower than integer instructions, right?
Floating-point is only good when precision is important.
And games weren't about precision, games were about speed - so it was all based on simplified, integer-only math.

You think of FractInt, the famous Mandelbrot generator, don't you? 😉
It's written in 32-Bit assembly and uses integers favorable..

FPU instructions are usually executed very quick (few cycles) , because an FPU is very good at math.

Normal processors are very bad at mathematics, actually.
They are not "computing", but rather compairing on a logic level. AND, NAND, OR, XOR etc.
A classic ALU (a main part of a CPU) can only know two types of calculation. Addition (+) and subtraction (-).
Any other type, like multiplication (* or x) and division (: or /) must be implemented using these two.

Anyway, many math teachers at school either not know that or tend to forget it (for ages).

Equally ironic is the fields of programming, also.
People good in math are not necessarily very good in programming.
Math teachers argue how good these people /pupils are in logical thinking and that they fit the computing business so very well.

However, language and writing skills are actual more required.
Unless someone works in machine language, programs are being written.
People good in grammar or language/communications may benefit here.
(Also, the foundation of modern technology, the radio/wireless technology, was all about music/communications.)

I guess that's why in the past many women also successfully operated mainframes or entered data on the terminals, despite the stereotypic "women are bad at math" thing. 😉

Re: Software for testing math-co (8087) ?

DNSDies wrote on 2021-02-12, 19:14:

Because math co-pros cost like $2000+ back in the day. They were nearly as much as an entire computer. […]
Show full quote

Because math co-pros cost like $2000+ back in the day.
They were nearly as much as an entire computer.

No developer wants to lock people out of a game for not having a $2000 piece of equipment with limited functionality and little or no real-world use in games.
*cough*RTX*COUGH*

That's true, but there was a market of free and cheap FPU software emulators, too.
The same floating-point code written for the real thing was able to run on these emulators.

And even if no FPU was available, many compilers had an FPU option that would include an 8087 emulation that would kick in automatically in case no FPU was installed.

Also, at the time, say '86/'87, it was foreseeable that FPUs would either drop in price or would become standard in the near future.
The 80486 was released in '89, but rumors of it's specs or a roadmap surely must have been cycling around for 1-2 years already.

FPU emulators..
For example, EM87 was public domain.
You could either get a copy of it from your computer dealer for a low price (say $5) or for free off a mailbox system/BBS, CompuServe, Fidonet, an university's database at the other end of the world via an X.25 connection.

Re: What are GOOD PC emulators ?

And then there were commercial FPU emulators. Like Franke387, which used 32-Bit code and was very fast.
Sometimes even outperforming 16-Bit FPU emulation code or floating-point libraries found in big compilers.
Yes, it did cost money (demo was available).
But not $2000, but more like $200.
And it surely made CAD/CAM programs, even the free/cheap ones, a noticeable bit quicker.

Errius wrote on 2021-02-13, 02:29:

I remember a text file called the 'co-processor faq' which used to be distributed on Usenet. Did anyone here save a copy? It explained all of this stuff in great detail.

http://www.cpu-collection.de/info/copro16a.txt

^This one? 😀

Jo22 wrote on 2021-02-13, 11:36:

Errius wrote on 2021-02-13, 02:29:

I remember a text file called the 'co-processor faq' which used to be distributed on Usenet. Did anyone here save a copy? It explained all of this stuff in great detail.

http://www.cpu-collection.de/info/copro16a.txt

^This one? 😀

That's it, thank you.

Errius wrote on 2021-02-13, 12:54:

Jo22 wrote on 2021-02-13, 11:36:

Errius wrote on 2021-02-13, 02:29:

I remember a text file called the 'co-processor faq' which used to be distributed on Usenet. Did anyone here save a copy? It explained all of this stuff in great detail.

http://www.cpu-collection.de/info/copro16a.txt

^This one? 😀

That's it, thank you.

You're welcome! ^^