xrayer

> LoneCrusader > Thanks for the updated ZIP. Did you happen to compare the newer files inside to their older counterparts to see if there were actually any additions? Most of the files of that three packages was the same and created in 2013. Only about 3 INF was updated - you can see they have diffrent date 2014 in the package and some files was added. I also edited the XML to add VID, PID and INF entries that was missing. I already received uniata experimantel port for win9x from xeno and bearwin. There's IdeDma.sys that was suggested to rename and replace the pdr file. I tried it but it didn't boot (nither on SATA2 port) and hagned in black textmode screen. Xeno told me he developed this version olny under vmware and there was some issues that caused crashes. So I don't wonder it doesn't work oin real HW. BTW I use uniata for NT4 and I tried a lot of versions and many of them crashed or had a problem that CD/DVD drive didn't work. It took me some time to find the latest version with working DVD for me - it is ver 0.44b2.

OK, thanks. As I run my W98 at home as a hobby system without any commercial potential I don't intend to order commercial patches for it. So I sticked with alternate boot from SATA2 HDD. I just wanter to try myself all possibilities that I could try...

But ver 10.x is for Win7-10 only and it's reworked differently (useless). I'm confused about intel's versioning systems. It seem's there are more INF packages targeted for different platforms but in fact they are mostly overlaping. I see that version from supermicro web 9.4.2.1019 is even newer dated April 25 2014 * Target CPU/PCH: Intel® Xeon® E5 v3/Core i7 / Intel® C610 series/X99 chipset but it seems to be a mix of older INFs, e.g. file couide2.inf: DriverVer=07/25/2013, 9.2.0.1035 it's same as from package 9.3.2.1020 So probably there was only a few inf files added/updated... update: I compiled one zipped INF package with most of and latest versions of files collected from 9.x.x inf packages and uploaded it here http://ulozto.cz/xHLkZvUK/infxp944-zip (click "Stahnout", fill the captcha and click stahnout again)

>LoneCrusader this https://en.wikipedia.org/wiki/List_of_Intel_chipsets could give you some idea what ICH, MCH and CPUs belongs together but I think it's not needed to loose much time with it. I think that I googled a lot for the latest Win2k/XP compatible INFs so I doubt there's something newer than 9.4.4.1006...

OK, I did tried some attempt with TSR myself... I found an opensource program protect.com for DOS. It's simple to understand and modify. I modified it to be silent on discarded write access. The unload after Win98 boots is not so easy as I though because when a DOS window is launched and program executed again to disable it only affect environment of that one DOS window and not system in global. So as a dirty test I added a counter of dicarded writes with condition that passed all writes after reaching some count. Then I do trial-error tune of count to see how system will react. If I block more than about 300 writes it booted to GUI. Unfortunately whole write protection idea proved wrong because when write access via INT13h was reenabled Win98 hanged totally. So even after esdi_506.pdr driver takes control there still seems to be INT13h accesses that kill it. So what only could help would be to patch BIOS INT13h routine to not doing any buggy DMA operations. This task going too complicated over the discomfort of booting Win98 from slave HDD on SATA2 port (where I have smaller primary partition that I cannot easily increase because of need to keep extended partition on the same HDD below 8,4GB limit for DOS 6.22).

Ok, nice, is it freely available?

I tried to search for some existing old DOS disk write protection utilities and found something: Eric Auer's fdshield - this can protect various area or all disk but throws classir abort/retry/fail message that needs interaction and so boot failed The FANTOM 2.2 - (fanram.arj package from http://www.dcee.net/Files/Utils/ ) This looked much more promissing - from the description: This is new NICE programm to protect your Hard Disk from Human-Disasters. Catching Functions: Copy HD<-->FD Delete HD, FD Format HD Rename HD, FD CreatFile HD, FD EditFile HD, FD All operations looks as normally works(you may see what files copied, disk formatted e.t.c.), but really, when you reboot PC, all files/formatted disks will be Ok ! I don't know if it hooks INT13h or INT21h. With this loaded in autoexec.bat I was able to normally boot to desktop with all start-upo programs but then Windows displayed a message about new TSR detected thet may slowdown PC and the mouse freezed. After some seconds mouse relived and I closed this window but I cannot do anything else, clickink on icons/start doesnt work, system was inresponsive, correct shutdown cennot be done only HW reset. But it seems it's on a good way! I belive if I would unload the TSR during boot it would work but unfortunately this TSR doesn't have unload option (I could put a unload call to a batch executed automatically after the boot).

