Any ideas of possible differences between sector-by-sector cloned disks?

MightyGorilla

Prominent
Jul 14, 2017
8
0
520
I'm attempting to clone & replace a 2.5" hard disk within a late 90s industrial PC made in Italy which runs MS-DOS for Embedded Systems.
(To my amazement the disk is currently still working far beyond its lifespan...but doesn't sound healthy at all.)

I've had no major issues cloning the disk to several forms of replacement device (both solid state and spinning disk), and DOS will boot from the cloned device- however the system's applications will load and then freeze with no error messages.

I realize this is a vague question, but is anyone aware of real techniques that vendors might have employed to prevent simple replacement of a drive (keeping in mind that this is an MS-DOS relic) such as writing bits of code to unused registers in the hard disk's firmware, or is that most likely just paranoia?

Might something with the original disk's partition table be causing some kind of obscure problem with the clones made, even though the system works with the original disk without issue?

I've cloned the disk with more than one PC and with two different types of software.
If this is a useful hint, I have seen the system progress slightly farther before freezing depending on which BIOS HD geometry I selected (LBA, CHS, or Large).

Thanks-
 
Solution
So I finally managed to solve my problem. The next device I tried was a small 32GB M.2 SATA connected to a AbleConn mSATA-to-IDE converter.
First, I used HDparm in a test system to hide most of the 32GB disk, and make it appear to be the exact same sector count as the original 4.8GB Fujitsu drive. I then imaged it with HDDRawCopy (which is by far the easiest utility to do sector-by-sector copies).

I added it to the ancient 486 system, and hey- the BIOS could actually see the drive, and it was the correct sector count. :)

I won't ever have an exact analysis of why this particular single-board-computer's BIOS had such issues with some of the devices I tried (but it's ancient, so I wouldn't expect them to all work either...) The...

MightyGorilla

Prominent
Jul 14, 2017
8
0
520


I booted it to a dos diskette to verify that all the drive letters are present and accessible, same as the original disk, but of course there's nothing I can do about the serial number short of an overly complicated firmware hack.

I ordered another old, exact model Fujitsu hard disk from Ebay just to see what it will do with that. I suppose if it was the serial number or something else in the firmware, I could carefully swap the disk's board, but that wouldn't accomplish much even if it worked, since I'm really wanting to replace it with a solid state device in the end.

The company does still exist- We've already had a tech flown out once before for problems we couldn't solve, but it's a big expense, and understandably their solution will be a major upgrade to the hardware, and not retro-fitting some unsupported components into their system. So it may come to that, but this didn't look so complicated at the start, lol. :)
 

MightyGorilla

Prominent
Jul 14, 2017
8
0
520
Well I can report back that the exact model 4.8GB disk booted fine after imaging and all applications worked properly, so there doesn't appear to be anything wild going on with the software checking S/Ns or the like, but now I'm still left with the question of why it won't work on any kind of solid state device.

It's at least an improvement that the replacement drive doesn't sound like it's bearings are a week from seizing up, but it's still not a good solution.
 

MightyGorilla

Prominent
Jul 14, 2017
8
0
520
I can happily report that cloning to the exact same model disk worked without issue, and after further tests, cloning to spinning disks (not SSDs) worked with larger (not-quite-so-ancient disks) AFTER using hdparm to reduce the visible sector size of the disk to make it appear the same as the old 4.8GB disk. (A 40GB Samsung disk)

For some reason, not a single solid state device I've been able to find will allow hdparm to make the same alteration.
Transcend 8GB PATA SSD tried and failed
KingSpec 8GB PATA Disk-On-Module tried and failed
Kingston 16GB PATA Compact Flash tried and failed
KingSpec 64GB PATA SSD tried and failed

So I'm still left wondering
1. Why this old system chokes when using a slightly different sized disk (even though the OS boots fine).
2. Why hdparm doesn't seem to work with any solid state devices to enable a Host Protected Area (HPA) when I can easily do it on the same system with spinning disks.

At this point I think I'm cutting my losses and will plan to feed this thing spinning disks as they fail.
 

MightyGorilla

Prominent
Jul 14, 2017
8
0
520
So I finally managed to solve my problem. The next device I tried was a small 32GB M.2 SATA connected to a AbleConn mSATA-to-IDE converter.
First, I used HDparm in a test system to hide most of the 32GB disk, and make it appear to be the exact same sector count as the original 4.8GB Fujitsu drive. I then imaged it with HDDRawCopy (which is by far the easiest utility to do sector-by-sector copies).

