Jump to content
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble

MSFN is made available via donations, subscriptions and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. Alternatively, register and become a site sponsor/subscriber and ads will be disabled automatically. 



Cixert

2 TiB limit size in MBR hard drives

Recommended Posts

Quote
Quote

I do Windows 9x programming as well. The DOS RAMDisks work well enough that making a Windows Version was not a priority. I probably could rewrite my USB Mass Storage Driver to act as a RAMDisk.

Whatever makes it easier to create it in 9X/ME and fully robust.

Since 64-Bit RAM is normally unused, you can create the RAMDisks in DOS and just leave them until needed.
I'm not sure what you mean by robust. They have proven stable under all of the circumstances I know of.

Quote
Quote

A GUI Interface is just fluff.

Customers love the fluff.  Guilty.

How much extra would you be willing to pay for fluff. How much extra would all of your friends and coworkers be willing to pay for fluff.

Quote
Quote

USB Sound Cards and Adapters work fine with Windows 98. The Motherboard doesn't matter.

The standard Drivers do that.

If you are talking about DOS USB Drivers, some exist.

You kind of missed what I was asking.  Regarding Intel USB 2.0, in 98SE Real DOS (not inside 98SE OS) could you find a way to bridge USB device detection using the 9X/ME core system files?  So as long as the user owned a 98SE CD to get the core and system files and used your DOS/USB interface program it could then in 98SE Real DOS basically detect any USB devices (USB Keyboard, USB Mouse, USB audio device, USB gaming controller, USB network device) or whatever USB device that used 9X/ME native USB drivers without requiring an additional manufacture driver to work).  A lot of these USB devices simply are plug and play in 9X/ME.  If you could make 98SE Real DOS run as normal but with added 9X/ME USB detection that allowed any USB devices connected to the USB 2.0 ports like a USB sound device could then be plugged in and on a hardware level any Real DOS based game could directly access this USB sound device for audio output.  Adding a USB game controller would automatically work as if it were a legacy PC joystick.  Is this within your programming expertise?

It sounds like you want to make Windows 98SE Drivers run without Windows 98SE. That would require containerizing the entire WDM Interface.
Then it would be necessary to interface between the Windows Audio and Networking Interfaces and those used by DOS Audio and Networking.
Keyboard and Mouse are already handled by SMI Emulation. Game Controllers can be handled fairly simply.

Send me a six figure retainer and I will work on it.

Quote

8GB was still an optimal partition size for 98SE until probably a decade ago.  For daily 98SE usage today I'd probably go with a 16GB partition.\

For a Boot Partition, it is OK. For data, not even close.

Quote
Quote

I don't think it does if connect the Drive and grab the data without using  Explorer or other Windows Functions.

Perhaps by disabling AutoPlay it wouldn't tamper with the drive at all.  Not entirely sure.  Only a DOS clone would seem the safest.

DOS is safest and fastest. I normally use DOS.

Quote
Quote

I keep telling you that 64K Logical Sectors will not happen.

I was giving it some thought.  It might not happen soon but given 64KB Physical sector drive size wouldn't actually be needed yet but if a pure 64KB Physical sector drive through the drive controller appeared as 64KB sectors and a proper OS support patch was done this would really benefit high transfer rates for large HD file sizes.

I already said 64KB Logical Sectors will NOT improve transfer rates, only that 64KB AUS might.

Quote

I started thinking about this USB adapter some more as I never really cared about it except that it worked.  The drive inside appears to be a 4K sector drive but with 512e out the hard drive Sata connector.

So the adapter doesn't really do any 4KB -> 512 Byte translation as I originally had thought since the drive does this natively.

Not so. The Adapter converts 4KB to 512B. The Drive converts then 512B back to 4KB which then accesses the appropriate Sectors. 

Quote

It wouldn't matter if the hard drive had a 64KB sector size anymore to break the MBR barrier. It can be a 4KB sector drive or even a 512 Bytes sector size drive as both should work.  I think the adapter is really an address translator to the 32-Bit legacy limit.  So any drive over 18TB would probably still work and won't corrupt the drive since you couldn't access that region or anything above 18TB.  Now if this address translator could be dumped and modified you could actually get 256TB MBR or higher capacities as long as the source drive was 512e and made the proper address translation changes done on the translation adapter side.  Since there is a hard disk transition from 512 and 512e to pure 4KB sector drives it's hard to guess when 512e drives will no longer be made but the writing is on the wall and since Windows 7 64-Bit already understands 4KB sectors only XP 32-Bit and lower will be affected unless patched.  A new adapter board would need to be made to accept pure 4KB sector drives and do a conversion to do address translation to the 32-Bit limit and it would once again work on all Operating Systems at least from 2000 SP3 and XP SP1 and up for higher than 18TB MBR capacities.

The MBR barrier is extended only by having larger Logical Sectors at the OS interface. The Physical Sector size of the Hard Drive, or the Logical Sector Size between the USB Adapter and the SATA Port on the Hard Drive are irrelevant. The Logical Sector size at the SATA or USB Controller is also irrelevant if using a DDO or emulator. Only EMBR or GPT can break the MBR barrier.

The OS has to understand the Sector size presented to it's FileSystem. Unmodified DOS and Windowx 9x is limited to 512B, XP and above appear to be limited to 4K. My modified DOS supports up to 32K and my modified Windows 9x supports up to 4K. These determine the MBR limits, nothing else.

All this nonsense about adapter boards and 64K will not increase the capacity of any OS beyond which has already been achieved.

No one is going to rewrite the FileSystems just to support 64K when it is far easier to support EMBR or GPT.

Maybe when Windows 14 comes out, they might add it, but don't count on ever getting an upgrade for Windows 12 or earlier.

 

 

Edited by rloew

Share this post


Link to post
Share on other sites

On 10/25/2017 at 2:43 PM, rloew said:

Since 64-Bit RAM is normally unused, you can create the RAMDisks in DOS and just leave them until needed.

I'm not sure what you mean by robust. They have proven stable under all of the circumstances I know of.

I'm talking about 9X GUI support like other commercial Ramdrives like those in XP.  Customizeable drive letter choosing, setting Ramdrive size, and the ability for multiple Ramdrives up to 24 or 23 meaning if C: is taken by your hard drive then D: to Z: can be assigned to use the available > 4GB+ RAM in what manner they see fit.

Rebooting the system will retain the saved settings.

If a user chose to they could have D: to Z: as Ramdrive drives of different capacities as long as it doesn't exceed the available RAM.

Now if you could also create hidden Ramdrives that don't use Drive Letters or extend the Drive Letters beyond Z: C2, D2, ... Z2 pattern so drive letter consumption won't be a limitation.

Quote

How much extra would you be willing to pay for fluff. How much extra would all of your friends and coworkers be willing to pay for fluff.