Realtek has some unified driver - sys file, that also was used for W2K and XP (that is obsolete now too, except XPE) so they may not want to disclose it. I don't remember other case where some company released public sources of their drivers. Simply Windows platform is closed source by default. BTW it's interesting that they still develop DOS drivers (god bless them for it)...

Did you ever get an answer? Maybe we should all email them with the same request... lol Of course not, as nVidia and some else I mailed e.g. for publishing some specification before. If you are not a big company that makes busyness with them nobody really cares, but I still try sometimes... BTW it's very different for small HW companies like DMP that makes their own x86 SoC and embedded boards (Vortex86) who have really kind support on theirs forum...

No, there IS difference, if I set legacy mode then also SATA3 port communicate via standard 1F0/170h ports and if I set native mode then SATA3 use FD00h port. Also the BIOS option is named like "SATA port 0-3 native mode enabled/disabled" (ports 0,1 are SATA3, ports 2,3 are SATA2 and ports 4,5 are disabled in legacy mode). I doubt that in my case is problem with odd address - it would also affect disk reading, not? I tried latest W9x Realtek drivers before and also newer W2k driver but none works with chip rev. E. >jaclaz LOL, I already have the Letter Assigner 1.2.0 on my W98 web and on my W98 CD but didn't looked there as I never needed this program before. I tried it and works fine, so I have finally the same drive letter order like if I would boot from SSD C:

>rloew I did one more experiment with Tenda (RTL8168) eth. driver. I removed my existing ndis driver and disabled "net start" in autoexec.bat (I load split8mb there). After reboot the RTL was detected and I installed uncommented Tenda driver. Immediatelly when it loaded my screen was garbaged and system hanged. After reboot I got "!" mark on RTL in devmgr and notice that driver was disabled by ASD due to failure. Even if I reenabled the driver it hanged again after reboot (all time I had disabled the EHCI sharing IRQ10). here's ASD.LOG Windows 98 4.10.2222 {CF2524C0-29AE-11CF-97EA-00AA0034319D} Starting a device Tenda TEL9901G Gigabit Ethernet NIC CI \V EN _1 0E C& DE V_ 81 68 &S UB SY S_ E0 00 14 58 &R EV _0 6\ 00 E2 00 >LoneCrusader, rloew Then I tried to set SATA native mode. If I boot from HDD (SATA2 port) it hangs after some loading and create quite big bootlog.txt where the last line indicating load of the esdi_506.pdr - so this should be the case where R.Loew's patch could fix it and boot will continue if esdi_506.pdr will be patched. But if I boot from SSD (SATA3 port) it, as usual, hangs much much sooner (bootlog has a few kB) due to vDMA problem so esdi_506.pdr has no chance to load and take control over. So this imply that the current patch will not help me. And I really don't need to use SATA native mode as I have only 3 devices attached (will be 4). >rloew "I have done this experimentally." - what do you mean exactly? Did you make some INT13h patch TSR? Something freely available to test? What do you think about idea to discard write request on INT13h? I don't know if Win98 really needs to write on disk before esdi_506.pdr will load - of course it will diable e.g. the bootlog. In other words - can Win98 boot from read-only disk up to stage where esdi_506.pdr loads (I assume that then INT13h is no longer used but what about in DOS window launched after boot?)... >LoneCrusader the MSHDC.INF seems to not updated (2013) and doesn't contain PCH SATA. MSHDC.INF is not included in your updated ZIP from dec 2015. Did I missed it or it's not done yet? >jaclaz Thanks, that looks promissing. It's a pity that it ended in dark abyss of the Internet so if it would work I will host it on windows98.xf.cz

