I am working with a 386 motherboard which has two oscillator slots, OSC1 and OSC2. OSC1 is for the main system bus and I assume OSC2 is for the FPU if you want to run it asynchronously from the CPU. There is a jumper to set when you want to run the FPU asynchronously.
If you have OSC1 at 80 MHz (CPU runs at 40 MHz) and OSC2 at 50 MHz (FPU runs at 25 MHz), then why are the FPU benchmark scores the same as when I run the system synchronously, that is, with just using OSC1 at 80 MHz? Is some circuit not setup properly on the motherboard?
Why do I want to run the FPU asynchronously? Because I am trying to get a system with a SXL2-50 running. With the SXL2-50, you run the CPU bus at 25 MHz using a 50 MHz oscillator. The SXL2 is clock doubled and runs at 50 MHz, but the FPU would only be running at 25 MHz. I would like to run the FPU asynchronously at 40 MHz using a 80 MHz crystal inserted into OSC2. As in the example above, the FPU scores of the FPU run at 40 MHz asynchronously are exactly the same as when it is run synchronously at 25 MHz. What am I doing wrong?
Plan your life wisely, you'll be dead before you know it.
If you use a late model intel FPU, it will almost certainly clock to 40MHz, and it has many of the enhancements that the Cyrix chips have. It's said Intel updated the core to reduce heat and to catch up to the competition. I've never compared the old/new intels but it would make for an interesting test.
I have one on order and am waiting for its arrival. I didn't order it for this project, but ordered it to see how it compares with Cyrix FPUs.
I have recently discovered that the grey top Cyrix FPUs, although a little faster than the newer black top ones, they have some incompatibilities. For example, if you are using a clock doubled CPU in clock-doubled mode, such as the SXL2 or the Cyrix DRx2, pcpbench will hang the system when you exit. At least it gives you a pcpbench score first. Similarly, if you are using a clock doubled CPU, you cannot run the quake benchmark if using a grey top. There are probably more incompatibilities, but these are the two I noticed recently. Using a DLC version of the Cyrix FPU or the black top does not exhibit this problem.
Plan your life wisely, you'll be dead before you know it.
I recommend also to read up on the different FPU descriptions as it shows where the incompatibilities are. Typically the software/benchmark/games struggle as they do not detect the FPU correctly and assume to have a certain feature set available...
I recommend also to read up on the different FPU descriptions as it shows where the incompatibilities are. Typically the software/benchmark/games struggle as they do not detect the FPU correctly and assume to have a certain feature set available...
That's so true. Reminds me of the early 386 boards with 287 sockets.
I always wondered how some software would react if it finds a 486 (486DLC) paired with an original i287 co-processor. ^^
The same is also true in reverse (old CPU+new FPU). The intel 287XL was basically an 387SX chip..
Additional features aside, there are some other differences between both of them.
Like the 2/3 thing and range of infinity. Wonder how sophisticated 286/287 software would react to 387 FPUs..
"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel
I'm not sure that the DLC will work with a 287. At least it when I tried a Make it 486 (SLC) in my original AT, it did not function with the 287XL (technically a 387SX internally). Can't remember if the system refused to POST, or if the FPU was just not detected.
I recommend also to read up on the different FPU descriptions as it shows where the incompatibilities are. Typically the software/benchmark/games struggle as they do not detect the FPU correctly and assume to have a certain feature set available...
An interesting read. I didn't read all of it, but some. The author didn't get into the 87DLC FPU at all, nor the the clock doubled ULSI FPU. The use of a Weitek 3167 sounds interesting, although their use is application specific. "In benchmark comparisons, the Weitek 3167 provided up to 2.5 times the performance of an Intel 387DX coprocessor." I was left wondering if there were any mp3 decoders compiled specifically for use by a Weitek.
This was interesting and made me wonder how do we know if the L1 is being flushed unnecessarily.
1In existing 386 systems, DMA transfers (e.g., by a SCSI controller or a soundcard) may cause the 486DLC's entire on-chip cache to be flushed, since no other means exist to enforce consistency between the cache contents and main memory. This reduces the performance of the 486DLC in these cases. The 486DLC on-chip cache does, however, allow specification of up to four non-cacheable regions, which is particularly useful if your system has memory mapped peripherals (e.g., a Weitek coprocessor).
This was interesting. I wonder if this is related to the issue I am having using the older grey-top Cyrix FPUs with the SXL2 when exiting PCPBench (only an issue if the SXL2 is clock doubled).
1The IIT 3C87, the Cyrix 83D87 (chips manufactured prior to November 1991), and the Cyrix EMC87 should not be used with the 486DLC, since they may cause the computer to lock up if the FSAVE and FRSTOR instructions are used. (These instructions are typically used in protected mode multiple task environments to save and restore the coprocessor state for each task. Note that Microsoft Windows also fits this description.) According to Cyrix, this problem occurs only with first revision 486DLCs (sample chips) and is fixed on newer ones.
There was also mention of a Chips & Technologies 38600DX CPU as a replacement for the Intel 386DX, said to be 100% compatible. I've never seen one of these, have you?
Plan your life wisely, you'll be dead before you know it.
Interesting, I also heard of compatibility issues with certain x87's (ULSI ?) and Windows 3.1.
As far as I know, there also exists a co-processor related patch for Windows v3.10.
No idea, if this applies here, but the patch was meant for 387-class math co-pros.
"The enclosed WW0548 disk contains a revised Windows WIN87EM.DLL file.
You must be using Windows version 3.1 to use this dynamic-link library
(DLL) file. If you have a version of Windows earlier than 3.1, you do
not need to replace your current WIN87EM.DLL file. You also do not
need to replace your WIN87EM.DLL file unless you are using the Intel
80387 math coprocessor. The Intel 80486DX and 80486DX2 processors do
not require the new file."
"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel
C&T 38600DX is out there. Not impossible to find, but these days a little expensive due to collectors. Probably not worth the effort. There's also a version of that chip with 512 bytes of internal cache, but it uses a proprietary pin arrangement and motherboard. Never seen one before.
Non-Intel FPU simply ignore the selection signal and always use CPU clock - which, AFAIK, has to be always present to have the bus/io at the same speed, after all the CPU has to be able to transfer data and instructions in and out of the FPU.
So that 25MHz FPU might simply be overclocked now. A good way to test would be to move the jumper from sync to async and benchmarking the FPU - it should have lower performance on async setting.
Somehow I doubt they can ignore anything, especially if they clocked by a different oscillator.
Intel387 TM SX MATH COPROCESSOR datasheet, 1.1 Pin Description Table:
CKM - input - CLOCKING MODE is used to select synchronous or asynchronous clock modes.
CPUCLK2 - input - CPU CLOCK input provides the timing for the bus interface unit and the execution unit in synchronous mode.
NUMCLK2 - input - NUMERICS CLOCK is used in asynchronous mode to drive the Floating Point Execution Unit.