I added it to the ancient 486 system, and hey- the BIOS could actually see the drive, and it was the correct sector count. :)

I won't ever have an exact analysis of why this particular single-board-computer's BIOS had such issues with some of the devices I tried (but it's ancient, so I wouldn't expect them to all work either...) The important part is that there are some "retro" solid state devices that will bridge the gap. Others would likely not have as many issues finding a device that works, because most of the ones I tried *did* work with DOS as long as their size wasn't far too large for the old BIOS to accept...

I had the added hindrance of needing a solid state device that would allow hiding most of it's space in an HPA, and many solid state devices don't seem to allow that- possibly the newest SSDs and older spinning disks being the most likely to work. This SiliconPower mSATA paired with an AbleConn IDE converter allowed HDparm to do its job.

Finally, I'll likely never know why the applications had such problems with newer drives, even when DOS & the system BIOS accepted them. A big clue though is that I finally found out that these devices run an old real-time OS after DOS boots (vrtx32/386) made by Ready Systems (which is now owned by a different company). I'm thinking the rtOS is doing direct disk access to specific hard-coded sectors and so imaging must result in an exact sector-by-sector clone. I'm sure the manufacturers would know how to update this stuff and be able to change the disk out without so much fuss, but I'm not them.
 
Solution

Paperdoc

Polypheme
Ambassador
This might be involved, based on the possible age of the system. The original LBA system for accessing HDD's used 28 bit for the LBA address. Given that one Sector is 512 bytes, that comes out to a max size of the HDD of 137 GB in decimal values, or 128 GiB in hexadecimal measurements the way Windows does it. The newer version of LBA raised that to 48 bits for the LBA address, capable of a huge number of Sectors - more than we may ever see on a rotating-disk mechanical drive. That became common just around or after year 2000. All current HDD's etc. support the 48-bit LBA system.

If you are using an older computer with only the original 28-bit LBA support in its BIOS, you can NOT install any HDD over that 128 GiB size. If applications believe the HDD is larger and will allow use of space above that boundary, the OS still will not be able to send an LBA value over the boundary. Thus it is possible for data to attempt to write above the boundary, but actually get written to a very different location, corrupting the old data at that location. So in systems like that, any replacement HDD MUST somehow be limited to behaving as if it only has 128 GiB of space. Seagate used to have a utility for imposing that limit on its HDD units, and I have used it with success. What you did with hdparm sounds like something very similar.

So, my hypothesis is that in using a modern storage device you ended up with a unit that can access space over the 128 GiB limit. Even if you set up its Partition to no more than that and left the additional space Unallocated, there might still be a problem in using such a HDD in an older computer with only this 28-bit LBA Support. Hence I suggest that a current HDD MIGHT be used if you can change its own parameters so that it believes AND reports to any outside inquiry that is real max size is not more than 128 GiB. I don't know how to do that using a SSD, although surely one that really IS less than 128 GiB should do the job.
 

MightyGorilla

Prominent
Jul 14, 2017
8
0
520
Thanks Paperdoc-
I'm sure that you're right that the BIOS in this hardware is incapable of reading above 128GiB, but nothing I've added has been larger than 64, and most have been 16GiB or less. I couldn't even get it to recognize an 8GiB Transcend IDE SSD, that was clearly made for retrofitting. My guess is that most of these devices don't support some antiquated parts of the ATA commandset that it's trying to use and this mSATA converter was designed more with compatibility in mind.

This old stuff can be a pain, but sometimes solving puzzles can be fun. I also had no idea that old systems used a different clock speed for the communication with the keyboard. Just navigating the BIOS menus will cause error beeps every 5-6 keystrokes. In the BIOS of a newer single-board-computer (that I ordered as a possible replacement for this one) there are keyboard clock settings of 6, 8, 10, and 12MHz to work around the fact that the old keyboards were slightly different (so it would seem). Not stuff I have to deal with very often, but good for general trivia. :)
 

Paperdoc

