MSxyz wrote on 2024-02-16, 15:00:

Unfortunately, most of the old DOS diagnostic software I have requires at least a 386 to run, so I can't check bus speed, memory transfer speed and other aspects to confirm (or disprove) my sentiment about this build.

Does anybody know where I could find some older system info/benchmark software than can be run on pre 386 machines?

Would any of this be of use to you?
https://www.philscomputerlab.com/dos-benchmark-pack.html

bartonxp wrote on 2024-02-16, 15:55:

MSxyz wrote on 2024-02-16, 15:00:

Unfortunately, most of the old DOS diagnostic software I have requires at least a 386 to run, so I can't check bus speed, memory transfer speed and other aspects to confirm (or disprove) my sentiment about this build.

Does anybody know where I could find some older system info/benchmark software than can be run on pre 386 machines?

Would any of this be of use to you?
https://www.philscomputerlab.com/dos-benchmark-pack.html

I have the latest Phil's pack already, but most programs won't run because they need at least a 386 🙁

Aside from Landmark 6 and Norton System Info 8 I don't have atm other benchmarks that seem to run on this machine.

I used this on a 286-- https://winworldpc.com/product/checkit/30

This is a good thread to look at: Kixs's 286 to the Max

MSxyz wrote on 2024-02-16, 15:00:

I was expecting somehow... better performance. The FPU particularly seems to run at 2/3 of the CPU speed. I know 287s are supposed to work like that, but I thought that later chips and most clones ran in sync with the CPU, right?

The Intel 80287 requires a 33% duty cycle clock signal at its operating frequency. This signal is typically generated by dividing the master clock of the mainboard by three (e.g. using the Intel 8284 clock/ready generator chip). On the other hand, the 80286 requires a 50% duty cycle at twice its operating frequency. Typically, the master clock of the board is used directly at this point. So a 286 at 20MHz has a master clock of 40MHz, and the 287 receives this clock divided by 3, resulting in 13.3MHz. As this clock division happens on the board, the 80287 is unable to do anything about the fact that it just receives a 13.3MHz clock signal. If your mainboard provides a clock generation circuit for the 80287 that is independent from the 80286 clock at 40 MHz, the chip could be clocked higher or lower. I would have expected at least 13MHz for the 286 if it is clocked at 40MHz/3, so possibly your board indeed has a dedicated 287 clock generation circuit that provides it with 12MHz derived from an 36MHz clock source, to allow synchronous operation with a 12MHz host processor. Looking at your image, I see an IIT 80287 clone. These clones are supposed to have a better clock efficiency as the 80286, so it looks like the clock of that processor is not even 12MHz. Check the configuration possiblities for the 287 clocking provided by your board.

Indeed, you are correct that there is a later coprocessor for the 80286 that compensates for this "issue". The Intel 80287XL has in internal PLL that generates a core clock at 3/2 of the the clock input, which will result in a clock at the same speed as the processor. This clock is not necessarily "synchronous" in the strict sense of the word, because the phase relation between the 286 clock and the 287XL clock is not well defined. I don't think any other 287 compatible chip includes a PLL, though.

Mkarcher is spot on; to resolve the issue of a slow fpu in the case of a board that does not provide a means to adjust the fpu frequency, the 80287xl is the best way to go.

Of course, unless you are actually doing fpu related stuff on a 286 (why??!!!) Then it's all just bragging rights... which is an equally valid reason to build a hot rod 286! 😀

The tools I use for 286/386 benchmarking include:

Norton SI
Landmark
CheckIT
Comptest
3DBench
ATPerf

In terms of games I use the Wolfenstein 3d benchmark demo and the F1GP demos.

As a comparison, most of my 286 boards achieve the following Norton SI CPU scores:

@16mhz ~12-13
@20mhz ~15-17
@25mhz ~18-20*

Not all of them run stable at 25mhz, and not all will run at 0 wait state at 25mhz either. In the latter case 20mhz at 0ws is usually the better option.

VLSI 80c201
https://www.target-earth.net/wiki/doku.php?id … t_vlsi_vl82c201

Eurosoft / Headland HT12A
https://www.target-earth.net/wiki/doku.php?id … t_eurosoft-ht12

GW / Headland HT12A
https://www.target-earth.net/wiki/doku.php?id=blog:286_pc

