It refers to only the TESTMBR version that is in RMPrepUSB v2.1.617 and later only. The previous version was different! Source code for TESTMBR is also included with the RMPrepUSB download.
I will assume that you are interested in this article because you have one particular system that will not boot from your USB drive (and most other systems will) - so you want to investigate why this weird system of yours will not boot.
I will start with describing how to make a test USB drive and how you can test your BIOS. Later, I will describe how to interpret the results.
Note: This will - of course - destroy all data on your USB drive!
The 5 BIN files are:
MBR0P.BIN - Debug MBR with no (i.e. an empty) partition table
MBR1P32S.BIN - Debug MBR with 1 entry in the partition table which has 32 sectors per track geometry (file is 31 sectors in size)
MBR2P32S.BIN - Debug MBR with 2 entries in the partition table which has 32 sectors per track geometry (file is 31 sectors in size)
MBR1P63S.BIN - Debug MBR with 1 entry in the partition table which has 63 sectors per track geometry (file is 63 sectors in size)
MBR2P63S.BIN - Debug MBR with 2 entries in the partition table which has 63 sectors per track geometry (file is 63 sectors in size)
The MBRxP32S files are 16384 bytes in size and will overwrite blocks 0-31 (sectors 1-32)
The MBRxP63S files are 32256 bytes in size and will overwrite blocks 0-62 (sectors 1-63)
Thus the PBR (partition boot record) will be left untouched if you choose the correct file. To check this you can use the USB Info button on RMPrepUSB and enter P1 for the start of the first partition. It should display the Partition Boot Record (aka Volume Boot Record or VBR) at sector xx. If in doubt use the 32S BIN files as these will not overwrite your PBR.
Q. Why have different BIN files and why do I need to format the USB drive in different ways?
A. When a BIOS detects a USB drive, it will interrogate the drive to try to determine how to treat the device (i.e. should it pretend it is a floppy drive or a ZIP drive or a hard disk, how many sectors per track and heads per cylinder does it have). So it matters how you partition and format the USB drive. For instance, if you format a USB drive which has no MBR or partition table, the BIOS may decide to treat it as a floppy drive. If you partition and format the same USB drive with an MBR and partition table containing a single partition entry, it may decide to treat the USB drive as a ZIP drive. If you partition and format the same USB drive with an MBR which contains two valid partition table entries, the BIOS may treat the USB drive as a hard disk. It is known that BIOSes do look at the contents of the first sector of the drive to try to determine what kind of device it is. It is also possible that some BIOSes may even look at the PBR active partition as well as the MBR to try to determine how to map the USB drive - for instance, if the PBR contained a BIOS Parameter Block (BPB) that held floppy disk values, the BIOS could decide to treat the USB drive as a ZIP drive instead of a hard disk drive. It is also known that a BIOS can treat a 256MB USB drive as a floppy drive, but a 512MB USB drive (that contains IDENTICAL contents), as a hard drive (the BIOS interrogates the USB drive for it's physical drive size and from the size returned it determines how it should map the drive). For this reason you should try these different combinations and then record the results each time:
If possible use different drive sizes - a 256MB USB drive, a 512MB USB drive, a 1GB USB drive and a 2GB+ USB drive in each of these different test formats to determine if your BIOS also uses the USB drive capacity to determine how to boot the drive. For instance some older Intel BIOSes will not boot from any USB drive if it is larger than 256MB (i.e. it will not even read the first sector into memory and execute the MBR code, if the physical capacity of the drive is over 256MB when first interrogated during BIOS POST). Typically these types of older BIOSes boot low capacity USB drives as ZIP (large floppy) drives.
Before a BIOS loads the data (code) from the first sector of a USB drive and runs that code, it has to decide how to 'map' that device to the standard int 13h BIOS call that all boot code uses. If the BIOS decides that the USB device is a floppy device, the BIOS will respond to 'floppy drive' int 13h requests (i.e. DL=00). If the BIOS treats the device as a hard disk type, it will respond to 'hard disk' int 13h requests (DL=80h). If the BIOS treats the USB device as a ZIP device, it will respond to access requests as a floppy (DL=00) but it will translate any request such that a request for Sector 1 (LBA0) will return the PBR of the device, a request for Sector 2 will return the sector after the PBR and so on. Thus to any real-mode (DOS) OS, the USB ZIP device will appear to be just like a big floppy disk with no MBR or reserved sectors.
There is no standard for how a BIOS should 'decide' on how to map a USB device. Different BIOSes use different decision trees. Some do not even bother and just assume all USB storage devices are of one type (e.g. HDD). Some older BIOSes assume all USB device are ZIP devices if they are over 1.44MB in size - otherwise FDD. Some only do the ZIP translation/adjustment if you use Int13h Standard CHS calls but do not translate sector addresses if you call the Extended Int13h interrupt routines!
Another thing the BIOS has to decide is what to do when the OS requests a 'read' or 'write' from Cylinder 5, Head 1, Sector 1 on the UFD using the standard Int 13h 02/03 calls. The UFD has no real heads or cylinders! So the BIOS has to translate this CHS 'address' into a Logical Block Address (LBA). But how does it know how many sectors are in a track (SPT) or how many tracks are in a cylinder (HPC)? One common method is to look at the Ending Head and Sector values in the partition table of the MBR. As (until Vista) all partitions ended at the end of a whole cylinder, the End Head value shows how many heads there are per cylinder, and the End Sector value shows how many sectors there are per track. The BIOS can then use these values to calculate an LBA address when the OS asks for CHS address 5 1 1. Unfortunately, other BIOSes just assume 63 SPT and 255 HPC. This is especially true of modern BIOSes because Vista and Win 7 Diskpart creates partitions at any start address and any end address now and does not adhere to the old DOS/Win98/XP 'rule' of starting partitions at the start of a track and ending partitions at the end of a cylinder. The Sectors per Track and Heads per Cylinder count is called the 'drive geometry' and can cause a lot of issues. It was quite common for some older BIOSes to default to 240 Heads per Cylinder as a maximum value.
Because when the int 13h disk call was first introduced on the IBM PC, the software engineers did not imagine you could have a disk larger than 500MB (that would be crazy!), they designed the int 13h interface to only go up to a maximum of 1024 cylinder by 16 heads (how can a disk drive possibly have more than 16 heads?) by 63 sectors per track. As disk sizes grew and disk became intelligent, the int 13h 'standard' had to be redefined. Each time it was redefined, the BIOS had to be changed and some were changed better than others! When disk drives reached over 8GB, the Extended Int 13h interface had to be developed and now even that is not good enough to handle modern drives over 2TiB (though 4TiB disks are just possible as long as the last partition starts below the 2TiB limit!). The whole thing is such a fiasco that it is a wonder disks boot at all! See here for more info.
Step 2 - Using the test USB drive on your problem system
IMPORTANT: You must follow these instruction exactly and you must make a note of all settings (even if you think you can remember afterwards!).
This shows the expected correct result for a UFD which has booted as a hard disk (63 SPT, 32 Heads per Cyl)
Repeat the test using a different BIN file. You can also re-format in step 1.3 using a different option (e.g. MSDOS or XP or Win7 PBR, 64/32 or 255/63, ZIP or HDD).
Using the table below, you can see that in this example, the USB pen was treated by the BIOS as a hard disk (80=Hard disk). An extended int 13h BIOS call was made to read sector 1 (LBA0) and the correct sector was returned by the BIOS. A standard int 13h CHS call to read sector 1 (LBA0) also returned the correct sector. We could therefore expect this BIOS+BIOS Setting+USB pen+partition table data to boot as a standard hard disk.
For a USB key that boots as a floppy, expect 00 and 'FDD0' to be displayed
For a USB key that boots as a super-floppy/ZIP drive expect 00 and ? and the first 16 PBR bytes to be displayed
For a USB key that boots as a hard disk, expect 80 and 'HDD0' to be displayed
If HDD & Z or FDD & Z or ? followed by non-PBR bytes is displayed then you have a strange BIOS indeed!
aaaa bbbb cccc dddd - e.g. 0000 1F02 003F 03B3 (AX DX CX_sector CX_cylinder)
These are the values returned after calling the Get Disk Geometry call (int 13h AH=8) - and can be interpreted as follows:
USB-FDD with MBR1P32S.BIN booted on Asus EeePC 904HD
This shows the BIOS has assumed 2 heads and 18 sectors per track (and ignored the partition table values in the MBR) and 317 cylinders. The 80 shows that the BIOS has mapped it as a hard disk (despite the USB device identifying itself as a floppy drive!). It shows 3 hard disks present as the USB device also has an HDD device on the controller (a 1GB USB Disk Pro). The HDD0 00 messages show that the BIOS is not translating sector addresses and so is not in ZIP mode. If any boot code or OS was placed on this drive, it may have problems. It would be best to use a non-MBR image with no partition table on this USB-FDD part of the drive.
Tip: To copy the TESTMBR BIN files onto a USB-FDD device (e.g. Netac U207, Disk Pro, etc.), use dd.exe v0.5 for Windows by John Newbigin:
You can also use dd on a physical USB drive after --list to find out it's designation under Windows - e.g. \\?\Device\HardDisk1\DR29 (but RMPrepUSB File->USB and USB->File is much safer!).
If you format a UFD using RMPrepUSB as USB-ZIP + FREEDOS, then the FreeDos PBR will be changed so that it has floppy drive parameters - therefore it may not boot if your BIOS maps it as a hard disk (80) instead of a floppy (00). So you should format the UFD as USB-HDD. Some BIOSes work better if you use 63/255 geometry and some if you use 64/32 geometry. Generally, if a BIOS maps a UFD as a hard disk, use 63/255 geometry. If you need to boot as a floppy (A:) then see the grub4dos tutorial examples for some methods to 'convert' a UFD that boots as a hard disk but can make it appear to the OS (DOS) as a floppy drive.
If you can see nothing wrong with the results returned by the TESTMBR code, you can try installing grub4dos. Use RMPrepUSB and click the 'Install grub4dos' button (after correctly re-formatting the USB drive using RMPrepUSB - of course). All you need on the USB drive is the grldr file which RMPrepUSB will copy across for you automatically. Now try to boot from the USB drive and you should get to a grub4dos command 'shell'. Once in this command shell, you can use some grub4dos commands to see how the drive has been mapped.
First type 'geometry' (you can type ge and hit the <TAB KEY> and grub4dos will fill in the rest of the command)
Next type map ( then hit the <TAB KEY> - grub4dos will show you what drives it thinks are present - rd is ramdrive and can be ignored as it is created by grub4dos
Now try ls / to list files on the current device (which should be your boot drive)
Notice that the geometry command shows how the USB drive appears to an OS with 64 heads, 32 sectors per track and 991 cylinders. It has two partitions (a dummy type 21 was created by RMPrepUSB USB-HDD option to try to force the BIOS to treat the UFD as a hard disk).
Tip: Sometimes using the command geometry --tune can change the BIOS drive CHS geometry. This command may be useful to include in your grub4dos menus.