rloew

I can't say without running some experiments, but I think he is running with about 99% of his System Arena filled.

Only disabling the Kernel Mixer reproduced your problem (Record yes, Play no). Disabling the Kernel Renderer killed everything. The rest, except the USB Audio itself, had no effect.

Delete/rename ACPI.SYS. Reboot. Install "PCI Bus" if needed.

SCANPCI does not provide enough information to make these choices. It is not even in any of my Products. I posted it to help diagnose problems. The Patches are normally installed long before NIC Drivers are installed, so the need for the /M Option cannot be determined in advance. The Option also handles large Registries. The size of the Registry can grow arbitrarily depending what the User installs later. Even I don't know when SPLIT8MB is needed. I thought it would no longer be needed when I developed the /M Option. Those games had far fewer things to check for. I doubt many of them would work in newer systems. I have already encountered enough of them that cannot even handle more than 2GiB of RAM. Also as I said before, they have the volume to cover the cost of testing on a large number of systems. Microsoft has 35 special cases, just in the ESDI_506.PDR Driver. In any case, I don't see my other customers clamoring for your "holy grail". So it will stay just as unobtainable as THE holy grail. Or are you offering to finance the time and equipment needed since you are the only customer?

Does the writing Error appear before the Desktop appears, shortly after, a while later, or do you have to do something to make it happen?

The clean installs seem to be OK except for the nVidia DLL Errors. I have seen these intermittently, not so consistently as you have. My Patch is for NVCORE.VXD so it is unrelated. These are separate issues. You can try removing/renaming NVCPL.DLL to cut down on the Errors. You might get some warnings about the missing file. I don't know much about the Intel 1000S MT. It's ID isn't in your SCANPCI dump. You mentioned USP3 in your third setup. It removes the SATA Patch. This would cause the ESDI_506.PDR failure. I noticed that NVCHECK said everything was OK. Did you flash the Video Card BIOS? If so, you can unpatch the Driver. Leave the PCI Patch, if used. Keep the Interrupt Fix. Since you bought my Patch, use the NVSIZE Program in the future. It gives a more detailed report than NVCHECK.

Yes.

Do you have Writing problems in true DOS to Drives connected to the Asmedia Controller?

8 DOS Boxes is not a lot, so there is a relatively small margin. I never measured DOS Box usage of System Arena RAM so I can't say how much. I don't know what other Programs need a significant amount of System Arena space. I guess you will find out. During original testing, I was able to run my old test system with 1GiB of RAM without File Cache Modification with my /A Option to eliminate the large ATI Video Driver footprint. It also didn't leave much margin. SE is limited to approx 1152MiB of working RAM without my Patch. ME can handle around 1.9GiB.

768MB generally works without any Patching. Newer Video Card Drivers generally have no effect. The issue I saw was with old ATI Drivers that tied up System Arena space. I added the /A Option to my RAM Patch to handle this.

SPLIT8MB punches holes in the first 16MiB of RAM so that large blocks cannot be allocated from it. This was designed to keep Gigabit NIC Drivers out of it. The later /M Option blocks this area during Initialization keeping the Registry from being placed in this area. This is usually enough to leave room for the NIC. Some recent systems seem to need both to leave enough DMA RAM space for other software. VFAT allocates 1 small block of DMA space as a reserve buffer. If this fails, VFAT aborts because there is no space left, so VFAT acts as the Canary.

You can debug the Driver by reflashing your Video Card Driver as described in the Manual for the NVSIZE Patch. After a reboot, NVCHECK can be used to verify that you did this correctly. Then you can use the Unpatched nVidia Driver. You would still need the PCI Patch and the Interrupt Fix if you were using them. There are a number of bugs in the nVidia Driver. My Patches fix the most serious ones.

You didn't set the Maximum File Cache, either in SYSTEM.INI, in the Control Panel, or by other means? If you didn't, can you open more than a few DOS Boxes If you are referring to the original generic VIA RAID Driver that claimed >137GB Support, it has a bug in it that can cause a specific block of Sectors to appear bad.

