Also tried experimenting to see if I could just have one or two partitions with either 120GB or two 80GB on them. Now it won't even let me do that. Both FDISK 1.4 and Ontrack just seem to lock up. It doesn't even reach 1%.

DustyShinigami wrote on 2026-03-23, 11:55:

Also tried experimenting to see if I could just have one or two partitions with either 120GB or two 80GB on them. Now it won't even let me do that. Both FDISK 1.4 and Ontrack just seem to lock up. It doesn't even reach 1%.

Might be time to check your system for old viruses using F-prot.

douglar wrote on 2026-03-23, 14:10:

DustyShinigami wrote on 2026-03-23, 11:55:

Also tried experimenting to see if I could just have one or two partitions with either 120GB or two 80GB on them. Now it won't even let me do that. Both FDISK 1.4 and Ontrack just seem to lock up. It doesn't even reach 1%.

Might be time to check your system for old viruses using F-prot.

I can't imagine there are any viruses. My system isn't connected to the internet. And anything I've added via my main PC - software, drivers, patches - would surely have been picked up on if there was anything dodgy. Plus, going back to a previous image of the C drive, where barely anything has been installed, would make it unlikely.

I did try just removing the IDE controller, going back to my previous image again before anything to do with it was installed, connected the HDD back to my HP366 controller, used the standard FDISK, and created a new partition with 127GB. This time, it worked! It reformatted, there are no BSOD when trying to run ScanDisk, and it copied a file to it over 1GB. ScanDisk still won't run for that drive though, but only because it complains I don't have enough memory. Maybe the Windows ME version will solve that...?

Ontrack can't detect the full capacity of the drive now, so I imagine the LBA-48 patch works and helps Ontrack to recognise the full amount, but the system still doesn't like it. So what I'll try and do now is re-add the patch and try making 2-3 partitions and see if it's fine.

DustyShinigami wrote on 2026-03-23, 14:27:

I can't imagine there are any viruses. My system isn't connected to the internet.

DOS is older than the internet. DOS viruses spread by floppy and can sit on the hard drive master boot record so reimaging a partition doesn't always remove it.

douglar wrote on 2026-03-23, 14:38:

DustyShinigami wrote on 2026-03-23, 14:27:

I can't imagine there are any viruses. My system isn't connected to the internet.

DOS is older than the internet. DOS viruses spread by floppy and can sit on the hard drive master boot record so reimaging a partition doesn't always remove it.

Oh, I see. Hmm. Interesting. Is there a tool to check?

Right, so it looks like the patch on its own and Ontrack isn't enough; it still can't see the full capacity. So it definitely needs to be connected to the RAID controller. So it looks like 127GB is the limit for me.

DustyShinigami wrote on 2026-03-23, 15:08:

Right, so it looks like the patch on its own and Ontrack isn't enough; it still can't see the full capacity. So it definitely needs to be connected to the RAID controller. So it looks like 127GB is the limit for me.

this doesn't seem to be a Boot/MBR virus issue but if you want to run a scan,you can use my tool to check your HDDs and floppies as well for old dos viruses..

p.s.: run it under DOS after booting from it not under Windows

Masaw wrote on 2026-03-23, 15:16:

DustyShinigami wrote on 2026-03-23, 15:08:

Right, so it looks like the patch on its own and Ontrack isn't enough; it still can't see the full capacity. So it definitely needs to be connected to the RAID controller. So it looks like 127GB is the limit for me.

this doesn't seem to be a Boot/MBR virus issue but if you want to run a scan,you can use my tool to check your HDDs and floppies as well for old dos viruses..

p.s.: run it under DOS after booting from it not under Windows

Awesome. Thank you for this. I'll give it a run now. 😁

Yep. Like I suspected - totally clean. C, D and E. 😀

Okay, this is an interesting turn of events. I honestly have no idea what I've done differently. I mean, I had the HDD set up so it was 127GB. It was connected to the HP366 controller. I think I installed the LBA-48 patch either before or after that. Then I installed the IDE controller, installed the default drivers on the CD, connected the HDD back to it, loaded up Ontrack 10, which recognised the full capacity, just made one partition again instead of multiple, rebooted, and it recognises the drive again, only this time there are no weird issues with ScanDisk. Apart from it complaining that I need more memory. But so far there's been no BSOD. And it's currently copying a 1GB file to it. No lock-ups.

Of course, it could all implode on itself at some point, but so far, this is promising. 😀

Backed them up first, but I've replaced the ScanDisk and Defrag with the ones from Windows ME and they're working fine. And it works fine with the E drive. 😀