It's not about how much extra but how good the interface and features it has so people want it.  If your 9X Ramdrive with a true 9X interface was created on par with an XP Ramdrive then a similar pricing to what other XP Commercial Ramdrive exceptional software would be priced if the feature set is identical.  Now if there are certain memory limits for 9X where the Ramdrive size is capped then yes you can't charge the same but less assuming you could do 2TB Ramdrive in XP but your 9X version was capped at much less due to an OS limit that can't be broken.  Now if you were really serious about doing it I could probably help guide the user interface design and look of it to where I would call it exceptional.

Quote

It sounds like you want to make Windows 98SE Drivers run without Windows 98SE. That would require containerizing the entire WDM Interface.
Then it would be necessary to interface between the Windows Audio and Networking Interfaces and those used by DOS Audio and Networking.
Keyboard and Mouse are already handled by SMI Emulation. Game Controllers can be handled fairly simply.

The Networking Interface doesn't need to be implemented as DOS browsing isn't critical.

Just getting the 98SE USB interface working on 98SE DOS.  I would say the USB Audio and maybe the USB game controller are really the ones that need to get targeted.

 

Quote

Send me a six figure retainer and I will work on it.

You assume this is about me and I am a Multi millionaire or Billionaire like Gates. I'm just giving you ideas on what real 9X users would possibly pay for especially those interested in using 9X DOS for legacy DOS gaming without dealing with the headaches / limits of 9X on post ISA slot modern hardware.

A real 6 figure project would be a DOS->W10 32/64 Bit OS all in one fully software compatible.

Quote

For a Boot Partition, it is OK. For data, not even close.

Boot Partition 2GB is fine.

OS Partition 16GB for 98SE would be plenty.  You create another dedicated partition much larger for Program Files and Document/Data storage.  There is no need to constantly bloat your OS partition and 16GB would probably be way more than enough for the main OS files as long as you separate the Program files and other files that can be redirected to another partition which allow it.

Quote

DOS is safest and fastest. I normally use DOS.

True.  About a week or so ago I found a suitable MBR reader for my data gathering tests.  I had a much older one in the early 80s for Floppy and MFM Hard Drives I used to use but I believe that one stopped working properly way before IDE drives or some newer DOS version it was incompatible with somehow.  I think I was using it on DOS 1.1 and 2.0 at the time.  The last time I really examined the MBR out of curiosity.  It was more about analyzing copy protected NON DOS boot disks.

Quote

I already said 64KB Logical Sectors will NOT improve transfer rates, only that 64KB AUS might.

I was talking about 64KB Physical Sectors on the platter side storage with a direct SATA connector that interfaces as 64KB Logical sectors to the OS.  So no conversion would take place.  Now adding on top of that the 64KB Cluster size or AUS it will just be icing and of course improve performance.

Quote

Not so. The Adapter converts 4KB to 512B. The Drive converts then 512B back to 4KB which then accesses the appropriate Sectors. 

You might be more specific here.  The "Adapter" are you talking about the "SATA to USB"?

Which side is the 4KB and which side is the 512 Bytes.

 

From what I can tell the Bare drive in the USB enclosure is a 4KB platter storage drive but converts to 512 Bytes on the SATA connector end.

 

These are the two typical scenarios to hook it up:

Hard drive platter 4KB Physical - HD circuit board to SATA connector - Logical 512 Bytes - SATA Cable - Sata Controller - OS

Hard drive platter 4KB Physical - HD circuit board to SATA connector - Logical 512 Bytes - SATA to USB Adapter - USB Cable - USB Port - OS

Quote

The MBR barrier is extended only by having larger Logical Sectors at the OS interface.

Logical Sectors would be 512 Bytes at the XP OS Interface?

Now you say larger Logical Sectors at the OS interface so how large Logical Sectors can XP SP1 handle?

Quote

The Physical Sector size of the Hard Drive, or the Logical Sector Size between the USB Adapter and the SATA Port on the Hard Drive are irrelevant.

Non modification of the OS and using true hardware is the objective of increasing the MBR capacity so it works on any system without modification.  Using a DDO or emulator adds another level of patching similar to just why not switch to GPT entirely if you're going that route.  There's a reason why using 18.0TB on XP via a USB cable is an advantage without any kind of OS modification.  Nothing needs to be done on the destination system at all.  As long as they are running XP SP1 or higher OS this drive can be automatically detected.

Now whatever they did in the actual SATA to USB adapter if they could incorporate that into the Hard drive circuit board then you could access the total capacity of the drive natively on the SATA controller or using a "regular" SATA to USB adapter.  I'm not certain why they chose to not do that and used a special adapter method.

Quote

The OS has to understand the Sector size presented to it's FileSystem. Unmodified DOS and Windowx 9x is limited to 512 Bytes.

This should include 2K and XP 32-Bit?

Quote

, XP and above appear to be limited to 4K.

My modified DOS supports up to 32K and my modified Windows 9x supports up to 4K. These determine the MBR limits, nothing else.

What do you mean here by limited to 4K?  Now here you are saying XP can understand 4KB Sector size and a regular 4KB native SATA drive will work with XP without any adapter?

Quote

All this nonsense about adapter boards and 64K will not increase the capacity of any OS beyond which has already been achieved.

No one is going to rewrite the FileSystems just to support 64K when it is far easier to support EMBR or GPT.

Maybe when Windows 14 comes out, they might add it, but don't count on ever getting an upgrade for Windows 12 or earlier.

The adapter boards already breaks the 2.2TB MBR standard limit.  So I would not say 18.0TB MBR max on XP is something to laugh at.

Rewriting the File Systems probably won't happen unless the technology is present first which is my point.  If 64KB drives were made as the first jump from 512 Byte drives then i would say yes Windows 8 probably would have supported 64KB now just like it currently supports 4KB drives.

https://support.microsoft.com/en-us/help/2510009/microsoft-support-policy-for-4k-sector-hard-drives-in-windows

The reason 4KB drives aren't supported on XP is because they didn't get these 4KB Native drives out fast enough to consumers so MS would have been forced to created an OS patch just like SP1 was created for the 128GB issue.

If MS and the hard drive manufacturers all agreed to 64KB drives and they released it today trust me there will be a patch coming from MS for Windows 10 for sure since it's still new.  Possibly W7 and W8.X would get a back port since W7 is still quite dominant an OS today.  If 64KB drives won't be out till 2030 of course it won't happen till way past 2030.

And it looks like you recently acquired a 4KB Native drive so this drive should work fine on Windows 8 without any special patching.

 

On 10/24/2017 at 3:26 PM, rloew said:

Not 4TiB Drives.

Sure I have.  I have done both the 4TB and the 8TB drives as I've partitioned and formatted it as one large MBR NTFS partition chunk.

I also did some testing last week and the 3TB drive is bootable to 98SE DOS directly connected to the SATA controller.  Though not many will try this ever.

Edited by 98SE

Share this post


Link to post
Share on other sites
Quote
Quote

Since 64-Bit RAM is normally unused, you can create the RAMDisks in DOS and just leave them until needed.

