1. Boot from a USB key to MSDOS
2. Run a partitioning tool to:
Wipe partition table and put standard MBR on it
Create 2000MB NTFS primary partition entry (not formatted)
Create a 60MB FAT16 primary partition and format it
Make the FAT16 partition active
3. Reboot from the USB stick again so that MS-DOS sees the formatted HDD partition
4. Run SYS D: to put boot code on the FAT16 partition (C: is the USB stick)
5. Switch off and on again (or CTRL-ALT-DEL) to allow it to boot from the hard disk
As I said, one hard disk worked but the other did not.
Here is the difference between the two drives though - the hard disk that did not boot had previously been prepared using WinPE 7 DISKPART and had been running Win 7. The hard disk that did work was a brand new hard disk.
When I looked at the FAT16 partition table, I saw that the CHS values were pretty crazy for the HDD that did not work, but reasonably OK for the HDD that did work (actually the Cylinder value was still wrong but at least it had 255 heads and 63 sectors per track for the Ending values).
So I then went into debug and did a quick Int 13h AH=08h call to get the Hard Disk parameters returned by the BIOS. With the 'good' HDD it returned a reasonable number (again the total cylinders was wrong but the HPC and SPT of 255 and 63 were correct). With the 'bad' HDD, the BIOS returned crazy values for everything! I had more identical systems and these also returned crazy (but different!) values.
In the end I fixed all the drives by simply wiping the partition table and rebooting them and only THEN performing the operations 1-5 as detailed above.
So what was happening?
Well many BIOSes that support large hard disks and support LBA translation but don't know quite how the hard disk was prepared i.e. what Heads-per-Cylinder and Sectors-per-track value to use when translating between LBA and CHS and vice versa. So what they do is look at the HDD partition table values on the hard disk itself during POST (Power On Self Test). Because FDISK (and XP Diskpart) always ended a partition at the end of a whole cylinder, the Ending Head and Ending Sector value in the partition table would tell the BIOS what translation had been used when the partition was made. Some BIOSes/Partition programs used 240 heads per cylinder, some used 255, some used 32 SPT instead of 63 SPT. If the BIOS looks at the Ending Head/Sector values it can decide what conversion to apply.
This was great until Vista (and Win7) Diskpart came along!
Vista and Win7 do not follow the unwritten law - 'Though shalt always end a partition on a whole cylinder' - so what values we see in the partition table after you format a HDD using Vista/7 Diskpart have no relation at all to HPC or SPT!
So, if the BIOS on first POST sees an empty partition table (or invalid partition table) it was defaulting to use 255/63 translation. If however, the partition table was one made by Vista Diskpart, the BIOS would see silly values like 17 HPC and 3 SPT and use these for LBA translation instead! Even though we wipe the partition table, when the partition code asks the BIOS for it's parameters, it uses the ones that it read from the partition table during POST and so returns silly values - these values are then used by the partition program to create a FAT16 partition which ends at a cylinder boundary again. So as the BIOS tells the partition program it has say 17 HPC and 3 SPT, the partition Ending Head/Sector values of 17 (actually 16 as it starts at 0) and 3 then get written to the FAT16 partition table. So no matter how many times I repeated the steps 1-5, it merely kept using the wrong HPC/SPT values every time!
Modern (correct) BIOSes should always assume 255/63 translation. They have to, as they simply cannot tell just by looking at the partition table any more!
Curiously, FAT32 Ms-DOS partitions worked fine on all drives, it was only FAT16 PBR boot code that did not.
So the moral is - always wipe (seems my mum's advice was right
!) - then reboot and partitionOR avoid MS-DOS FAT16!
:
