As bizzare as it might sound... have you tried 98? Just to rule out that it's not just 95 out of the 9x family to do that?

feipoa wrote on 2024-05-04, 03:18:

I am in the mist of setting up my super charged SXL2-90 system using a Symphony SL82C461 based 386 motherboard (DTK PEM-4030Y). One of the problems I ran into was the inability to use any FPU within Windows 95.

Your problem might be the rather extreme OC. In theory the clock-doubled chips should stick to the single-speed bus but for some reason this does not fully apply to the co-processor I/O channel. I never got around to putting LA on my mobos but I have seen, multiple times, such x87 instability when the clock doubler is activated.

From what little testing I was able to do I noticed freezes, glitches and crashes but only when x87 code was executing. So either the SXL(C) chips do not properly slow down to 1x bus speed when talking to the NPU or there is some timing issue (setup or hold time violations) that cause the comm channel to glitch. I even had a case where one of my 387 chips was consistently mis-detected as 287 due to glitches in the testing sequence. I think Win9x attempts to both detect the NPU type as well as trap the exceptions - as any sensible OS should. DOS doesn't much care about these exceptions as it doesn't use NPU at all and its single-task operating mode mean it's always the app that is responsible for those.

TL;DR: Try disabling the 2x multiplier and (if that's not enough) reduing the bus speed further to get in spec.

Hi Deunan. Thanks for your reply, but it looks like you may have missed one of the lines I wrote above, namely: "It also happens with a regular AMD 386DX installed, not just the SXL2 CPU." I had already tested the AMD 386DX at 40 MHz. I think I also tested it at 33 MHz.

PCBytes, no I haven't tried Windows 98. I haven't run Windows 98 on any 386 class hardware.

feipoa wrote on 2024-05-04, 11:07:

Hi Deunan. Thanks for your reply, but it looks like you may have missed one of the lines I wrote above, namely: "It also happens with a regular AMD 386DX installed, not just the SXL2 CPU." I had already tested the AMD 386DX at 40 MHz. I think I also tested it at 33 MHz.

I did miss it, sorry. But I also had issues with some 386DX chips when it came to x87, this was clearly dependent on the stepping. The most stable was a late Intel 386DX, the earlier chips and pretty much all AMD ones had issues (the older the chip, the more severe). Interestingly the SXL chip I had was rock solid in that mobo but only tested at x1 multiplier. So please test it at x1 speed even if you had already tried other, slower chips.

From your description it looks like something specific to win95 and dtk pem 4030y.
Otherwise the rest of the op systs will not work too.
Few quick searches online revealed nothing about this kind of stuff.

Deunan, for the purpose of being thorough, I retested with the SXL at 1x and with an i387DX, but the error persists.

pshipkov, yes, I haven't seen any example of this sort online. Uncharted territory?

Remember looongggg time ago, i use my 386+387 for Autocad 10 working. Windows 95 have problems to load and i solve loading a 387 emulator before boot, but maybe my memory fails or problem what different, specially because remember this 386 was so unstable.. but back on time is all i have jeje

feipoa wrote on 2024-05-04, 22:31:

Deunan, for the purpose of being thorough, I retested with the SXL at 1x and with an i387DX, but the error persists.

That sucks, this combo is the one that worked the best (never had a single problem). FYI the problems I had only manifested on one particular mobo, a (clone) 386WB running at 33MHz. The chipset is Opti 391B+392. I never tried to run Win95 on it, the problems were already in DOS (Quake demo would eventually glitch, hang or crash back to command line).
All the CPUs and NPUs worked stable and without issues in other mobos but there was clearly something wrong with the way 386WB handled BUSY from x87 as the results were 100% repeatable.

Wait for the YB board to arrive. That will allow you to intersect the prob.

So far didnt hit a 386 hw config that hard-fails with 387 chips like that, but i dont test this class components with w95 and nt.

The only good reference to a VMCPD error is this from MS: https://ftp.zx.net.nz/pub/archive/ftp.microso … -us/136/255.HTM
but only applies to Cyrix dlc cpu + cyrix fastmath...did hex edit the win95a and osr2 .vxd's and there is some code differences.

Thanks Horun. Good to know Microsoft had some information on the issue. It's unknown if using Win95a would be a suitable workaround.

Just in case that URL disappears, I think it could be beneficial to future problem hunters to display the information here.

1Error Message: A Fatal Error Has Occurred in VxD VMCPD (136255).
2
3The information in this article applies to: Microsoft Windows 95.  This article was previously published under Q136255
4
5SYMPTOMS
6After you install Windows 95, you may see the following error message on a blue screen the first time the computer restarts: Windows: A fatal error 0D has occurred at 0028:xxxxxxxx in VXD VMCPD(01) + 000026B. The current application will be terminated. If you press any key, you see the same error message. If you press CTRL+ALT+DEL to restart the computer, the same error message occurs.
7
8You can start Windows 95 using Safe mode.
9
10CAUSE
11This problem can occur on computers using a Cyrix 486DLC processor and a Cyrix FastMath coprocessor. Some computers with this processor and coprocessor are not compatible with Windows 95.
12
13RESOLUTION
14To work around this problem, disable support for the coprocessor in Windows 95. To do so, follow these steps:
15
161. Restart your computer. When you see the "Starting Windows 95" message, press the F8 key, and then choose Safe Mode from the Startup menu.
172. Click the Start button, point to Settings, and then click Control Panel.
183. Double-click the System icon.
194. On the Device Manager tab, double-click the System Devices branch.
205. Click Numeric Data Processor, and then click Properties.
216. On the Settings tab, click the "Never use the numeric data processor" check box to select it, and then click OK.
227. When you are prompted to restart your computer, do so.
23
24MORE INFORMATION
25Vmcpd.vxd controls the floating-point operations in Windows 95. 
26
27Modification Type: Major	
28Last Reviewed:	12/17/2000
29Keywords: KB136255

It is good to know that I can disable the NPU in Safemode so that I don't have to remove the physical FPU.

Small update:

I've been working on this system for several months now, so thinking my memory might not be fresh enough, I reran the Am386DX w/i387 FPU. I did not receive the VMCPD.VXD error, however, the system still is not usable (that's the part I remembered, "doesn't work"). Instead of seeing the VMCPD(01) blue screen at boot, I am able to reach the desktop, but receive an error for which I cannot do anything in Windows 95.

