rloew

The Drive runs slow when it is running in Compatabilitiy mode using the BIOS Driver. When it uses the Windows Driver, it crashes. You need my SATA Patch to properly use a SATA Drive on that Motherboard.

I could combine the two regions into one RAMDisk if enough customers requested it. Of course that would leave no room for anything else. It is not limited to 32GiB. That is the largest RAM I have. The limit is 63GiB or 1023GiB depending upon Processor. The RAMDisk uses PSE not PAE. Windows 9x does require HIMEM.SYS or an alternative. It is not needed in CONFIG.SYS as IO.SYS will load it automatically if not specified. I never tested 2K, XP or Vista with my 4KB emulator. I doubt that they would even Install. Since the emulator is only for Real Mode, the Sectors would not correspond to those seen in Protected Mode. I had to add a matching 4K emulator to the Windows 98SE Protected Mode Driver. I use my own Multi-Boot Profile MBR so I do not need a Boot Loader Partition or anybody's Boot Menu. Exceeding 16TiB on USB with XP may also be possible by patching the Mass Storage Driver to split the Drive into 16TiB pieces. I have seen a commercial Driver that does this for Internal Data Drives larger than 2TiB.

Only Internal Floppies are corrupted..

After further experimentation I have determined that unlike VFAT.VXD, FASTFAT.SYS and presumably NTFS.SYS do not handle Partiition offsets so they do not need to be modified. The Extended MBR Patch will need to be placed further down the Driver stack.

You mixed two very different quotes. The Z87 split the 32GiB of RAM into 3GiB of 32-Bit RAM and 29GiB of 64-Bit RAM. The 64-Bit non-XMS RAMDisk used the 29GiB. I could have added a 32-Bit non-XMS RAMDisk up to 3GiB as well. Standard HIMEM.SYS works with the Z87. Otherwise I would not have been able to run 98SE. My non-XMS RAMDisks do not require HIMEM.SYS to work. I never said my Multi-Boot Profile MBR would not boot XP, Vista or 7. I am running XP from it right now. I said XP, Vista and 7 cannot be Booted from a Native 4KB Hard Drive, with or without my MBR. My modified DOS and 98SE can be booted from a Native 4KB Hard Drive. Windows 8 and 10 claim to be able to boot and should work with my MBR.

My Extended MBR and GPT can be combined. Using my Multi-Boot Profile MBR, they can be used even with systems that do no support Hybrid GPT. Native 4K Drives, unless provided with a Jumper or other option, are probably years away. I don't know about Internal Drives, but many BIOSes cannot recognize 4K USB Drives. Patched Windows 98SE will boot from these disks as well as Windows 8 and 10, but XP, Vista, and 7 will not.

I am referring to 512 Byte Sector Size Disks. Only Windows 9x requires the patch for 4K Sectors. 4K Drives won't be a problem until you exceed 16TiB, which probably won't be too long from now. I already developed a MBR Extension that is compatible with existing Software and provides 40 Bit Sector Numbers. I have been using 4TB Bootable Hard Drives with Windows 98SE for years. I am looking into the possibility of extending XP in the same way. The Paragon Driver appears to be a 4K translator. It would be limited to 16TiB and does not support Boot from the same Drive. Using translators, I have Booted Windows 98SE from simulated 4K Drives and DOS from a simulated 32K Drive with a 128TiB Partition.

@rloew will patching fasfat provide high disk support those who use ntfs ? Obviously not. Assuming the experiment works, both FASTFAT.SYS and NTFS.SYS and any other File System Drivers would need to be patched.

What resources are being used by the CDROM Drive?

UNIATA does work as promised. I can access >2TiB through the ASPI Interface. This proves that ATAPI.SYS, even the Windows 2003 SP2 Version does not support READ(16)/WRITE(16). I still do not have access through \\.\PHYSICALDRIVEx though. I will have to Patch FASTFAT.SYS to see if it can reach UNIATA without truncation.

The FAT and NTFS Filesystem Drivers do support 4K Sectors. The MBR does not care about Sector size. It just uses the first 512 Bytes. The PBR header has the Sector size encoded in it but doesn't matter otherwise. The associated loader code has to deal with the Sector size as needed. ATAPI.SYS assumes 512 Byte Sectors and truncates Sector Numbers beyond 32 Bits. Not sure about Read(16)/Write(16). I will look into UNIATA.

