Look at line 3933.  If the -mi86 option is used and the retf instruction has no prefix, the instruction jumps to the address specified by the last 2 bytes on the stack (the offset) and the next-to-last 2 bytes on the stack (the segment).  However, if the last 4 bytes on the stack are the offset and the next-to-last 4 bytes on the stack are the segment and the -mi86 option is used, the instruction must be prefixed with 0x66.  On lines 3922-3925, these 8 bytes are pushed on the stack.

a_flags is at an offset of 2 bytes, a_text is at an offset of 8 bytes, and so on.  a_flags describes the kernel (with the options shown on lines 3029-3033) and a_text, a_data, a_bss, and a_total are sizes.

Note that the A_SEP flag describes this executable (the secondary boot loader) whereas the K_I386, K_RET, K_INT86, and K_MEML flags describe the kernel.

This executable (the secondary boot) is compiled with the -mi86 option and runs in real mode and not in protected mode.  For this reason, the secondary boot is not be able to take advantage of the protection features of protected mode.  However, since this is the first time we've run into the A_SEP flag, it's a good place to discuss shared vs. separate segments.

In protected mode, the text (code) and the data+bss+heap+stack (I will refer to this as the total data - see the next paragraph for a description of each of these) in an executable with separate text and total data segments are protected from one another.  For example, if the code tries to jump to a memory address that's within the total data segment, the hardware triggers a segment violation.  If they're not separate (A_SEP in a_flags is not set), chaos results.  Another advantage of separating the text and total data is that the text can be shared among multiple instances of the same program.  The total data will differ between two instances of the same program but the text will be the same.

Data contains initialized global variables, bss contains uninitialized global variables and must be initialized to zero (see lines 3091-1098), and the heap is the memory that malloc() allocates at run-time.

It's best to also keep the data+bss+heap and the stack separate - although Minix doesn't separate the two for the reasons given in section 4.7.3.  This means that if the heap or the stack grows too large, one can overwrite the other.  If the stack overwrites the heap and the overwritten data is not accessed immediately, identifying the problem is difficult.

On disk, the a_text field in the header holds the size of the text and the a_data field holds the size of the data.  If the kernel doesn't have separate text and total data segments, the variables a_data and a_text are combined into a_data and the variable a_text is set to zero (see lines 3069-3071).  Note that even though the values are changed in memory, they do not affect the values on disk. a_bss is the size of the bss.  a_total is the size of the data+bss+heap+stack (separate) or the text+data+bss+heap+stack (shared).  Unlike a_text, it doesn't need to be modified if the text and total data are shared. a_total determines the top of the stack (see lines 3075-3077) and is also used (with a_text) to determine the global variable _runsize (see lines 3127-3135) which is needed by boot.c in initialize().

The following values are the offsets of the entries within the global descriptor table.  For example, since the entry for the kernel code is the 7th entry (see line 4267) and the size of each entry is 8 bytes, its offset is 6*8 (remember that the first entry has a 0 offset).  The MCS_SELECTOR is pushed onto the stack (if the K_RET flag is set for the kernel) before jumping to the kernel (look at lines 3918-3920) .  Also before the jump is made to the kernel, the ds and es registers are loaded with DS_SELECTOR and ES_SELECTOR, respectively.

A similar trick is used in the kernel.  Read the 5th paragraph of section 2.6.3 of Operating Systems for details.

Variables that are shared between assembler and C code are prefixed with an underscore ( _ ) in the assembler code but are not prefixed with an underscore in the C code.

Before boot is called on line 3180, a few things are done.  (Don't confuse the two boot's; one's an address (line 3062) and the other's a function defined in boot.c (line 3180).)

Lines 3062-3080: The ds, ss, and sp registers are loaded.  The values loaded depend on whether this executable has a separate text and total data (A_SEP in a_flags is set) or this executable has a shared text and total data (A_SEP in a_flags is not set).

Lines 3092-3097:  Clear the bss.  The bss contains uninitialized global variables and needs to be zeroized.

Lines 3100-3135:  Initialize various global variables so that when boot (line 3180) is called, the C code can access their values.

Lines 3137-3177:  Initialize the array mem[].

Why can't the instruction mov ds, #LOADSEG be used instead of using ax as an intermediate register?  The 80x86 processors forbids immediate data to segment register transfers.  (Immediate data is data that is within the instruction itself, as opposed to data that is at a memory location or data that is in a register.)  Memory to segment register transfers are also forbidden.  Only register to segment register transfers are allowed.  The one exception to this rule is the cs register.  The cs register is even more restrictive.  The only two instructions that can alter the cs register are jmpf (far jump) and return retf (far return) instructions.

mov ax, #0

is slower and is 3 bytes compared with xor's 2 bytes.

Interrupts are disabled with the cli (clear interrupts) instruction and reenabled with the sti (set interrupts) instruction.

I don't know what "blanking" is.  If you know, please submit a comment to the site which will be displayed below.

If the mem[1] and mem[2] memory areas are continugous, then mem[1] and mem[2] are combined.

Since mem[] is an uninitialized variable, it is found in the bss space, which was zeroized on lines 3091-1098.  The following instructions are not needed since these 4 bytes are already zero.

