feipoa wrote on 2024-05-07, 09:18:

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

Win95 on 386. I might even consider installing it from floppies for the fun of it. I'm sure I'll put a DLC in at some point as well (and also SXL) for testing. I've built a Debian machine out of my 386WB mobo (for which I had to set up my own package repository on a modern Linux box) but I doubt I'll be happy with the Win95 performance, so I'll probably end up imaging the card and reusing parts for different project.

feipoa wrote on 2024-05-07, 09:18:

These two Symphony boards do demonstrate further strangeness

I guess these mobos have some quirks that make them unusable in some cases. I remember quite a few issues with HW even back in the DOS era (I/O cards somehow not working properly when trying to setup a daisy-chain "network" for Doom or Diablo using serial ports, my slow SVGA using 128k banks which most games didn't support even though VESA spec allows it, the stereo issue of SBpro and some clones, various problems with PnP cards and old BIOSes, etc).

I see you have a few shadow regions defined, is it for XTIDE? Disable the ones you don't use, might help. I'd also try enabling memory relocation if you have less than 16M of RAM installed, every bit helps.
The options I'd play with are I/O recovery time and ALE (should be ISA-specific but who knows) and fast A20 gate since I've dealt with mobos where this is broken. Though that would probably trip the kernel right away rather than cause issues with libraries.

BTW did you try de-turbo? How does this mobo implement turbo anyway, via CPU clock or extra RAM waitstates? If the former then it might just help the timings and solve some issues. Obviously it would not be usable like that but at least offer some extra info about the mobo.

I definately used to install Win95a on an Am386dx from floppies. I still have the original Microsoft Win95-floppy box set I bought from that era. Win95 performance wasn't great on the 386, not even for 1996 standards.

Those shadow regions are for:

Promise FloppyMax - adds boot/BIOS support for the LS-120 SuperDisk as A:\
AHA-1522B SCSI card

Since you mentioned XTIDE, I do plan to get that going as a test for the system without SCSI, just to see if the SCSI card is somehow interfering with the audio. The CF card I'm using is on SCSI via ACARD adaptors, so hopefully it will be a straight plug-in to the IDE controller w/XTIDE.

I'm using 32 MB. I don't particularly care about the extra 300-ish KB with memory relocation. On some motherboards, I've run into trouble with that feature, so I usually leave it disabled.

I have already tried adjusting the I/O recover times, ALE, ISA speed, Fast A20, etc.

I have not tried de-turbo. Great idea! On this system, I cannot hot de-tubro. I must de-turbo before power on, or before POST, otherwise system hangs. I haven't looked into how de-turbo is implemented.

I set the system to de-turbo mode, and boy was it slow, however I still could not boot into Windows 95c w/FPU installed. I also still heard white noise while playing sound in non-single-mode DMA (mkarcher referred to this is Demand Mode DMA).

For completeness, I should reinstall Win95c on a formatted CF card, then check for FPU issues again. If FPU problems still present, then install Win95a. I'm using USB Imager in Linux, so reverting back to my existing setup will be quick.

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

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?

Was that the full TI486SXL cpu & FPU on the Chaintech board?

MikeSG wrote on 2024-05-08, 08:51:

Was that the full TI486SXL cpu & FPU on the Chaintech board?

I'm not sure what is meant by 'full' ? I was using the same SXL2-66 PGA on a 168-to-132 interposer with a Cyrix FasMath CX-83D87-40 on the Chaintech 340SCD. The SXL was running at 2x33.

I just meant both TI486SXL and FPU.

Horun mentioned on the last page, but if the DTK PEM-4030Y (Symphony Labs SL82C460) board has 16bit write burst, it might interfere.

https://www.betaarchive.com/wiki/index.php/Mi … _Archive/134295

MikeSG wrote on 2024-05-08, 11:43:

I just meant both TI486SXL and FPU.

Horun mentioned on the last page, but if the DTK PEM-4030Y (Symphony Labs SL82C460) board has 16bit write burst, it might interfere.

https://www.betaarchive.com/wiki/index.php/Mi … _Archive/134295

Thanks for reminding me. I wrote previously that I was going to try wb16off.exe but later forgot about it. I will try it soon.

Unfortunately, placing WB16OFF.exe into C:\Windows or C:\windows\system and adding it to the autoexec.bat file did not change the situation with the VMCPD blue screen on startup.

I'm gonna mention it even though I guess you already tried

Came across this https://www.oocities.org/~budallen/fatalexp.html
mentions

13 (0Dh): General Protection Fault
Any condition which is not covered by any of the other processor exceptions will result in a general protection fault. The exception indicates that this program has been corrupted in memory usually resulting in immediate termination of the application.

Have you tried with a different amount of ram ? 😀

Thanks. Yes, I tried booting with 32 MB, 16 MB, and 8 MB. Still get VMCPD error. So far, the only way around it is to remove the NPU.

feipoa wrote on 2024-05-07, 09:18:

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.

I made adjustments to AUDDRIVE.SYS both for Windows NT 3.51, driver Version v1.03 and Windows NT 4.0, driver version 2.01.18. The original drivers are attached at How to set Single mode DMA on ESS ES1868 drivers in Windows NT 3.51? .

Here are replacement files that were already tested by feipoa to solve the issue that his board is incompatible with the ESS sound card when using demand mode DMA. The patched driver is using single mode DMA all the time, which may impose performance drawbacks, and is only useful if demand mode DMA does not work correctly. This is not meant as generally recommended "improved" version of the driver.

I named the patched file AUDDRIVS.SYS (S = single mode), you can overwrite AUDDRIVE.SYS after installing the original driver with it, or you might create an INF file that actually provides two selectable drivers, one using demand mode DMA (by referencing AUDDRIVE.SYS) and another one using single mode DMA (by referencing AUDDRIVS.SYS).

The changes are put in the public domain - the original driver is obviously still copyrighted by ESS.

As this is the first time I've run into this problem, I wonder if this white noise issue only affects Symphony 461-based systems. Note that I needed to rename AUDDRIVS.SYS to AUDDRIVE.SYS in order for the installation to work with the other ESS driver files.

Deleted my 4 GB FAT32 Win95c partition on the 8 GB CF card, then tried to install Win95a on a new 2 GB partition, but Windows kept complaining about something. Unhelpful errors like "Setup cannot install Windows 95 on your computer. An error was detected while formatting your primary hard disk partition". It would specify this at 99% formatted. The DOS 6.22 installer had the same issue.

After some confusion, it turns out that Windows 95a doesn't like installing if there's an NTFS/NT partition on the HDD. I removed everything on the CF card via FDISK, then installed Windows 95a. I forgot how slow installing Win95a from diskettes was. Windows 95a finishes installing (SXL + FasMath installed), then reboots. We are at the point where Setup wants to setup Control Panel, Programs on Start Menu, etc... when the VMCPD blue screen appears.

Thus, Win95a has the same problem with DLC-class processors and an FPU. I completed installation using an Am386DX + FPU. Then I disabled the NPU in System Properties, plug in the SXL2, and reboot. No blue screen. Strange. I don't know why disabling the NPU in Win95a works, but not in Win95c. Maybe has something to do with those updates I did to Win95c which insists on 486 instructions.

Still, no working FPU in Win95a, but at least it booted with NPU disabled in System Properties.

My IBM BL3-100 is able to boot into my Windows 95c installation. System Properties shows no NPU. I run Autoddetect hardware and it finds the NPU. I then set NPU to disabled in System Properties and reboot with the SXL2 installed. VMCPD Blue Screen shows up. Put BL3 CPU back into the motherboard, but VMCPD Blue Screen shows up. Strange.

I am noticing that the NPU option in the BIOS stays on ENABLED when the SXL2 CPU is installed, but if I have the IBM BL3 or Am386DX CPU installed, I can set the NPU to DISABLED.

feipoa wrote on 2024-05-10, 10:23:

I am noticing that the NPU option in the BIOS stays on ENABLED when the SXL2 CPU is installed, but if I have the IBM BL3 or Am386DX CPU installed, I can set the NPU to DISABLED.

It could be a buggy BIOS. Some apparently don't even allow to change this option, it's autodetect only. In fact it's not impossible that certain HW configuration makes the BIOS mess up some mobo setup registers, which then trip Win95 for some reason.

If I understood correctly, running the system once with DLC also messes up things for the IBM chip? Did you try loading BIOS defaults and restoring the required settings one by one, to see if it goes away with IBM CPU?
Also, 386DX works properly with the NPU installed, correct? So the issues on the other OS are probably related to some software that installed 486-only system libraries?

Deunan, you read correctly. Once I installed SXL, then tried to go back to the IBM chip, it shows got blue screen. Only worked with IBM if I hadn't put the SXL into the system yet on a clean w95 installation.

I did not try to reload default BIOS settings, then reset my preferences. I just looked at the settings and they looked OK. I'll try soon if my plan below fails.

Yes, the Am386DX worked fine on a fresh Win95a installation with the FASMATH NPU. Yes, the 486-only libraries was messing up the potential use of an Am386DX on this system.

My next plan is to:

Install Win95c fresh (FAT32) with the Am386+387 installed. Go into System Properties, disable the NPU, swap to the SXL2 (leaving FPU installed). Reboot, hope it works. Then don't every swap to BL3, or try to enable the NPU in software.

The plot is thickening...
Win95c fresh install...

Am386DX + FPU + System Properties NPU enabled = Windows 95c runs fine

Am386DX + FPU + System Properties NPU disabled = VMCPD blue screen (Win95a ran OK here)

Am386DX + removed FPU + System Properties NPU enabled or disabled = Windows runs fine

SXL2 (L1 disabled) + FPU + System Properties NPU enabled = VMCPD blue screen

SXL2 (L1 disabled) + FPU + System Properties NPU disabled = VMCPD blue screen (Win95a ran OK here)

SXL2 (L1 disabled) + removed FPU + System Properties NPU enabled or disabled = Windows runs fine

In short, if I want to be able to boot into Windows 95 using my SXL CPU and not physically removing my FPU, I can only use Windows 95a. For this to work, I must have the NPU disabled in System Properties / Device Manager.

A few drawbacks of using Win95a:

I must reinstall Windows 95 and setup all my applications (20 hours of work)
I must also reinstall NT4 and setup all applications (recall that Win95a did not want an existing NT partition to format the HDD correctly)
My Promise FloppyMax controller/BIOS and LS-120 drive show up in MS-DOS compatibility mode in Win95a, but not Win95c. This is a known limitation. It must run in 16-bit mode.

feipoa wrote on 2024-05-11, 09:05:

Am386DX + FPU + System Properties NPU disabled = VMCPD blue screen (Win95a ran OK here)

That one is still weird. You are probably done with this by now but if not then consider installing 95B (OSR 2.1). There might be a bug in the later kernel or libs that causes this issue. With the original RTM version you loose FAT32 support, and USB among other things.

I didn't even realise there was a Windows 95 OSR 2.1. But looking at the table on the wiki page, https://en.wikipedia.org/wiki/Windows_95
looks like there was. I have Windows 95 retail release, OSR 2.0, and OSR 2.5, but no 2.1. Did 2.1 just add the USB supplement? I remember installing those USB files for OSR 2.0 in the past without issue, but on an ISA only system, USB is not happening.

Do you think trying OSR 2.0 is sufficient?

At present, I'm getting my drivers setup on win95a and will probably install NT4 along side it. I can easily make an image of the CF card on my Linux system, then try a clean install of OSR 2.0, but it doesn't guarantee the SXL will work with NPU set to disabled in System Properties. It will take about an hour of waiting to answer this question.

Deunan, for completeness, I decided to install OSR 2.0. It took forever on a 386DX - even slower than the w95a diskette version. Unfortunately, once I disabled the NPU in System Properties and restarted, I would get the VMCPD blue screen. This is with the Am386DX, so no purpose in trying the SXL2.

It looks like I am stuck with Windows 95a, or run Win95c but tolerate physically removing the NPU each time I want to run Windows 95. I will likely stick with Win95a and just put in the hours to install all the apps, updates, and do the same for the NT4 partition. Luckily, the more useful CF card with w31/nt351 is already setup. The w95/nt4 CF card is mostly an extra curiosity.

On the flip side, if anyone has any other suggestions to get the SXL2 + FPU working in Windows 95, I'd likely give it a go. It is fairly easy to copy my disk image back to the CF card.