I have had the opposite experience. As a general rule, AMDs were more stable, (I only have one with a nForce chipset), had more features, and less expensive. Clock speeds have caught up, but differences in architecture make comparisons difficult. For example, AMD CPUs are faster for Multiply/Add operations while slower for Loops. I bought my Intel Z87 a few years ago to compare speeds, after hearing people say that Intel was faster, and to identify possible issues with my Products with Intel CPUs. The M5A97 AMD was faster than the Intel doing my Multi-Core Matrix Algebra program after adjusting for the lower Clock Speed. I saw the same difference when I bought my AMD970 SLI Krait. In this case I had to adjust for the higher Clock Speed. AMD CPUs have a number of MSRs and APIC Functions that come in very handy. I had to make multiple changes to my Multi-Core and MEMORY64 Packages to support Intel CPUs. The Z87 was the first Computer I found that needed SPLIT8MB to Boot.

The first Machine is passable as far as RAM is concerned. The truly unmodified RAM limit is not 512MiB as Microsoft says. It is around 768MiB, more or less, depending on how many DOS Boxes you want to open at the same time and type of Video Card Driver. The Second and Third Machine need the File Cache to be limited to be stable. How is this implemented? The Third Machine also needs a Patched Hard Disk Driver to work with more than 137GB of the 640GB Drive.

Theoretically you could, but you are getting errors so there may be a problem. Moving to SATA3_0 would help isolate the cause. Move only the Sintechi for now.

That System is committed. I used another System that had no Sound Card. I Installed the USB Audio Adapter. Only it appeared in Device Manager. There were many Devices visible, including the one you mentioned, in Safe Mode. By experimenting, I found that I only had to Enable the Kernel System Renderer and the Kernel Audio Mixer to get Sound Playback. Without the Mixer, it apparently would support Recording but not Playback. I would look at the Mixer Device. This uses WDMAUDIO.INF and KMIXER.SYS.

In normal Mode. I have seen the others on different Computers. I'm not sure what Installs or activates them.

I don't think any of those Devices are needed to get USB Audio playback. I just installed a USB Speaker. In the "Sound" section I only see a PCI Sound Card and the USB Audio Device. Nothing else.

That is the HD Audio Bus.

The Asmedia Controller is set to Native Mode just like the other Controllers, so the SATA Patch is needed in all cases. All of the Controllers are set to "IDE" Mode currently. The alternative is RAID or AHCI. SATA 0 is the safest way to test as it is the First Primary Master. If you want to use AHCI for other OSes on SATA 0-3, you can try SATA 4.

You appear to be alone in thinking that these Patches require too much User Involvement. What you are requesting would require me to obtain all the Hardware and Software available and test every combination. I am not Microsoft, so I don't have the volume of business to cover my costs at any reasonable price. Even they don't do a good job based on your standards. The fact that you use a lot of Software makes it far harder to isolate problems as they interact with each other. You just spent quite a bit of time finding out that your "microfreezes" were caused by Anvir. You seem very quick to assume it's my Patches that are the problem without any verification, yet you are reluctant to consider other possibilities. I am still waiting for you to find an actual bug. You need to start from scratch, with only the basic Hardware, an empty Hard Drive, and an unmodified Windows Installation CD. Whenever you ran a test, there seemed to always be something unexpected present.

Windows 95 checks if there is a Mouse. If none is detected, It puts up a requester dialog. If you are in the process of installing USB Drivers and are using an USB Keyboard and Mouse, you cannot answer the requester. There is a MSDOS.SYS Option to override this. Corrected earlier post.

As far as I know, most modern Motherboards do not have COM or LPT ports.

Setting "Force M.2" made the problem Device disappear. I would recommend using this setting. I just noticed that the Asmedia Hard Disk Controller also is showing the incorrect code. Install the SATA Patch. Then move your Hard Drive to SATA 0 on the Motherboard. You may want to remove the Asmedia Card.