NVME driver

[SweetLow]

Release:

https://github.com/LordOfMice/Tools/blob/master/nvme9x.zip
https://github.com/LordOfMice/Tools/blob/master/nvment.zip
https://github.com/LordOfMice/Tools/blob/master/nvme2k-src.zip

readme:
NVMe driver for Windows 9x.

Base: nvme2k 1.0.0.2 https://github.com/techomancer/nvme2k
Changes: Port for Windows 9x, 64-bit LBA & Fixes

1. Generic
- added SCSI 64-bit LBA commands processing (large drives support).
Tested on Windows 9x ONLY
- fixed controler shutdown code
- speed up of command queueing and it is less CPU consuming
- fixed enormously low speed or false positive errors on executing
of large size requests
- various code rectifications

2. Windows 9x specific
- port with 2 bug fixes
- install script nvme9x.inf written

Install and uninstall as usual hardware, nothing specific.

Edited November 26, 2025 by SweetLow

[toutounet]

Release : nvme2k 1.0.0.3 https://github.com/techomancer/nvme2k

[SweetLow]

5 hours ago, toutounet said:

Release : nvme2k 1.0.0.3

This is NT driver, not for this section.

[toutounet]

I cannot reply in your Russian forum but you are mistaken regarding IFSMGR.VXD 2227, it was Q301540.EXE and not 302540. How can you ignore it!

[SweetLow]

2 hours ago, toutounet said:

I cannot reply in your Russian forum but you are mistaken regarding IFSMGR.VXD 2227, it was Q301540.EXE and not 302540. How can you ignore it!

This is not my question there but thanks in any case.

[pangoomis]

This driver won't help you boot 9x from NVMe if the legacy 16-bit disk access provided via your motherboard's CSM mode does not work - I'm getting IOS error on bootup on both MSI B650M GAMING PLUS WIFI and MSI PRO H610M-B DDR4 motherboards when trying to boot 98SE from NVMe drive. Something to do with incorrect handling of interrupt 13h for NVMe drives when switching to protected mode or something...

Omores on his videos use mostly ASUS motherboards and NVMe drives just work for him - ASUS does CSM differently? 

I've only tested this driver when booting 98SE from a SATA drive on my H610 motherboard while having a NVMe drive inserted in the mobo's slot, it works fine in that regard.

[SweetLow]

12 hours ago, pangoomis said:

ASUS does CSM differently?

Yes. I have two systems with native NVMe support in CSM and only one can boot - HP notebook on Core gen8 with InsydeH2O UEFI BIOS. But to do so I pushed to write my own DDO as in real mode this BIOS has bug which failed any Int 13h read or write on request with more than 8 sectors. No one bootloader can boot with such restriction and MS bootloader BOOTMGR that WRITES into file system under some circumstances can corrupt this file system even.

Int 13h on Core gen10 on mobo with AMI UEFI BIOS does not work at all in Virtual 8086 Mode. And this is "must have" feature to boot any system that relates on this mode in boot time/work time icluding Windows 9x, Safe Mode of Windows 9x and DOS in protected mode with EMM386 or somthing like this.

This problem is not new, RLoew faced with those buggy BIOSes with his AHCI driver too as the root of problem is the same - PCI Bus Master Controllers including ATA, AHCI and NVMe have identical program model of the I/O request: SG List pointing to the I/O buffers. There is solutions (double buffering) which can struggle with I/O buffers in the "wrong" memory but no one solution can solve the problem of SG List in the "wrong" memory as no one software except the driver itself "knows" about this list.

So to solve the problem you have to replace buggy code of Int 13h handler in form of 1. new CSM DXE module, 2. DDO that supports NVMe or 3. driver in form of .SYS or .TSR

[Start Me Up]

Is the problem with int 13h during the part of the booting process before the driver even loaded?

Edited December 12, 2025 by Start Me Up

[SweetLow]

23 minutes ago, Start Me Up said:

Is the problem with int 13h during the part of the booting process before the driver even loaded?

It is.

[SweetLow]

https://github.com/LordOfMice/Tools/blob/master/nvme9x.zip
1. Partial handling of Windows 9x specific requests that use Linear Scatter/Gather buffer.
2. Cut out hassles came from NT code, in particular two or more NVMe controllers should detected and work without problem now.

[SweetLow]

https://github.com/LordOfMice/Tools/blob/master/nvme9x.zip
Full handling of Windows 9x specific requests that use Linear Scatter/Gather buffer.
Update is recommended.
Install either by reinstalling the device or manually copying nvme2k.mpd and nvmevsd.vxd to %windir%\SYSTEM\IOSUBSYS\

The problem and solution are described in detail in
https://github.com/techomancer/nvme2k/issues/15

There are no remaining issues, except for slightly slower performance under Windows 9x than under NT. This turned out to be an issue with the implementation of standard OS service for DMA (Bus Master) controllers – it's almost impossible to receive a real requests for the controller longer than 64K over any length of time. Solution is possible, but this would require custom implementation, using non-standard code.

[SweetLow]

On 12/26/2025 at 4:21 PM, SweetLow said:

Solution is possible, but this would require custom implementation, using non-standard code.

https://github.com/LordOfMice/Tools/blob/master/nvme9x.zip

High speed of executing large (>64K) I/O requests.
Custom DMA handling instead of using OS service.
Large requests (from 64K to max size supported by controller) executed as fast as in NT now.

[SweetLow]

On 12/7/2025 at 1:37 PM, SweetLow said:

Int 13h on Core gen10 on mobo with AMI UEFI BIOS does not work at all in Virtual 8086 Mode.

Ok, as I made all enhancements to the driver which I planned (and some checks of NT version of this driver too) now I have time to test some very strange info that @Omores was the first to discover:

On some CSMs Int 13h for NVMe does not work only for Extended version of this service (Functions 4xh Read/Write) and works for Standard (Legacy) under [Protected] Virtual 8086 Mode. I literally could not believe in this stupidity but after my own test on above mentioned system I can say that this is TRUE.

What does it mean? You can boot from non LBA (old DOS) FAT versions of MBR partition (0Bh for FAT32, 06h for FAT16) exactly as Omores did.

To fast check that your system has this bug/workaround just run:

http://sweetlow.orgfree.com/download/hdsize.zip (if you will get error under Chrome try to copy/past this address into browser address line directly for the second time)

HDSIZE.EXE /R1

and

HDSIZE.EXE /E /R1

under DOS+EMM386 if you can boot from some other (non NVMe) drive.

If you will get error (9 with high probability) or this: "Read 1 Sectors @ 0 LBA... Success, but these sectors are untouched: 0" message on some (NVMe) drive for the first command and no errror for the second then you have exactly such problem.

Edited Wednesday at 09:44 AM by SweetLow
clarifications

[MERCURY127]

yesterday i can successfully boot my 98 from nvme! 

0) (early) i convert my nvme gpt disk with installed win10 to mbr type, w/o data loss. unfortunatelly, i use already existed win10 recovery partition for new 98 copy - format as fat32 lba 545 mb at end of disk. it was wrong.
1) (yesterday) i move win10 ntfs part at disk end (cant delete it - there is value data), make new fat32 CHS part 500 mb at disk begin, format it and copy existed 98 folder from other disk.
2) at start i forget copy new build of SweetLow's driver, so use build w/o vsd, and after boot get many bsods "write error on disk C:" and garbage in file system. after SweetLow told about, i update driver, and get properly work 98 in protected mode. also verify booting in safe mode - here also all ok.

now i will try grow this partition to 8 and then to 20 gb, for new tests.

Edited Thursday at 10:46 AM by MERCURY127