I also have a Peaktron SA-286, but it's a really poor performer:
https://www.target-earth.net/wiki/doku.php?id … otout_pa286-sa1

There's a Biostar board with the late 286/386SX Scamp chipset too, which should be fairly speedy, but it is damaged and I've not been able to fix it:
https://www.target-earth.net/wiki/doku.php?id … _vlsi_vl82c311l

Here's a useful chart I did of all my boards, in their various cpu/waitstate configurations, for Landmark cpu/fpu speeds:

Obviously click through on the previous links to see the actual configurations tested, as well as the other benchmarks (ATPerf, Wolf3d, etc).

The standout FPU results on the Eurosoft/HT12 board are due to a separate oscillator for the fpu, which can be swapped out independent of the cpu, as well as changed in terms of the ratio of the clock fed to the fpu. Couple that with the 3/2 ratio of the Intel 287XL and it's a proper stormer in terms of floating point performance.

Your CPU performance is in the right ballpark... but definitely on the low end; I'd check that you have decent memory fitted (70ns or better), and enable 0 wait state operation if you have either a BIOS or jumper option to configure it. Also enable ROM shadowing and bump the ISA clock up from the default 8MHz - the latter options won't impact CPU performance, but will increase overall speed.

mkarcher wrote on 2024-02-16, 17:57:

MSxyz wrote on 2024-02-16, 15:00:

I was expecting somehow... better performance. The FPU particularly seems to run at 2/3 of the CPU speed. I know 287s are supposed to work like that, but I thought that later chips and most clones ran in sync with the CPU, right?

The Intel 80287 requires a 33% duty cycle clock signal at its operating frequency. This signal is typically generated by dividing the master clock of the mainboard by three (e.g. using the Intel 8284 clock/ready generator chip). On the other hand, the 80286 requires a 50% duty cycle at twice its operating frequency. Typically, the master clock of the board is used directly at this point. So a 286 at 20MHz has a master clock of 40MHz, and the 287 receives this clock divided by 3, resulting in 13.3MHz. As this clock division happens on the board, the 80287 is unable to do anything about the fact that it just receives a 13.3MHz clock signal. If your mainboard provides a clock generation circuit for the 80287 that is independent from the 80286 clock at 40 MHz, the chip could be clocked higher or lower. I would have expected at least 13MHz for the 286 if it is clocked at 40MHz/3, so possibly your board indeed has a dedicated 287 clock generation circuit that provides it with 12MHz derived from an 36MHz clock source, to allow synchronous operation with a 12MHz host processor. Looking at your image, I see an IIT 80287 clone. These clones are supposed to have a better clock efficiency as the 80286, so it looks like the clock of that processor is not even 12MHz. Check the configuration possiblities for the 287 clocking provided by your board.

Indeed, you are correct that there is a later coprocessor for the 80286 that compensates for this "issue". The Intel 80287XL has in internal PLL that generates a core clock at 3/2 of the the clock input, which will result in a clock at the same speed as the processor. This clock is not necessarily "synchronous" in the strict sense of the word, because the phase relation between the 286 clock and the 287XL clock is not well defined. I don't think any other 287 compatible chip includes a PLL, though.

Thanks for the throughout explanation. While I was searching for information on the M209 motherboard, I managed to get a short document detailing the various connectors and jumpers on it. It seems this motherboard can select via a jumper (JP5) if the coprocessor is run at the same frequency of the CPU or via a dedicated crystal. On my motherboard, however, the jumper is permanently soldered in the 'same as CPU' position, and the second crystal is not present. For that reason, I was surprised to see that the FPU is running at reduced frequency. Either my board is of different design or I misinterpreted what is written.

No, you are correct. Your board is probably a slight cost reduced version produced without the optional oscillator. It's quite common to find slight variations like that.

You could probably retrofit one (I would use a DIL socket rather than directly soldering the oscillator can itself), and desolder the solder bridge to enable it, if you were confident enough to do so.

At any rate, I'll try running a few more benchmarks among those which were posted here. The BIOS is rather basic, so I'm pretty sure there're no options to make it faster.

A shame, because those 60ns SIP modules are pretty rare, but they're probably wasted here.