I'm not sure what you mean by robust. They have proven stable under all of the circumstances I know of.

I'm talking about 9X GUI support like other commercial Ramdrives like those in XP.  Customizeable drive letter choosing, setting Ramdrive size, and the ability for multiple Ramdrives up to 24 or 23 meaning if C: is taken by your hard drive then D: to Z: can be assigned to use the available > 4GB+ RAM in what manner they see fit.

Rebooting the system will retain the saved settings.

If a user chose to they could have D: to Z: as Ramdrive drives of different capacities as long as it doesn't exceed the available RAM.

Now if you could also create hidden Ramdrives that don't use Drive Letters or extend the Drive Letters beyond Z: C2, D2, ... Z2 pattern so drive letter consumption won't be a limitation.

Size and Drive Letter are already customizeable. You can have as many as you want. To make them permanent, put the commands in AUTOEXEC.BAT.

Hiddem RAMDisks would have no value since they cannot be accessed. You already know that Letters beyond Z are not going to happen.

You still did not answer my question about robustness.

Quote
Quote

How much extra would you be willing to pay for fluff. How much extra would all of your friends and coworkers be willing to pay for fluff.

It's not about how much extra but how good the interface and features it has so people want it.  If your 9X Ramdrive with a true 9X interface was created on par with an XP Ramdrive then a similar pricing to what other XP Commercial Ramdrive exceptional software would be priced if the feature set is identical.  Now if there are certain memory limits for 9X where the Ramdrive size is capped then yes you can't charge the same but less assuming you could do 2TB Ramdrive in XP but your 9X version was capped at much less due to an OS limit that can't be broken.  Now if you were really serious about doing it I could probably help guide the user interface design and look of it to where I would call it exceptional.

I did not ask how much people would pay, I asked how much EXTRA people would pay  for the GUI Interface over what they would pay for the existing design.

PSE supports 2TiB so that is not a problem.

Quote
Quote

It sounds like you want to make Windows 98SE Drivers run without Windows 98SE. That would require containerizing the entire WDM Interface.
Then it would be necessary to interface between the Windows Audio and Networking Interfaces and those used by DOS Audio and Networking.
Keyboard and Mouse are already handled by SMI Emulation. Game Controllers can be handled fairly simply.

The Networking Interface doesn't need to be implemented as DOS browsing isn't critical.

Just getting the 98SE USB interface working on 98SE DOS.  I would say the USB Audio and maybe the USB game controller are really the ones that need to get targeted.

Quote

Send me a six figure retainer and I will work on it.

You assume this is about me and I am a Multi millionaire or Billionaire like Gates. I'm just giving you ideas on what real 9X users would possibly pay for especially those interested in using 9X DOS for legacy DOS gaming without dealing with the headaches / limits of 9X on post ISA slot modern hardware.

A real 6 figure project would be a DOS->W10 32/64 Bit OS all in one fully software compatible.

It is about you. No one else is asking. If you are not a Billionaire, buzz off. 9x runs as well or better than DOS on any Motherboard. The functionality lost is not even available in DOS.

I'm thinking more like 8 figures for your universal product.

Quote

For a Boot Partition, it is OK. For data, not even close.

Boot Partition 2GB is fine.

OS Partition 16GB for 98SE would be plenty.  You create another dedicated partition much larger for Program Files and Document/Data storage.  There is no need to constantly bloat your OS partition and 16GB would probably be way more than enough for the main OS files as long as you separate the Program files and other files that can be redirected to another partition which allow it.

I use 8GB for my Boot Partition. I do not have a lot of Applications. I have 6TB of Data Partitions.

Quote

I already said 64KB Logical Sectors will NOT improve transfer rates, only that 64KB AUS might.

I was talking about 64KB Physical Sectors on the platter side storage with a direct SATA connector that interfaces as 64KB Logical sectors to the OS.  So no conversion would take place.  Now adding on top of that the 64KB Cluster size or AUS it will just be icing and of course improve performance.

No improvement. Translation involved rescaling the Address and Length Arguments of a Request. The Data Transfer is the same. Only misalignments cause problems because extra transfers are needed.  

Quote

Not so. The Adapter converts 4KB to 512B. The Drive converts then 512B back to 4KB which then accesses the appropriate Sectors. 

You might be more specific here.  The "Adapter" are you talking about the "SATA to USB"?

Which side is the 4KB and which side is the 512 Bytes.

There is only one Adapter. The USB to SATA Adapter.

The USB Bus is 4K in this case. The SATA Bus is 512B.

Quote

From what I can tell the Bare drive in the USB enclosure is a 4KB platter storage drive but converts to 512 Bytes on the SATA connector end.

Yes.

Quote

These are the two typical scenarios to hook it up:

Hard drive platter 4KB Physical - HD circuit board to SATA connector - Logical 512 Bytes - SATA Cable - Sata Controller - OS

Hard drive platter 4KB Physical - HD circuit board to SATA connector - Logical 512 Bytes - SATA to USB Adapter - USB Cable - USB Port - OS

Yes.

Now I am testing scenario #3 and #4.

Hard drive platter 4KB Physical - HD circuit board to SATA connector - Logical 4KB Bytes - SATA Cable - Sata Controller - OS

Hard drive platter 4KB Physical - HD circuit board to SATA connector - Logical 4KB Bytes - SATA to USB Adapter - USB Cable - USB Port - OS

Quote

The MBR barrier is extended only by having larger Logical Sectors at the OS interface.

Logical Sectors would be 512 Bytes at the XP OS Interface?

Now you say larger Logical Sectors at the OS interface so how large Logical Sectors can XP SP1 handle?

Normally 512.

I did not test XP SP1.

XP SP3 can handle 4KB at the FileSystem level. The USB Stack can also handle 4K. The IDE stack only handles 512B.

Quote

The Physical Sector size of the Hard Drive, or the Logical Sector Size between the USB Adapter and the SATA Port on the Hard Drive are irrelevant.

Non modification of the OS and using true hardware is the objective of increasing the MBR capacity so it works on any system without modification.  Using a DDO or emulator adds another level of patching similar to just why not switch to GPT entirely if you're going that route.  There's a reason why using 18.0TB on XP via a USB cable is an advantage without any kind of OS modification.  Nothing needs to be done on the destination system at all.  As long as they are running XP SP1 or higher OS this drive can be automatically detected.

Now whatever they did in the actual SATA to USB adapter if they could incorporate that into the Hard drive circuit board then you could access the total capacity of the drive natively on the SATA controller or using a "regular" SATA to USB adapter.  I'm not certain why they chose to not do that and used a special adapter method.

Since the IDE Stack only handles 512B Logical Sectors. There is not way to adapt a Hard Drive to increase capacity. Your proposed circuit just makes it a 4Kn Drive, undoing the internal translation,

A Patch or new Driver for XP is needed.

Quote
Quote

The OS has to understand the Sector size presented to it's FileSystem. Unmodified DOS and Windowx 9x is limited to 512 Bytes.

