Export thread

I’ve been a licensed user of SpinRite since v6.0. The reason I acquired it was primarily to address 3TB and 4TB SATA drives used in my direct-attached and NAS drive arrays. My bad on v6.0, there were drive size limitations. But with v6.1, I have never been able to get SpinRite to recognize a drive above the 2.2GB limit, it seems no matter what I’ve tried.

I can get FreeDOS to boot and SpinRite to run, as I have tried on several different machines with CSM BIOS support and able to boot off USB. I have tried directly attaching to the motherboard on a desktop, and also connecting SATA drives externally via USB. I have bought and tried 6-7 different adapters and hard drive cradles which purport to support larger hard drive geometry. All show my drives at 2.2TB, even though if I boot into Windows they all show 4TB.

I’ve tried everything I know to do, with desktops, laptops, different external hard drive cradles and SATA adapters, and I have never been able to use SpinRite on my hard drives, as they are all above this 2.2TB limit, and no combination I’ve tried will do it in SpinRite, even though the hardware and normal OS detects it fine. It seems that we are being progressively caught in a bit of tech-evolution no-man’s land with an awesome tool (SpinRite) which is pinned to legacy BIOS and legacy OS and hardware to run it, but trying to address current hard drive geometry. I understand why, and the eventual best solution will arrive in v7.0. But for now, I’d like to figure out a solution, and so I am requesting help, which might take one of the following forms (or all):

- If there is something simple I have somehow missed in process or configuration, let me know. I am always a fan of the “I’m an idiot” solution — it resolves things quickly!
- Unless this has been published somewhere and I’ve missed it (and if so, so have all the public AI models — we need to get those trained), what we need is a published machine spec for running SpinRite v6.1 so that it boots to SpinRite and recognizes large hard drive geometry properly. I’m not talking about just a list of standards that needs to be supported, I’m talking about specific brand and model of either laptop or motherboard, any required components, and specific configuration required on that build — a “SpinRite Utility System” you might say. If I can get that, I’ll buy the components and build it. No more weeks and months of testing or acquiring old or new hardware uncertain that it will do the job. This would solve the problem for me, and I imagine many others, until SpinRite v7.0 emerges.
- Some other option I am not aware of.

I anyone can give me a hand / point me in the right direction, I'd greatly appreciate it. I've owned SpinRite for years but have never been able to use it on a whole box of SATA drives for my drive arrays. Thanks so much for your help!

Brad

The issue you're encountering is that the machines you've tried are likely all old enough to not have a modern BIOS that is capable of 48-bit LBA addressing. All older machines only did 32-bit LBA addressing and 2^32 x 512 bytes = 2,199,023,255,552 bytes (which is your 2.2TB limit.) For completeness, 2^48 x 512 bytes = 144,115,188,075,855,872 bytes, or 144,115 TBs. I have newer AMD machines that are able to Legacy Boot, but also support 48 bit LBAs and I have successfully used 3TB drives with SpinRite during development testing of version 6.1.

48bit LBA addressing was "invented" around 2003. Perhaps you could supply information about the machines you've tried (including BIOS supplier and version) and someone else here will know info about them and can confirm what I've suggested.

Another possibility is that DOS is picking up on the NAS specific format of the drives, and the NAS is using MBR which is also limited to 32 bit LBA addressing. GPT (GUID Partition Table) supports 64-bit LBAs. If you can blank one of the drives, then you could put a GPT partition on it and see if anything changes.

PHolder said:

The issue you're encountering is that the machines you've tried are likely all old enough to not have a modern BIOS that is capable of 48-bit LBA addressing. All older machines only did 32-bit LBA addressing and 2^32 x 512 bytes = 2,199,023,255,552 bytes (which is your 2.2TB limit.) For completeness, 2^48 x 512 bytes = 144,115,188,075,855,872 bytes, or 144,115 TBs. I have newer AMD machines that are able to Legacy Boot, but also support 48 bit LBAs and I have successfully used 3TB drives with SpinRite during development testing of version 6.1.

Perhaps you could supply information about the machines you've tried (including BIOS supplier and version) and someone else here will know info about them and can confirm what I've suggested.

Click to expand...

Thanks for the reply. I’ve tested a few semi-recent Lenovo laptops (2018, 2019) which had no problems CSM booting and running SpinRite but couldn’t recognize drive size about 2.2TB. It sounds like you’ve gotten past it. What I want to do is stop randomly testing hardware, and build a small rig with hardware that is known to work. Do you (or does anyone) know a hardware configuration I could buy off of Amazon right now (either pre-built or I’ll assemble it) which is known to work? How about Raspberry Pi -type stuff — anything in the mini / micro computer / board config which might work?

Thanks in advance!
Brad

Okay, well if your machines are that new, then I guess it must be your drive. It appears you replied while I was still editing my reply above, so give the final version another reading and see if you're willing to make a test of repartitioning the drive.

Once we know if that's the catch, you might decide to try using the ZimaBoard that Steve himself actually used for his development. There is more details around it elsewhere on this site, including a recommendation for a more powerful power supply to power spinning drives. One word of warning, it appears that there is a newer model (ZimaBoard 2) that is as yet unknown if it supports Legacy Booting. I have a support query into them, but have not heard back yet. It appears supply of the original might be dwindling, as they might be intending to replace it with the new one.

I’ll try to repartition the drive, and I’ll post the results back here. Thanks so much for your help. Stay tuned…

How did you create your SpinRite 6.1 boot drive? I don't think it should matter as long as it's DOS or FreeDOS, but something isn't quite right in your setup. 6.1 absolutely supports drives larger than 2.2 TB, it's one of the main reasons Steve created 6.1.
Would you be willing to share your log files? They are in the SRLOGS folder on your SpinRite boot drive. I recommend putting them in a ZIP file before uploading them here.

Mount each drive internally as SATA, one at a
time, as the only drive in a computer, boot
from a FreeDOS USB, with no CONFIG.SYS if
necessary ( or ONLY BUFFERS=98 ), and try:

SPINRITE NORAMTEST SKIPVERIFY

Also, @Paul F created and kindly 'donated' a
utility that empowers SpinRite 6.1 to run on
MS-DOS, so if FreeDOS still does not pass
access to the full drive, let us know and we'll
help you try MS-DOS and SpinRite 6.1.

brado2049 said:

I can get FreeDOS to boot and SpinRite to run, as I have tried on several different machines with CSM BIOS support and able to boot off USB. I have tried directly attaching to the motherboard on a desktop, and also connecting SATA drives externally via USB. I have bought and tried 6-7 different adapters and hard drive cradles which purport to support larger hard drive geometry. All show my drives at 2.2TB, even though if I boot into Windows they all show 4TB.

Click to expand...

Some general information . . .

Any external drive, be it USB, ESATA, any cradle/adapter will be accessible ONLY thru the BIOS and hence subject to BIOS limitations, including 2.2 TB capacity.

SpinRite 6.1 is not hardware NAS compatible.

Drives connected internally to the motherboard should be accessible via SpinRite 6.1's native drivers and thus not subject to any BIOS limitations.

What do you see on the "System's Mass Storage Devices Discovered" screen for internally connected drives? Specifically in the Type column???
For a drive connected directly to a SATA controller on the motherboard, the Type column should show AHCI or ATA or IDE.
IF all you see in the Type column is BIOS then (a) the drives may not be connected properly or (b) a BIOS setting may be overriding and forcing BIOS access.

Last but not least . . . when SpinRite 6.1 is able to use its native drivers to access an internal drive then partitioning is totally irrelevant and BIOS limitations do NOT apply.

Hope something here helps . . .

Maybe unrelated, but, depending on the contents of track 0, especially
being blank or unpartitioned, and having run System RAM Test, SpinRite
6.1 Release 4 may show a 'ghost', a second copy of a drive that is
inaccessible, see
https://gitlab.grc.com/Steve/spinrite-v6.1/-/issues/686 if and when
@Steve brings the SpinRite 6.1 development archive back online:



No problem, just access the first instance of that drive, or run:

SPINRITE NORAMTEST

@Steve promises an eventual Release 5 to address that and any other
subsequent discoveries and quirks we may find.

Thank you everyone for all your responses. You’ve given me a couple things to try.

• Because the current hardware I have are laptops (two Lenovo and a Razer), all which can boot CSM / SpinRite but cannot see above the 2.2TB limit, I think I have been running into the MBR limit, so GPT partitioning is the first thing to try.
• I’d like to have an optimal rig which avoids the issues with USB cradles — direct-connect SATA and native SpinRite drivers (which I never understood before). I have heard Steve mention the Zima boards several times over the last year on podcast episodes, and one of you mentioned it above, but I wasn’t completely sure of the use-case. Is my situation a proper use case for the Zima hardware? If this *is* the use-case, if anyone can link to a good resource on this forum for Zima hardware / configuration (I’ll search myself too, but I don’t want to inadvertently miss the good posts).

If / when I get things to a happy place — especially if I can build a tiny / compact rig for this, I’ll post the details here.

Final note — I’m a career software developer / security guy that’s done some OS filesystem / driver development in the past — kind of makes me wonder if it might be worth developing a virtualization layer for SpinRite — it would be really cool if (just using this as a use-case example disregard the specific Docker reference) you could just gun up SpinRite using something like Docker on any newer hardware and it would run bypasing lower-level hardware issues. Hmmm…..

brado2049 said:

I think I have been running into the MBR limit

Click to expand...

SpinRite 6.1 doesn't care about MBR vs GPT. Please post your log files.

Are you attaching the drive INTERNALLY as SATA to the laptop, even
with adapter cables if the drive is 3 1/2" and the internal bay is 2 1/2"?


Or are you attaching the drive via a USB-to-SATA adapter?

A USB adapter will be subject to the CMOS BIOS restrictions, and
USB was a mess of non-standard misbehavior.

Hence the call to install the drive internally as SATA - and have it be
the ONLY drive, in order to simplify things,

- - - - -

Regarding 'bring your own OS and drivers' to bypass CMOS BIOS, see:

https://forums.grc.com/threads/how-to-run-spinrite-on-a-uefi-only-machine-part-1-of-5.1613/

... and equivalent 'spinrite vm virtual machine' search results at forums.grc.com

... and:

https://www.grc.com/x/news.exe?cmd=article&group=grc.spinrite.dev&item=56492&utag=




That's a 128GB nVME under SpinRite 6.1.

=8^o

brado2049 said:

Final note — I’m a career software developer / security guy that’s done some OS filesystem / driver development in the past — kind of makes me wonder if it might be worth developing a virtualization layer for SpinRite — it would be really cool if (just using this as a use-case example disregard the specific Docker reference) you could just gun up SpinRite using something like Docker on any newer hardware and it would run bypasing lower-level hardware issues. Hmmm…..

Click to expand...

Peter gave a link to what is essentially a virtualization layer using a full-blown VM. I don't know if something like Docker will work with code that's running in 16-bit real mode and uses the BIOS, which SpinRite 6.1 still does. Right now Steve has no plans to further develop the 16-bit real mode SpinRite. His goal with SpinRite 7 is to move the code to Win32 which will run under Windows as well as a separate embedded OS that supports Win32 that he has purchased the rights to.

Wow -- thanks everyone for the great responses! Forgive the slight delay in response, I'm so delighted at the knowledge and help, I wanted to make sure to have good information to provide in a reply. I was in the middle of an office move, and had some of my gear packed, so I had to set it up again. Ok, hopefully I'll have the info needed to completely diagnose this issue in this post, but if there's anything missing, I'll be happy to get it with your guidance. So without further qualification, here we go with my setup:

• Lenovo ThinkPad laptop, Model 20QQS6CN00. Product page / manual - https://pcsupport.lenovo.com/us/en/...-20qn-20qq/20qq/20qqs6cn00/document-userguide
• BIOS version/date: LENOVO N2NET61W (1.46 ), 7/23/2024
• USB dock: StarTech.com Standalone Hard Drive Duplicator, External Dual Bay HDD/SSD Cloner/Copier, USB to SATA III Docking Station - https://www.amazon.com/dp/B019Y4JE22?ref_=ppx_hzsearch_conn_dt_b_fed_asin_title_1&th=1
• Hard drive: Toshiba MDO4ACA400 4TB

As requested, I have attached my SpinRite logs from a past run, in which you can see that the 4TB drive is only being recognized as 2.2TB. I have also attached a screenshot of this drive in Windows Disk Management which shows the drive being recognized properly.

Ok....SpinRite superheros unite! I'm ready to follow whatever guidance you have, anything I need to try, etc. Thank you so much for your help so far, and any help you give from this point forward. It is greatly appreciated!

NOTE: this is the hardware I have accessible at the moment, so I'd love to get this working properly with this computer if possible.

brado2049 said:

As requested, I have attached my SpinRite logs from a past run

Click to expand...

Thank you! Do you have any logs from when you tried connecting this drive to a desktop via a SATA port?

brado2049 said:

I have also attached a screenshot

Click to expand...

Unfortunately, that didn't come through. This forum has a hidden size limit of 500 kB, so you'll have to resize the image.

