deomsh

You're going a bit too fast for me. 1) If SESP21A gave problems, try another one, like 98 SE MDCU. Best is after reboot going in Safe mode first to fully finish the installation. 2) Did you combine a Stage One installation with the unofficial Intel inf-updates from @LoneCrusader ? And of course with driver updates like MDCU. About DosLFN-drivers: I have no real experience, but you can find much on mdgx' site.

Thanks, I see no errors in the procedure. You can continue in three different directions. 1) Updating Drivers. Did you already tried the Unofficial Service Pack I suggested earlier? 2) Take your loss and try using your MS-DOS CD-ROM-drivers inside Windows (some drawbacks: at least no Long File Names, burning software will not work and no digital audio available). Just un-rem MSCDEX in AUTOEXEC.BAT. 3) Trying a new installation in a Windows-directory with a different name, with following procedure in two stages. Stage One: installation without PCI-BUS to determine if CD-ROM acces is possible at all. If not, you're lost in space. If there IS actually CD-ROM access, continue with Stage Two. Stage Two: first delete Standard VGA (without reboot!) and then manually add the PCI-BUS with Add New Hardware Wizard and continue installing PCI-Devices. Following setup-line is needed for Stage One: SETUP /P I,S=DETECTBUS,DETECTFLOPPY (watch the space between P and I). Instead of 'I' an ACPI installation is possible too, with 'J' instead of 'I'. Depends on the 'desired' installation in Stage Two. BTW skipping detection of the Floppy Disk Controller by adding DETECTFLOPPY is not stricty necessary, but can be helpfull *somehow*.

I do not fully understand. Were, after setting the Ultra Ata controller to 'No connections' the resources used before free (after rebooting)? IRQ's 14 and 15 should be NOT used anymore, can be seen in Properties of Computer inside Device Manager (everything before manually installing the new controller). After installing a Standard IDE/ESDI Controller the Add New Hardware Wizard states the settings can be altered in Device Manager before shutting down the computer. At least on my System. I had choice between several Basic Configurations, some with conflicts, some without. No need to change individual resources. But my system found the drives only after restarting Windows (second restart in the whole process). BTW, the Controller's Driver should 'find' the drive, that's fully normal in my experience.

I'ts impossible to remember all those properties and switches of command-line utilities, so don't feel bad. I have been using DIR a very long time, but I had no idea what's DIR /b until @jaclaz mentioned it. I repeated your approach two times without emptying Recycle Bin in between in Windows. This time I got a message to delete FOUR non-existent files. No difference between Normal Mode and Safe Mode! Nor starting Explorer, or Ending Explorerer with Taskmanager. But all harmless in my opinion, after 'emtpying the empty' everything is fine. A personal statement about 'DELTREE /Y': it's excellent to supress prompts if sub-directories are present, or in batch-files. Not for use with a single directory from the command-line. DELTREE is 'somehow' a dangerous command. For instance DELTREE \ gives strange results, even if given from inside an almost empty directory! The prompt is the last 'wall' against destruction. Even giving n after prompt will not stop this DELTREE-process: the next prompt will be there immediately. But luckily has MS-DOS CTRL+C... BTW Don't try this at home.

I am sorry to hear that. Maybe another possibility, if you didn't tried already: 1) Set Connections of your current Hard Disk Controller to 'None'. DO NOT DELETE! Reboot.... 2) Go to Control Panel and use Add New Hardware Wizard to install manually 'Standard IDE/ESDI Hard Disk Controller' and reboot. BTW you probably will loose DMA-access with this controller! Edit: some pictures of my -virtual- system after this operation (I needed TWO Standard IDE/ESDI Controllers): http://imgur.com/gallery/kk3oJdB

I have tested your approach, but DELTREE seems to ignore attributes. Afterwards Windows recreated Recycle Bin as expected, but was NOT 'seen' as empty by Windows on my system, although it was empty actually. After 'emptying' everything was fine. So there must be some administration outside the Recycle Bin. Can't find it! See my screenshots: http://imgur.com/gallery/ATh81qo BTW the two deleted files had both attributes RAH, One started with a dot, one with '~'. Can not be seen on the screenshots. After my experiment I took a look in the Microsoft MS-DOS 6.2 Technical Reference (1993). On page 177 I found: 'The deltree command deletes all files contained in a directory or subdirectory, regardless of attributes.'

Hmm. Code 10 gives no clue I'm afraid. If there are no conflicts seen in the original 'Basic configuration' you can try following. 1) Check if there is any NOIDE-entry in your registry. Remove! More details here: https://www.techrepublic.com/article/solve-ms-dos-compatibility-mode-problems-on-pci-ide-controllers-with-these-troubleshooting-tips/ 2) Write down ALL what is showed in the Basic configuration. Probably only IRQ's and Input/Output (I/O) addresses. 3) Then change to your working 'Configuration'. Compare the two configurations and write down the values NOT used in the working configuration. 4) Go to Properties of Computer (still inside Device Manager) and open the tab 'Reserve Resources'. Reserve the Resources from the Basic configuration that are NOT used in your working configuration. Probably only I/O-addresses. After next boot Windows will be forced to use other, available, Resources. 5) Reboot and pray. BTW I'm not sure if this procedure must be done in Normal mode or in Safe mode. Personally I never needed it. Just an idea based on 'PC HULP', a Dutch translation of a German book from Andreas Voss and Thorsten Konetzko (publisher Easy Computing).