Polypheme
Ambassador
Yeah, I neglected to think about the HDD access mode. A machine that old knows nothing about SATA, and will use only an IDE protocol. Now, what that does when used on a AHCI device I don't know. In current computers that have both types of ports, there is no easy way to access a SATA unit from an IDE port to find out. But I would not be surprised to find that, when the BIOS runs its POST and the initial identification query to the HDD unit is carried out, the response from a SATA drive may contain data the BIOS cannot recognize. Then it would no know how to deal with that storage device.

It is also possible, if that system is even older than I thought, that its BIOS does not know how to use LBA properly, and it requires specification of the even older CHS parameters to use a storage device. Do you recall how its HDD parameters were set up before you started? If that were the case, I don't think there is any way to enter CHS parameters for a modern HDD. That tasks may be left to an adapter, but your adapter seems unable to do that - or, at least, can't for an SSD.

Given what you now know, I suggest your best path forward is not to attempt to use an SSD in the old machine. Use an HDD. It may be VERY hard to find a new one that is not over 128 GiB ("137 Gb"). Moreover, ideally you should get an with an IDE interface so you don't need an adapter. I found these two examples. Both are end-of-life devices represented to be new, but with limited warranty coverage NOT from the original manufacturer.

https://www.newegg.com/Product/Product.aspx?Item=9SIAAEE3XR1053&cm_re=IDE_hard_drive-_-22-144-102-_-Product
That one's a WD unit of 80 GB.

https://www.newegg.com/Product/Product.aspx?Item=9SIA5AD1T69209&cm_re=IDE_hard_drive-_-1Z4-002P-00009-_-Product
That's a 160 GB Seagate product. Too big. I think. BUT if you download Seatools for DOS and burn it to a bootable CD, you can run it on a newer machine and alter the configuration of this Seagate unit before trying to put anything on it. The tools in that package include two for limiting the apparent size of the unit. One can allow you to limit its size to the maximum number of LBA addresses it will accept. To fit into the 128 GiB limit that is 268,435,456 (2^28). The other limits the device to 32 GB for earlier machines. I don't know how to do that latter change on a WD unit, but maybe they can tell you how to use their disk utility software for that kind of job. Either way, you should be able to make some reasonably recent HDD behave properly in the old machine. Once you can do that, you can clone the old data to the modified new unit using a new machine but insisting on a MBR Partition system and a Format using FAT32 rather than NTFS. That combination should work in the old machine.
 

MightyGorilla

Prominent
Jul 14, 2017
8
0
520
Paperdoc,
I appreciate the extra thought on this curious old stuff, and I did get it resolved and working. To answer some of the subjects brought up, this board long predates SATA, AHCI, etc (appears to be from the mid 90s even though the machine it's inside is from late 90s) however the IDE-to-mSATA adapter worked flawlessly.

The BIOS was using LBA, though- and it was critical to the project to reduce the mSATA chip's storage to mirror the LBA sector count of the original disk. Several of the other adapter devices I tried would be recognized by the BIOS (not all) but NONE of those devices would allow the creation of the HPA to reduce the overall sector count to match, which doomed those particular devices. Had this just been a simple DOS system, without the realtimeOS layer, that part would not have been necessary, so I just want to point out that there are a lot of good options for solid state replacements in old systems...

My last ditch effort was going to just be normal spinning disk HDDs, but the machine is in an abusive environment that is extremely hot. Getting away from mechanical storage was the goal, overall. Please note - The difficulty in creating an HPA was limited to those other solid state devices. There was never any issues with that on HDDs, so nearly any drive would likely work (but would be a huge waste of disk to limit a 250GB disk to 4.8GB!)
 

Paperdoc

Polypheme
Ambassador
Thanks for those details. So you did get the revised system to work as you need. Congratulations! Dealing with obscure mis-matches among different technologies from many development periods is always a huge challenge.

As an example. I have a friend who's a professional librarian by training. He has shown me documents dealing with the problems of trying to preserve data and information so that it can continue to be accessed as our storage and retrieval technologies change. It's a nightmare! Not only do the technologies change, but many have much shorter lifetimes than we have been used to in the past, making data disappear by corruption due to age of the medium.

Your particular situation is all too common. So may industries have computer-based systems doing critical functions that have become very old and started to fail. Yet nobody really has any records of how that system was designed (what was the basis of the software?) so that it can be replaced with a new set of tools that duplicates the functions of old ones. And in fact, many firms caught in that bind are shocked to find out how much such a re-development project might cost! It is nowhere near as simple as replacing a 40-year-old AC motor.