Illegal operation: Explorer executed an invalid instruction in module SHLWAPI.DLL.

I suspect this may be related to the lack of the 486 instruction set in the Am386DX. There's a good chance that Win95b/c makes use of 486 instructions. I receive the same error with or without an FPU installed when using an Am386DX. Thus, I cannot say for certain whether or not Win95a will work with an Am386DX+FPU on this particular motherboard.

The above SHLWAPI.DLL error will persist, that is, if the user presses CLOSE, the error will keep coming back.

I still haven't got anywhere on this, but wanted to clarify the Am386DX situation. There's still some hope that Win95a may resolve the issue with this particular motherboard. I don't have any pre-configured Win95a setups, so this won't be a quick test. I have, however, been able to use the same HDD/CF card (w95c) without issue on my IBM BL3 w/Cyrix FPU system and on an 8433UUD motherboard with Intel DX4-100. Thus, the evidence strongly points to a particular compatibility issue with this motherboard and FPUs [and possibly only when a 486DLC/SXL is installed].

I did try running an ordinary 486DLC with the L1:Disabled option set in the BIOS and not running any L1 enabling software. With an i387DX installed, the issue remains with VMCPD. Curiously, when the DLC is installed, I notice an additional blue screen stating exception OD in ELNK3.VXD, but it can be disregarded by pressing ANY KEY to continue. Why this additional blue screen doesn't happen with an SXL installed is a mystery.

feipoa wrote on 2024-05-05, 08:02:

I suspect this may be related to the lack of the 486 instruction set in the Am386DX.

This is odd. I don't remember Win95 not being bootable on 386 if installed on 486, but then again I haven't really done anything like that in a looong time. If you are up to some experimenting you could try a fresh install on 386DX to see if any of these problems go away. The error code does point to cmpxchg instruction, which is 486+ but I would think the kernel detects the CPU on boot and doesn't use instructions that are not supported.

AFAIR the problem with Cyrix DLC and x87 combo, that's mentioned in the article above, was some timing issue that glitched the I/O channel in some cases. So almost exactly as the problem I have with my 386WB but specifically related to a particular Cyrix CPU steppings - or at least Cyrix claimed this was corrected later on. Can't remember now if on DLC side or x87 side (or both?). This is mentioned in coproc.txt and actually also mentions early OPTi chipsets so that's why I'm sticking to my theory.

A little further digging into Win95a and Cyrix, from the General.txt : Computers with Cyrix CPU
"If you have an Epson 866C or Microcenter Winbook computer, you may experience periodic general protection faults. To fix this problem:
1. Copy WB16off.exe from Windows 95 Setup Disk 1 (or if your product is on CD, from the \Win95 directory) to your Windows directory.
2. Add the following line to your Autoexec.bat file: c:\windows\wb16off.exe "
Epson 866c had a Cyrix DX2-66 from a quick read...but no math-co

Horun, that's really out of the box. I'll try it though.

Deunan, yeah you'd think there would be some CPU detection routine and not use instructions not present on the CPU, but Win95 b/c were for OEM's only. Were there any new systems with an Am386DX or i386DX being sold in 1997? Another possibility - I think I have some Win95 unofficial service pack installed, so it might be expecting 486's.