OK, I may give it one more try since I solved conflicts with other devices. But as it runs only 100Mbit it may parform worse than Rmode NDIS that indicate running at 1Gbit and also don't produce any warning. Also boot process it quite fast. OK, and could you be a bit more detailed what the SATA patch do or what's aimed to fix? I'm not sure if it's targetted to this specific Issue as my SATA2 ports run fine. From the short description "SATA Patch and INF File for Windows 9x." I cannot Imagine. I can see that even with Lone Crusader's updated INF files I don't have SATA controller installed but a standard IDE. It seems OK as I have set IDE legacy mode in SETUP instead of native so SATA stays completly hidded for Win98. I can try reenable it. I think my problem can be fixed 2 ways: 1) have a native SATA driver like UNIATA that will take UDMA control as soon after boot (but maybe it will hangs sooner before such driver will load if windows tries to write something - a alog file or registry or so...) 2) make a TSR that will modify or hooks INT13h services to not use DMA transfers or at least discard write access until other IDE/SATA driver can load. The case of making XHDD driver handle DMA using XMS and be compatible with Win98 was denied by Jack as it would require a lot of effort to match Windows driver specifications and do workarounds of Windows memory managements bugs and that is far out of scope of XHDD driver which is intended for DOS only... So nothing simple. Anyway I can quite good stay with booting from CH0-slave HDD via BIOS boot manager. Is there a way how I could easily swap the drive letters under Win98? I have more primary FAT16/FAT32 partitions (2 on SSD and 3 on HDD) which letters are assigned differently when I boot from HDD than from SSD...

Yes, I don't wonder that it probably cannot. For me Tenda driver didn't worked but maybe because of the same IRQ sharing problem. Can you check what other devices use same IRQ as RTL in your system? Sigh, why the PnP hell don't allow me to change resources manually (or very limited only for devices like COM and LPT)... Is there available some demo testing version please? No, I don't use AHCI. When I enable AHCI in SETUP then disks are not detected by BIOS itself on power-on BIOS screen but it launch optional PCI ROM with AHCI BIOS that detect disk after. But I agree that AHCI BIOS is a piece of crap. When I was testing with single disk on SATA3 it boots Win98 and DOS in AHCI mode (via INT13h services provided by AHCI BIOS) without problem but when I complete my new computer and use one SSD as primary master on SATA3 and one HDD on primary slave on SATA2 it even cannot boot from the SSD and when I switched boot disk to HDD it resulted in FS corruption of one FAT32 partition on the SSD disk (yes I had some backup but...) so I don't want to see AHCI BIOS anymore! :\ For DOS I have now clean solution. J.R.Ellis released new version of his DMA drivers that contains XHDDBOOT.SYS which can be loaded without XMS before memory manager (it use lowmem) it take control of DMA over BIOS and after memory manager is loaded the full XHDD.SYS which use XMS for caching and disables XHDDBOOT.SYS. But this drivers are not compatible with Windows.

BTW 82801 is ICH (IO controller hub) that integrates more PCI devices with corresponding VID&PID and 82802 is FWH (FirmWare hub) - it's just Flash EPROM with your BIOS that have LPC interface (serialized ISA bus) so there's no VID&PID. 82801 has PCI to LPC bridge that has it's VID&PID. This 82801 chip is not Asus specific, it was used by many manufacturers in P4 era and later it was replaced by small cheap SPI serial Flash EPROMs. FWH may use some memory range and/or IO resources but no IRQ. I don't have such machine installed now.

I finally found why Win9x couldn't boot from devices attached to SATA3 port, see the bottom of my post here.

