SweetLow

The first and only tool that you need to do this is MS bootsect.exe It can set (modern) MBR code and nt5- or nt6+ boot sectors.

But problem is here already without anything

But it is not the only solution. Boot Managers allow this too. I used PLOP - for USB booting from ROM primarily but it has ATA drivers too.

Use NT5 bootloader AND NTDETECT.COM, both they are compatible with NT4 kernel. As I remember it was fixed in NT4.0 SP4 or near but if you will use NT5 things it does not matter. But it is definitely offtopic HERE.

It is not the USUAL address of main or add-on BIOS (it is 9BFB:0000 really and this is conventional memory near the end). Of course, any BIOS code can relocate itself into conventional memory but I never saw such thing. P.S. And it is pretty easy insulating by booting from other media.

It's all true, but we discuss setup problem as I can understand (means no ACPI, no PM drivers, no Power Management - something like Safe Mode). We literally do not touch any of these problems.

If it is really RAM problem then try the second path - restricting memory size visible to Windows. Restrict XMS memory to some value enough to boot Windows. 96 or 128M would be ok. burnmem, xmsres, limitmem...

IOS.Log: UnKnown int 13 hooker MBRINT13 Driver Name: mbrint13.sys Character Driver Driver Info: INT 13 Hook: 9BFB0000 You are using some INT 13h MBR Handler (not conforming to Windows 9x Safe MBR Hook standard). If we were 25 years ago I could say this is an MBR virus.

Rare case. It is definitely not the BOOT problem as problems with storage subsystem usually hаve place on earlier stage. And in such situation I would switch to hardware tests before anything else (memory (RAM) first).

It's uknown now. And what did you mean about "the second stage installer" and "idle for about 30 seconds" simulatneously? Installer definitely does not IDLE, it's installing something.

Use vanilla himem and or limit memory (software, NOT harware) or use RLoew's big memory patch.

Ok, the first suspiction is known: PCI\CC_010182 This is non-standard PCI ATA controller - with the first switchable ATA channel. OTOH, BIOS really programmed this channel in legacy mode (82), so there is no problem with installation. But I see the real problem with the second channel: Secondary IDE controller (single fifo) [hdc] ** HARDWAREID: MF\BADSECONDARY WTF? Try to delete this channel (in Safe Mode if it is invisible in Device Manager or use some third party tool). You should get "Secondary ATA Channel (dedicated IRQ)" for this channel. P.S. Where you got this "SATA.INF"? It's my renamed ATAPCIBM.INF And don't stop here - try to use the latest version of ESDI_506.PDR too: https://msfn.org/board/topic/186313-patches-for-esdi_506pdr-from-windows-98se-rloews-terabyte-plus-pack-21-and-more/ And the next step - show me the %windir%\IOS.LOG

No, it should not. Ok, put somewere the output of: https://github.com/LordOfMice/Tools/blob/master/devtree.zip devtree /p /vv > outfile

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.