Hi, This doesn't seem to have received any answers yet.
> I see the MBR code essentially loads the boot sector of the active > partition and puts it at address 0000:7c00. Then the boot code is > executed by jumping to that address. This is correct. > 1. INT 0x13 with AH=0x42 does extended read operation. But what if the > BIOS is old? Will it do nothing and set an error flag in CF? Yes, BIOSes not supporting (LBA) extended functions should flag an error. However, the boot sector or MBR can/should test whether the BIOS supports (LBA) extended functions via the detection function first. That's 13.40 or something, look it up in your reference. As opposed to only checking CF, you should check for both NC and the signature value (in bx I believe) to verify that the detection function is supported. MBRs and boot sectors depending on LBA support are easier to write; specifically as you do not have to write handling for two interfaces and as calculating CHS addresses from linear sector numbers is then unnecessary. (LBA addresses are the same as linear sector numbers.) (Getting rid of the LBA support and always using the CHS interface is a bad idea though, because CHS is limited to the first 8 GiB or so of the disk.) > 2. Compared to the MBR, does the boot sector also contain partition > location > information? I searched the Web and looked at some pages about it, but > didn't find any. Then, how does it call INT 13 and boot the kernel? Maybe > I'm not understanding this correctly, so please correct me if I'm wrong. This is how it's usually done for FAT partitions, yes. In the FAT "BIOS Parameter Block" (BPB, it contains informations about the file system) there is one field often called "hidden sectors". This is simply the number of sectors on the disk that are in front of the boot sector; in other words, the (LBA) address of this partition. This information is virtually useless: if you know where you read the sector from, you shouldn't need that information in the sector itself. However, as you must have noticed, there is no interface for how to pass the sector address from the MBR code to the boot sector code, so this field is necessary as it isn't communicated to the boot sector code. Knowledge of the file system can be read and calculated from the BPB, including the position of the FATs, the root directory (FAT12/16 special area or FAT32 cluster) and the data area. The boot sector code parses as much of that as necessary, then scans through the root directory. (Some loaders expect the first root directory entry to be the one for their kernel.) The loader then reads either the first few sectors of the first/only kernel file or that entire file. (In the former case, the first few sectors contain a more advanced file system driver.) On FAT32, some systems use secondary boot code sectors behind the first one to store more code. (This is similar to the loading scheme which stores a more advanced driver at the beginning of the kernel file.) Regards, ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