Hi, after a day messing around I finally managed Win98 USB 2.0 to work. I went to backup of my W98 install on old P31 board, copied in all machine*.inf files and let redetect the HW again. What a surprise, both EHCI, root hubs and generic hubs was detected fine but I got a BSOD after detection of SB audigy. When I disabled it the USB 2.0 works fine (with existing nUSB 3.3d I used before). Even the plugged devices was automatically detected in systray! I got high speed about 18MB/s when copying from USB flash, fine... But no sound, this suxx... So I give one more try, again restore the backup, infs and redetect. It seems that the process is a bit random like Win98 plays Motne Carlo with me (and the PnP). This time the USB stuff was detected fine, Soundcard was detected fine but I was unable to install NDIS driver for ethernet adapter RTL8111E (that worked for me before). When I browsing devmgr I didn't see any resource conflist but found that one EHCI has shared IRQ with the eth.NIC. So I tried to disable this EHCI and after some further messing I was finally able to install DOS NDIS driver and use it with Windows (it may have worse performance than 32b native drivers but still fine for normal browsing). If I reenable the second EHCI it worked for a while but I got a BSOD soon so I kept it disabled. So finally I have most of peripherals working as expected, summary: USB 2.0 - works 1/2 of available ports (only one EHCI active but at high speed and autodetection) Sound - works with SBA2 native drivers HDD/DVD - works with standard IDE controlled, speed is OK as BIOS supports DMA network - limited support of RTL8111E by DOS NDIS driver but fine for general use VGA - 7900GT/256M with latest nvidia beta drived works fine as before Here's my fully expanded devmgr tree "screenshot". The only remaining issue is that I cannot boot Win98 from my SSD attached to SATA3 port. It was discusses in this thread I found that it's caused by BIOS bug or rather BIOS simplification of DMA logic that doesn't properly suports DMA on SATA3 ports in v86 mode. It hangs on any write disk access. And as Win98 switches to v86 mode and tried to write to disk it hangs. This effect also happen under DOS if some advanced memory manager like JEMM/QEMM/EMM386 is loaded and switch CPU in v86 mode. I found that it can be cured by installing J.R.Ellis DMA driver before or just after loading the memory manager and DOS then can write to SATA3 attached disk fine. But unfortunatelly this driver is not compatible with Win9x due to some Windows bugs and it only boots to desktop where explorer.exe crashes immediatelly. So as a workaround I moved my Win98 installation from C: (SSD, primary partition) to D: (HDD, primary partition) and then I need to run BIOS boot manager at boot to choose HDD to boot. It then become C: so no need to change paths and Windows boots fine. But it swap also some other driver letters that are not so important at this time for me. Would the R.Loew SATA patch be related to this issue? I think that it would need a windows native SATA driver that will take DMA control over BIOS but intel didn't released any for PCH chipsets for Win9x of course. Maybe someone could write a drived based on UniATA opensource but I don't know how much are the disk driver models different from NT and how much effort it would be, probably unreal...

Interesting, I didn't know that's possible to run some DOS command after shutdown. Is is possible also with automatic windows start? If I will call win.com explicitly in autoexec.bat will it then continue next lines after shutdown? There's FDAPM utility by Eric Auer, that can shutdown a PC both APM/ACPI ways. If no APM detected then it parse ACPI table to learn how to shutdown it. The command is fdapm /poweroff Unfortunatelly due to latest unofficial nvidia drivers bug the windows doesn't reach the shutdown screen so I use reboot instead. If I want to shutdown automatiucally I create a flag file before reboot, then reboot windows at some event and when it boots again I check the presence of flag file on C:\ and if the file exists I will delete it and perform fdapm /poweroff. As flag file was deleted it will boot normally on next power on...

