Chadti99: You also tested the Promise EIDE2300. Did you happen to try running a CD-ROM drive as Slave on the Primary EIDE port in Windows 3.1x with the Promise EIDE2300.386 32- bit driver?

by default both ports are ide. you can switch either one to EIDE through driver's arguments. for example M1:8 turns the second port to EIDE..
but if manual tells you to expect problems with cd-roms - you should : )
at the same time i dont blame the Promise developers for not future proofing the controller for CD-ROMs because even 8x models from 2-3 years later max out at 1.2mb/s theoretical speed limit which is way within the comfort zone of plain old IDE.
i would expect the same for the ZIP drive, so plug it to the second port and will be fine.

I should have a 2x and 4x IDE drive I can connect it to, however I have doubts it will help the situation w/Win3.11. W95 didn't exhibit this issue. Perhaps the DOS CD-ROM driver is messing up Windows. I will try to REM the DOS CD-ROM driver.

pshipkov wrote on 2022-04-03, 23:42:

by default both ports are ide. you can switch either one to EIDE through driver's arguments. for example M1:8 turns the second port to EIDE..

From what I remember reading the manual, M0 or D0 refers to the Primary port: MASTER, while M1 or D1 refers to the Primary port: SLAVE - not the Secondary IDE header. Do I remember incorrectly? So the Secondary Master, I assume, is M2 and the Secondary Slave M3 ?

One other item I should try again is running Promise's install configuration with the CD-ROM connected. Maybe it will do some magic on the driver files.

pshipkov wrote on 2022-04-03, 23:42:

i would expect the same for the ZIP drive, so plug it to the second port and will be fine.

Only if I can resolve the issue with Windows 95 running in compatibility mode for the Secondary port.

feipoa wrote on 2022-04-04, 00:44:

From what I remember reading the manual, M0 or D0 refers to the Primary port: MASTER, while M1 or D1 refers to the Primary port: SLAVE - not the Secondary IDE header. Do I remember incorrectly? So the Secondary Master, I assume, is M2 and the Secondary Slave M3 ?

Hmm, maybe you are right. I better check things before talking too much. Will clarify soon.

feipoa wrote on 2022-04-04, 00:44:

Only if I can resolve the issue with Windows 95 running in compatibility mode for the Secondary port.

I see.

---

Unlikely the installation process to do magic, but you can give it a try of course.

I tried 3 different CD-ROMs: Hitachi from Q1-1997, Mitsumi from Q2-1996, Lite-On from 2001 and 5 different DOS drivers: hitachi, nec, goldstar, mitsumi, liteon. All exhibited the same issues with Windows 3.11 and the Promise 32-bit driver. Also, it looks as if there isn't a Windows 3.1 driver for the CD-ROM becaues Windows 3.1 relies on the DOS CD-ROM driver.

I then tried to force the Master (cf hdd) and Slave (cdrom) to use PIO only, that is, /D0:7 and /D1:3, but because the Promise installer hacks the DOS driver upon their "full install" method, it insisted on using the DMA setting /M0:7.

I retested with the CD-ROM on the ISA port (secondary IDE) and no issue in Win3.1. Thus I will move on to figuring out why Windows 95 has compatibility mode issues with the CD-ROM on the Secondary port. I may need to use this rare ISA card I have which is specifically for ATAPI devices (LS-120, ZIP, CD-ROM, tape, etc).

There is certainly no shortage of curious discoveries with this old hardware. It reminds me a lot of modern Linux.

Can you use the unmodified driver from the archive and set D# flags ?
I use the non-installed driver and have control with D or M flags.

Good to hear you are getting somewhere with the optical drives.

Your last sentence - good analogy. : D

Yeah, I can use the unaltered eide2300.sys file to pass the /d0:n flag, however symptoms persist in W3.11. The driver ignores the /d1:2 value I sent it for the CD-ROM. Looks like the DOS driver only cares about fixed disks and not other devices. I suspect the Windows 3.1 eide2300.386 driver also doesn't have non-fixed disk information and this is messing up 32-bit access. *sigh* I wonder how many of these cards were returned because of this issue.

I managed to get the Windows 95 Promise EIDE drivers working, but the results were pitiful.

Using the Promise EIDE2300+ Windows 95 drivers, Roadkil returns 1.18 MB/s for a 64K block. This is with the DOS EIDE2300.SYS driver loaded before booting Win95.

