Hi,
Thank you for so detailed explanation! This helps me a lot! I'll take time
to read it more carefully and search through the Web for clearer
understanding. Thanks again.
Best regards,
Robbie
On Tue, Sep 20, 2011 at 10:30 PM, C. Masloch <c...@bttr-software.de> wrote:
> 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
>
------------------------------------------------------------------------------
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