This should include 2K and XP 32-Bit?

The FileSystem in Windows 9x actually supports 2K Sectors but some other parts of the stack don't.

No idea about 2K. XP apparently was designed with 4K support.

Quote
Quote

, XP and above appear to be limited to 4K.

My modified DOS supports up to 32K and my modified Windows 9x supports up to 4K. These determine the MBR limits, nothing else.

What do you mean here by limited to 4K?  Now here you are saying XP can understand 4KB Sector size and a regular 4KB native SATA drive will work with XP without any adapter?

The FileSystem in XP supports 4K. I thought it might fully support 4K after reading the web page I posted. When it failed in my experiments, I reread the page carefully.
Apparently he was using a RAID Driver that did work. The standard ATAPI.SYS does not. I could not get UNIATA to work either.

Quote
Quote

All this nonsense about adapter boards and 64K will not increase the capacity of any OS beyond which has already been achieved.

No one is going to rewrite the FileSystems just to support 64K when it is far easier to support EMBR or GPT.

Maybe when Windows 14 comes out, they might add it, but don't count on ever getting an upgrade for Windows 12 or earlier.

The adapter boards already breaks the 2.2TB MBR standard limit.  So I would not say 18.0TB MBR max on XP is something to laugh at.

I said what has been "achieved". 16TiB with USB already can be done. Nothing new here.

Quote

Rewriting the File Systems probably won't happen unless the technology is present first which is my point.  If 64KB drives were made as the first jump from 512 Byte drives then i would say yes Windows 8 probably would have supported 64KB now just like it currently supports 4KB drives.

https://support.microsoft.com/en-us/help/2510009/microsoft-support-policy-for-4k-sector-hard-drives-in-windows

The reason 4KB drives aren't supported on XP is because they didn't get these 4KB Native drives out fast enough to consumers so MS would have been forced to created an OS patch just like SP1 was created for the 128GB issue.

If MS and the hard drive manufacturers all agreed to 64KB drives and they released it today trust me there will be a patch coming from MS for Windows 10 for sure since it's still new.  Possibly W7 and W8.X would get a back port since W7 is still quite dominant an OS today.  If 64KB drives won't be out till 2030 of course it won't happen till way past 2030.

Maybe if there was a compelling reason to go to 64K. The gain from going from 512B to 4K is far greater than the gain from going from 4K to 64K.

The fact that paging is 4K and many OSes such as 9x and presumably NT use 4k blocks internally, made 4K an easy choice. 64K would require a major rewrite of every OS FileSystem.
More likely they would add a translation driver to convert it down to 4K, which defeats the purpose of having 64K Logical Sectors in the first place.

Incidentally, Microsoft doesn't mention that you cannot boot 4Kn drives on many Motherboards, even if the OS supports it.

Quote

And it looks like you recently acquired a 4KB Native drive so this drive should work fine on Windows 8 without any special patching.

You must have read my Topic between updates. I added Windows 8 shortly after. I'm adding more updates in a few minutes. 

Quote

Not 4TiB Drives.

Sure I have.  I have done both the 4TB and the 8TB drives as I've partitioned and formatted it as one large MBR NTFS partition chunk.

I also did some testing last week and the 3TB drive is bootable to 98SE DOS directly connected to the SATA controller.  Though not many will try this ever.

You said you were partitioning Disk since MFM Days. I'm sure you haven't been partitioning 4TB Drives that long.

You can connect any size Drive to a SATA Controller and access or even Boot from it in DOS. It just won't be fully accessible without my Patches.

Edited by rloew
  • Like 1

Share this post


Link to post
Share on other sites

 

On 11/4/2017 at 7:29 PM, rloew said:

Size and Drive Letter are already customizeable. You can have as many as you want. To make them permanent, put the commands in AUTOEXEC.BAT.

Yes but not many would want to dig around in DOS to setup the Ramdrives.  Otherwise why did Microsoft develop Windows?  But as an attempt to simply the OS user interface so even kids and grandparents could use the computer instead of CLI geeks.

Aside from that assuming they setup the Ramdrive in DOS preloaded in the Autoexec, if they loaded into 98SE OS and wanted to change the Ramdrive letter from a DOS assigned Z: to X: would this work while within 98SE OS or would exiting to real 98SE DOS from 98SE OS work or would a warm reboot be required after modifying the autoexec be done first?

I would assume you need to do a warm reboot since the OS loading has either dirtied or locked the Ramdrives from changing drive letters or capacity.

Quote

Hiddem RAMDisks would have no value since they cannot be accessed.

Well if you can make a hidden Ramdisk (not use a drive letter) as the Temp drive location it would be useful in that case as most people won't be digging around there.

You also mentioned you had a drive letter mounter to do any switching so you could switch it to a real drive letter when needed and force another drive out.

Quote

You already know that Letters beyond Z are not going to happen.

It was wishful thinking maybe you had one more Ace up the sleeve if programmed for 9X/ME.

Quote

You still did not answer my question about robustness.

Most of the ideas I stated were to make it such but as you said they are not possible.

So if the foundation of ideas can't work the subsequent ones will not matter.

Quote

I did not ask how much people would pay, I asked how much EXTRA people would pay  for the GUI Interface over what they would pay for the existing design.

Not sure.  I haven't checked your prices vs the current prices for others.

I suppose if yours did cost $20 then a GUI version for $30 would be reasonable to me and possibly others.

Or a combo package of both versions for $40 basically older CLI and newer GUI options for the user.

Quote

PSE supports 2TiB so that is not a problem.

Then the price above I think would be fair for most all things equal.  What is the capacity limit of the Ramdrive for DOS and for 9X/ME?

Quote

It is about you. No one else is asking. If you are not a Billionaire, buzz off. 9x runs as well or better than DOS on any Motherboard. The functionality lost is not even available in DOS.

I'm thinking more like 8 figures for your universal product.

Depends on your target audience.  With 9X you are restricted and need a compliant 9X/ME based graphics card and drivers.  Going to real DOS most older DOS based games should work and native applications or utilities.  Now if FreeDOS was used instead possibly the source code could improve DOS hardware compatibility that might open up multiple cores to be utilized.  The 98SE USB advantage is allowing a USB sound device to be identified as a Sound Blaster type when used with DOSBOX.  There is less work for the user to get a DOS gaming rig going on a modern system in this manner than it would be to install 98SE from scratch on a Coffee Lake system.  Now if you're not a frequenter of Vogons you might not know the niche it may fill there for legacy gamers.

But this is the only viable idea I have of making 98SE relevant today on newer machines so it isn't about me.  Remember I have older P4s with ISA slots and have made SkyLake work with 98SE but the limitations and the steps to get it to work properly versus the 98SE DOS using 98 system files and USB 2.0 support would simplify a lot of the problems.  Most standard 9X/ME applications can run properly in XP so direct 9X/ME apps really are now pointless to most consumers.