If I comment out the DOS EIDE2300.sys driver, then Roadkil returns 1.55 MB/s in Windows95. The speed isn't good, nor is the fact that the DOS driver pre-loaded is slowing things down in Windows. I thought that when protected mode drivers are loaded, they completely replace the real mode drivers.

I then tested the Windows standard ESDI/EIDE driver WITH the DOS EIDE2300.sys driver pre-loaded. Results were 1.89 MB/s.

Again, if I comment out the DOS EIDE2300.sys driver, then the Windows Standard ESDI/EIDE driver returns 3.10 MB/s. This is a far cry from the 8+ MB/s results I get in pure DOS using CoreTest and the DOS eide2300.sys driver.

This is interesting info. I assumed dos drivers will be discarded in win9x, but apparently thats not the case.
I guess i dont hit that issue because environment setup goes through different paths in autoexec.bat/config.sys.
I think both roadkill and plethora of dos tests are somewhat misleading, at least thats what i recall since our round of testing a while ago.
Timing the copying of 100mb of few big files and 100mb of lots of small files was shown numbers different than both synthetic tests.

I resolved the issue with MS-DOS Compatibility mode in Win95, thus using the CD-ROM on Promise EIDE2300+ Secondary IDE port.

When I thought all was well, I tried to boot NT4 and NT3.51 - well, they will return "incompatible boot device" and not boot up at all when the CD-ROM is connected to the Secondary port. The NT's want it on the Primary, which W3.11 did not want. In NT 3.51, using the Promise supplied driver instead of the default ATAPI driver worked fine. However, NT4 will need to use NT 3.51's driver, which is sort of half-installed with some install error, but appears to be working none-the-less.

NT4 really doesn't run well with only 16 MB of RAM, but NT 3.51 runs very fast on this system. Thus, I have decided to setup CF #1 with DOS/W3.11/NT3.51 and CF #2 with W95/NT4. CF#1 will be the default CF card. Just need to find some working Crystal 4232 NT 3.51 drivers now.

Been talking to somebody in private about couple things.
Figured it will be good to share some of them in the public space - can be useful to others.

