rasz_pl wrote:

That would be $594 June 1997. 1996 was $599 non MMX 200MHz, $84 K5-PR100 and ~$150 Pentium 100MHz. The game worked well only on […]
Show full quote

canthearu wrote:

Nah, it was likely that targetting Intel's pipelined FPU was the only way to reach decent overall performance on processors of the day.

At least this way, the game worked pretty OK on most computers of the day. In mid 1996, when Quake released, the Pentium 233 MMX was Intel's top of the line mainstream processor

That would be $594 June 1997. 1996 was $599 non MMX 200MHz, $84 K5-PR100 and ~$150 Pentium 100MHz. The game worked well only on Intel computers for over a year, and even after that you needed >$250 K6 to get close to <$100 Pentium speeds.

canthearu wrote:

however, most people would be running systems much slower than that.

Between the choice of having Quake run well only on Intel Pentium Processors, and crap elsewhere, vs having it just run like crap everywhere, the first option was the best.

Im talking about shipping two code paths, something ID did later anyway in Quake 3. There was a chance for no fpu version running decently(20fps) on non Intel 100MHz CPUs (K5/Cyrixes), maybe even fastest socket 3 ones.

fixed point certainly can be done, consider Atari Falcon (Motorola 68030 @ 16 MHz; Motorola 56001 @ 32 MHz) running Quake engine at ~6-10fps https://www.youtube.com/watch?v=hDXSMgW-r5M
https://www.youtube.com/watch?v=WpwlZgQPCpk&l … 3Ww_M5nMm10m0UM

A couple of points gai:
a) The K5 released only a few months before the release of quake, and initially at very slow speed (PR75 anyone). This would not have realistically been enough time to write a new 3D engine pipeline for quake to re-optimize for non-pipelined FPUs.
b) The K5 processor is very, very rare, especially just after release in 1996. ID software isn't going to spend valuable time to support 0.01% of processors, especially processors in the low end of the market, which are less likely to be used for gaming and also more likely to use pirated software.

The Fixed point renderer for the atari is certainly very impressive, but offers much poorer quality output then the renderer that ID software implemented. You can see sparkling in the texture mapping and there are the occasional z-buffering error like the door texture during the middle of the video.

@feipoa - just hit tab after the rendering finishes!

alvaro84 wrote:

@feipoa - just hit tab after the rendering finishes!

OK, I'll try it out. If it fails, then I'll have to install 20.0.

What system & CPU was ID using during the initial development of Quake? P166?

Feipoa,

Excellent thread, I'm looking forward to seeing new benchmarks... hopefully they may show the DX-2 66MHz in a different light.

Interesting to see how the ULSI DX2-66 compares with the rest, I knew performance wasn't great but i'm surprised to see that running it in tandem with a clock doubled CPU makes not too much difference... here's hoping it is just the program not liking the clock double feature!

I saw on an italian website, a RapidCAD running in tandem with other FPU's, like a Weitek and a Fasmath. Not sure if this will cause probs for the RapidCAD or if both working in tandem is actually possible or not, or what performance is like. I think it was this guy: - https://www.youtube.com/watch?v=wAT7hbIOhgg .... they also have a website displaying all sorts of oddball era hardware which is where I saw the combination used.

I managed to find a couple of 3167 Weiteks @ 33MHZ... both currently sitting on two daughtercards in the Systempro... still haven't got around to learning UNIX to put them to good use, but is on the list of projects.

feipoa wrote:

Phido wrote:

I wrote some quick basic code that benchmarked some FPU instructions, depending on the FPU make, some were twice as fast as others. Even though basic is quite a high level language and each math operation would be padded with a dozen other instructions, and NOP's as the whole compiler X87/X87 emmulation at run time trick.

Can I test it?

Sure. However, my 386 is currently packed away, it will be a little while, I will come back to this thread and post it. I'll dress it up so it can be a useful benchmarking tool rather than my own personal exploration tool for FPU's.

386_junkie wrote:

I saw on an italian website, a RapidCAD running in tandem with other FPU's, like a Weitek and a Fasmath. Not sure if this will cause probs for the RapidCAD or if both working in tandem is actually possible or not, or what performance is like. I think it was this guy: - https://www.youtube.com/watch?v=wAT7hbIOhgg .... they also have a website displaying all sorts of oddball era hardware which is where I saw the combination used.

That was a pretty interesting video. The 3167 appears to be about 75% faster than the RapidCAD in the particular application this user was using.

