georgel wrote:

OFFTOPIC: is the RapidCAD's coprocessor working with the Ti486DLC?

Well, there is no coprocessor to RapidCAD? Isn't it just some piece of logic to make the mainboard believe that there is a separate co-processor?

Exactly. The actual FPU is a part of the main chip (RapidCAD-1). Which is essentially a 486DX. RapidCAD-2 that goes to the FPU socket is just a dummy part.

BinaryDemon wrote:

Kixs going the distance with the testing! I don’t think OP is going to get playable FPS on his Nexgen CPU, looks like he should invest in a 3D card.

I actually have no desire to play the Quake. If I had I would use one of my better chips for that. Like one of these from my wall art 😀

For me it is just a curiosity. I am working on a benchmarking project and would like to put Nx586 performance to a perspective. My estimation is that the NexGen sytem with a solid FP emulation can roughly match the performance of slower 387 part (at least roughly comparing Wheetstone results) and checking if I can gather any evidence about that.

BinaryDemon wrote:

...I don’t think OP is going to get playable FPS on his Nexgen CPU...

Well anyway I expected you to get some 6 FPS on Nexgen with Q87, not minutes per frame like some posters here suggested. Unfortunately no one here has made real tests (

Of course, nowadays everyone has better CPUs to run that software. I remember days when 386DX motherboards were sold for $2000 not to mention 387.

georgel wrote:

kixs wrote:

Quake crashes. Not EMM.

This is what you see and your conclusion is quite simplistic since you don't know what causes the crash! When quake runs there is a lot of underlying software that runs too: the BIOS and BIOS extensions, the DOS and its TSRs, the EMM (the PM hypervisor), Q87 (the hypervisor's extension), DOS4GW (The PM DOS extender that gets its memory from the EMM's pool and switches constantly between PM and RM via EMM's VCPI and provides flat memory PM context to quake while serving all quake's OS requests passing them to DOS/BIOS and other RM handlers that may be present in the system), and on top of these runs Quake. It's like a concert.

It's all been said about RapidCAD above...

It looks like this on the same motherboard I've tested Ti486DLC:

Here is about EMM. I've installed QEMM 9.01 and 386max 8.03.

QEMM: Quake crashes the same way as with EMM386 - see the last photo below
386max: Hangs/reboots when loading Q87X

And some screenshots:

PS:
I'm interested in benchmarks too... that's why I'm doing this 🤣

Well, if you like testing here are all versions of Q387 I bumped on throughout the years. If you find version that is not here, please let me know. Some of its earlier versions may behave better with quake.

mpe wrote:

Exactly. The actual FPU is a part of the main chip (RapidCAD-1). Which is essentially a 486DX. RapidCAD-2 that goes to the FPU socket is just a dummy part.

A 486DX without L1 Cache 🤣
They really crippled the Chip and killed off its performance..

Back in the Day you buy this one only for upgraded FPU Performance 😉

A bit OT. But thinking about the RapidCAD I am wondering what was the reason for it having no L1.

I can't think of any commercial/marketing reason. The RapidCAD was a niche retail product for Intel that never really competed with 486. If anything Intel would likely be happy to sell more $499 RapidCADs directly to consumers than $449 (or how much the DX-33 cost at volume in 1992) 486's to OEMs.

Was there some sort of compatibility issue with 386 motherboards? When first CPUs with L1 cache came in late 80s I remember concerns about self-modifying code etc. Cyrix who made some early 386->486 upgrade solution had problems with their tiny 1K L1 cache and they provided tools for disabling it.

georgel wrote:

Well, if you like testing here are all versions of Q387 I bumped on throughout the years. If you find version that is not here, please let me know. Some of its earlier versions may behave better with quake.

all_q387.rar

Thanks. Mission accomplished. That was what I needed.

I took the latest version from your archive, installed stock DOS 6.0 EMM, ran Q87X and Quake now runs on my Nx586-P90:

And results?

0.9fps (1122s). Almost exceeded the Q87 shareware demo grace period 🙁

At integer load (Doom) this CPU is roughly equivalent to P66-P75. These get about 20fps in Quake. 486DX-33 gets about 4fps.

So Quake needs the FPU for a reason 😀

0.9 FPS seems excessively bad. It’s probably worse but maybe try Tronix’s exe anyway?

BinaryDemon wrote:

0.9 FPS seems excessively bad. It’s probably worse but maybe try Tronix’s exe anyway?

Why? Software emulation of an FPU is always going to be a couple of orders of magnitude slower than a hardware pipelined FPU.

mpe wrote:

0.9fps (1122s). Almost exceeded the Q87 shareware demo grace period 🙁

Seems a bit weird that my 486SX2-80 is faster at 1.1 FPS (with max screen size) 😕

canthearu wrote:

BinaryDemon wrote:

0.9 FPS seems excessively bad. It’s probably worse but maybe try Tronix’s exe anyway?

Why? Software emulation of an FPU is always going to be a couple of orders of magnitude slower than a hardware pipelined FPU.

Just because kixs testing with an 486 SX2-80 was faster.

mpe wrote:

Thanks. Mission accomplished. That was what I needed. […]
Show full quote

Thanks. Mission accomplished. That was what I needed.

I took the latest version from your archive, installed stock DOS 6.0 EMM, ran Q87X and Quake now runs on my Nx586-P90:

0.9fps (1122s). Almost exceeded the Q87 shareware demo grace period 🙁

At integer load (Doom) this CPU is roughly equivalent to P66-P75. These get about 20fps in Quake. 486DX-33 gets about 4fps.

So Quake needs the FPU for a reason 😀

The file in this archive should be identical to the link I gave several days ago so it is unclear why it ran now and why you had problems before?
It is very odd that your nexgen performs worse than SX2-80. Are you sure that all caches are enabled and your motherboard fully enables them and supports this type of CPU?

I am not a game expert but as far as I know Doom and Quake use similar engines and have common roots. If Doom needs only integer CPU for 20 FPS then this statement is false:

mpe wrote:

So Quake needs the FPU for a reason 😀

Just for comparison q87 can be run on a machine that has FPU. This will effectively disable the coprocessor part and emulate it. Then one could compare results on one and the same CPU

Some more benchmarks:

Quake v1.06 Timedemo demo1, minimum screen size

With Q87X:
Am486SX/2-80: 1.7 FPS
Am486DX2/80: 1.7 FPS
Am486DX4/160: 3.4 FPS

With FPU:
Am486SX/2-80: /
Am486DX2/80: 16.4 FPS
Am486DX4/160: 26.4 FPS

What about the difference between Q87X and Q87? Or some of its earlier versions 3.xx?

Tried Q87 but it didn't disable FPU on Am486DX2/80. Didn't try it with DX4/160.

You haven't tried it properly. The mechanism of enabling emulation (e.g. disabling the FPU if present) is identical in both Q87 & Q87X.

I did it the same way as always. Will try again...

---

Tried again... unless it's as quick as FPU, Q87 doesn't disable it.

---

In NSSI, Comptest... it shows the fpu being emulated. Benchmarks show that also. But in Quake it runs as fast like the native FPU. On the other hand Q87X really disables FPU in Quake too.

Very interesting!!! Ok, I have a theory, maybe this is incorporated in the latest version of q87 4.13 and I have missed it...I have to check it first myself. Anyway the real results would be when no physical coprocessor is present like with your SX2-66 AMD CPU.