A simpler fix would be to a change of the BootDrive value to 0xFF. As you said, the current value is 0, but thats by design, since all the values have been filled for a 1.44M diskette.
Even the File System ID could have been set differently, since the neutral value 'FAT ' is allowed here.
--- Phillip Susi psusi@cfl.rr.com wrote:
Well, I finally solved my problems with getting freeldr to boot from a hard drive. The first is a problem with fat.bin itself. Early during it's execution it checks to see if the boot sector header specifies a device ID of 0xff, and if so, it uses the device ID the bios passes in CL when it invokes the boot sector, otherwise it uses the device ID in the boot sector header. The device ID field of the boot sector is inherently unreliable and should NEVER be used. In my case mtools was leaving it as it was in fat.bin, which is 0, so it was trying to access the floppy instead of the hard disk. I have fixed this by removing the check to see if the field is 0xff, so the code will always use the device passed by the bios.
Kind regards,
Usurp (aka Sylvain Petreolle)
humans are like computers, yesterday the BIOS was all - today its just a word
That probably would have worked too, but I don't trust various disk utilities to preserve the value at 0xFF. Also if it is always going to be 0xFF, then there is no reason to bother with checking it to see if it is 0xFF, and skipping the check frees up a few precious bytes of space in the boot sector anyhow.
Sylvain Petreolle wrote:
A simpler fix would be to a change of the BootDrive value to 0xFF. As you said, the current value is 0, but thats by design, since all the values have been filled for a 1.44M diskette.
Even the File System ID could have been set differently, since the neutral value 'FAT ' is allowed here.
-
Phillip Susi -
Sylvain Petreolle