mov 0(di), #0
mov 2(di), #0

Also, since the lower 2 bytes of the base of both mem[1] and mem[2] are also zero, the following instructions are also not needed:

mov 8(di), #0
mov 16(di), #0

The lower 2 bytes of the lower memory size are stored in 4(di) and the upper 2 bytes are stored in 6(di) (lines 3443-3144).  Likewise, 12(di) and 14(di) hold the size of the memory between 1M and 16M.  20(di) and 22(di) hold the size of the memory above 16M.  Since int 0x15 , ax=0xE081 returns the number of 64K (not 1K) blocks of memory in bx (see line 3152), 20(di) will equal 0.

If the _exit function is called, then for one reason or another, the boot code has decided to exit rather than jump to the kernel.  If no error occured (status=0), reboot.  Otherwise, wait for a key to be pressed and then reboot.

Let's look in boot.c where both of these functions are called.  lowsec holds a 2-byte integer while rem_part holds a 2-byte offset address in its lower 2 bytes and a 2-byte segment address in its upper 2 bytes (see lines 3104-3105).  mon2abs converts the 2-byte offset address of lowsec (using ds as its 2-byte segment address) to a 4-byte absolute address and vec2abs converts the 4-byte segment:offset address found at rem_part to a 4-byte absolute address.  The figure below shows the relationship between the stack of vec2abs and the variable rem_part.

The comment for vec2abs is a little misleading.  As the above example shows, vec2abs can be used for conversions of segment:offset vectors that are not interrupt vectors.  This is the only place in the boot sequence where vec2abs is called.

If the source or destination address is greater than 1MB, extended memory must be accessed using the int 0x15, ah=0x87 bios call.

Keep in mind that the system is still in real mode.  When (and if) the system is switched to protected mode, this problem goes away.  In protected mode, 4GB of memory can be accessed.

If the absolute address range 0x1000-0x2000 were copied to location 0x1800-0x2800, the source range and the destination range would overlap.  Overlaps are not allowed.

After line 3253, the stack will look like this:

Either 1 byte or 0 bytes is then copied from ds:si to es:si.

The return address (which is only an offset) of this function is popped into bx to start this function.  The last instruction before the final instruction, retf, is to push this offset on the stack.  The returning offset will be the same but the segment will be different (the new segment is pushed on the stack on line 3364).

If you can shed any light on the brk and sbrk calls, please submit a comment to the site which will be displayed below.

brk specifies the address on the heap (addr) to which malloc() wishes to allocate.  sbrk specifies the incremental space on the heap (incr) that malloc() wishes to allocate.

printk("\nOut of%s", " memory, use chmem to increase the heap\n\0");

The "%s" is replaced by the second string.

chmem is a utility program that changes the size of the stack.  It does this by altering the a_total field in the executable's header (see comment for line 3029).

As usual, the greatest difficulty arises if the device is a floppy drive.  If _device is a floppy, an attempt is made to read the first sector to make sure the drive is properly functioning.  If the drive is properly functioning, an attempt is made to read the 18th sector of the first track, then the 15th sector of the first track, and finally the 9th sector of the first track (see line 3483).  If the attempt to read the 18th sector of the first track is successful, then there are 18 sectors on a track and only a 1.44M floppy has 18 sectors on a single track.  If the 18th sector can't be read but the 15th sector can be read, we know we have a 1.2M floppy and if only the 9th sector can be read, we know we have a 720K floppy.

If the carry flag is not set and everything worked, the jnc instruction jumps to memory location finit0ok.  The data that is copied to memory is not examined.  We are only concerned with whether we are able to perform the copying operation.

Again, we won't look at the data that we copy to memory.  We are only concerned with whether we are able to perform the copying operation.

The div instruction divides dx-ax by the operand (in our example, the value at address sectors) and puts the quotient into ax and the remainder into dx.

Two div instructions are used in this function.  It's unclear to me why they don't load the top 2 bytes of sector into dx , the bottom 2 bytes into ax and then execute only one div sectors instruction.  Since sectors is 2 bytes, dx can hold the largest possible remainder.

If the value in dx-ax is large (for example 0x0FF0FF00) and the operand is small (for example 0x0004) and you are interested in the quotient (note that we are only interested in the remainder in this function), then two div instructions are necessary.  Otherwise, the ax register will overflow (i.e. the quotient will exceed 2 bytes).

For this function, let's look at 2 examples.  sector=0x0151FF00, sectors=0x30 for the first example and sector=0x0151FEF0, sectors=0x30 for the second example.  The first example is on a boundary and the second example is not on a boundary.

Example 2:
ax=0x0151, dx=0x0000

Example 2:
ax=0xFEF0
dx=0x0001

Example 2:
ax=0x0AA5
dx=0x0000

Example 2:
dx=0xFFFF (-1 in two's complement)
carry flag (CF) =1

Example 1:
ax=0x0000

Example 2:
ax=0xFFFF

This function is called from C code.  C expects the return value from called functions to be in the ax register.

Example 1:
ax=0x0000  (a zero represents false)

Example 2:
ax=0x0001  (a nonzero value represents true)

Look at the get_sector() function in bootimage.php.  bufaddr will usually be the absolute memory address of an array (in this case, the array buf).