However your background programming expertise is mainly in DOS and an understanding of 9X/ME so this is something I would think you'd be capable of doing rather easily.  We all wish we were billionaires but then we wouldn't be working anymore.  Like you said there is no free lunch so if you want food on the table you must make something that brings in the dough like your patches.  Just eyeballing the 98SE tests I've done on socket 1151/AM4 motherboards the pool of people trying to get these to work on these modern systems is less than I would have suspected.  Even recent attempts by others seem to have failed where I was successful and not many probably use my technique either.

DOS itself is rather simplistic and easier to get working even on a Coffee Lake system.  There is also no AHCI driver issue to deal with or any potential 9X/ME based conflicts that come up plaguing the system.  Otherwise I'm out of any other ideas that you can sink your teeth into of value.  I see no other branch to prolong 98SE's usefulness on modern systems and that's just being honest.

So it comes down to a FREEDOS modification to support multicores and being able to run 98SE programs at the command line.  98SE USB detection of devices (sound and game controller) in 98SE DOS the system is running.  Two other useful programs MUNT and DOSBOX that would definitely be 9X/ME programs if it could be run at the 98SE Real DOS command line would make 98SE relevant on modern systems.  Otherwise I would say the death coffin is pretty much closed for 9X/ME relevance which is regrettable.

Quote

I use 8GB for my Boot Partition. I do not have a lot of Applications. I have 6TB of Data Partitions.

I need the FAT16 for the backward compatibility of DOS programs in case it dislikes FAT32 partitions.

Quote

No improvement. Translation involved rescaling the Address and Length Arguments of a Request. The Data Transfer is the same. Only misalignments cause problems because extra transfers are needed.

Sounds like SSDs going forward for larger capacities would be a better solution to avoid these misalignments.  The drives do take a beating and slow down reusing deleted space.

Quote

There is only one Adapter. The USB to SATA Adapter.

The USB Bus is 4K in this case. The SATA Bus is 512B.

Are all the USB to SATA adapters you have 4K USB Bus and 512B SATA Bus including the two USB docks you previously mentioned?

What current > 2.2TB drive capacities do you have now aside from the recent 6TB 4Kn drive?

Does your SATA to USB adapter allow the 6TB 4Kn drive to recognize the entire drive as one large MBR NTFS partition uncapped?

Quote

Now I am testing scenario #3 and #4.

Hard drive platter 4KB Physical - HD circuit board to SATA connector - Logical 4KB - SATA Cable - Sata Controller - OS

Hard drive platter 4KB Physical - HD circuit board to SATA connector - Logical 4KB - SATA to USB Adapter - USB Cable - USB Port - OS

You might want to see if your new 4Kn drive hooked via SATA directly can interface with XP SP1-3 and the same for USB 2.0 Port to XP SP1-3.

Does both the SATA and the USB method allow booting off this 4Kn drive on the Z87?

Quote

Normally 512.

I did not test XP SP1.

XP SP3 can handle 4KB at the FileSystem level. The USB Stack can also handle 4K. The IDE stack only handles 512B.

So both XP SP3 and the USB Stack handle 4KB at the FS level?

Are you saying XP works with your 4Kn drive directly connected via SATA and also using your SATA to USB on the USB 2.0 ports?

Quote

Since the IDE Stack only handles 512B Logical Sectors. There is not way to adapt a Hard Drive to increase capacity. Your proposed circuit just makes it a 4Kn Drive, undoing the internal translation,

The IDE stack is used if using the IDE controller with IDE devices but what about a BIOS setting SATA in IDE compatibility mode, does this use the IDE stack in XP?

How does this affect computers using the XP AHCI mode which SkyLake and all modern systems are now stuck on?

Quote

A Patch or new Driver for XP is needed.

You are talking about the IDE stack?  What files are needed to be patched?  This sounds like something that would affect NT/2K since they lack AHCI.

Quote

The FileSystem in Windows 9x actually supports 2K Sectors but some other parts of the stack don't.

No idea about 2K. XP apparently was designed with 4K support.

So what ends up happening in 9X when using the 2K Sectors or your 4Kn drive?

Quote

The FileSystem in XP supports 4K. I thought it might fully support 4K after reading the web page I posted. When it failed in my experiments, I reread the page carefully.
Apparently he was using a RAID Driver that did work. The standard ATAPI.SYS does not. I could not get UNIATA to work either.

Well you can examine my 8TB post I updated it with the DOS MBR I extracted.

Quote

I said what has been "achieved". 16TiB with USB already can be done. Nothing new here.

I don't think anyone has actually "achieved" and hooked up a true 16TB single drive as MBR in XP just yet.

Now there was this Samsung 16TB 2.5" SSD that cost a fortune that only Bill Gates' son could afford.  It's doubtful the owner of something like that would hook it to XP or make the attempt to get it seen as a 16TB MBR drive but most likely GPT on Windows 10.

Quote

Maybe if there was a compelling reason to go to 64K. The gain from going from 512B to 4K is far greater than the gain from going from 4K to 64K.

Assuming the OS's supported 64KB wouldn't the 64KB open up higher capacities just as 4K vs 512B?

I would figure it would be less of a burden when transferring TBs of data per second one day.

Quote

The fact that paging is 4K and many OSes such as 9x and presumably NT use 4k blocks internally, made 4K an easy choice. 64K would require a major rewrite of every OS FileSystem.
More likely they would add a translation driver to convert it down to 4K, which defeats the purpose of having 64K Logical Sectors in the first place.

Yes the 64KB to 4KB translation does slow it down but since it's done on the drive side the OS wouldn't care as long as the OS was happy with the 4KB blocks.

Quote

Incidentally, Microsoft doesn't mention that you cannot boot 4Kn drives on many Motherboards, even if the OS supports it.

There's only one way to find out and test on as many motherboards one has starting with the newest.  Since I have more Intel MBs you probably won't have to do that much work weeding out just the AMD ones that work with 4Kn drives.  I'll take care of the other half as soon as some cheap 2.5" 4Kn drive pops on the market to do some more testing.  But for the Bootable testing even the smallest capacity drive will do down to 128GB to see how they work with older OSs.

Microsoft has been notorious for leaving out exact facts that matter.  I'm sure they might as well have stated somewhere DOS will not work on anything past a P4 but here I am using it still today.

Quote

You must have read my Topic between updates. I added Windows 8 shortly after. I'm adding more updates in a few minutes. 

Must have been then.

Quote

You said you were partitioning Disk since MFM Days. I'm sure you haven't been partitioning 4TB Drives that long.

I started using 4TB as soon as they were available since most of these still supported XP via USB.  And since I learned my lesson with 2.5" drives using 512 Bytes AUS I began repartitioning these 4TB drives with 64KB AUS so they perform better.  I do have one 4TB 2.5" drive but the performance was real sluggish so I might have to check if this particular drive I had used 512 Bytes or 4KB which was the default.

Quote