Subject 1: image quality of various RAMDACs from late 80ies to mid 90ies
SS2410, 24-bit, Diamond Multimedia (?)
KDA0476PL-80 / KDA0476PL-80, 6-bit, Samsung
ATT20C490-80, 24-bit, AT&T
SC15025CV-A, 24-bit, Semtech
WB2C476-80, 6-bit, Winbond
UM70C178, 6-bit, UMC
GD-5420/5426/5428/5429/5434, 24-bit, Cirrus Logic
TKD8001, 24-bit, Trident
TR9C1710-80DCA, 8-but, Music
> MU9C9760V-80DC, ?-bit, Music (didn't work in any of the cards)
> Bt121KPJ80, 3x8-bit, Brooktree (didn't work properly on Diamond SpeedSTAR 24, overheats, dull colors)
> ADV101KP30, 3x8-bit, Analog Devices (didn't work properly on Diamond SpeedSTAR 24, overheats, no picture)

Used the corresponding video drivers.
Used 20" Dell LCD monitor.
Invoked monitor's auto-adjustment after switching to every screen mode.

Image quality compared with:
DOS terminal - text console.
DOS VGA - Wolf3D.
Windows 3.1 800x600 in 256, 32k, 64k colors.

1          DOS TERM    DOS VGA    256     32k      64k
2KDA0476   blurry      sharp      sharp   -        -
3SS2410    sharp       sharp      sharp   sharp    -
4ATT20C490 sharp       sharp      sharp   sharp/N  sharp/N
5SC15025CV sharp       sharp      sharp   sharp    sharp (with WDC90C30 only)
6WB2C476   sharp       sharp      sharp   -        -
7UM70C178  sharp       sharp      sharp   -        -
8GD-54##   sharp       sharp      sharp   sharp    sharp
9TKD8001   sharp       sharp      sharp   sharp    -
10TR9C1710  sharp       sharp      sharp   -        -

N - noise (EDIT: User Feipoa reported that he does not see noise on his card. It can be specific issue with the hardware here.)

So RAMDACs matter, especially in higher screen resolutions with enough colors.

---

Subject 2: 486 CPUs capable of 180/200MHz

Ever since i burned that Am5x86 ADZ chip capable of handling 200MHz on air cooling i have been searching for a replacement.
None of the other 13 486 DX5 chips that i had could do 200MHz on air, so i splurged for a fresh batch of 10 more ADZ processors.
Ended up with 23 chips - a decent number to draw some conclusions about probability of finding 180/200MHz capable silicon.

6 of them work at 180MHz (3x60) on air cooling.
2 ADZ and 1 ADW can do it reliably at 3.3V.
2 ADZ and 1 BGC(!) need 4V.

From these 6 chips 2 ADZ can work at 200MHz (3x66 or 4x50) on air cooling.
One can do it reliably at 4V.
The other one needs 5V.
(still verifying complete stability but feels like it is there)

So, it looks like the Am5x86 ADZ/ADW tech is very 180MHz capable (roughly 25% probability) and rarely 200MHz capable (10-15% chance).
Still, not a bad ratio at all.

The most precious chips are the ones that can handle 180MHz @ 3.3V and/or 200MHz @4V.

Subject 3: 8087 FPU overclocking

Been experimenting with several different 10MHz rated FPUs for that super fast XT.
Selecting a CPU was easy - 16MHz rated NEC V30 HL, but there were several different 8087-1 models.
Wanted to see if there was a difference between them and eventually pick the best option for the XT rig.
What i saw - chips with C 1980 marking on them have the best chance of high overclock.
They seem to work just fine at the peak 17.13MHz i am running the system on.
Chips with C 1978 marking are not scaling very well.
Also some of the chips with '80 '84 marking on them are also not OC-friendly.

That's pretty interesting about the 8087-1 chips. They're all NMOS, I would have assumed they'd all fare poorly. Maybe I'll look into the (c)1980 chips to see if I can duplicate your results. Unlike 286+ systems, if you have an unstable FPU it will bring down the whole machine, so if you want to overclock an 808x with FPU, then you'd better be careful.
Did you try out the NEC 8087 clone? It's supposed to be CMOS.

Have you seen NEC 8087 in the real life ?
It looks like AMD NEC and Cyrix produced collectively 5 or so 8087 clones before Intel came rumbling on them.
So far the only 8087 FPUs i have seen are from Intel.
Some vague memories about seeing on picture some Russian spin-offs rated at single MHz digits.

Is not NEC 8087 supposed to be a 80187 class design ?
If you have one for sale - i am reaching for the wallet ...

I think he might be referring to these: https://www.cpu-world.com/forum/viewtopic.php?t=36536
There may be one or two left. Dunno...

It would be neat to have some real life performance testing of these.

Nice article.
Indeed - it will be great to check the perf of one of these NEC FPUs ...

I don't have a 8086 to experiment with. Perhaps you can procure one of these NEC FPUs?

By the way, I've arrived at some additional information which may put into question some of the Am5x86-180/200 benchmark scores. I've been doing some tests with the STB Powergraph64V replica VLB cards and an m919. It appears as if DOS Quake (shareware 1.06) benchmark scores are a good amount better when using only 32 MB compared to 64 MB. Thus, to more precisely compare scores, we may need to come to some standard for memory quantity. Some of my results,

32 MB EDO
Quake = 12.3 fps

32 MB FPM
Quake = 12.3 fps

64 MB EDO
Quake = 10.2 fps

64 MB FPM
Quake = 10.2 fps

If I recall, you had to reduce the memory size on some of your tests, down to 32 MB, in order to get the fastest L2 or memory timings working with LSD and 200 MHz.

There is no NEC 8087 available in the usual places but managed to obtain one through another source, so will see soon how the NEC one stacks against Intel's.

---

M919 and amount of system memory.
Checked the notes in M919 @180/160MHz and indeed - this board does not like more than 32Mb with the default 256Kb L2 cache module. Maybe the bigger cache module will lift that limit.
Also, your results above look a bit too low. System running at 133MHz ?

CPUShack didn't have any NEC's left?

I'm running the M919 v3.4 with the 1024K cache stick and have L2 in WB mode (I think). I can understand an issue with 256K and L2:WB, but not with 1024K L2. Slow results don't matter here, just looking at the 32mb vs. 64mb. I am using a Cyrix 5x86 at 100 MHz and don't have the register settings loaded.

However, I will re-run the tests with L2 disabled completely, and if needed, with L2 set to WT.

I just checked quake on the m919 with L2:disabled. 32M=ll.3 fps and 64M=9.6 fps.

You might want to check for this case on your LSD board, or any board you are trying to obtain maximum DOS Quake scores on. If 32M results in inflated scores, or 64M deflated scores, then we might want to run all tests with exactly 32M.