I have run a few more tests. I tried using AutoCAD R12 to render a sample 3D drawing, e.g. nozzle3d.dwg. Unfortunately, both the i387DX amd Cyrix FasMath (black-top) complete this task in 33 seconds, +- half a second. Nozzle3D was one of the samples that took longer to render.

I then played around with a few more fractals from fractint. Manzpower and spinder took the same time to load on the FasMath, the ULSI DX, and i387. Lorenz3D3 was a little different though with:

FasMath = 1 min and 10.08 sec
ULSI DX = 1 min and 9.59 sec
i387DX = 1 min and 12.72 sec

Not exactly ground breaking. The i387DX was, as expected, the slowest but I expected the FasMath to be faster than the ULSI DX.

I also tried running Roy Longbottom's Linpack for double precision, LINPCOD, but all 3 FPU's scored 0.49 Mflops. I also ran,

ByteMark32 (results are an index value for floating point operations, where 1.00 is for a P90)
FasMath = .058558
ULSI = .053007
i387DX = .047281

NSSI
FasMath = 5103 Kwhetstones/s
ULSI = 4969
i387DX = 4863

Roy Longbottom's WHETCOD
FasMath = 5.183
ULSI = 4.409
i387DX = 3.961

With Landmark, the Cyrix FasMath (black-top) performed 24% better than the i387DX; with WHETCOD, the FasMath performed 31% better than the i387DX; with ByteCPU, the Fasmath performed 24% better than the i387DX; with NSSI, the FasMath performed 5% than the i387DX; and with select Fractint fractals, the FasMath performed 4% better than the i387DX.

What VGA card are you using? Some programs that draw a lot on the screen (and that possibly includes fractint as well if it uses BIOS rather than hand-crafted assembly to output pixels) will flatten the scores due to screen output code taking tons of CPU time. As for AutoCAD it's possible it was desiged to work with 287 as well and maybe even contains earlier code for the 8087, so it kills performance by overusing FWAIT too much.

Well, as far as I know, R11 of AutoCAD requires a 386 or better. They even call it AutoCAD 386. Interestingly, R12 is a lot faster than R11, e.g. when opening Site-3D.dwg. You can check it out too if you wish, Autodesk AutoCAD R12 DOS (found at WinWorldPC)

I'm using an ISA-based Cirrus Logic GD-5434, branded as the SpeedStar64. In Fractint and AutoCAD, I have it set for 1024x768x256c

feipoa wrote:

Well, as far as I know, R11 of AutoCAD requires a 386 or better. They even call it AutoCAD 386. Interestingly, R12 is a lot faster than R11, e.g. when opening Site-3D.dwg. You can check it out too if you wish, Autodesk AutoCAD R12 DOS (found at WinWorldPC)

I'm using an ISA-based Cirrus Logic GD-5434, branded as the SpeedStar64. In Fractint and AutoCAD, I have it set for 1024x768x256c

As far as i'm aware, AutoCAD 13 is the last version that can be used with a 386 / Win 3.11... I could be wrong, but I distinctly remember 13 was the last version able to do what I am hoping to do with the RapidCAD set. What would be rather excellent, would be if the Weitek 3167 can be used with AutoCAD. This would be extremely convenient, and would lessen the dependency on having to fully follow through and learn code like UNIX in full.

Ultimately, I hope to test the Weitek 3167 for performance, ideally both of them in the Systempro together simultaneously... though if not, standalone in a separate system.

Oh, and as I have a soft spot for Weitek... in the standalone system, i'll be looking to use Weitek based graphics adapters, one for ISA bus;

... and this 4MB VLB based card... both tested in the same system that has an EMC socket.

Not much difference in performance between DOS versions of ACAD 12 and 13. R12 is little "lighter" and a bit faster.

Anyone knows of a program that supports Cyrix EMC87? I'd like to test it in a "real world".

feipoa wrote:

Well, as far as I know, R11 of AutoCAD requires a 386 or better. They even call it AutoCAD 386. Interestingly, R12 is a lot faster than R11, e.g. when opening Site-3D.dwg. You can check it out too if you wish, Autodesk AutoCAD R12 DOS (found at WinWorldPC)

I'm using an ISA-based Cirrus Logic GD-5434, branded as the SpeedStar64. In Fractint and AutoCAD, I have it set for 1024x768x256c

yeah i think thats one of the fastest isa video cards in the world, i have one from stb.

feipoa wrote:

I have run a few more tests. I tried using AutoCAD R12 to render a sample 3D drawing, e.g. nozzle3d.dwg. Unfortunately, both the i387DX amd Cyrix FasMath (black-top) complete this task in 33 seconds, +- half a second. Nozzle3D was one of the samples that took longer to render.

..AutoCAD, I have it set for 1024x768x256c

I would guess Autocad uses FPU per primitive (lines/polylines, no splines in r12) and such a high resolution dwarfs any fpu advantage by spending most of the time drawing the lines?

rasz_pl wrote:

I would guess Autocad uses FPU per primitive (lines/polylines, no splines in r12) and such a high resolution dwarfs any fpu advantage by spending most of the time drawing the lines?

It took only 1.5 seconds less to render the drawing if I use 640x480x256c as opposed to 1024x768x256c.

After resisting for a loooong time, only being a passive reader, I had to register now - this is way too interesting not to be a part of 🤣

So, how is the used 486SXL performance-wise in comparison to a "clean" 386 cpu? Would the difference between fpus maybe be greater if the cpu was less powerful? I assume that the reason for choosing the 486SXL is because it is the most performance to get in a 386-socket? I know it would give the RapidCAD an unfair advantage, since it is more 486-like, but I would suspect that the 387's were all meant to upgrade 386's?

Welcome to the forum!

H3nrik V! wrote:

So, how is the used 486SXL performance-wise in comparison to a "clean" 386 cpu?

Do you want the SXL compared against the AMD DX40 or Intel i386DX? I can give Doom a quick run.

H3nrik V! wrote:

Would the difference between fpus maybe be greater if the cpu was less powerful?

I cannot say for certain, but I suspect not.

H3nrik V! wrote:

I assume that the reason for choosing the 486SXL is because it is the most performance to get in a 386-socket?

You can put a regular 486 into a 386 socket using a Transcomputer. download/file.php?id=32749&mode=view

H3nrik V! wrote:

I know it would give the RapidCAD an unfair advantage, since it is more 486-like,

The absense of L1 cache on the RapidCAD made regular CPU operations rather disappointing. See the CPU bar on the Landmark charts.

H3nrik V! wrote:

..but I would suspect that the 387's were all meant to upgrade 386's?

Would the socket option on i486SX systems accept a FasMath? I haven't experimented much with this.

feipoa wrote:

H3nrik V! wrote:

So, how is the used 486SXL performance-wise in comparison to a "clean" 386 cpu?

Do you want the SXL compared against the AMD DX40 or Intel i386DX? I can give Doom a quick run.

I ran DOOM and Landmark v2 with an SXL-33 and i386DX-33 on the same system (Cyrix FasMath, black-top). For comparison, I also ran the RapidCAD.

In Doom, the SXL scored 9.79 fps and the i386 scored 6.08 fps; so, a 61% increase. For comparison, the RapidCAD scored 6.99 fps.

In Landmark, the SXL scored 107 for CPU and 147 for FPU. The i386 scored 51 for CPU and 115 for FPU, so an increase of 110% CPU and 28% FPU.

both sxl and rapidcad are 486-class kernels stuffed into package of 386. however, the rapidcad has internal cache removed and the sxl without fpu.
as a result, rapidcad has fastest fpu on a 386 board, while the sxl has faster integer performance.

feipoa wrote:

I ran DOOM and Landmark v2 with an SXL-33 and i386DX-33 on the same system. […]
Show full quote

feipoa wrote:

H3nrik V! wrote:

So, how is the used 486SXL performance-wise in comparison to a "clean" 386 cpu?

Do you want the SXL compared against the AMD DX40 or Intel i386DX? I can give Doom a quick run.

I ran DOOM and Landmark v2 with an SXL-33 and i386DX-33 on the same system.

In Doom, the SXL scored 9.79 fps and the i386 scored 6.08 fps; so, a 61% increase.

In Landmark, the SXL scored 107 for CPU and 147 for FPU. The i386 scored 51 for CPU and 115 for FPU, so an increase of 110% CPU and 28% FPU.

Yeah, what I was actually curious of is whether the drastically higher Integer performance of the CPU affected the benefit of using the FPU - especially taken into account the very little speed increase you see from the clock-doubled FPUs with the 486SXL. i.e. is the SXL so fast that the actual idle time is what equals out the difference between FPUs. Hope it makes sense? 🤣

This is the site I was talking about... a Rapidcad used with a Weitek... at the same time!

http://www.cpu-museo.it/fpu/rapidcad_3167/rapidcad_3167.html