updated RAR-archive in first post. Many new programs for XT.

Ekb wrote:

updated RAR-archive in first post. Many new programs for XT.

RAR archive is missing.

feipoa wrote:

Ekb wrote:

updated RAR-archive in first post. Many new programs for XT.

RAR archive is missing.

Really? It opens, only warns that the old version of the browser. But you can still download.

Hello all.
They sent me a photo benchmark 286.
CPU: 27,7MHz
Memory: Zero Wait State

What motherboard is pictured?

If I understand correctly, there's no practical reason to use 286 over downclocked 386DX?

You are correct. Also 386DX-40 has a turbo option. So with turbo off it's like some 286. No need to play with jumpers or oscillators.

I'm a bit late to the party, but thanks to the OP for the detailed comparison and the benchmark suite.

I'd like to benchmarks a few of my systems, however while uploading the archive to VirusTotal it gives 4 viruses detected:

AegisLab:
Troj.DOS.MMi.l1AR

CAT-QuickHeal
HLLW.Freemem.B

Jiangmin
Constructor.DOS.DBVG

Rising
Trojan.Win32.Agent.yjt (CLASSIC)

Are these false positives? I'd like to know if these utilities are safe to use.

Hi, i would download the "doctorHARD 3.7" benchmark but i can't find it ! can you help me ?

I've done a few benchmarks on my own 386SX-25.

While your 286 still seems to beat it most of the time, my 386-SX 25mhz is definitely a fair bit faster than your example.

I am using 70ns RAM, running with 0WS on read and write ram (according to bios), and 2/4 bus ratio. Chipset is Opti and using ET4000 graphics card. (although, I probably won't see much difference with a slower card, these slower systems are less sensitive to video card speed)

I think it is kinda unfair to compare a highly optimized 286 with a rather slow or optimized 386. I'll try to run a full suite of benchmarks as soon as I can.

Edit: 🤣, replying to a 3 year old thread 😀

There is no time limit here as long it's in the right context.

Please post your scores as optimised 386SX are pretty rare.

@canthearu, mine is pretty fast too, it outperforms cacheless 386DX25 found there 😁

I tried my PC Chips M205 (or unmarked variant) with the real-mode compatible portion of Phil's DOS benchmark pack, though not the array of other older benchmarks used here so far. It started as a 20 MHz board with Harris 80C286-20 and had 80 ns CMOS DRAM installed, so I assume it's using 1-wait-state operation. (technically a really fast DRAM controller should allow zero WS at 20 MHz with 80 ns DRAM, but given the age of the chipset and nature of the board that didn't seem likely; with the CPU having a 1990 date code and BIOS set-up screen also citing 1990, and I think the D60 chipset dates to 1988 if the BIOS copyright sticker means anything and DIP-socket-only RAM, albeit newer 20 pin 256kx4-bit sockets only)

I've got somewhat conflicting results with it overclocked at 25 MHz. (with 60 ns Siemens DRAM)

3DBench 1.0 only gives 6.3 while using a CL 5420 512kB (VRAM version)

System Information 8.0 gives a score of 12.6

However, Landmark 6.0 rates it as a 33.6 MHz AT, so not as fast as the 39 MHz figure here, but also not that far off, but that 3DBench score is much lower and shouldn't be due to the VGA card.

I'm not sure if 3DBench makes heavier use of hardware multiply/divide or shifts and look-up tables, but heavy use of tables (and any other tricks involving RAM access) would certainly make wait states hurt more. I'm pretty sure that shows up pretty noticeably in Wolfenstein 3D.

If there's any real-mode based polygonal 3D (or sprite scaling) based games that make heavy use of mul/div instructions rather than memory-bound tricks, those could be good benchmarks to work with. (some old flight/combat sims maybe)

The floppy disk version of X-Wing is real-mode compatible and uses EMS for many of its features, but can run purely in base memory, too (at best you get cutscene music and in-game adlib sound effects, but no imuse soundtrack without a lot of EMS RAM).

If X-Wing used hardware multiply and divide rather than LUT optimization (or conditional code checking when shift+add operations are faster to use) it might be a good example for testing raw clock speed over memory performance.

I've put a few hours into playing X-Wing at 20 and 25 MHz so far and it's pretty playable at times, but horrible at others. (though a 386SX-40 I've also tried still chokes in a lot of the same situations where poor framerate isn't the worst issue and massive lag is: lots of capital ships and, especially, tons of projectiles being rendered seems to be the worst, and assuming all those projectiles require 2 3D points to be plotted each, that makes sense given I'm talking scenes with hundreds or thousands of them on-screen: so dropping 3D model detail doesn't do all that much)

OTOH, it'd be interesting to compare a 386DX at 16, 20, and/or 25 MHz to compare if that fares much better. (especially late 80s vintage boards that would be stuck with slow RAM and wait states) Or even a DX-40 without cache and with slow RAM, like a budget 2MB build from around 1993~94 using cheap (used or surplus) 256kB SIMMs, probably 80 ns. (granted, 60 ns DIPPs in an overclocked 286 would be rather out-of-era too, though I'd think someone overclocking and upgrading a 1990 vintage 286-20 using 70 ns RAM might be plausible and 70 ns might do OK at 25 MHz with wait states and not-crazy-hot ambient/case-internal air temps)

X-Wing also runs in plain MCGA/VGA mode 13h, no fancy unchained mode tricks for multiple frame buffers (like 4 in Wolf3D and Doom), VGA hardware scrolling, or VGA hardware fill to accelerate polygon drawing (or 2D scaling or expanding RLE formatted bitmaps), and lots of block copying from main to VGA RAM. So if 16-bit block copy operations get accelerated on a 386 making use of the wider bus (and registers), there'd be a noticeable advantage there, even though the ISA bus (and VGA RAM wait states) would be the same bottleneck. (aside from a VLB 386 build, which certainly wouldn't represent a 1989/1990 era system, but could for a new one in 1993)