One strange thing I have noticed, after I'd connected the HDD to my main PC and transferred all the CD images back to it, and then re-connected it back to my RAID controller, when it tries to verify the patch during boot, it says it's unable to verify or somesuch. I'm not sure if connecting a HDD from one PC to another leaves some kind of footprint...? I mean, it's still FAT32; that hasn't changed. Luckily, I've not encountered any issues still. Fingers crossed.

DustyShinigami wrote on 2026-03-23, 19:11:

I'm not sure if connecting a HDD from one PC to another leaves some kind of footprint...?

When a hard drive becomes visible to a PC, there is a "geometry" assigned by the BIOS. When the drive is partitioned & formatted, all the access is done according to the rules of that geometry. If a drive changes geometry, the old partitions and format will no longer look right to the computer.

Drives build after 1993 usually speak LBA and work best with LBA type geometries, and can be moved between systems that support LBA without much issue. LBA = Linear block addressing. Blocks are addressed 0..N and it's pretty simple. Drives formatted under LBA28 can be taken to LBA48 systems without issue because it's a linear geometry. There are just more storage blocks. (There is also an LBA 22, but that's only on certain drives from 1992/1993 and you don't ever want to mess with that.) Computer BIOS released after June 1994 usually support LBA geometry. Operating systems >= Win95b understand LBA28.

Then there's CHS, (Cylinders, Heads, Sectors) This is sort of like a 3d address space. In MFM or RLL drives, it corresponded to physical components of the drive and you needed to be well aware of what geometry to use or things would not work. IDE drives use a "soft" geometry. They try emulate any geometry you give them in the BIOS as long as it isn't larger than the actual drive size. This means any shmuck can go in and configure random stuff and it would sort of work. For a while at least. Until you lose your CMS setup or upgrade your motherboard.

Drives < 512MB used CHS ( cylinders <= 1024, heads < 16, sectors per track < 64)
Drives < 8.4 used ECHS (Enhanced CHS, cylinders > 1024)
Drives < 32GB sometimes used Large CHS for Unix and Novell and for people that just liked to chose random options when setting up their BIOS.

With CHS type geometries, you have to make sure that the drive gets the same geometry configuration when you move it. If the CHS you select settings are not the same as the settings used when the drive was formatted, your computer will mostly see a strange kaleidoscope version of your data and there's usually going to be really severe problems with the file system past the first few hundred KB. Likewise, if you take an LBA formatted drive and switch it to a CHS geometry, you will get similar problems.

Interesting note-- IDE Controllers newer than 2008 rarely know how to speak CHS any more. If you every try to connect an old drive that only knows CHS to a controller that tries to use LBA, there's going to be a lot of clanging as the drive tries to put the heads in places that they were not meant to go. Drive is usually fine afterwards, but you will be a little startled.

douglar wrote on Today, 15:57:

When a hard drive becomes visible to a PC, there is a "geometry" assigned by the BIOS. When the drive is partitioned & formatte […]
Show full quote

DustyShinigami wrote on 2026-03-23, 19:11:

I'm not sure if connecting a HDD from one PC to another leaves some kind of footprint...?

When a hard drive becomes visible to a PC, there is a "geometry" assigned by the BIOS. When the drive is partitioned & formatted, all the access is done according to the rules of that geometry. If a drive changes geometry, the old partitions and format will no longer look right to the computer.

Drives build after 1993 usually speak LBA and work best with LBA type geometries, and can be moved between systems that support LBA without much issue. LBA = Linear block addressing. Blocks are addressed 0..N and it's pretty simple. Drives formatted under LBA28 can be taken to LBA48 systems without issue because it's a linear geometry. There are just more storage blocks. (There is also an LBA 22, but that's only on certain drives from 1992/1993 and you don't ever want to mess with that.) Computer BIOS released after June 1994 usually support LBA geometry. Operating systems >= Win95b understand LBA28.

Then there's CHS, (Cylinders, Heads, Sectors) This is sort of like a 3d address space. In MFM or RLL drives, it corresponded to physical components of the drive and you needed to be well aware of what geometry to use or things would not work. IDE drives use a "soft" geometry. They try emulate any geometry you give them in the BIOS as long as it isn't larger than the actual drive size. This means any shmuck can go in and configure random stuff and it would sort of work. For a while at least. Until you lose your CMS setup or upgrade your motherboard.

Drives < 512MB used CHS ( cylinders <= 1024, heads < 16, sectors per track < 64)
Drives < 8.4 used ECHS (Enhanced CHS, cylinders > 1024)
Drives < 32GB sometimes used Large CHS for Unix and Novell and for people that just liked to chose random options when setting up their BIOS.