Do you know that you can push a 30pin simm socket into a those sipp holes? That way you can use normal Simms.

My guess is that the board has wait states enabled, if you can figure how to set 0ws it should improve.

I would definitely recommend you remove that battery asap, though it hasn't leaked yet, chances are that now it has been charged again, it will leak and damage the board ..

Ok, so I ran a few more benchmarks and did some testing...

I also found a couple of M209 motherboard manuals scans online. None mentions a jumper or bios setting to change the wait states. In the BIOS you can only enable parity or force turbo mode always on/off. It seems these motherboards all share the same design (which is something I suspected already, seeing as numerous and widespread they were...), the only variation being having one or two crystals (and the optional jumper to select it) and the chipset sporting a different brand name.

I also swapped the ET3000 for an ET4000 but, predictably, the only result was to double the maximum video throughput. I knew already that the ET4000 would be faster but, at this stage, I'm just going in the dark moving things around randomly to see if there's any change... 😀

I also got a copy of CheckIt 3.0 which contains the Dhrystone / Whetstone benchmark. The scores are 3683 Dhrystones and 422.2K Whetstones; I believe these figures are more or less in line with a 286-16 and a little more than a 386sx-16, but I'd like to have some confirmation for good.

I also ordered a couple of 287XL on ebay to see if I can, at least, improve the FPU score.

Here's a copy of my Dhrystone results, I logged them from both CheckIT and CompTest, to be sure one or the other wasn't wildly inaccurate; there's some variation at the higher (25MHz+) end, but more or less both utilities agree with each other.

I think you're correct - your current board is performing like a middle of the road 16MHz, 1ws system. A well tuned, 0 ws 16MHz system should be ~4000 Dhrystones, 20MHz achieving around ~5000 and 25MHz achieving ~6000+... if stable!

For completeness, here are the Whetstone results:

... obviously you are already aware of the fpu/clock limitations of your current board, but helpful to compare once you get that 287XL installed!

Seems that board isn't going to win any speed contests, but there are still plenty of things which will run absolutely fine on it, so I wouldn't be too disheartened!

I would rerun your tests with the FPU removed, I had one 286 board that was much slower with an fpu installed on integer tasks but ran full speed with the FPU removed, I never could determine why this occurred.

Next Depending on the year of production your m209 might overclock (sometimes the chipset is capable of higher clocks than the cpu)

I would try a 45mhz, 48mhz and 50mhz crystal

Some 286-20’s were oc friendly and others wouldn’t at all.

A slight overclock on a 286 can make a fairly large performance bump and might make up for the apparent mediocre timings on the board.

Lastly there should be memory speed utilities that test the full address range for read/write speed, my guess is that your board is injecting waitstates somewhere even when set to 0ws, a memory speed test would tell.

Occasionally the ISA bus would get set to a strange slow clock on 20mhz systems, I don’t think this could explain your overall performance but well worth speeding it up if possible

Comptest and ATPerf at pretty good at figuring effective memory latency, I'd second the suggestion to see what is actually going on. It's almost certainly not running in zero wait state mode... If that is even an option for that board!

Thanks for all the inputs. I removed the FPU, used different video and IO cards but the board won't bulge from those results. One thing I noticed is that if I remove one bank of RAM the scores don't change, so the board must be configured to always insert some wait states or doesn't make use of bank interleave as it should. The purpose of going multi bank is to hide the RAM precharge time gaining one clock (or two in faster systems) in back to back memory accesses. This is especially important for a CPU without any cache or a chip like the 286 which maintains a prefetch queue (almost a must for a CISC architecture, since instructions are uneven in length)

MSxyz wrote on 2024-02-16, 15:00:

I was expecting somehow... better performance. The FPU particularly seems to run at 2/3 of the CPU speed. I know 287s are supposed to work like that, but I thought that later chips and most clones ran in sync with the CPU, right?

Ho there. The original i80287 did, I think.
The 287XL and clones might behave differently.

It was also possible to run an 80287 asynchronously, on its own speed.
By using an interposer with its own quartz generator, for example.

By the way, there's an classic document called "Everything you always wanted to know about math co-processors". It's from 1993 and still interesting to read.

https://dougx.net/gaming/coproc.html

https://www.vogonswiki.com/images/2/21/Coproc.txt