Thanks for the drivers.
Will check them out and update the 2 speedsys screens posted in previous threads.

---

Not far ago a conversation about 286 motherboards built on 386 VLSI SCAMP chipset piqued my interest, so decided to check one of them myself.

Unnamed 286 motherboard with printed 2016XXVB-V1 on it. There is a small sticker on the back clarifying the release date - mid 1993.
Soldered 20Mhz Harris CPU, on-board IDE controller.
386 BIOS. Exactly the same as the one in Biostar_MB-1220VE (another SCAMP based 286 board).
Basically no jumpers. All perf settings are in the BIOS.
Came with 1Mb RAM, 60ns chips which is pretty rare.
Can take up to 32Mb of RAM.
2 Jumpers control which type of memory is used.
Inserted IIT 20MHz rated FPU for the tests.
All settings adjusted for maximum performance.
The on-board IDE controller stopped working under that configuration. Swapped it with external one and all was good.

Was thinking initially to swap the CPU to 25MHz one, but then decided to test it as is, compared to the very fast VLSI system from the first page, clocked to the same frequency.

The usual set of stats:

benchmark results

Performance is pretty bad.
Not sure what was the business logic behind releasing this motherboard in year 1993 with such characteristics.
Decided not to bother with swapping the CPU with 25MHz rated one.

In another thread was discussed the possibility of SCAMP potentially offering best perf in the 286 class, but it looks like VLSI produced just one good chipset - 16QC.

@Feipoa
Tried the UMC drivers you provided.
Version 3.1 worked best. Stable with HDD speed at 17 (max 18) and Sandisk CF card.
Pretty much doubled the I/O metrics to ~7-9Mb/s from ~3-4Mb/s before.
Updated SpeedSys screenshots.

Does it properly use DMA? And which operating systems have you tested it with?

Looks like it.
OSes - checked with DOS, Win3.11, Win95 OSR2.

... and Ubuntu 14.04.
Kidding.

lol. Ubuntu is not fit for human consumption.

pshipkov wrote on 2021-03-20, 22:22:

Pretty much doubled the I/O metrics to ~7-9Mb/s from ~3-4Mb/s before.

That same speed increase was also observed in Win95 osr2? Seems odd that Win95 OSR2 wouldn't have the DMA drivers included with the OS. I had the impression that those UMC 8886 drivers were for the original diskette version of Win95a.

I see how my answer reads wrong. Better version:

Tested with with DOS, Win3.11 and Win95.
Performance is good now with DOS and W311.
It was always fine with Win95.

feipoa wrote on 2021-03-21, 01:33:

🤣. Ubuntu is not fit for human consumption.

pshipkov wrote on 2021-03-20, 22:22:

Pretty much doubled the I/O metrics to ~7-9Mb/s from ~3-4Mb/s before.

That same speed increase was also observed in Win95 osr2? Seems odd that Win95 OSR2 wouldn't have the DMA drivers included with the OS. I had the impression that those UMC 8886 drivers were for the original diskette version of Win95a.

Hey. Are you sure the UM8886 even supports DMA? I still have that MB-8433/40UUC-A which has the UM8886AF. I know we've talked a bit about this and I thought we had concluded that the UMC drivers bluescreen when running Win95b/c. I wonder if the changes to Win95 for FAT32 support breaks compatibility.

I haven't looked it recently, but a while back I was looking closely at the UM8886 drivers. I believe most of the speedup comes from enabling multi-sector transfers, enabling 32-bit transfers, and the way the driver programs different timings into registers of the UM8886 chip. I even got to the point of writing some stuff to put in autoexec.bat to program those timings without loading any drivers or TSRs, so that Win95 won't go into DOS compatibility mode which it does if it sees int 13h hooked.

It looks like you spent time on this.
I remember having exchange with you about UMC drivers. You provided code that didn't work on the hardware here and we left it there.
But i think you are hinting at a conversation you had with Feipoa.

What was your approach of determining dma/no-dma ?

Some VLB SCSI controllers that use DMA access don't work with cache in WB mode.
While so far all VLB EIDE ones do.
That is the only hint i can think of.
But actually never spent much time looking at this.
Just accept it as the way of life.
😀

pshipkov wrote on 2021-03-22, 16:41:

What was your approach of determining dma/no-dma ?

I didn't think IDE used DMA at all in the 486/VLB-era. I thought DMA was introduced with the Intel Triton Pentium chipset. Wasn't this why SCSI was a "power user" feature back then.
Since Linux is up as a topic, looking through the source code for the Linux drivers for these chips is one way to see whether DMA is implemented in the driver or not.

At least some of the drivers for the VLB EIDE controllers reviewed in this post provide DMA access. There are control flags for it and explanation in related README files.
Most of them are equal or much faster than same period SCSIs.