You're running into a 2.2 TB limit on your laptop because SpinRite only knows how to access USB drives through the BIOS. Windows has its own USB drivers, so it's able to access the full size of the drive. I think the only way you're going to get SpinRite to see the full size is to use SATA. A few options include:

• Borrow an old desktop from a friend. 6th-generation Intel and older (or AMD equivalent) work best. SpinRite does not need a powerful CPU.
• Buy an old desktop from a thrift store, eBay, FB Marketplace, etc.
• Buy a Zimaboard, if they're still available. https://shop.zimaspace.com/collections/zima-products-family/products/zimaboard-single-board-server
• Buy an adapter for your laptop, such as the one that Peter mentioned, or something like this (plus an external power supply): https://www.amazon.com/Adapter-SATA3-0-NO-Riad-Desktop-Support/dp/B0B5RJHYFD

@ColbyBouma, thanks for the reply. Responses:

Do you have any logs from when you tried connecting this drive to a desktop via a SATA port?

Click to expand...

Unfortunately, not at the moment.

Quick clarification:

You're running into a 2.2 TB limit on your laptop because SpinRite only knows how to access USB drives through the BIOS.

Click to expand...

I was under the impression that there was a way for SpinRite to work with drives connected via USB. Can it be said definitively that the only way SpinRite will recognize drives above the 2.2TB limit is with direct SATA connection to the motherboard, and connecting via USB will not work in any configuration?

Buy a Zimaboard, if they're still available.

Click to expand...

Do you (or anyone) happen to know if the Zimaboard2 supports CSM / legacy booting? I think those are still available...

I tried attaching that screenshot again, hopefully it took this time. Thx again for your help.

brado2049 said:

Quick clarification:
I was under the impression that there was a way for SpinRite to work with drives connected via USB.

Click to expand...

In most cases, Nope. Please see https://forums.grc.com/threads/usb-support-in-spinrite-6-1.1479/ for more information.

SpinRite 6.1 (like its venerable predecessor SpinRite 6.0) can only access external drives (USB, etc.) via the BIOS, subject to all the limitations of the BIOS.

brado2049 said:

Can it be said definitively that the only way SpinRite will recognize drives above the 2.2TB limit is with direct SATA connection to the motherboard, and connecting via USB will not work in any configuration?

Click to expand...

In almost all cases: Yes The rare exception would be a system with a more modern BIOS that can address space beyond the 2.2 TB limit.

With a direct connection to a SATA controller on the motherboard, SpinRite 6.1 will be able to use its native drivers, thus eliminating the BIOS and its limitations entirely.

Regarding the screenshot: SpinRite 6.1 is partition agnostic. SR 6.1 will treat a drive (0, 1, or 2) as a single raw data drive entity when using it's native drivers.
The BIOS, however, would see each partition as an individual BIOS drive entity.

Happy Saturday! I chased down a little further, reading various doc and a little ChatGPT research help. Forgive me if I may be repeating certain things some of you have said above in this conversation. Some of my research has been to understand that, and also to reconcile it with what I'm seeing. Here are some things I have dug up:

*** The 2.2 TB Limit on legacy BIOS

• The legacy BIOS boot process uses the Master Boot Record (MBR) partitioning scheme.
• MBR uses a 32-bit field to store the maximum number of sectors.
• Assuming 512-byte sectors:
  • Max sectors = 2^32 = 4,294,967,296
  • Max size = 4,294,967,296 × 512 bytes ≈ 2.2 TB
• So with MBR, legacy BIOS cannot boot from partitions that extend beyond this size because it cannot address beyond the 2^32 sector boundary.

*** How disks >2.2 TB are recognized on legacy BIOS systems

As data disks (not boot disks)

• The OS can use disks larger than 2.2 TB for data only by initializing them as GPT (GUID Partition Table).
• The BIOS doesn’t interact with GPT directly — the OS’s drivers do once loaded.
• So you can attach a 4 TB drive on an old BIOS machine, format it GPT, and it will work as a non-boot data drive in Windows, Linux, etc.

Using 4K native sectors

• Some drives (like Western Digital’s Advanced Format 4Kn disks) use 4096-byte native sectors.
• This effectively allows the 32-bit sector field to address up to:
  • 2^32 × 4096 bytes = 16 TiB
• However, these drives must be paired with BIOS or OS drivers that support 4K native. Many legacy BIOS implementations still fail here.

Ok so I have gone the route of #1 above -- I have a USB thumb drive that is a SpinRite boot drive created with the SpinRite utility for doing so. It boots legacy BIOS just fine, and I can run SpinRIte. I also have a hard drive initialized as GPT, which in Windows is recognized as its full 4TB capacity, which verifies another aspect of the setup, which I also researched separately, which is that my StarTech USB cradle's USB-SATA bridge inside supports 48-bit LBA, so it can see up to 6TB of disk space (my drive is only 4TB).

According to all the research I've done, and whatever pseudo-reasoning AI can stumble through, my configuration should work. Here is the conclusion statement from the ChatGPT research I did:

*** Will it [my configuration] work?
Yes.

• Legacy BIOS only cares about the drive you’re booting from (your small USB drive).
• Your OS (Windows, Linux, etc) handles GPT for data disks just fine.
• So your 4TB drive, even connected by USB, will be fully accessible with a GPT partition table.

That brings me back to the question of why this isn't working -- and bear with me, I'm just trying to understand why, because solutions stand on the shoulders of understanding the why of things. I read the forum thread just posted above:

In most cases, Nope. Please see https://forums.grc.com/threads/usb-support-in-spinrite-6-1.1479/ for more information.

Click to expand...

That talks a lot about BIOS, but according to the research I did (and I probably am just not fully understanding it), the BIOS primarily governs the boot drive, not the data drive. As a result, I didn't fully understand the referenced post, and in particular this statement:

Accessible BIOS drives will typically be limited to just the first 2.2 TB of capacity, with the exception of the rare BIOS that is able to access additional capacity.

Click to expand...

...my research seemed to indicate that It is not the BIOS, but the OS support for GPT that determines whether the full capacity of a non-boot data drive is accessible. So I guess that is the clarification I am asking now -- is the problem ultimately one that SpinRite does not fully support GPT?

Again, forgive me -- despite having worked on OS file systems in the past, I'm not the expert on these specific driver issues. I'm just trying to understand very specifically what is causing the problem. It might lead to other ideas for solutions, and likewise, rule out trying things that would not work, saving time. Likewise, knowing the specific problem will help answer the next obvious question of why direct-connect SATA would work while USB-SATA bridge would not in this case, which I would like to understand before dropping $300 on a ZimaBoard2 -- which I'll do when I understand why that works and this does not. I think I'm close, but there's still a missing piece of the puzzle in the explanation. Thanks again so much for your help and guidance.

brado2049 said:

...my research seemed to indicate that It is the OS support for GPT that determines whether the full capacity of the drive is accessible. So I guess that is the clarification I am asking now -- is the problem ultimately one that SpinRite does not fully support GPT?

Click to expand...

Both SpinRite 6.0 and 6.1 are:
- OS agnostic
- File system agnostic

SpinRite 6.1 is also:
- Partition agnostic (Thus SpinRite 6.1 does NOT care about GPT)

SpinRite 6.0 is, however, partition aware, but is not NOT compatible with GPT partitioning.

If SpinRite 6.1 can use it's native (built in) drivers to access an internal drive connected to a controller on the motherboard, then the above applies to SpinRite 6.1. SpinRite 6.1 then will have NO limitations re OS, file system, data, partitioning, drive capacity - all will be completely irrelevant to SpinRite 6.1

However, if SpinRite 6.1 must use the BIOS to access a drive, then BIOS limitations (including capacity) will apply. But each BIOS drive will simply be a single raw data entity with OS, file system, data, partitioning all irrelevant to SpinRite 6.1.

ONLY via the FORCE command line option:

SPINRITE FORCE

Otherwise, SpinRite 6.0 will try to recognize drive
data operating system contents, and update them
with anything newly found regarding bad sectors.

- - - - -

SpinRite 6.1 is contents agnostic, EXCEPT for
unpartioned drives, where they may show up as
a second ghost drive after running the System
RAM Test. It's not a danger, just confusing.
Solution: the NORAMTEST command line option:

SPINRITE NORAMTEST

If a computer has no SATA sockets, only M.2 or
NVMe, you can try an M.2-to-SATA adapter,
and provide your own power supply to a SATA
drive:


Otherwise, a dedicated old cheap computer with
SATA sockets on the main system memory bus
board is an excellent route - some of us never
throw old computer stuff away, it always seems
to come in handy.

@DanR, @peterblaise, and everyone else-- thanks so much for the great help! You and others have been so helpful. Forgive me again -- I'm a career developer, and sometimes higher-level or partial explanations, while accurate in intent, actually raise other questions. So I was poking a little more at ChatGPT, and it produced some technical details that were incredibly insightful, and given everything I had read on these forums, contained a detail or two I did not expect. I decided to format the entire conversation in Markdown and attach it for any other inquisitive souls which might come after (notice the extension of *.md.txt -- for some reason it would not take an attachment with a *.md extension).

Give the attached doc a read...it surprised me -- but according to this conversation, the TLDR of why in my case the 2.2TB limit (warning, the below is a bit pedantic) appears to be the following:

Your BIOS is part of the limit (via Int 13h), but mainly the DOS application does not support GPT nor large addressing.

• To fully see & use the 4TB GPT drive, you would need either:
  • a modern OS that bypasses BIOS after boot (Windows, Linux), or
  • special DOS drivers that implement large LBA and GPT.

Click to expand...

In other words as I understand this, sparing the lower level details (see the attached doc):

The problem isn't one of large-drive capacity support via USB connection (or my specific USB-SATA bridge / 48-bit LBA support) or GPT partitioning vs direct-SATA connection. Strictly speaking, direct-SATA connection isn't providing any drive support or solving a problem per se that exists in a USB configuration, and the problem isn't a BIOS limitation per se. The problem is both FreeDOS and SpinRite support of viable configurations (not a knock, just a clarification, as it makes the difference in whether trying to debug a configuration is a worthwhile move -- or starting over). The problem seems to be that FreeDOS doesn't support it, and best I can tell (could be wrong), is that SpinRite's drivers implement large LBA and GPT only with direct-connected SATA drives. Following, there isn't really anything magic about a ZimaBoard or any other hardware, and there should be no struggle for config -- direct-connect SATA to motherboard, done-and-done. It's not whether other configs properly support large hard drive capacity, this is about SpinRite drivers.

I think I now understand a lot of isolated comments many of you have posted above in their proper context. Forgive me again for taking a bit more research to clarify what I imagine are a few who commented above thinking "yeah, that's what I told you before". Your comments are greatly appreciated and even right on, I just needed to understand what was under the hood of those comments. Again, your guidance got me to this point.

So..if anyone could confirm what I've said above, I think I can consider this a solved and explained issue (if not, LOL, I guess more to do! ), and I hope the attached doc helps another hard drive / SpinRite traveller.

brado2049 said:

SpinRite's drivers implement large LBA and GPT only with direct-connected SATA drives. Following, there isn't really anything magic about a ZimaBoard or any other hardware, and there should be no struggle for config -- direct-connect SATA to motherboard, done-and-done.

Click to expand...

When SpinRite 6.1 can use it's built-in native drivers with an internal drive connected to a motherboard controller:
BIOS -> Boot FreeDOS
FreeDOS -> Provide a DOS environment for SpinRite 6.1 to reside and run in
SpinRite 6.1 -> Native Driver -> Controller -> Drive
Neither the BIOS or FreeDOS are involved here with SpinRite 6.1's operation hence NO BIOS/DOS limitations apply
SpinRite 6.1 will run at the max speed the controller-drive combo is capable of, with NO limitations re drive capacity or drive formatting.

When SpinRite 6.1 cannot use it's built-in native drivers with an internal (e.g. NVMe) or external drive:
BIOS -> Boot FreeDOS
FreeDOS -> Provide a DOS environment for SpinRite 6.1 to reside and run in
Drives will now all be "BIOS" drives
SpinRite 6.1 -> BIOS -> Drive
Now all BIOS/DOS limitations will apply, seriously handicapping SpinRite 6.1 and severely limiting what SpinRite 6.1 can do.

Yup, thanks @DanR. After going through this process and research, I now understand enough of what’s under the hood to understand the why of yours and others explanations.

It might have been the subtext of a lot of comments, and understood by a lot of the posters, but perhaps an improvement could be made to the doc and GRC SpinRite support to be a little more definitive on what works / doesn’t for SpinRite users, and make it part of the lead, rather than something they have to search for. Specifically what not to do / what’s not worth the time — that could be a major timesaver. It is fine that folks are experimenting with hardware and various configurations and VM’s and the like — that’s interesting info and helpful for some that want to go that route. But the most expensive variable in the equation by far is time, and then secondly, probably the hard drives / data you need to rescue.