On that note, Wolfenstein 3D (and Doom) wouldn't gain as much from VLB VGA cards over low wait state ISA ones given they always do single pixel writes and write to VGA registers rather than block copying a local framebuffer into VGA memory. (that should also mean that particularly fast 8-bit VGA cards should also do as well as 16-bit ones) But fast, low wait state main RAM and cache still benefit those a lot due to the heavy use of look-up tables and memory-intensive operations.

There's some other games I want to look into that claim to need 386s, but actually run on a 286 and sometimes lower (V20/30 and 188/186 CPUs have most or all of the added 286 instructions outside of the extended 24-bit address modes/registers and protected mode).

Nearly all of these are 1992 or 1993 releases, and I think Ultima VII should work (and is an odd case using BIG/UNREALMODE rather than EMS), but most others would be specific to games citing the need for Expanded memory rather than Extended. Darklands might be among those and Return to Zork really looks like it, with the floppy version even specifying 640k minimum and 256kB EMS for CD-ROM. (it might need more for full features, but I'll bet less than 2MB, similar to X-Wing; if it really just needs 256kB EMS, it'd work fine in a 1MB 286 system with EMS support)

RPGs, graphic adventures, and multimedia point and click type games from that period also probably work out better on slower systems (the 2D portions of X-Wing run at almost full speed at 25 MHz with the 'fast' settings, and full speed with proper speech/mouth synch at medium speed at 20 MHz: though I think it still looks better with the added animation in 'fast' mode)

B-Wing, Tie Fighter (at least the floppy version), and X-Wing Collector's CD-ROM (DOS) all use a similar upgraded engine, but still specify EMS version 3.2, so could run a a 286 but I doubt they'd be remotely playable. Tie Fighter CD-ROM edition (DOS) might be similar, but obviously also too much to be playable, especially in 640x480 mode.

As to the 386(SX) vs 286 comparison, I'd think a Headland HT18 based 386SX could be a good reference against the HT12/A, though you'd need a board that allows wait state configuration for good measure. (I don't have an HT12 board, but I do have an HT18 386SX-25 board that works, but I haven't done much with it and need to look into the feature set)

Supposedly the HT18 has hardware EMS support, too, so enabling drivers for that might be worth comparing to EMM386 performance. (it also implies it'd be useful as a 286 chipset, but I'm not sure it was ever used as such)

