SweetLow

1. Set using one channel expressy in controller properties in Device Manager. 2. After that check that you do not have NoIDE key in Registry HKLM\System\CurrentControlSet\Services\VxD\IOS It is APIC and HAL using it.

>this is insulated by checking Safe Mode The problem was reproduced in Safe Mode, it is definitely not the OS configuration problem. Something is unusually bad on your PC. Like Int 13h BIOS handler I suppose now. This can try to check and fix but process is far beyond casual user possibilities.

Check Variable MTRRs (and use something like Disk Test from AIDA64 for tests, it is much more clearer).

It can be problem with ACPI setted and storage drivers but this is insulated by checking Safe Mode.

1. Use Logged Boot and BOOTLOG.TXT to find the point of problem. 2. Use /M option in RLoew's big memory patch. 3. Do you can boot into Safe Mode (WITH RLoew's big memory patch)? >I reinstalled my old pc many times Why do you think that just reinstalling system can solve such problem? You try to use UNSUPPORTED hardware, reinstalling vanilla OS has zero chance to help.

>1gb ddr2 > SATA HDD 160GB It is collection of known (and already solved) problems. Both in pinned topics of this forum.

WHAT? If you got reboot when try to boot with logging - check the new BOOTLOG.TXT

http://sweetlow.orgfree.com/download/esdi_506.zip Added 2025/03/01: 1. [TBP2.1 - SATA] Data synchronization with BIOS: - Returned physical geometry extraction from IDENTIFY for drives with LBA. 2. [98SE] Drive parameters setting error in drive reset handler no longer causes a general read/write error for drives with LBA. 3. [98SE] Uninitialized CMOS drive type definition variable. For all but the first two drives on Legacy Primary Channel, it could have been anything, usually what was on Legacy Primary Channel (i.e. type 47), and if there was no Legacy Primary Channel, it was 0 or really something random. Now anything other than real CMOS data will give you a 95 disk type. This reflects the FFFFh value that was already used in the code for the unset parameter in one place, and now it is also used for the default value. 4. [98SE] Minor change: IDENTIFY read error no longer resets other flags and sets IDENTIFY error flag, but only sets the IDENTIFY error flag (OR instead of MOV).

What about the first thing wou have to use when you got problem with booting - BOOTLOG.TXT (dedicated to solving exactly such problems)?

P.S. And try to check some USB Storage - will it work too?

1. I have some planned test - try to do BIOS EHCI Hand On not in driver, but under DOS - really like you did (and I already have code for BIOS EHCI Hand Off under DOS). But it is not a high priority. 2. BIOS HAS TO do the things you did with controller manually exactly when BIOS EHCI Hand On takes place - but it does NOT.

There is test version: http://sweetlow.orgfree.com/download/usbehci.zip with BIOS EHCI Hand On, but it does not work on all tested systems. With high probability modern BIOSes just omit this function as NT-like OSes (and even ME) just do not have such thing as exit to real mode. Or some condition should met before transition of ownership for USB controller from OS to BIOS but there is nothing in standard about this.

Ok, I answer 1. If you are using (bul*****) browser which is literally violating Internet standards - it is YOUR problem. 2. But even in such case there IS workaround: Copy link and past it into address line and if you will get error - reload once again.

In reference dual booting of Windows XP and 98SE there is no such thing as "GRUB Loader" really, only NTLDR, BOOT.INI and something like BOOTSECT.DOS...

Release: https://github.com/LordOfMice/Tools/blob/master/ramdrv4m.zip >Unresolved problems at this time: >1. Due how the IOS works, there is two consecutive >blue screens with warning on exit to DOS when a swap file is located >on RAM Drive. This behavior is non-specific to RAMDRV4M. >2. RLOEW disks do not work after exiting to DOS Fixed too early destruction of controller object on Windows exit.

Release: https://github.com/LordOfMice/Tools/blob/master/cregfix.zip Added .SYS and DPMI versions

JFYI. much modern version of this pack is available now: http://sweetlow.orgfree.com/download/usb20_win9x.zip

Version for testing: http://sweetlow.orgfree.com/download/ramdrv4m.zip RAMDRV4M->README: >Unresolved problems at this time: >1. Due how the IOS works, there is two consecutive >blue screens with warning on exit to DOS when a swap file is located >on RAM Drive. This behavior is non-specific to RAMDRV4M. >2. RLOEW disks do not work after exiting to DOS. I managed to write a workaround for these problems (under Windows 95 & 98, not ME) and it turned out that both problems are actually the same problem - unplanned (and too early) deletion of the drive by the OS. However, the source of such impolite behavior is unknown still.

http://sweetlow.orgfree.com/download/cregfix.zip For test: Added WP_OFF.EXE and as it is PM application it clears CR0.WP (Write Protect) bit only. Works with Ring 0 DPMI hosts only - as included CWSDPMI R5 and R7 versions.

I assume just because it is relatively easy way to deal with PM environment.

It is good logic, but this problem now is minor for systems with this bug. Ok, but i think it is not so simple for DPMI executables at all.

And why did you ask solution without having problem?

N.B. And probably you can just do such version youself if you need it: COPY /B CREGFIX.EXE+CREGFIX.SYS CREGFIX.EXE, isn't it?

It is only half of test. Do Windows load successfully after that?

Two solution exist - or make driver (.SYS version) and run it before EMM386 or make DPMI version of CREGFIX. P.S. http://sweetlow.orgfree.com/download/cregfix.zip .SYS version for test