SweetLow

If you said about error in some software you had to describe exactly error in software, not behaviour of hardware. If you have error in himem.sys then take patched version (one of the two "preferred", of course) and just replace %windir%\HIMEM.SYS (or anywhere you want). >if you know whether "patcher9x" package includes all fixes from rloew's patchmem not all fixes, but all essential

It is normal for hardware with Always On A20 line, I assume it is obvious.

Hibernate support AFAIK. Yes for _PATCH_ itself. But you can use SATA.INF, of course, if you wish. I said about binaries and .INFs already above. I don't understand what did you ask. You can not use two .INFs simultaneously. You should select one of them for particular adapter.

>can any of your updated versions work on Windows 95 Osr 2.x? EHCI_506.PDR - probably: https://msfn.org/board/topic/187782-silicon-image-si680other-unsupported-pci-ide-controller-under-windows-95-osr-20/page/2/#findComment-1286966 I don't use any of windows 95 now. So check and tell us. >I was thinking i can use the updated ACHI.PDR Yes. > requiring also PATCHSATA No. This ESDI_506.PDR is prepatched standalone version (including enhanced version of PATCHSATA). You can use new .INF file too for "SATA" adapters: http://sweetlow.orgfree.com/download/WIN98SE_ATAPCIBM.ZIP but there is not strict dependency between binaries and .INFs. And "WIN98SE" in the name of file is just the source of original file, it should work on any Windows 9x. >but the specific version of ESDI_506.PDR becomes irrelevant when switching to AHCI mode and using the ACHI drivers Yes. ESDI_506.PDR and AHCI.PDR are completely independent (as the hardware they handle are independent). >Can users replace all updated files in your package into the original package of Rloew's files and use in the same way Yes. They can be used this way too. But not with RLoew's packages only. Anywhere you meet ESDI_506.PDR (of according OS, of course; Millenium ESDI_506.PDR has some additional features for example and is not recommended to be replaced) or AHCI.PDR just replace them with these patched versions.

http://sweetlow.orgfree.com/download/esdi_506.zip Fixes: 1. [TBP2.1 - BigHDD] Fixed - data underrun in the initialization procedure of PM Only drives. This resulted in slowdown on booting (sometimes significantly) and caused other problems. 2. [98SE] ATA devices are no longer considered to be in a stopped state (SpinDown) after initialization. 3. [98SE] The CMOS type of a PM Only drive on non-primary ATA channels when added after the boot stage is now consistent with that during boot. 4. [98SE] Fixed the setting of the I/O request call method in the drive initialization procedure. This did not affect functionality in the vast majority of cases, but has been improved nonetheless. Update is recommended due to point 1.

There is exact answer your question. Stan Mitchell, Inside the Windows 95 File System,1997

https://github.com/oerg866/win98-quickinstall/issues/22#issuecomment-4488077576 RLoew's Terabyte Plus 3.0 ESDI_506.PDR data corruption bug. Fix: http://sweetlow.orgfree.com/download/esdi_506_tbp3.zip

0. Use the newest versions of ESDI_506.DPR & AHCI.PDR too. 1. C:\WINDOWS\SYSTEM is not need, of course. 2. Literally few days ago when I solved problem of executing ATA commands (like setting PATA transfer mode for PATA device on SATA Host - PATA Device bridge) I made the dumper of IDENTIFY info without using smartvsd.vxd interface too, so for the first take: https://github.com/LordOfMice/Tools/blob/master/atainfo.zip unzip content and run DumpIDENTIFY.exe. You should get 3 .DAT files and no errors or warnings. 3. If success on step 2 then try to use SMARTInfo - this is the same thing as DumpIDENTIFY but with smartvsd.vxd interface using. You have to get IDENTIFY.DAT dumps too and no errors.

If you said that 98SE ESDI_506.PDR 4.10.2225 works in 95 OSR2 then it is half of work as ESDI_506.PDR from TBP should work in 95 OSR2 too.

Now reread my post about what Rloew did and what he didn't. >Interesting, it is also not tied to single vendor drives? Yes, it's generic.

Requirement for patch is NOT what patch does, I assume it is obvious. And you continue skipping some parts of information. Take it all. MANUAL.TXT -> HARD DRIVE SIZE LIMITS None of them. And it does not use even one byte of memory after it did its work.

