deomsh

Sorry for the confusion, I forgot you switched to the 'normal' IDE-Controller. But I ment the IDE-Controller in general, not the identification from your Intel-inf file (driver of the Primary will in both cases be ESDI-506.PDR I presume). I was hoping de-activating the controller would help to overcome MS-DOS Compatibility Mode and connect <somehow> your AHCI-Controller to your hard-drive.

Did you try to disable the Ultra ATA controller? Setting connections to 'none'.

If you really have only ONE harddrive (the one you showed in a picture earlier), I do not understand the 'Intel ICH8M Ultra ATA Storage Controllers' entry. The AHCI-controller looks 'good'. Just a wild guess: search in your in INF-folder for the phrase 'Intel ICH8M....' and rename the INF-file (with extension 'BAK' or whatever you like). Then remove 'Intel ICH8M Ultra ATA Storage Controllers' in Device Manager and reboot. B.T.W. If the other Intel-devices are mentioned in the same INF-file, remove them too before reboot.

Nice SMARTDRIVE make such a big difference. Just curious if maximun Read-Ahead buffer gives more improvement: SMARTDRIVE /L /B:57344 (buffer forced in Low Memory is normally faster, but will cost more 'low mem' of course).

During the final tests of FATLSDIR.G4B I found NTFS to be very slow. Especially a problem if parsing directories with many files, or if searching for a file or a directory. After some changes I couldn't get any faster. See following comparisons made with LOOPTEST.G4B (working version, unpublished). Performance of FAT16 is best, FAT32 'good' too. EXFAT already much slower (different filesize!), but NTFS is really bad. I think the bottleneck is the speed of raw cat --length=0 FILE - indispensable to identify directories and used to get file-size too. With help of LOOPT

Thanks @RainyShadow, but I asked that earlier, before he switched to RLoew's AHCI-driver, BIOS should be in AHCI-mode now. According to the earlier picture of Device Manager there are TWO harddisk controllers and ONE standard IDE 55 disk and ONE Primary controller with yellow exclamation mark. I would like to see a new picture, of the current configuration. Devices viewed by Connection, with all harddisk connections visible.

Your story is vague for me. Please show full CONFIG.SYS and AUTOEXEC.BAT. Is the C-drive IDE?

I am a bit out of idea's, except that reinstalling with SETUP /p i is worth a try. If I red your posts correctly, you used the /p j-switch so far.

Hmm. Are there any SATA-options in the BIOS? If yes, is SATA set to IDE-mode (=ATA, not AHCI)?

I had the same problem. Not fully sure about it, but it seems that the SATA patch needs a decent Microsoft version of ESDI_506.PDR. Most easy is to extract the original version from the CD-cab, replace the new version in IOSUBSYS, delete the backups. Then run in Real mode MS-DOS first RLOEW's High Capacity Disk Patch, and second the SATA Patch.

Hmm. Maybe its better to use your USB-FLOPPY to copy the content of the WIN98-directory (as its named on the original CD) to a directory on your harddrive, let's say C:\WIN98 (commands: md C:\WIN98 and copy D:\WIN98\*.* C:\WIN98 -if 'D:' is your CD-station). Then remove the USB-FLOPPY and reboot to your harddrive in MS-DOS-mode. Go to your installation-directory with command: cd C:\WIN98 and run setup again. Afterwards you can try if you can get access to your USB-FLOPPY from Windows.

@kannalo I hope you don't have Windows ME, is more complicated because HDATSR.EXE can't be used. If: in SYSTEM.INI [drivers] wavehda=hda2.dll is written (file must be in C:\WINDOWS\SYSTEM); in AUTOEXEC.BAT the line HDATSR.EXE is present (and file in C:\WINDOWS), than the installation succeeded.

@kannalo First of all: what are the specs of your machine? Which type of motherboard (or laptop), which HDA-codec? Please give as much details as you can find. And what message gave Windows during the crash?

If you boot from USB-FLOPPY, the BIOS will use USB-Legacy mode, so MS-DOS will have access to the USB-FLOPPY without a driver. During setup Windows 98SE will install its own USB-driver. As soon this driver is 'active' the USB bus will 'reset', and (still needed) access to the USB-FLOPPY will be lost.

Thanks, I will try So far I relied heavily on Imgburn for ISO's and on my CD/DVD-collection. I had a bad time testing ISO's because I tried a new version of Grub4Dos too, which gave problems with UDF. Maybe it's good to run some new tests. I saw that in between 'mkisofs' evolved to CDRTOOLS-3.02a10-win-x86_64 (following an old link in your post). Luckily I possess Windows 10 64-bit. I hope the command-line will accept your script. My script changes nothing on the source-side, I rely on what 'ls' is able to read, and on 'fat' or 'dd' for copying. I started my script to be able to co