Here is my SETUP screen: There are 3 USB related options 1st enable/disable EHCI (if disabled it's not visible also under windows) 2nd enable support for USB keyboard legacy function (AFAIK it's done as SMM routine to be transparent to OSes but it's often buggy). I intentionaly use both PS/2 KB & mouse to avoid need of this 3rd enable support for USB storage (probably via INT13h extension) so e.g. DOS can access and also boot from it. I have enabled only the 1st option. The issue I previously mentioned with XP was not related to this BIOS options. I just wanted to note that I have to manually disable the USB hub power saving mode because XP couldn't power on it automatically. And I guess that Win98 may have similar problem but I don't know if such power saving function is enabled (or what is the default state) when USB INF or nUSB is installed.

Yes, I have normally USB Legacy Storage Support disabled, I only enable it when I need to boot from USB flash. Maybe the problem have some clue to USB power saving mode of USB ports - I had also problem with USB ports in WinXP that when I didn' have plugged any USB device during boot then it couldn't be detected later. But if I plugged them before boot it worked at high speed. Then I found that I need to disable USB power down of every 2 USB root hubs in device manager (the last tab). Maybe Win98 is also not able to succesfully power on USB ports automatically when some device is plugged in (power down feature may be enabled in chipset by default)... PROBLEMCHYLD already offered me his USB stack from the nSP and I tried but worked even worse - it siledntly detected some device at boot (probably the 2nd hub) that caused BSOD and I couldn't skip it.

I found on intel site version 9.4.4.1006 that contains more HW and 9.4.0.1027 https://downloadcenter.intel.com/download/24394/Chipset-Intel-Chipset-Device-Software-for-Intel-NUC-DE3815TY https://downloadcenter.intel.com/download/23061/Chipset-Intel-Chipset-Device-Software-for-Intel-Desktop-Boards They are not described to support XP but in readme it is and structure is same as older ones. This is probably why I failed to find it directly on intel's web but google showed... UPDATE: In my case I have no choice in SETUP to disable partial USB devices. Just enable or disable all. Maybe it could be achieved by manual messing with PCI config registers before Windows boot. Maybe Win98 PnP capabilities are exhausted to assign HW resources. I have similar problem on a notebook with PCMCIA controller where I cannot install PCMCIA disk driver otherwise I get BSOD. Under WXP it works, of course... I think using W2k driver would have better chances than Me as it's newer. I didn't tested W2k on my machine but I expect that when INFs are available for W2k same as XP, then it should work. Maybe it's needed to port more parts of W2k USB driver stack to W98 but wdmstub is little bit magic for me, I don't know it's capabilities.

BTW I found newer intel INF package version 9.4.0.1026 (5.8.2013) for W2K-W8.x. I wonder why intel withraw this from his site and offer much older 9.2.0 from 2011. The current version 10.0 is only for W7-10 - so this mean intel condemned XP to death. We would need make some unofficial INf package for recent HW (like Skylake and future)...

Thanks for the nUSB package. Today I made a new clean install (with himemx limit to 1GB) and used your INFs during 2nd install phase. It went as expected, most of devices was detected except USB EHCI that had "!" mark and some unknown PCI device that I already saw there in my older tests, probably nothing important. Then I installed nSP, removed 2 "!" marked EHCIs in safe mode and installed nUSB 3.5. After reboot it detected 2 EHCI, 2 USB 2.0 root hubs and 2 Generic USB hubs. Here arose the first problem. 1st Generic USB hub was installed OK (from USB2.INF) but the 2nd which followed makes Windows go BSOD. I repeated more times but it always lead to BSOD so I must skip this 2nd device. Afte boot when I go to devmgr and click Refresh the Generic USB hub was detected again, I must not to install it otherwise BSOD... But when I plugged the USB stick and skip that hub then Mass storage was detected and flash drive was detected succesfully. It took quite long time, about a minute. Then USB disk icon appeared in systray (of course not automatically, only when manual refresh). When I access the drive it's extremely slow. I copied a 0,5MB for more than a minute, commander show me ~6kB/s - LOL much slower than old floppy! But file was copied OK and was readable on other PC. So it works same crappy way like your X58. Here's my updated shot of devmgr:

Hi, I added requested files to package, download it again http://http://rayer.g6.cz/1tmp/nusb35cz.zip The usb2.inf and usbstor.inf are from CZ nusb 3.3 pack. I think it's not necessary to keep them localized - this is only names of devices and don't affect windows GUI. As there's no longer CZ maintainer I think it's better to use english verison of inf fils that is up to date than old localized ones. Aha, I read that the remove of UHCI happened since P55 so I though X58 is affected too. But R.Loew made it working even on newer chipset than mine so it is possible... What is Automatic Skip Driver agent and how do I disable it during install? But it's not related to already installed system...

I installed nUSB 3.5 and checked again that all files from the package are at the right place. Only a few of files are localized in CZ windows so I put them here: http://rayer.g6.cz/1tmp/nusb35cz.zip please can you make installer package of it? Unfortunatelly it still doesn't work. Here's my devmgr: I tried Refresh button after plug in but any new device didn't appeared in any section... Please upload a sshot of your devmgr on X58 to have better idea how it should look like. Is there some automatic tool that will carefully clean up any trace of previous nUSB from system, just to be sure if it doesn't interfere with some previous install. Probably I would need to try fresh install with your chipset infs and then nusb to prove it if the problem is not caused by some old config... BTW my USB stick has a LED that lights up when system detect it and communication is established. The LED blinks when system R/W the media. But in W98 it only blink for very short time when plugged in and doesn't light up. So it seems like EHCI/hub is not initialized.

I checked USBD.SYS and it's on a place: C:\WINDOWS\SYSTEM32\DRIVERS version 4.10.0.2226, size 18944B I tried to get nUSB 3.5 from MSFN thread but the link on zshare seems so be dead. After some googling I finally founf eng. version here http://www.tmeeco.eu/9X4EVER/GOODIES/(there are also a lot of drivers that may be useful) I extracted the files and going to find matching cz counterparts. Is it possible somehow to run installation proces from directory with extracted files? There seems nothing like setup.exe or else to run (I extracted via Winrar)...