This is not clear to me. Has the CD-DRIVE a yellow exclamation mark, or (parts of) the Controller? Maybe a picture would be helpfull. From the Resources tab too. Are there any Error Codes in Device Manager, or IRQ or I/O conflicts?

First about your second question. During Setup, most vxd's of a certain class are 'bound together' in one file: VMM32.VXD (in %windir%\SYSTEM). The directory 'VMM32' can be fully empty! Sometimes Setup will copy one or more vxd's to the VMM32-directory. If an updated vxd is needed, it can be copied to this directory. Such vxd's are loaded during boot instead of their counterparts in VMM32.VXD! In your case IOS.VXD will already have been in the VMM32-folder. I have seen this in Windows 98SE installations on my own motherboards too. BTW be aware there are other types of vxd's too. You can find them in %windir%\SYSTEM and in %windir%\SYSTEM\IOSUBSYS. About ESDI_506.PDR: I don't expect anything in this direction. But feel free to try. My opinion: do not use the unofficial 48-bit updates if you are using HCDP and SATA RLOEW-updates who patch ESDI_506.PDR. On my boards I had bad experiences. As lender of last resort an Unofficial Service Pack can be used. To stay at the safe side, I would suggest OLD 98 SE SP2 2.1a Stable, NOT the 3.xx versions. I am not against them, but reinstalling Windows will not overwrite all updated files. If one wanted to get rid of them, sometimes FORMAT C: is the best option (apart from installation in a new Windows directory with a different name, like 'Win98SE').

You can try the 4.10.2225 versions (both files!). Extract them with 7z in Safe Mode and copy to %windir%\SYSTEM\VMM32 I would suggest to try CONFIGMG.VXD first. You can find many updates and unoffical service packs here: http://www.mdgx.com/web.htm

Hmm.. What version numbers have CONFIMG.VXD and IOS.VXD?

It is a well known 'secret' if Windows' SETUP can't find CD/DVD drives having MS-DOS drivers in CONFIG.SYS/AUTOEXEC.BAT can be helpfull. In one of your previous post's I found you are using SHSUCDX in AUTOEXEC.BAT. As far as I know SETUP will search for MSCDEX. Afterwards MSCDEX will be REM'd out by Windows SETUP. In your case such a line would look (something) like this: C:\WINDOWS\COMMAND\MSCDEX.EXE /D:IDE-CD Don't know if this will be helpfull, just an idea that came up to my mind.

About vcache: On 'low' memory systems (below 512 MB) there should be no need to set vcache entries * (unless there are stability problems!). In general above 512MB maxfilecache should be set. RLOEW gave as a rule of thumb: minimum 1/24 of total memory. He saw no need to set minfilecache. * Edit: although Q181862 prescribes that below 512 MB maxfilecache should be set to 70% of RAM! My experiments, reported in my thread SMARTDRIVE REVISITED.... https://msfn.org/board/topic/176877-smartdrive-revisited-sata-drives-in-msdos-compatibility-mode/page/2/ of December 8, 2018, suggests if minfilecache is NOT set, it's still there and set internally by Windows. The value depends on total memory (not fully lineair!). So minfilecache is only needed if maxfilecache is set BELOW the internal value if minfilecache. About CONFIG.SYS: FILES, BUFFERS and STACKS are MS-DOS-related, should not affect Windows performance. In case of MS-DOS windows, the number of FILES in each VM can be increased with SYSTEM.INI entry PerVMFiles. Also there is MinSPs to increase spare stack pages. See: http://www.mdgx.com/lastweek.htm

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 LOOPTEST.G4B is tried to reproduce the behavior if this internal Grub4Dos command. The story is a bit complicated, because LOOPTEST.G4B has one command-line only, so all variables are set to one fixed value. Following print-screen shows my approach, using some magic (and some patience to get a 'working' command-line. Watch use of '#' instead of %^% ! First command is FATLSDIR.G4B, showing first 5 files to test with cat. By chance I had numbered files, used in earlier tests. After deleting all variables, the third command is LOOPTEST.G4B, with ONE Grub4Dos command-line to execute (too long to fit on the screen). Fourth command shows the variables 'fed' during the looptest to Grub4Dos for execution. Also final values of the three variables, changed after each single test-loop. The time of 1000 executions of the Grub4Dos command-line is almost the same as the difference between FAT and NTFS (see second print-screen above). I tested the difference between cat and raw cat too, without conclusive results. 'Raw' seems a little bit faster, but access-time to a file in VBOX 6 has a considerable variation, about 6.5%. To me it seems that the other commands used, can't be of much influence on speed. See last print screen (showing 'middle-part' of the command-lines too). BTW after last command value of 'size' is no longer file-size. So my question is if the slow file-access in case of NTFS is by default, or if there are faster solutions with Grub4Dos to get the size of a file? Edit I did some more test 'in the wild' on a 500GB sata HD/SSD hybrid disk. This time there where sometimes long looptests with FAT32/FAT16 too, so I can not rule out hardware /dataset related issues. For now I will skip these experiments.

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.