I assume no Rloew neither LLXX released ATA 48-bit LBA drivers for 95/98FE/ME, 32-bit only. 48-bit ATA commands used internally of course, but processed LBA in driver restricted to 32 bits. The real ATA 48-bit LBA drivers are available in Terabyte Plus Pack for 98SE only as RLoew never released generic 48-bit patch (but referenced it in some manuals). If there is no hang during boot, only size restriction in BIOS than it can be fixed to view full size under Windows probably. I made very similar patch for fixing problems in BIOSes for >128GiB/2TiB drives like using LBA 28-bit only size or wrap-around the size of >2TiB drives.

http://sweetlow.orgfree.com/download/SiI0680.zip Take \NEW\ATA0106.INF version for the first. If it will not work - make new version of devtree.txt WITH INSTALLED driver and resend it.

Ok, CC_010600 is "Serial ATA controller - vendor-specific interface". It is unusual for PATA controller. But no matter, use RLoew's ATA0106.INF from Terabyte Plus Pack with patched ESDI_506.PDR. If you sent me info I asked I could verify that this .INF really will work on your hardware but you continue to ignore some parts of request.

SUBSYS (subsystem) and CC (class code) are definitely different things. Looks like it will be endless with SUCH approach. Ok, get: https://github.com/LordOfMice/Tools/blob/master/devtree.zip run devtree.exe /vv /p > devtree.txt in console and put result (devtree.txt file with size ~ few tens of kilobytes) somewhere to download

Well, knowing now internals of ESDI_506.PDR I solved this puzzle completely from the second attempt (the first attempt was disabling IOR_IDE_PASS_THROUGH handler to prevent BSoDs): IDENTIFY (including ATAPI devices) and SMART commands work in AHCI.PDR Plus fixed few other bugs seen in process of main development, I personally recommend to pay attention to N5. http://sweetlow.orgfree.com/download/ahci.zip readme: Patches of RLoew's AHCI.PDR 3.0 1. Fixed broken handler of information about internal structures (system hangs/reboots when trying to read them). 2. Fixed accessing an uninitialized pointer variable (wild pointer) in the power-down handler (SYS_POWER_DOWN) leading to BSoD / hang-on / reboot. Thanks to https://github.com/PluMGMK 3. Fixed bug in the handler for ATA commands without data transfer, such as standby drive or working with removable media. These commands were previously just not executed. 4. Made new working handler of IOR_IDE_PASS_THROUGH request, IDENTIFY (including ATAPI drives) and SMART commands are supported. 5. Fixed random CPU port write access in some cases on executing Input/Output Request. 6. Fixed bug in enable Media Status Notification function. 7. Memory copy speedup in Input/Output Request handler.

MSINFO32, REGEDIT Be careful, you can not get simple information after third iteration and ignores some data for unknown reason. It is not smart behaviour.

1. SiI controllers have 3 modes - pure ATA, non RAID and RAID. 2. I assume it simpler to see the data than post on forum.

PCI IDs, including Class, Subclass and Protocol like this --- Bus 01, Device 0B, Function 00 - Silicon Image, Inc. RAID Controller --- PCI\VEN_1095&DEV_3112&REV_02&CC_010400

There are special .INFs from RLoew or me for ATA controllers in PCI Native Mode or non-RAID mode of SiI controllers (check what you really have BTW). Sometimes it works without them but it is better with.

Real PCI ATA controllers work in PCI Native mode so usual ESDI_506.PDR will not work. You need something like RLoew's "SATA" patch but IDK does it work for 95.

Yes, it's possible to do this. But 1. it is not clear result as you do calibration of CPU wait loops in one mode (fast with caching) and then use this waits in other mode (very slow without caching). That's why I slow down system before starting Windows, not in running Windows. 2. It is not works always. For example trying to disable WC for non-local buffer in system memory on Radeon PCI-E cards (direct emulation of AGP behaviour) leads to immediate freeze. Because it is DMA working, CPU less involved.

No, processor caching control is not PCI entity. You can use my package for MSR & MTRR processing (and just use MTRR_RST.EXE from it now) or use "CPUSPD cd" for example for disabling caching in CR0 control register.

I booted to DOS prompt and disable cache (two methods used - through MTRRs or through cache control bit in CR0) and then run Windows - for clean result. Booting is painfully slow but possible nonetheless. P.S. AFAIK this does not disable caching of SM area but I can't imaging scenario that can influences HDA controller using.