GRC tech support couldn’t give me a hardware configuration known to have worked (I asked, told them I’d go buy it immediately if they could give me a config which was known to work), and pointed me toward the forums. That’s fine, as there’s great info and a great community here on these forums (and again, I thank all of you for your guidance), but I think the info could be put on the front page as a starting point for those that want to get up and running. If weeks of testing and research can be saved with a purchase costing a few hundred bucks, that’s not even a decision. Unless I have an intellectual curiosity to go under the hood (which is fine), I make that purchase day 1 (and I did — unfortunately I was buying the wrong hardware to solve the wrong problem).

Maybe I can help contribute something here. I just ordered a ZimaBoard2 with the intent of making it a dedicated SpinRite rig. If a success, I’ll summarize the experience and post it here. Maybe that can serve as a possible known go-to SpinRite hardware configuration for anyone that wants a dedicated rig and would like to bypass searching / testing hardware.

Thanks again for the help here. We’ll see what happens with the ZimaBoard2.

brado2049 said:

ZimaBoard2

Click to expand...

I am concerned that the BIOS may be so new on the ZimaBoard2 that it won't allow legacy booting. They don't seem to have info either way in the documentation I searched. (I did make a request to their technical support, but it's all automated and they never got back.)

You could also spin up VirtualBox under Windows and run SR in a virtual machine. The VirtualBox BIOS can definitely address drives larger than 2.2 TB.

If you are not testing your boot drive, no need to create a boot drive, just install VirtualBox on your running Windows install and follow instructions to map your drives.

PHolder said:

I am concerned that the BIOS may be so new on the ZimaBoard2 that it won't allow legacy booting. They don't seem to have info either way in the documentation I searched. (I did make a request to their technical support, but it's all automated and they never got back.)

Click to expand...

Yeah, I have the same concern. I had also fired off a message to their tech support and also posted to their Discord, but crickets on both. I decided to take the plunge anyway and find out. I have other potential uses for the ZimaBoard2 even if SpinRite doesn't pan out. But I should know shortly (within a week if shipping info is accurate), and I'll post back here when I do.

Scott said:

You could also spin up VirtualBox under Windows and run SR in a virtual machine. The VirtualBox BIOS can definitely address drives larger than 2.2 TB.

If you are not testing your boot drive, no need to create a boot drive, just install VirtualBox on your running Windows install and follow instructions to map your drives.

https://forums.grc.com/threads/how-to-run-spinrite-on-a-uefi-only-machine-part-1-of-5.1613/

Click to expand...

Thanks for that link, Scott. Depending on what happens with the ZimaBoard2, yours might end up being the only game in town. I may end up doing it on VMware Fusion or Paralllels b/c I prefer to work on macOS (b/c of other development support needs), but I'll eventually get there.

brado2049 said:

Thanks for that link, Scott. Depending on what happens with the ZimaBoard2, yours might end up being the only game in town. I may end up doing it on VMware Fusion or Paralllels b/c I prefer to work on macOS (b/c of other development support needs), but I'll eventually get there.

Click to expand...

You can run VirtualBox on an Intel Mac, instructions in the same link. Or you can run SpinRite in QEMU on either an Intel or Apple Silicon Mac:

Well, what do you know, I just got a reply from the Zima Store folks. Here’s the answer: ZimbaBoard2 does not support legacy booting, it only supports UEFI booting. So ZimaBoard2 … no go. .

brado2049 said:

Well, what do you know, I just got a reply from the Zima Store folks. Here’s the answer: ZimbaBoard2 does not support legacy booting, it only supports UEFI booting. So ZimaBoard2 … no go. .

Click to expand...

Thanks for that. I *WAS* looking at one as well.

@Tazz — I know, bummer. I’ve gone through this hardware testing drill before, but now that I really understand the problem for the first time, I’ve got more motivation to solve it. I have a decent guess based on the SN podcast and what I’ve read on these forums that a known working hardware configuration that could be bought right off the shelf might be welcome. No promises, but over the next weeks I’m going to see if I can’t come up with a hardware configuration which can be easily purchased for a dedicated SpinRite rig.

brado2049 said:

No promises, but over the next weeks I’m going to see if I can’t come up with a hardware configuration which can be easily purchased for a dedicated SpinRite rig.

Click to expand...

You will almost certainly find that any "new" machines currently available will not do legacy boot. Your best bet is to look for a second hand machine that is a few years old. If it is not urgent, there may be a lot of them after 24 October ( end of W10 support) that still do BIOS booting.

Here’s something interesting I just ran across — has anyone heard of or tried CSMWrap, which allows CSM booting capabilities on UEFI-only systems? If this as advertised, then perhaps something like ZimaBoard2 actually might be an option running CSMWrap to get legacy boot support. https://github.com/FlyGoat/csmwrap

If anyone has any info about this, please post!

brado2049 said:

dedicated SpinRite rig

Click to expand...

The OG ZimaBoard 2G was still listed last time I looked. You don't need more RAM than that for SpinRite, so get one of those if you still can. Steve mentioned getting a beefier power supply also, this should link you to that post: https://forums.grc.com/threads/zimaboard-and-ide-drives.1414/#post-10610

brado2049 said:

has anyone heard of or tried CSMWrap

Click to expand...

millQ was able to get it working:

PHolder said:

The OG ZimaBoard 2G was still listed last time I looked. You don't need more RAM than that for SpinRite, so get one of those if you still can. Steve mentioned getting a beefier power supply also, this should link you to that post: https://forums.grc.com/threads/zimaboard-and-ide-drives.1414/#post-10610

Click to expand...

@PHolder Yeah, just grabbed a ZimaBoard off of Amazon, so in a week I’ll give that a try. Thanks!

ColbyBouma said:

https://forums.grc.com/threads/using-csmwrap-to-get-bios-on-uefi-only-systems.2129/

millQ was able to get it working:

https://grc.com/groups/spinrite.dev:56492

Click to expand...

Thanks @ColbyBouma ! I contacted the Zima folks tonight because they were very courteous in their support reply to my last question and explanation of the SpinRite use case (they were very interested to learn about that apparently). I asked if their engineers might test CSMWrap on the ZimaBoard2 and let me know if it is compatible, and if so, I’d buy it again (I returned the other) and test SpinRite on it. I’ll post here when I get an answer from them.

FWIW, the original ZimaBlade does work well for a dedicated SpinRite solution. I have 2 of their NAS packages. SpinRiting a NVMe drive in the PCIe slot does work, but where it's through the BIOS it's slow.

Since it only has one USB port you do need to get either a PCIe to USB adapter or some kind of USB-C multiport adapter that supports pass-through charging. Also, if you go the multiport adapter route you'll need to get a USB-C charger because of the non-standard USB-C power adapter that comes with the ZimaBlade.

So ... what does SpinRite 6.1 say about ANY OTHER SATA drive in
ANY OTHER computer for you?

Especially with these command-line options:


Reminder: you are using a boot FreeDOS USB made by SpinRite 6.1,
yes?

Could you kindly list specifics so we all can know of apparent exceptions?

Computers ... make, model, BIOS, date ...
Drives ... make, model, firmware, date ...

• Lenovo ThinkPad laptop, Model 20QQ56CN00.
  Product page / manual - https://pcsupport.lenovo.com/us/en/...-20qn-20qq/20qq/20qqs6cn00/document-userguide
  
• BIOS version/date: LENOVO N2NET61W (1.46 ), 7/23/2024
  
• USB dock: StarTech.com Standalone Hard Drive Duplicator, External Dual Bay HDD/SSD Cloner/Copier, USB to SATA III Docking Station - https://www.amazon.com/dp/B019Y4JE22?ref_=ppx_hzsearch_conn_dt_b_fed_asin_title_1&th=1
  
• Hard drive: Toshiba MDO4ACA400 4TB

A 2024 computer is not expected to have an old-fashioned CMOS BIOS for booting and presenting devices to any DOS.

USB devices are not expected to provide full speed nor full size reporting through an CMOS BIOS to any DOS.

You need another computer where you can install the drive to be tested as an internal SATA drive.

On ANY other computer, what does free ReadSpeed say about the drives in the computers?

https://www.grc.com/readspeed.htm

Reminder:

peterblaise wrote Jul 1, 2025​

So ... ?!?

peterblaise said:

You need another computer where you can install the drive to be tested as an internal SATA drive.

Click to expand...

Thanks for the comments.

Agreed. This was the net of the research / comments of mine earlier in this conversation. I had been barking up the wrong tree (both now and a while ago), in thinking that the issue was my hardware. In my case, it wasn’t. My hardware adequately supported large hard drive capacity, if the software did. SpinRite didn’t in my config (and I’m referring to my latest testing over USB, not testing done in the past). I was under the impression testing over USB was possible. For the most part, it is not — you must have internal SATA connection. My lesson learned.

To that point, an update: I’ve been talking with the Zima Store folks about CSMWrap, and they were interested in that — they’ve got a sale that just started, so I decided to give this a greater college try: I ordered a ZimaBoard and a Zimaboard2 (the Z2 won’t ship until August). Once those arrive, I’m going to try to get SpinRite working on both, the ZimaBoard out of the box, and ZimaBoard2 with CSMWrap.

I have also spec’d out a mini-ITX config if I have to go that route, as I’ve been wanting an open-bench config in general for miscellaneous hardware testing. But I’m going to hold off on that until after the ZimaBoard tests.

DanR said:

The rare exception would be a system with a more modern BIOS that can address space beyond the 2.2 TB limit.

Click to expand...

Well, the BIOS Enhanced Disk Drive Services (EDD) spec was released back in 1995. It allows up to 64-bits of disk addressing, far more than SCSI or ATA. I doubt there's any BIOS around today that doesn't support it, and SpinRite will use EDD when it detects the BIOS supports it. The 2.2TB limit is almost certainly not because of BIOS limitations these days, or even in the last 20 years.

@jlee, as far as I understand, the BIOS limit relevant in this thread limits USB access.

Not IDE ATA SATA.

- - - - -

Some really old-by-now BIOS, especially PATA-generation, never expected to 'see' any drive larger than 28-bit LBA topping out at 137.4 GB, though later PATA climbed to 750GB via 48-bit LBA before SATA overcame PATA, yet some folks bridged 1 TB SATA to PATA in some systems.

Not USB.

New BIOS - actually BIOS with ISA sockets - 'today' is mostly to replace legacy systems targeted for industrial installations still running Windows XP or earlier with dedicated custom programming that can't be migrated to more-modern equipment, but the facility is in need of new systems to replace ageing systems that have become unreliable or impossible to maintain, see:
https://www.google.com/search?q=Who+sells+new+legacy+BIOS+computers+with+ISA+sockets?

'Today', systems generally have moved on to UEFI, and not BIOS, and the few new systems with a Compatibility Support Module (CSM) have, in my experience, been crappy at BIOS, FreeDOS, and SpinRite 6.1.

Hence this thread.

I believe the challenge in this thread is for folks to find any semi-vintage computer that uses BIOS with 48-bit to 64-bit LBA and has SATA sockets and or permits adapters to attach a drive under test directly as SATA.

So, yes, BIOS Enhanced Disk Drive Services (EDD) facilitated access to 64-bit Logical Block Addressing (LBA), but computer vendors in that generation never expected USB thumb drives to do anything other than transfer small amounts of data between computers via 'sneaker net', so they never paid for any research and support to make USB boot and access fully functional or standard through the BIOS and DOS.

It was a long time before external USB HDDs became a 'thing', and they were for backup, not booting.

It even took a while for USB to boot with anything more than a small drive and a single-purpose utility on board, vendors having become accustomed to diskette and CD reproduction houses for full operating system distribution, where a gazillion copies of boot USB drives with full Windows was unimaginable.

So, yes, they built USB as a boot method, but I have one BIOS that is so stupid that it marks ALL USB drives that are present at boot as the size of the largest USB drive under 137GB, so if I leave a 16GB and 256GB USB drive inserted, they both get turned over to FreeDOS and SpinRite 6.1 as 16GB drives.

I have other computers where the BIOS only sees one USB drive, so I can boot to SpinRite, but it is not shown any other USB drive in the computer.

USB sux.

So the challenge is to test used computers to find one that can behave for the user's goals, and testing USB drives via SpinRite 6.1 is a significant challenge, partly due to the dominance of UEFI that does not turn drives over to SpinRite 6.1, and partly due to legacy BIOS being so variable - no vendors depended on USB drives doing anything predictable under DOS, instead, letting Windows bring it's own drivers, so BIOS never got sophisticated, USB wise.

- - - - -

That being said, I suggest plugging the USB drive in question into ANY Windows computer and running free ValiDrive on it, see:
https://www.grc.com/validrive.htm

ValiDrive is like a mini-SpinRite 6.1 Level 5 under Windows, and I run ValiDrive on ALL USB drives, including 20TB drives in USB adapters.

Of course I do!

So, @brado2049, the original poster wrote:


Yes, CSM and BIOS and USB sux.

But Windows 'sees' the drives just fine via USB . . . so run ValiDrive on them, and get back to us with the results - charts please!

Thanks.

jlee said:

Well, the BIOS Enhanced Disk Drive Services (EDD) spec was released back in 1995. It allows up to 64-bits of disk addressing, far more than SCSI or ATA. I doubt there's any BIOS around today that doesn't support it, and SpinRite will use EDD when it detects the BIOS supports it. The 2.2TB limit is almost certainly not because of BIOS limitations these days, or even in the last 20 years.

Click to expand...

It is apparently a legacy spec that is no longer commonly used.


To quote Google's AI:

No, BIOS Enhanced Disk Drive (EDD) services are not commonly used in modern computer systems
,
EDD is a legacy specification that provided a way for the BIOS to interact with disk drives and make information available to operating systems, particularly older ones like MS-DOS.

Why EDD is less common now

• Modern Interfaces: The rise of newer interfaces like SATA and NVMe has shifted the focus away from older standards like the conventional INT 13h interface that EDD built upon.
• UEFI: The transition to Unified Extensible Firmware Interface (UEFI) in modern computers has also reduced the reliance on traditional BIOS standards like BIOS Boot Specification (BBS), which is related to how the BIOS handles the boot process.
• Operating System Advances: Modern operating systems have their own robust methods for accessing and managing storage devices, often bypassing the need for BIOS-level services like EDD once the OS has booted.

While EDD might still be present or enabled in some systems for backward compatibility, its role in the day-to-day operation of modern computers is significantly diminished.

I am not qualified to either agree or disagree.

Really, @brado2049, run free ValiDrive under
Windows on the drive attached as USB in an
adapter, and show us the results.


ValiDrive is like a mini-SpinRite Level 5,
checking 576 regions across a drive.

Thanks.

Wow, we really have entered the next
generation.

Good word, 'generation', because at first it was
AI-enhanced, merely quoting web sites that
responded to the search terms, but it was not
generative AI, that is, Google did not appear
to be inventing responses without web
sources.

Now, in only a few years since Google started
AI-enhanced features, I'm starting to see what
appears to be generated contents, as if
conversation, correcting my inquiry, and
redirecting me to rephrase.

I think we are going t have to be scrutinizing
of making decisions based only on Google's
AI-enhanced search summaries.

I hate to include Google's list of links, but it
may become a requirement in support of
whatever we think we are sharing, as if it's
authoritative.

Google AI-enhanced search results are like a
mini-Wikipedia [ Article ] on demand
WITHOUT the [ Talk ] page behind showing
our work and contrarian points of view, and
without human intervention.

And we really have to highlight our own
hands-on experience.

So, what's it gonna take to nail down what is
going on in the challenge:


?

Thanks for the additional conversation @DanR and @peterblaise — looks like there’s some additional possibilities of things to try — greatly appreciated!

I wanted to give a status on what I’ve been up to. This may be no new information for many, but I imagine there are some who might be helped (it helped me), but for everyone I wanted to confirm that this was an affordable and quick route to a working SpinRite hardware rig.

I bought both a ZimaBoard 232 and a ZimaBoard 2. The latter is not shipping until August, and I confirmed does not support CSM / Legacy boot. However, I’m going to test some other possibilities on it once received (e.g. CSMWrap). However, I received the ZimaBoard 232 a few days ago, and today opened the box and gave it a try.

I can happily report, right out of the box, no BIOS configuration changes or anything related required, was able boot to my USB drive (created as prescribed in the SpinRite doc) and run SpinRite. Further, it did indeed recognize the full 4TB capacity of the SATA hard drive I had used for prior tests in this forum thread (the full capacity of which had not been recognized by SpinRite over USB).

This is probably worthy of a blog post in the near future, but for now, I am including a few screenshots, and this summary note: if you are looking for quick path to a dedicated SpinRite rig for SATA drives (other options if you leverage the PCIe expansion), for the total of ~$105 (which included the ZimaBoard 232, Mini-DisplayPort to HDMI adapter, and SATA Y-cable), you’re in with this config. SpinRite estimated 7.26 hours for a Level 3 on my 4TB drive.

I hope this helps someone. I’ll post again if / when I get a blog post written and have some interesting testing info on ZimaBoard 2 once received.

I'm imaging the "Yeehaw!" shout when the
4TB measurement appeard on SpinRite's
screen!

;-)

Thanks for sharing - the resolution is so important.

@peterblaise -- your imagination would have indeed been accurate. I was thrilled when I saw the full capacities of a few different drives come up. In finally getting to run a long-running SpinRite operation, I inadvertently discovered something I had forgotten (much to both my humor and annoyance), that older OSs weren't plug-and-play. In the screenshots I shared in a previous post, I had this rig attached to a monitor with four inputs, and after about 4 hours of running a Level 3, with a LOOOOOONG way to go, I switched the monitor input to another computer to do some work. Oops...no way to get the display back, switching back and even disconnecting / reconnecting the display didn't work. I was completely blind to progress. LOL...well dedicated monitor employed now....

brado2049 said:

@peterblaise -- your imagination would have indeed been accurate. I was thrilled when I saw the full capacities of a few different drives come up. In finally getting to run a long-running SpinRite operation, I inadvertently discovered something I had forgotten (much to both my humor and annoyance), that older OSs weren't plug-and-play. In the screenshots I shared in a previous post, I had this rig attached to a monitor with four inputs, and after about 4 hours of running a Level 3, with a LOOOOOONG way to go, I switched the monitor input to another computer to do some work. Oops...no way to get the display back, switching back and even disconnecting / reconnecting the display didn't work. I was completely blind to progress. LOL...well dedicated monitor employed now....

Click to expand...

Have a look here: https://forums.grc.com/threads/turn...ank-when-i-turn-it-back-on-next-morning.1418/

Specifically the second page. It sounds like the same thing you're experiencing.

@Tazz — thanks for that — yep, appears that was pretty much it. I connected my ZimaBoard to a dedicated monitor (no change of input) and ran SpinRite again, and now powering the monitor off / on has worked fine so far.

DanR said:

It is apparently a legacy spec that is no longer commonly used.

To quote Google's AI:

No, BIOS Enhanced Disk Drive (EDD) services are not commonly used in modern computer systems
,
EDD is a legacy specification that provided a way for the BIOS to interact with disk drives and make information available to operating systems, particularly older ones like MS-DOS.

Click to expand...

All that is saying is that the legacy BIOS is no longer used to access disk drives, which we know to be true. But EDD is still supported by all BIOS CSMs today that I know about.

SpinRite definitely uses EDD if it's present, take a look at

https://grc.com/groups/spinrite.dev:53707
https://grc.com/groups/spinrite.dev:36848

peterblaise said:

@jlee, as far as I understand, the BIOS limit relevant in this thread limits USB access.

Not IDE ATA SATA.

- - - - -

Some really old-by-now BIOS, especially PATA-generation, never expected to 'see' any drive larger than 28-bit LBA topping out at 137.4 GB, though later PATA climbed to 750GB via 48-bit LBA before SATA overcame PATA, yet some folks bridged 1 TB SATA to PATA in some systems.

Not USB.

Click to expand...

To get to a USB drive via the BIOS you have to use the BIOS interface. It used to be that the BIOS interface was limited to 8GB. Thus even if you had a SCSI or some other drive that allowed you to address LBAs past 8GB, 8GB was all that you could do through the BIOS. A big reason for EDD was to get past that. Every BIOS today supports EDD, so the BIOS interface limit is not a factor in accessing USB drives.

That's the front end of the BIOS, the BIOS interface. You also have to worry about the backend which here is the actual USB drive. The BIOS takes commands from the BIOS interface and has to issue the appropriate commands across the backend interface, which on an external USB drive is the USB interface.

USB drives themselves use different protocols across the USB cable to access the drive. The oldest is SAT, which uses SCSI commands. There are different SCSI read and write commands which allow larger LBA ranges and transfer sizes. The smallest SAT allows are the SCSI READ (10) and WRITE (10) commands, which can address 32 bits or up to 2.2TB. But I'd be surprised if any BIOS today implementing SAT to access USB drives only supported READ (10) and WRITE (10) commands. And no USB drive of greater than 2.2TB is going to limit its support to only READ (10) and WRITE (10) SCSI commands.

There are also more modern USB protocols for accessing external drives and AFAIK they all support more than 2.2TB.

All of which is to say that modern BIOSes should allow you to access any external USB drive greater than 2.2TB.

At some point they all became legacy ad hoc, subcontracted, least
common denominator, so there are no 'modern', nor 'standards'.

They've moved on to UEFI, which is proving equally random,
unpredictable, and frustrating, but usually talk to NVMe ( though
SpinRite does not ).

So long as the computer booted for the vendor, they were done, fini,
moved on, no additional BIOS features promised or supported.

As mentioned, an HP tech asked my why I wanted to boot from USB.


In other words, they did not consider it a feature worth supporting, so
if it fails, they do not care, and have no remedy.

Hence the hunt for used gear that actually does what we want, and
no 'specifications' help, only hands-on testing, and that's only good
for the current test, the next test may prove the gear is inappropriate,
hence having multiple old BIOS-computers at hand.

- - - - -

Our own @Paul F wrote programs to test USB and replace limited
BIOS access with less-limited SCSI access, hoping to get past BIOS
quirks, and then SpinRite had access to the entire drives, if slowly.

Amazing, but ultimately easier and more reliable to use another
computer and or another attachment method.

So, got a stack of used computers to keep on hand, "just in case"?

;-)