On some further news, I setup the PEM-4036YB with the same hardware and BIOS used on the PEM-4030Y, but the problem with Win95c and a FPU installed prevails! I think I'll grab a 386 board with a non-Symphony chipset to test.

feipoa wrote on 2024-05-05, 08:02:

Illegal operation: Explorer executed an invalid instruction in module SHLWAPI.DLL.

I suspect this may be related to the lack of the 486 instruction set in the Am386DX. There's a good chance that Win95b/c makes use of 486 instructions. I receive the same error with or without an FPU installed when using an Am386DX. Thus, I cannot say for certain whether or not Win95a will work with an Am386DX+FPU on this particular motherboard.

The instruction cited in that error message is indeed a 486 instruction. It was uncommon at Windows 95 times to unconditionally use 486 instructions in code paths relevant for 386 systems without checking the CPU type and falling back to a 386 instruction code-path. The specific instruction in this case is "(LOCK) CMPXCHG" which can be used to efficiently implement locks, especially on multi-processor systems. Do you know whether you SHLWAPI is an original Windows 95 library, or it has been "helpfully updated" during some software installation?

On my Windows95c system, with lots of other software and updates installed, this is the information for: SHLWAPI.DLL
SHLWAPI.DLL
version 5.50.4807.2300
294 KB (301,328 bytes)
July 23, 2001
Windows 2000

On the Windows 95c (OSR 2.5) CD-ROM, cab20:
SHLWAPI.DLL
version 4.70.0.1155
36.0 KB (36,864 bytes)
August 24, 1996
Windows NT

It does look like this file was updated at some point. Maybe IE4 integration, then later IE5? Maybe the unofficial Win95 service pack?

Swapping the SHLWAPI.DLL from the CD-ROM into C:\Windows\system will not help the issue as there are several other associated files which need to match up. Nonetheless, I have no intention of running an Am386DX or i386DX on this system.

...

I placed all the hardware from the Symphony461-based DTK PEM-4030Y board onto another 386 motherboard, a Chaintech 340SCD, which is based on the SiS Rabbit chipset. The Chaintech is able to boot into Windows 95 with the FPU installed. No problem. Thus, the issue with the FPU is somehow related to a specific combination of the DTK's motherboard hardware and Windows 95.

Once I was in Windows 95 on the Chaintech system, I set the NPU to disabled in System Properties, then placed the hardware back into the PEM-4030Y motherboard, but I still get the VMCPD.VXD blue screen error and cannot continue loading Windows 95. I'm out of ideas to try next... anyone?

feipoa wrote on 2024-05-06, 04:18:

I have no intention of running an Am386DX or i386DX on this system.

I think this will be my next project 😀 But I'm in no rush, tons of other things to do first, so don't expect results anytime soon.
It's a good thing you mentioned the unofficial service pack, I'll be more careful installing stuff and I'll try to create backup images of the CF card (or HDD) between such steps so that I can revert to previous state more easily. I wonder if I could speed this up by setting up PCem with the exact HDD geometry I will use...

feipoa wrote on 2024-05-06, 04:18:

Thus, the issue with the FPU is somehow related to a specific combination of the DTK's motherboard hardware and Windows 95.

Are there any BIOS setting related to the NPU? Like "Co-processor Ready# Delay" that you can see in the photos here: Re: 386 dram 0 wait state causes no boot, cache related?
At this point I'd also play with cache settings, RAM WS, anything that could upset the system. Perhaps there is something else there that makes Win95 unhappy for some reason.

Deunan, your next project is setting up an Am386DX? At least put a DLC in there to make it more interesting.

Yes, I have tried lowering every sort of BIOS setting; it doesn't help. Unfortunately, the NPU option in the BIOS doesn't let me set it to disabled. It is an automatic setting only, with no override. This means I have to physically remove the NPU to boot to Win95.

There is not any "Co-processor Ready# Delay" option. There's not even a DMA speed setting. The only BIOS configuration page is shown here:

These two Symphony boards do demonstrate further strangeness in that I must have their sound card drivers set to 'single-mode DMA', rather than what I believe is the default 'Demand mode DMA'. If I do not set single-mode DMA, I only hear white noise when playing sound. There's another thread on this issue, but too, without resolution. How to set Single mode DMA on ESS ES1868 drivers in Windows NT 3.51? If you know anyone who can modify the Windows NT 3.51 drivers to have a single-mode DMA option, or even have single-mode DMA hard coded, please let me know. As it stands, this system only works well in Windows 3.11. It can work in Win95 w/out NPU, or within NT 3.51 / 4.0, but without sound, regardless of the CPU installed.