The VIBRANT driver you enclosed is from 1995. Where is the latest 1997 driver pack? And is there any benefit to using it?

That's the latest one - go for it.
Apparently the developers worked with HW manufacturers to include support for upcoming graphics cards.
I see there hardware that was released throughout 1996 - or with other words - until the beginning of 1997.

Much appreciated for sharing the updated VIBRANT drivers. I was able to select my Diamond Speedstar64 and set it up for 1024x768x16bit. Rendering took 23 minutes at this resolution on a SXL2-66 with ULSI2-66. Is there a database to compare chevy results with?

In your thread, you noted in 3D Studio R3, that chevy took:

1 min. 53 sec. on an Am5x86-160 and
16 min. on an Am386 DX-40 w/FasMath.

though your resolution was 640x480.

thats probably because 3ds3 only renders in phong mode, while 3ds4 defaults to the more advanced metal mode.

I just re-read carefully what Feipoa wrote in his last reply and realized that i somehow completely misunderstood his message until now.
I am going to delete my last two replies so i don't confuse this thread.
Sigh ...

@Feipoa
I think that resolution of 640x480 is a good compromise between minimizing the time spent on rendering while getting good test samples. But up to you really.

pshipkov wrote:

@Feipoa
I think that resolution of 640x480 is a good compromise between minimizing the time spent on rendering while getting good test samples. But up to you really.

Use the VIBRANT drivers at 640x480 + the rendering at 640x480, or I can keep the VIBRANT drivers at 1024x768x16bit, but set the rendering size to 640x480? Also, does selecting a different format for the render, Tanga vs. bmp, for example, alter the render time?

These options won't affect render times.
For convenience, you can set the VIBRANT driver to the resolution you plan to render at, this way you won't have to adjust the settings every time before running a render.
You are using device driver to show pixels on screen, so file formats don't matter.
Hope these notes are helpful.

OK, I left the VIBRANT drivers at 1024x768x16bit and rendered at 640x480 (presumably at 16-bit colour depth?). Render time was 10 min. 45 sec.

Finally, some distinction!

Rendering chevy at 640x480x16bit using the TI486SXL2-66 and,

ULSI DX2-66: 10 min. 45 sec.
Cyrix FasMath (black-top) at 33 MHz: 11 min. 58 sec.

The ULSI would have saved you 1 min. and 13 seconds.

feipoa wrote:

Finally, some distinction! […]
Show full quote

Finally, some distinction!

Rendering chevy at 640x480x16bit using the TI486SXL2-66 and,

ULSI DX2-66: 10 min. 45 sec.
Cyrix FasMath (black-top) at 33 MHz: 11 min. 58 sec.

The ULSI would have saved you 1 min. and 13 seconds.

this is extremely fast, my 386dx-40 with fastmath took about 17 minutes to render a 640*480 image.
will you test the intel, iit, c&t and ulsi-dx fpus too?

~10%, dang !

Notice how misleading the initial LandMark tests are.
There ULSI and FasMath are 1% apart.

Quake indicated a 13.5% improvement.

feipoa wrote:

SXL2-66 + Cyrix FasMath-33 (black-top) ... Quake: 3.0 fps […]
Show full quote

SXL2-66 + Cyrix FasMath-33 (black-top)
...
Quake: 3.0 fps

SXL2-66 + ULSI DX2-66
...
Quake: 3.4 fps

But I suspect running the same benchmark with the SXL at 33 MHz would not yield 13.5% when using the ULSI DX2-66 over the FasMath-33.

So for the results thus far, it seems that the ULSI DX2-66 improved FPU results from 0-13%. Not exactly the 100% improvement a typical consumer would be expecting.

Do you consider the ulsi chip an upgrade, or native 386 class hardware ?
I am more interested in "clean" componenets in general, so trying to figure out if i should look into it eventually.
Thanks.

I don't know how to classify the ULSI DX2. Probably as a cancelled OEM FPU for the SXL2-66 or DRx2-66. The SXL was supposed to be OEM-only, so it was likely being put into new motherboards, probably for industrial use. The ULSI DX2-50 and IIT-2-50 were most likely targeting the SXL2-50. I suspect there was lack of motherboard development and support for the QFP144 and PGA-168 versions of the SXL2-66, so the ULSI DX2-66 was discarded. I've seen several NOS for sale of the PGA-168 SXL2-66, but have never seen one being sold on the accompanying motherboard.

I've never seen evidence that SXL CPUs were used in industrial hardware. I've only ever seen them used in upgrade kits, or PC compatibility cards for British PCs. The SXLC chips on the other hand probably made it into some laptops.

Neither have I; it is pure speculation. The basis for the speculation is a) OEM-only, b) an industrial supplier has all those NOS PGA-168 SXL2-66's for sale. I've never seen the PGA-168 SXL2 in an upgrade kit. Perhaps produced for an application-specific motherboard design because almost no 386/486 motherboards appear to have support for the SXL2-66 pin out.

noshutdown wrote:

this is extremely fast, my 386dx-40 with fastmath took about 17 minutes to render a 640*480 image.
will you test the intel, iit, c&t and ulsi-dx fpus too?

Yes, but on a different system. The PGA socket on the Mark V Baby Screamer is uncharacteristically tight. Also, it is difficult to remove while in the case, so I'll probably move the testing back to my ALI M1429-based 386.

On the Mark V Baby Screamer, I ran chevy with the ULSI-DX2-66 and the SXL at only 33 MHz and the result was 14 min. and 56 sec. I also ran it with Cyrix FasMath 33 and SXL-33 and the result was 15 min. and 40 sec.

From these results, then, using the ULSI DX2-66 on an SXL-33 offered a 4.9% improvement over the FasMath-33. Similarly, using the ULSI DX2-66 on an SXL2-66 offered an 11.3% improvement over the FasMath-33. So to get the most out of your clock-doubled FPU, it seems that a clock doubled ALU is required.

Is there a difference in Speed if used without Onboard L2 Cache ?

yes, huge.

@FEIPOA
Btw, the actual render times are not in the render dialog (gray background), but when Esc, then at the bottom of the screen -white text on cyan background. figured i should clarify that.
I welcome your intention to run the tests on a native 386 cpu+mobo, otherwise upgrade kits and stuff make these hybrid systems that tend to "blur the picture".