The Linux thing was a joke.
Recently Feipoa spent quality time on Ubuntu 14 and i teased him about it.
But you have a good point - o.s. Linux drivers can provide the right info in code.

It was actually 16.04 LTS, not 14.04. Not enough time left in extended security maintenance in 14.04 for me to have bothered.

I think there is normally a DMA check box in Win95 on the device manager properties to determine if DMA is working in IDE. I recall those um8886 drivers breaking things when I checked the DMA box.

Will check, but was it not win98 that exposed it in the drivers dialog for the first time ?

Definitely don't trust my memory. It could have been that the DMA check box was only for CD-ROM drives.

I do recall a thread (don't trust my memory) whereby somebody found the 486 ALi chipset drivers for Win9x and there was quite the improvement with DMA enabled.

Didn't run Win98 since ... well 1998, but clearly remember that people had to manually open the HDD IDE driver properties dialog and turn-on DMA or whatever the option was. This improved perf.

I just checked my Windows 95c installation and the CD-ROM properties page definitely has a DMA check box option, but as I don't have any installation which is using the onboard IDE for HDD access, so I cannot check in that regard.

Some drivers show this option while others don't.
For example SiS 496/497 has DMA with PIO3 speeds and either Windows95 has built-in support for it or the chipset handles it under the hood (like how it does DMA/PIO3 in DOS/Win31 without the need of a driver), but there is no DMA option in the control panel.
At the same time other drivers (Win95 built-in or third party) show such option.

I am not curious enough to drill into this as long as performance is there.

Abit PB4 revision 1.3, based on ALI M1487/1489 chipset (Acer).

Recently i spent time to check couple of late/good 486 motherboards with POD100 CPUs.
One of them was Abit PB4. It didn't work with the POD100 at all - couldn't get half way through POST.
Tried hard, jumper settings and everything, but to no avail.
While this was a bit disappointing, the motherboard is actually pretty good, so worth sharing some info about.

Very late design. Compact layout. Fast and stable. Works really well with AMD 486DX5 ticking at 160/40 MHz.
The easiest jumpers setup i have seen so far on a 486 class mobos.
All BIOS settings on max (for best performance) with one small exception for the 3D rendering tests - cache timings had to be set to 3-1-1-1 (down from 2-1-1-1) for complete stability.
Temporarily upgraded the BIOS to the latest available version, but to my surprise it was less stable with maxed out settings.
Downgraded shortly after to the original BIOS the board came with.
Tested with 32MB FPM RAM, 256Kb SRAM (maximum supported), Matrox Millennium PCI VGA, on-board IDE (requires DOS/Windows drivers), CF card.

--- Am5x86 at 160MHz (4x40)

IDE I/O is great.

benchmark results

Numbers are so-so.
PB4 does pretty well in Wolf3D and Doom.
A bit behind in Quake 1 and PC Player Benchmark.
Scores well in WinTune2 (accelerated Windows GUI).
Weak in compute (3D rendering tests).

--- Am5x86 at 180MHz (3x60)

Quick check online reveals that its clock generator supports 60/66MHz (datasheet).
The PCB does not implement the full table of frequencies, but the mod is very simple to make.
Tried it and ... nothing - falls back to 33MHz.
Experimented with different voltages supplied to the corresponding pin, including some silly things - no luck.
So, no 180MHz for this guy.
Checked online to see if others tried and/or succeeded with the clockgen mod, but didn't find any relevant information.
Anyone ?

---

While Abit PB4 does not win in any discipline it is definitely in the fast line with the rest, which is expected for a late 486 motherboard.
I don't have a lot of experience with Abit and Acer hardware, but they got this board just right for sure.

cache timings had to be set to 3-1-1-1 (down from 2-1-1-1) for complete stability.

That's fairly common for motherboards with single-banked cache and no on-motherboard memory buffers. If the board had doubled-banked 256K instead of single-banked 256K, I bet it would just barely pass with 2-1-1-1.

pshipkov wrote on 2021-03-25, 07:00:

Abit PB4 revision 1.3, based on ALI M1487/1489 chipset (Acer). […]
Show full quote

Abit PB4 revision 1.3, based on ALI M1487/1489 chipset (Acer).

Recently i spent time to check couple of late/good 486 motherboards with POD100 CPUs.
One of them was Abit PB4. It didn't work with the POD100 at all - couldn't get half way through POST.
Tried hard, jumper settings and everything, but to no avail.
While this was a bit disappointing, the motherboard is actually pretty good, so worth sharing some info about.

POD100 in a 486 board? Wasn't 83 the highest released socket 3 POD?

@Feipoa
Didn't look at this ALI chipset specification, but you are probably right.
I remember you talking about single/double banked caches. Do you have more detailed info somewhere about that ? Findings, etc.

@H3nrik V!
Look here