With CHS type geometries, you have to make sure that the drive gets the same geometry configuration when you move it. If the CHS you select settings are not the same as the settings used when the drive was formatted, your computer will mostly see a strange kaleidoscope version of your data and there's usually going to be really severe problems with the file system past the first few hundred KB. Likewise, if you take an LBA formatted drive and switch it to a CHS geometry, you will get similar problems.

Interesting note-- IDE Controllers newer than 2008 rarely know how to speak CHS any more. If you every try to connect an old drive that only knows CHS to a controller that tries to use LBA, there's going to be a lot of clanging as the drive tries to put the heads in places that they were not meant to go. Drive is usually fine afterwards, but you will be a little startled.

I see. Fascinating stuff. And thanks for explaining it in an easy way to digest. Do modern PCs still use LBA or is it something else now? Which is also linked to my next question - will the geometry, from when it was connected to my main PC to my retro PC, have changed drastically that problems could crop up later? So far, I've had zero issues, though that patch will no longer verify. I suspect if I uninstall it (not sure if I did) it won't re-install it now.

Also, thank you everyone for your help. 😀

They do. Sata drives and nvme drives both use lba48.

Changes in effective geometry through different translations are very nasty things.

Wherever possible, the use of linear addressed sectors (lba) is vastly superior.

CHS geometry is an anachronism from when drives had stepper motor actuators, and each value had a real representation for where the head array was over the platters.

To help conceptualize things:

These three expressions give the same number of sectors:

16 cyls, 4 heads, 16sec/t (16 * 4 * 16 = 1024 sectors)
4 cyls, 16 heads, 16sec/t (4 * 16 * 16 = 1024 sectors)
MAXLBA=1024 (1024 sectors, linearly)

Suppose your partition table is using the CHS flavor, using the first option.

It says the partition starts at cylinder 15, head 0, sector 0.

Now, suppose you put this drive in another machine, that interprets it using the second option. Cylinder 15 is out of bounds, because the max addressible cylinder is 3. A read error happens.

Now, consider the reverse.

The partition is at cylinder 3, head 0, sector 0.

You move it to the other machine, where it initially acts 'fine'. Reads several sectors fine. Until it tries to read head 5, which is out of bounds. Read error occurs.

With LBA, 'sector 500' is what is asked for. (For example) 'Partition starts at sector 500' is what an LBA style partition table says. OS asks for sector 500, and returns sector 500.

This is the same regardless which computer it's put in.

The different 'kinds' of LBA define the number of bits that are allowed to store the value for number of sectors. 24bit LBA tops out at 16,777,215 sectors. 48bit LBA tops out at 281,474,976,710,655 sectors.

We dont have drives that big yet.

wierd_w wrote on Today, 16:35:

They do. Sata drives and nvme drives both use lba48.

Huh. Interesting to know. I would have thought they'd have come up with something even better. Mind you, it looks like LBA48 came out roughly around the same time as PCI-E and even that's still going strong.

wierd_w wrote on Today, 16:35:

They do. Sata drives and nvme drives both use lba48.

Mostly-- Just a couple notes--

• SATA devices attached to a controller in legacy mode do LBA addressing & the same ATA commands and receive those commands through x86 I/O space (0x1F0, 0x170) just like classic IDE drives from 1980's. The controller captures the commands from the emulated ports put them into FIS (Frame Information Structures) for the SATA device. They rarely implement TCQ (Tagged Command Queueing) because TCQ for PATA was pretty much a failure.
• SATA II & III (>= 2004) devices support AHCI Mode (Advanced Host Controller Interface). When in ACHI mode they do LBA48 addressing with a slightly updated ATA command set, but the commands are sent directly through FIS to the SATA device, no more legacy PATA port emulation, reducing latency. These devices often support NCQ (Native Command Queuing) at a depth of up to 32 commands in flight.
• NVME devices do linear addressing because that's the sane way to do things but it's not the same thing as LBA48. It's a 64 address, not 48 bits and there's no more ATA command layer, they use a different set of commands, which is why you don't see cheap NVME - PATA bridges like you do with SATA. NVME devices have two in memory queues, a submission queue (ASQ) & completion queue (ACQ) . Each queue is up to 65,535 commands deep, and provide extremely low latency compared to PATA or SATA and much better support for multi-core processors.

Interesting! I didnt know nvme did 60 bit linear addressing.

The max size drive that tabulates to is mindboggling.