But [ for us poorly supported end users who are hunting down old
BIOS systems, before acquisition, for us, there is ] no way to tell if EDD
is present or fully supported and functional.

So, "... buy it and try it ..." is the slogan of the day.

Got a stack of used computers to keep on hand, "just in case"?

;-)

- - - - -

* From the web: In the context of BIOS drive access, EDD stands for BIOS Enhanced Disk Drive Services.
Here's a breakdown of what that means:

• Enhanced Disk Drive Services (EDD): EDD is an extension to the legacy BIOS INT 13h interface, which traditionally used Cylinder-Head-Sector (CHS) addressing for disk access. EDD was developed to address limitations of the old system, particularly in handling larger drives and newer interfaces.
• Purpose of EDD: EDD enables the BIOS to communicate more effectively with the operating system (OS) about connected disk drives. This includes providing details such as:
  • Bus Location: Whether the drive is connected via PCI, SATA, USB, etc.
  • Interface Details: Information about the interface (e.g., ATAPI, SCSI).
  • Drive Parameters: Capabilities and geometry of the drive.
• Key Improvements with EDD:
  • Larger Drive Support: EDD helps the BIOS support hard drives larger than the 528 MB limit of the conventional INT 13h interface.
  • Logical Block Addressing (LBA): EDD replaces CHS addressing with LBA, which simplifies data access and supports much larger storage capacities. According to Lenovo, "LBA works by assigning a logical block address to each block of data on a storage device... allowing the system to easily locate and retrieve data without the complexity of traditional addressing methods like cylinder-head-sector (CHS)".
  • Information for the OS: The information gathered by EDD is exported to the OS, allowing it to make more informed decisions about how to interact with the drives. This can include information needed for boot processes or for handling different SATA modes (IDE emulation vs. native SATA).