The XP ATA Driver (PATA and SATA) is hard coded for 512 Byte Sectors. Not sure about AHCI. Changing it to 4K is not going to help since there are no Drives. Patching the Driver to translate might work. It would be necessary to determine how Sector size is reported to the Driver stack. I can Boot DOS and Windows 9x from a 4K Drive but most BIOSes do not support it so I need a 4K emulator DDO. I have booted DOS using a 32K emulator DDO. It reported 128TiB of Free Space in C:.

The USB HDDs >2TiB that work use 4KiB Sector mapping. I know of no ATA HDD that does. The message path is still 32Bits so READ(10)/WRITE(10) CDBs are used. There are USB HDDs >2TiB that do not use 4KiB Sector mapping. They will not work with XP. I upgraded the USB and SCSI Drivers to support READ(16)/WRITE(16) to access these Drives in 9x.

There is some mention of a Boot-Lock in Windows 10. I'm not sure how it works. It could have just been luck. Causing damage requires a number of things to happen. 1. You have to access an area to put it in cache. 2. You have to Shutdown, not Restart. 3. You have to write something into the cached area using another OS instance. 4. You have to return to the first OS Instance. 5. You have to write something that edits, not replaces, a Cache Block. Or You write to Files or Structures that have been replaced in step 3 and are still cached. Not all corruption will be obvious. Damage may not show in SCANDISK. If you work in different areas with the different OSes, damage is minimized. If you work in a different area before going to the problem area, you may flush the Cache, preventing damage. @jaclaz: Quite a few seconds.

No. The tab provides Hardware Protection. That is why I said "writable" Floppy Disk.

Windows 8 and Windows 10 have a new "feature" called "Fast Startup", "Fast Boot", or "Hybrid Boot". This is a form of mini-Hibernate Mode. Unlike full Hibernate, this is not documented in the Shutdown User Interface and is enabled by default. If you Shutdown, not Restart, Windows 8 or 10, this Mode will save the File Cache in the Hibernation File. If you then modify any of these Cached Drives using a different OS Instance, then access it again from the original OS Instance, the Cache will not match what is on the Drive. If you then make changes, the Cache will be written to the Drive possibly corrupting it. Windows often writes to Drives in the background, so you can corrupt a Drive even if you do not intentionally write to it. There are numerous reports of this problem along with instructions on turning off Fast Startup on Google. I strongly recommend that anyone using Multi-Boot or swappable Drives, including Virtual ones, disable Fast Startup if using Windows 8 or 10. In a pinch, always select Restart, not Shutdown, when closing Windows 8 or 10 if Fast Startup has not been disabled. For those of you not born yesterday, never put a writable Floppy Disk into a Windows 10 system. It will be corrupted even if you don't intentionally write to it.

@dencorso: I have identified the problem and a solution. It is not specific to FAT32. It can affect any non-Microsoft Controlled Multi-Boot System or swappable Drive. Windows 8 may also be susceptible. I will open a thread shortly.

I have replaced: ntfs.sys mf.sys fastfat.sys disk.sys atapi.sys scsiport.sys Still no access above 2TiB. A total replacement produces a Stop 7B BSOD. storport.sys is not in my System. diskdump.sys is a crash dump Driver. It would not be part of the main stack.

I already tried atapi.sys and scsiport.sys. More files need to be updated. ACPI updates should not be needed.

If it doesn't crash, maybe. It will have to be SP1 or later.

Atapi.sys needs to be upgraded. The ASPI interface will need to support READ(16) and WRITE(16) SCSI Commands.

Maybe that "Terrorist Edition" remark is not so ridiculous after all. Running Windows 10 has corrupted some of my FAT32 Partitions, even ones that I did not intentionally access. Don't even think about putting a Floppy Disk in a machine running Windows 10.

On the subject of stability, consider this sequence of Operating Systems. OS #1: First in series. "A" is buggy. OS #2: "A" is fixed. New parts "B" and "C" are buggy. OS #3: "B" and "C" are fixed. New parts "D", "E", and "F" are buggy. Sound familiar? Which is more stable? #3 because they fixed "A", "B", and "C", or #1 because there is only one thing wrong? None are perfect. I choose what works best for me.

XP is fairly decent, but 7, 8 and 10 are nothing but trouble. The IE browsers on my 7 and 8 stopped working properly months ago. Windows 10 appears to cause corruption in FAT Partitions and immediately corrupts Floppy Disks.

I am not aware of any problems with my non-XMS RAMDisk on modern systems. I had no problem using a 29GB RAMDisk with my Z87 Motherboard. You can PM or E-Mail me or post in the 95/98/ME forum for further discussion.