I messed up: that 6.3 FPS was actually using my Ati Graphics Ultra in 8-bit mode (i've now discovered the 16-bit mode jumper and apparently it applies to the VGA core, not just the Mach 8 ). Or it might have been at 20 MHz ... either way it's wrong. (though I know for sure 20 MHz + 8-bit ATi = 5.6 fps)

At 25 MHz it does 7.7 FPS in 3DBench (and doesn't seem much bottlenecked by the ATi card, with 7.6 vs the 7.7 of the CL5422, though I need to try the 5420 with the zero wait state jumper set).

Down at 20 MHz stock speed, it's 6.2 or 6.3 FPS

I also got the M205 and 286-20 stable with EMS and XMS at 25 MHz with a 90 mm fan blowing across the board (board elevated about .5" to allow some under-board flow as well).

I then got it to go 27 MHz without stability issues after warming up by using the same fan configuration. However, it fell back to being stable only in real-mode (XMS disabled, 640kB + 1408 kB EMS, shadow RAM disabled).

But I realized I could slim down the Vibra drivers by deleting the 'unit=0' portion of the config.sys line. There might be a valid parameter to set there to the same effect (unit=1 maybe?) but deleting it seems to work fine for using it just for SB/SB-16 compatibility (and no added features). So I could run X-Wing with DOS loaded Low and full features enabled (600 kB available when loaded High and ... I forget, but I think 570 or 576 kB when loaded low: so not enough for WCII's full features).

But the minimum configuration for full X-Wing functionality is 1.5MB and DOS loaded low for 896 kB EMS available along with more than the 550 kB base memory needed. (so full digital SFX and full IMUSE MIDI functionality; 256 kB EMS is specified for digital sound, but only really gets you the speech in the intro and sfx in transitions: the music and most/all digital SFX are missing in-game)

27 MHz got the Landmark score up to 36.5 from 33.6 (and listed 27.214 MHz), but that's still lower than the zero wait state 25 MHz build, but I think better than zero WS 20 MHz.

And 3DBench was still only 8.2 fps.

X-Wing's detect.exe went from 150 ticks at 25 MHz to 140 at 27. (actually varied at 150~154 and 140~142)

So I guess the overall performance makes sense for a 1 wait state system vs 0 ws, and memory bound tasks are 1.25 to 1.33 times faster with zero ws at the same clock speed.

I'm not sure if 0 vs 1 ws differs on different chipset makers terminology since there's access time and also memory cycle times to consider, and a chipset (and RAM) fast enough to provide zero wait state access times might still not allow for the DRAM to cycle in time for the next read or write request depending on the instruction execution times. A few 286 instructions take only 3 cycles to execute vs most others (non-slow multi-cycle ones) at 4 clock cycles so you'd need RAM to cycle in 3 clock ticks for true zero wait states, otherwise you'd get 0 wait access times, but additional waits added to fast instructions to pad them out to the 4 clock minimum interval.

OTOH, the examples I'm seeing appear to line up with true zero wait states along with 1 ws being added to access timing, so 3-clock instructions take 4 clocks and 4-clock ones take 5 (hence the 4/3 to 5/4 speed differences in memory-sensitive tasks).

And given the 1.32x speed advantage at 25 MHz over my D60 board (10.2 vs 7.7 FPS) in 3DBench, I assume 3DBench makes heavy use of 3-clock instructions.

I'm also going to assume that 3DBench does a lot of table optimized 3D math and not hardware arithmetic given the performance scaling there. (VGA framebuffer copying would be a big memory bottleneck, but so would vertex math if done purely with ALU instruction)

I suspect X-Wing does make heavy use of actual mul/div instructions given the clock speed seems to make a major difference and I can set the 3D models to max detail (so poly count changes little/not at all at visible distances) and have the framerate mostly bottlenecked by BIG models rather than complex ones (ie large models with full-frame overdraw ... like getting closer to the platforms in the proving grounds to approaching a freighter or capital ship: X-Wing Historical Mission 1 is an easy one to get a freighter for reference).

The game definitely chokes with tons of laser blasts or projectiles being drawn on-screen, and I'm not sure where the limit is there (lot and lots of line-draw commands) or is it more the physics and collision detection (and object tracking) overhead that's choking it?

Performance also seems close to identical to a 386SX at the same clock speed so far, but I'm eyeballing it, not frame counting. (though detect.exe gives similar results, too ... I'll try to compile a list when I have time and also compare the 386SX chipsets I have: PCCHips/SARC from the M396, Headland HT18, and an ALi chipset on a board that looks very similar to the PCChips one, but is slightly slower at the same clock speed ... but also has a problem with a BIOS mismatch or damaged address lines that's screwing with the RAM above 2MB, I think it might be more BIOS related given 384 kB get reserved, yet shadow RAM can't be enabled and the UMA also isn't available: DOS acts like there's shadow RAM reserved, but there isn't)

The PCChips board has a soldered-in BIOS so I cant try swapping, but I do wonder if it's the same ALi chipset. (part numbers don't match, though, and a tleast for 286 era stuff, PC Chips didn't change or fake part numbering)

I also haven't compared a 386DX to see if there's any difference.

I assume the programmers avoided 386 and 386SX no-nos for real-mode, like mis-alligned words that add overhead with the word-aligned addressing. (and the 286 allows for byte-alligned 16-bit operations, I think ... otherwise I'm not sure what the difference would be for that)
There's also a few instructions actually faster on the 286, and I think some 8-bit arithmetic, but I might be wrong there. (I want to say 8-bit unsigned division is faster, maybe 8-bit multiply)

I did notice the NEC V33 has faster 16-bit multiply than the 286 or 386. 8-clocks for 8-bit multiply and only 12 for 16-bit. (about 2x as fast as the 286 and 386, and I believe faster than the 486 as well)

It's also not compatible with 286 protected mode and has 2 special instructions for accessing 24-bit address space from Real-Mode instead. (and I don't think it's EMS compatible either, but that would've been cool: native EMS bank-switching MMU support; it's probably mostly compatible with LoadALL real-mode address extension tricks in the 286 though)

I think it's pin-compatible with the 286, though, which would make it an interesting drop-in replacement. I wonder how well they overclock.

Or back around 1992 it seems like it would've been a good fit for a game console aimed at x86+VGA game compatibility: ie almost 1:1 ports of DOS games ... except it'd probably need a CD-ROM drive in leu of anything hard-drive install intensive.

A zero wait state 16.67 MHz V33 should've done 16-bit 3D math almost as fast as a 386SX33 and had memory bandwidth better than a 1 ws SX25 (or about dead equal in math and I/O speed to a 3 ws SX33) ... assuming real-mode operation and not making use of the 386's expanded 16-bit register modes. (potential heavier use of registers and more register-register operations)

edit:
The V33 is not pin-compatible with the 286, it's PLLC68 packaged, but the pin mapping is quite different so you'd need ot rig up an adapter board for it to work, unfortunately.

That's probably one of the reasons it didn't get used more widely (even with the Protected Mode restriction), though I wonder why NEC did that or didn't offer a pin-compatible version.

It's only 68 pins, so also shouldn't be that big of a project to rewire on a project board (or map out and etch a PCB) ... though having it end in a 286-compatible PGA-68 pinout would probably be easier than trying to rig up some weird PLLC socket plug, so soldering a PGA socket onto a 286 board. (and you could just plug a PLLC socket into the PGA socket for normal 286s)

Though come to think of it, some EMS-capable chipsets only allowed EMS to be enabled with all XMS memory disabled anyway, like the Suntac D62 (I think), so those would've been a good fit for the V33 back then, just locked into EMS mode.
Though I suppose there could have been himem.sys implementations (or other himemory extenders) that used the V33's native address extension modes instead of 286 protected mode. (useful for OS and driver level stuff to access the HMA, not for software that explicitly needs to run in protected mode)

Oh wait, I forgot the pics, and the grayscale text mode pics are from when I had the Graphics Ultra running in it.

And that last (color) benchmark shot was from my initial, uncooled, semi-stable test and used a different 54 MHz oscillator. (I got a batch of 5 off ebay, not sure if any is more stable than another, but the benchmarks seem to get consistent readings off the same oscillator when run again) I marked the one I had the most success with, though it may not matter.

Oh men .. you save my day with your topic, because I've tested my old 386-dx25, on one of a very first of 386 motherboard existing model.
And with a old version of SYSINFO (for my 286 an 8088), with a score half as good as a 286 !!
So I was been verify terrified :p

I just used an version 8 & 9 of SYSINFO from your RAR package and I've the same scores around like yours finally.

Dear all,

Once I‘ll find time I will post my 386sx/25 MHz results here based on VLSI chipset.

What I alread can say is that:
- impressed by the 286 scores
- too low scores for 386sx and especially DX

Eg my 386sx at 27,5 MHz w/o cache reaches:
- 21,7 Norton SI Score NU SI8
- 10,1 3DBench

The slow results for the 386 might result due to the underclocking. In most cases where you don’t use an external ISA/DMA oscillator you will decrease the ISA bus speed while downclocking core frequency. At the end we might reached a situation where the 286 runs at 13,5MHz ISA and the 386 somewhere below 8 like 5 MHz. especially the DMA clock benchmark is indicating this.

To sum: I love such benchmarks but pls look in detail about the compared environments.

Nice weekend.

I know its an old thread, but i just built my first version of "FAST 286" project a few weeks ago. Still at 25MHz...

iPonRMA wrote on 2023-07-05, 19:11:

I know its an old thread, but i just built my first version of "FAST 286" project a few weeks ago. Still at 25MHz...

Nice build 😀

But some specs with more photos would be nice 😁

Since I was replacing a blown up Tantalum cap on one wavetable card today and had some free time, I took the chance to do the oscillator removal on one 286 board and replacing it with a socket - this was in the plans for many years 🤣

Originally running at 20MHz with soldered Harris 80286-20, I tested it up to 27MHz. Screenshot at 25Mhz as a teaser. Will do another thread for "Kixs's 286 to the Max Too" soon 😁