You can connect any size Drive to a SATA Controller and access or even Boot from it in DOS.

It just won't be fully accessible without my Patches.

What do you mean by "fully accessible?" and which named "patches" are you referring?

Currently I can see the 3TB drive fine in 98SE DOS otherwise I couldn't partition it and make it bootable.

Edited by 98SE

Share this post


Link to post
Share on other sites
Quote
Quote

Size and Drive Letter are already customizeable. You can have as many as you want. To make them permanent, put the commands in AUTOEXEC.BAT.

Yes but not many would want to dig around in DOS to setup the Ramdrives.  Otherwise why did Microsoft develop Windows?  But as an attempt to simply the OS user interface so even kids and grandparents could use the computer instead of CLI geeks.

Aside from that assuming they setup the Ramdrive in DOS preloaded in the Autoexec, if they loaded into 98SE OS and wanted to change the Ramdrive letter from a DOS assigned Z: to X: would this work while within 98SE OS or would exiting to real 98SE DOS from 98SE OS work or would a warm reboot be required after modifying the autoexec be done first?

I would assume you need to do a warm reboot since the OS loading has either dirtied or locked the Ramdrives from changing drive letters or capacity.

Not many of my Customers are kids or grandparents. A GUI that edits the AUTOEXEC.BAT file would be simpler than trying to integrate it. Reboot is needed. 

Quote
Quote

Hidden RAMDisks would have no value since they cannot be accessed.

Well if you can make a hidden Ramdisk (not use a drive letter) as the Temp drive location it would be useful in that case as most people won't be digging around there.

You also mentioned you had a drive letter mounter to do any switching so you could switch it to a real drive letter when needed and force another drive out.

A Temp Folder has to be named. I could make an INT 13 RAMDisk that provides an unnamed drive, but this requires programs that can use it.

The swapper only runs in DOS. It can swap an existing Drive with a non-existing Drive but they both need to be Drive Letters A-Z.

Quote
Quote

You still did not answer my question about robustness.

Most of the ideas I stated were to make it such but as you said they are not possible.

So if the foundation of ideas can't work the subsequent ones will not matter.

No. Robustness means strong, sturdy, reliable, not fancy. Your ideas are unrelated to "robustness". 

Quote
Quote

I did not ask how much people would pay, I asked how much EXTRA people would pay  for the GUI Interface over what they would pay for the existing design.

Not sure.  I haven't checked your prices vs the current prices for others.

I suppose if yours did cost $20 then a GUI version for $30 would be reasonable to me and possibly others.

Or a combo package of both versions for $40 basically older CLI and newer GUI options for the user.

Maybe you should check first. 

Quote
Quote

PSE supports 2TiB so that is not a problem.

Then the price above I think would be fair for most all things equal.  What is the capacity limit of the Ramdrive for DOS and for 9X/ME?

2TiB.

Quote
Quote

It is about you. No one else is asking. If you are not a Billionaire, buzz off. 9x runs as well or better than DOS on any Motherboard. The functionality lost is not even available in DOS.

I'm thinking more like 8 figures for your universal product.

Depends on your target audience.  With 9X you are restricted and need a compliant 9X/ME based graphics card and drivers.  Going to real DOS most older DOS based games should work and native applications or utilities.  Now if FreeDOS was used instead possibly the source code could improve DOS hardware compatibility that might open up multiple cores to be utilized.  The 98SE USB advantage is allowing a USB sound device to be identified as a Sound Blaster type when used with DOSBOX.  There is less work for the user to get a DOS gaming rig going on a modern system in this manner than it would be to install 98SE from scratch on a Coffee Lake system.  Now if you're not a frequenter of Vogons you might not know the niche it may fill there for legacy gamers.

But this is the only viable idea I have of making 98SE relevant today on newer machines so it isn't about me.  Remember I have older P4s with ISA slots and have made SkyLake work with 98SE but the limitations and the steps to get it to work properly versus the 98SE DOS using 98 system files and USB 2.0 support would simplify a lot of the problems.  Most standard 9X/ME applications can run properly in XP so direct 9X/ME apps really are now pointless to most consumers.

However your background programming expertise is mainly in DOS and an understanding of 9X/ME so this is something I would think you'd be capable of doing rather easily.  We all wish we were billionaires but then we wouldn't be working anymore.  Like you said there is no free lunch so if you want food on the table you must make something that brings in the dough like your patches.  Just eyeballing the 98SE tests I've done on socket 1151/AM4 motherboards the pool of people trying to get these to work on these modern systems is less than I would have suspected.  Even recent attempts by others seem to have failed where I was successful and not many probably use my technique either.

DOS itself is rather simplistic and easier to get working even on a Coffee Lake system.  There is also no AHCI driver issue to deal with or any potential 9X/ME based conflicts that come up plaguing the system.  Otherwise I'm out of any other ideas that you can sink your teeth into of value.  I see no other branch to prolong 98SE's usefulness on modern systems and that's just being honest.

So it comes down to a FREEDOS modification to support multicores and being able to run 98SE programs at the command line.  98SE USB detection of devices (sound and game controller) in 98SE DOS the system is running.  Two other useful programs MUNT and DOSBOX that would definitely be 9X/ME programs if it could be run at the 98SE Real DOS command line would make 98SE relevant on modern systems.  Otherwise I would say the death coffin is pretty much closed for 9X/ME relevance which is regrettable.

You can run 9x without Video or Disk Drivers. I already have a partial solution for AHCI.

New machines use USB 3 so 9x Drivers would not be of any help even if I could interface them.

I am very rarely on Vogons so I don't know how many games can't be run on 9x that can be run on DOS.

Quote
Quote

I use 8GB for my Boot Partition. I do not have a lot of Applications. I have 6TB of Data Partitions.

I need the FAT16 for the backward compatibility of DOS programs in case it dislikes FAT32 partitions.

The vast majority of Programs don't care about the FileSystyem type.

Quote
Quote

No improvement. Translation involved rescaling the Address and Length Arguments of a Request. The Data Transfer is the same. Only misalignments cause problems because extra transfers are needed.

Sounds like SSDs going forward for larger capacities would be a better solution to avoid these misalignments.  The drives do take a beating and slow down reusing deleted space.

I already have a TRIM Program.

Quote
Quote

There is only one Adapter. The USB to SATA Adapter.

The USB Bus is 4K in this case. The SATA Bus is 512B.

Are all the USB to SATA adapters you have 4K USB Bus and 512B SATA Bus including the two USB docks you previously mentioned?

What current > 2.2TB drive capacities do you have now aside from the recent 6TB 4Kn drive?

Does your SATA to USB adapter allow the 6TB 4Kn drive to recognize the entire drive as one large MBR NTFS partition uncapped?

Most of my adapters auto-translate. They use 4K Sectors on the USB Bus for Drives >2TiB and 512B Sectors for smaller Drives.

The two Docks are non-tranlating