In essence, EDD acts as a bridge between the BIOS and the OS, allowing them to better understand and utilize modern disk drives with their increased capacities and diverse interfaces.

Hi A laptop setup that works with Spinrite 6.1 on a 14 Tb desktop drive.

ThinkPad T400 laptop released in 2008 with an Ultrabay Slim swappable hard drive /DVD drive slot that connects directly to the motherboard. I was able to use the Ultrabay Slim slot cradle to connect a 2.5 inch SATA drive or a 3.5 inch SATA drive using a SATA 22Pin Male to Female Data Power Extension Cable 50cm
plus a 12v molex connector off an external drive hub.
https://www.amazon.co.uk/Docking-Tccmebius-TCC-S868-UK-External-Enclosure-Red-Black/dp/B07MVFPJ5K
The laptops boot screen was unable to detect the 14Tb drive when connected via usb using the usb hub but when connected via the Ultrabay slot it detected it as 14 Tb.
The laptop could also detect smaller 1 TB 2.5 and 3.5 SATA drives via usb using the usb hub but the Smart data was unavailable and the time to complete was very much longer.
I am very happy even if it takes 39 hours to do a level 3 on this 14Tb drive.

peterblaise said:

Re: "... SpinRite definitely uses EDD * if it's present ..."​

But no way to tell if EDD is present or fully supported and functional.

Click to expand...

Incorrect. EDD defines a function "Check Extensions Present" which can be used to determine if EDD is supported. You load the following registers with

AH 41h
BX 55AAh
DL BIOS device number

and then execute int 13h. If the EDD extensions aren't present, it causes an error (i.e., the carry bit is set with AH set to 1) since it's an illegal request under the old int 13h definitions. If EDD is supported (i.e., the carry bit is clear) you get a bit map in CX that tells you more about which parts of EDD are supported. Thus before doing anything SpinRite can use this test to determine whether or not to use EDD.

Cool that the EDD specification implementation promises predictable
accessibility and enumeration.

I updated my prior post-15793 to say:


Has anyone seen EDD play out in the environment in question?

From https://www.grc.com/groups/spinrite.dev:36848


I dunno - anything informative there?

Thanks.

And from https://www.grc.com/groups/spinrite.dev:53707