I have at least one External Drive that uses an adapter that appears to always translate since it is <2TiB. I haven't opened it so there might not be a physical adapter.

Quote
Quote

Now I am testing scenario #3 and #4.

Hard drive platter 4KB Physical - HD circuit board to SATA connector - Logical 4KB - SATA Cable - Sata Controller - OS

Hard drive platter 4KB Physical - HD circuit board to SATA connector - Logical 4KB - SATA to USB Adapter - USB Cable - USB Port - OS

You might want to see if your new 4Kn drive hooked via SATA directly can interface with XP SP1-3 and the same for USB 2.0 Port to XP SP1-3.

Does both the SATA and the USB method allow booting off this 4Kn drive on the Z87?

Windows XP SP3 does not support 4Kn drives hooked via SATA. The BT-300 USB Adapter passes through the 4K Sectors so it should work with XP the same as more conventional large External Drives.

The Z87 won't boot off 4K USB Devices, only 4Kn SATA Devices.

Quote
Quote

Normally 512.

I did not test XP SP1.

XP SP3 can handle 4KB at the FileSystem level. The USB Stack can also handle 4K. The IDE stack only handles 512B.

So both XP SP3 and the USB Stack handle 4KB at the FS level?

Are you saying XP works with your 4Kn drive directly connected via SATA and also using your SATA to USB on the USB 2.0 ports?

The FS supports 4K.

The lack of IDE support prevents a SATA Connected 4Kn Drive from working.

Quote
Quote

Since the IDE Stack only handles 512B Logical Sectors. There is not way to adapt a Hard Drive to increase capacity. Your proposed circuit just makes it a 4Kn Drive, undoing the internal translation,

The IDE stack is used if using the IDE controller with IDE devices but what about a BIOS setting SATA in IDE compatibility mode, does this use the IDE stack in XP?

How does this affect computers using the XP AHCI mode which SkyLake and all modern systems are now stuck on?

Different BIOS manufacturers use the term IDE rather ambiguously, typically to refer to the older Technology.

It can mean:

PATA not SATA
Legacy not Native
Register not AHCI
Not RAID

In the case of XP the IDE Stack handles all Register based Controllers, not AHCI. PATA vs. SATA and Legacy vs. Native Mode settings are not relevant.

If you have an AHCI Driver or use the latest UniATA, you have AHCI support.

Quote
Quote

A Patch or new Driver for XP is needed.

You are talking about the IDE stack?  What files are needed to be patched?  This sounds like something that would affect NT/2K since they lack AHCI.

Not sure. At least PARTMGR.SYS. You have the Paragon GPT Loader, I don't. It replaced files.

Quote
Quote

The FileSystem in Windows 9x actually supports 2K Sectors but some other parts of the stack don't.

No idea about 2K. XP apparently was designed with 4K support.

So what ends up happening in 9X when using the 2K Sectors or your 4Kn drive?

2K is the limit for an unmodified 9x FS. I upgraded it to 4K with my Patches. I can't test 2K with my 4Kn Drive. I tested 2K performance by putting a FAT32 Partition on a CD.

Quote
Quote

The FileSystem in XP supports 4K. I thought it might fully support 4K after reading the web page I posted. When it failed in my experiments, I reread the page carefully.
Apparently he was using a RAID Driver that did work. The standard ATAPI.SYS does not. I could not get UNIATA to work either.

Well you can examine my 8TB post I updated it with the DOS MBR I extracted.

RFDISK can make any MBR I need. Your post is irrelevant here.

Quote
Quote

I said what has been "achieved". 16TiB with USB already can be done. Nothing new here.

I don't think anyone has actually "achieved" and hooked up a true 16TB single drive as MBR in XP just yet.

Now there was this Samsung 16TB 2.5" SSD that cost a fortune that only Bill Gates' son could afford.  It's doubtful the owner of something like that would hook it to XP or make the attempt to get it seen as a 16TB MBR drive but most likely GPT on Windows 10.

I said "can be done", not did. The capability to do 16TiB with USB is old news.

Apparently you are admitting the even a 16TB Drive is going to end up being Partitioned with GPT. So stop pushing >4K Sectors.

Quote
Quote

Maybe if there was a compelling reason to go to 64K. The gain from going from 512B to 4K is far greater than the gain from going from 4K to 64K.

Assuming the OS's supported 64KB wouldn't the 64KB open up higher capacities just as 4K vs 512B?

I would figure it would be less of a burden when transferring TBs of data per second one day.

I was referring to Physical Sector size.

The capacity increase only applies to MBR. EMBR and GPT won't have this problem for a long time. 

The timing bug in Windows 98 will reappear long before these speeds are achieved.

Quote
Quote

The fact that paging is 4K and many OSes such as 9x and presumably NT use 4k blocks internally, made 4K an easy choice. 64K would require a major rewrite of every OS FileSystem.
More likely they would add a translation driver to convert it down to 4K, which defeats the purpose of having 64K Logical Sectors in the first place.

Yes the 64KB to 4KB translation does slow it down but since it's done on the drive side the OS wouldn't care as long as the OS was happy with the 4KB blocks.

As I mentioned before, switching from 4K to 64K Physical Sectors would only provide a mild capacity improvement. The ECC overhead was already reduced by going to 4K.

The translation itself does NOT slow things down as long as alignment is maintained.

Translation only affects Pointers and Length not the actual transfer.

A 512B request such as read 16 Sectors starting at Sector 800 is translated to a 4K request to read 2 Sectors starting at Sector 100. Everything else is the same.

Quote
Quote

Incidentally, Microsoft doesn't mention that you cannot boot 4Kn drives on many Motherboards, even if the OS supports it.

There's only one way to find out and test on as many motherboards one has starting with the newest.  Since I have more Intel MBs you probably won't have to do that much work weeding out just the AMD ones that work with 4Kn drives.  I'll take care of the other half as soon as some cheap 2.5" 4Kn drive pops on the market to do some more testing.  But for the Bootable testing even the smallest capacity drive will do down to 128GB to see how they work with older OSs.

Microsoft has been notorious for leaving out exact facts that matter.  I'm sure they might as well have stated somewhere DOS will not work on anything past a P4 but here I am using it still today.

You will need to buy the Drive and my TeraByte Plus Package. I am planning to add the newest 4K fixes soon.

Quote

You said you were partitioning Disk since MFM Days. I'm sure you haven't been partitioning 4TB Drives that long.

I started using 4TB as soon as they were available since most of these still supported XP via USB.  And since I learned my lesson with 2.5" drives using 512 Bytes AUS I began repartitioning these 4TB drives with 64KB AUS so they perform better.  I do have one 4TB 2.5" drive but the performance was real sluggish so I might have to check if this particular drive I had used 512 Bytes or 4KB which was the default.

You cannot use an AUS smaller than the Logical Sector size.  

Quote

You can connect any size Drive to a SATA Controller and access or even Boot from it in DOS.

It just won't be fully accessible without my Patches.

What do you mean by "fully accessible?" and which named "patches" are you referring?

Currently I can see the 3TB drive fine in 98SE DOS otherwise I couldn't partition it and make it bootable.

Fully accessible means that the entirety of the Disk can be accesses without causing corruption.

The "Patches" refer to my TeraByte Plus Package Patches. This the only relevant Package to this entire discussion.

When I wrote it, I combined all my major Disk related projects into one Package. This includes:

LBA-48 support.
Providing support above 2TiB for 512B Disks.
EMBR support.
Large Logical Sector support.
Larger Cluster support.
Native Mode and PCI/PCI-E Card support.
Partition fixes and improvements
Replacement Boot loader for IO.SYS.
BIOS replacement DDOs.
Advanced Partitioning and Formatting tools.

You can see and boot from a 3TB SATA connected 512e Drive but you cannot access all of it. DOS would not understand an address above 2TiB. If you use the 4TiB MBR approach, you will corrupt the Drive.

Edited by rloew

Share this post


Link to post
Share on other sites

It looks like support for Drives between 2TiB and 16TiB is disappearing.

In addition to reports that newer USB Drives no longer use 4K translation, I just tested a newer USB/SATA Adapter and it does not do 4K translation either. 

The Adapter did work with a 4Kn Drive, so this may be the only option left for >2TiB with unmodified 2K/XP.

Share this post


Link to post
Share on other sites

I just ran some experiments to break the 256TiB Partition limit in NTFS. I was unable to get past 64KiB Clusters using Patches or the 4KN Drive so the limit still stands.

I was able to get 512KiB Clusters to work in Windows XP (USB) and 7 using FAT16 and FAT32 with 4K Sectors. This increases the FAT16 limit to 32GiB. FAT32 is still stuck at 16TiB.

Share this post


Link to post
Share on other sites
On 30/08/2017 at 2:48 AM, jaclaz said:

 we have many reports of 3 Tb disks (512 bytes sectored) working just fine in XP (limited to a first parttion of 2.2 Tb or however up to the 2.2 Tb limit) and the internet is choking full of reports of both XP and 7 showing the 746 Gb issue, but with no real "fix" if not "try this other driver version, and reportedly the standard Microsoft drivers work.

Can you tell me where I can see some of these reports? Sorry, but it's really hard to Google for this subject and get relevant  hits unless you already know most of the answer.

Specifically, how do I format a 3TB drive to get a 2,2 TB partition readable in XP without any 3rd-party driver or hacks? XP disk management doesn't see the unformatted disk at all, whether  connected by SATA or USB caddy.

I can boot to Ubuntu by USB to use a Linux disk tool.

Share this post


Link to post
Share on other sites

XP should see it but may under-report it's size. Linux or Windows 7+ tools should be OK.

Connect using SATA unless you are sure that your USB enclosure does not translate to 4K.

No hacks or drivers are needed if you are using SP1 or later.

Share this post


Link to post
Share on other sites
5 hours ago, rloew said:

XP should see it but may under-report it's size. Linux or Windows 7+ tools should be OK.

Connect using SATA unless you are sure that your USB enclosure does not translate to 4K.

No hacks or drivers are needed if you are using SP1 or later.

 

Well, I plugged it into internal SATA and Windows XP storage management couldn't see it at all. But I could scan it with GSmartControl.

I put it in a generic SATA-USB caddy, same.

Then finally put it in my old WD Elements enclosure.  In USB this was detected as a 2 TB drive that I could format and partition.

So at least I have a working new drive slightly larger in size than  the original 1.5TB it replaced.

 

Share this post


Link to post
Share on other sites
9 hours ago, Asp said:

Can you tell me where I can see some of these reports? Sorry, but it's really hard to Google for this subject and get relevant  hits unless you already know most of the answer.

Specifically, how do I format a 3TB drive to get a 2,2 TB partition readable in XP without any 3rd-party driver or hacks? XP disk management doesn't see the unformatted disk at all, whether  connected by SATA or USB caddy.

I can boot to Ubuntu by USB to use a Linux disk tool.

The issue is that there is no actual "good for all" solution, these reports are (the ones I have seen) confused/confusional and/or use this or that specific driver/tool/whatever, like - say - Seagate DiscWizard,  or Asus Disk Unlocker, or newer Interl RST drivers, it is a mess, and part of it may be connected actually to the actual motherboard BIOS.

In your case the problem seems that the disk needs to be "seen" by the motherboard, depending on a number of factors it may be seen as a 746 Gb disk.

You can try doing a "blind" partitioning with grub4dos as we did with Tripredacus, around here:

http://www.msfn.org/board/topic/176480-2-tib-limit-size-in-mbr-hard-drives/?do=findComment&comment=1142954

but the disk needs to be *somehow* seen by BIOS (and thus by grub4dos).

jaclaz

 

EDIT: @Asp I see now you solved the issue another way, ignore the above

Edited by jaclaz

Share this post


Link to post
Share on other sites
1 hour ago, jaclaz said:

but the disk needs to be *somehow* seen by BIOS (and thus by grub4dos).

It was always seen by the BIOS, whether connected by SATA or USB just Windows XP couldn't until I used the WD enclosure.

For completeness, now that it is formatted, I should take it out of the enclosure and try the other methods again, but wrestling the box open and closed again takes a while and risks breaking the case , so I'll just let sleeping disks lie.

Thanks for your reply though. I'd never heard of GPT 'til yesterday, never having had a disk larger than 1.5TB before, so it was a crash course.

  • Like 1

Share this post


Link to post
Share on other sites

The WD Enclosure might be translating to 4K. Use CHKDSK on the Drive Letter to find out.

If so, you can Partition the entire 3TB with the proper Partitioning tool.

Share this post


Link to post
Share on other sites
11 hours ago, rloew said:

The WD Enclosure might be translating to 4K. Use CHKDSK on the Drive Letter to find out.

If so, you can Partition the entire 3TB with the proper Partitioning tool.

No. It's pretty old, and came with a 1.5TB that didn't need that. It showed as 2 TB unformatted to Windows.

This is what GSmartControl reports

Device Model:     WDC WD30EJRX-89G3VY0
Serial Number:    WD-WCC4N2REE8AH
LU WWN Device Id: 5 0014ee 26475a2d4
Firmware Version: 80.00A80
User Capacity:    3,000,592,982,016 bytes [3.00 TB]
Sector Sizes:     512 bytes logical, 4096 bytes physical

That's the same as when it was directly connected  via SATA.

I assume that logical would be 4096 if it was translating.

 

 

Share this post


Link to post
Share on other sites

GSmartControl might be reading the information from the Disk Drive. If so, it is reading the Sector Size of it's SATA Interface, not necessarily the USB Interface.

Try making a small Partition and format it with 512 Byte Allocation Units. If it works the Interface is 512 Bytes.

Never mind CHKDSK, it doesn't provide what is needed.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now


  • Recently Browsing   0 members

    No registered users viewing this page.

×