Lots of tweaks.

Submitted by:	Joerg Wunsch <joerg_wunsch@uriah.heep.sax.de>

1 files changed, 14 insertions, 17 deletions

diff --git a/share/doc/handbook/memoryuse.sgml b/share/doc/handbook/memoryuse.sgml
index b76a16c..bb5baee 100644
--- a/share/doc/handbook/memoryuse.sgml
+++ b/share/doc/handbook/memoryuse.sgml
@@ -1,4 +1,4 @@
-<!-- $Id: memoryuse.sgml,v 1.2 1995/06/30 17:37:42 jfieber Exp $ -->
+<!-- $Id: memoryuse.sgml,v 1.3 1995/09/25 04:53:33 jfieber Exp $ -->
 <!-- The FreeBSD Documentation Project -->
 
 <sect><heading>PC memory utilization<label id="memoryuse"></heading>
@@ -11,26 +11,26 @@ of how FreeBSD uses PC memory, ie
 what 0-640K gets used for, does the kernel load there or higher,
 is the kernel relocated, etc.  Is there a paper on this?</em>
 
-The boot sector will be loaded at 0:0x7c00, and relocates itself
-immediately to 0x7c0:0.  (This is nothing magic, just an adjustment
-for the %cs selector, done by an ljmp.)
+The boot sector will be loaded at <tt>0:0x7c00</tt>, and relocates itself
+immediately to <tt>0x7c0:0</tt>.  (This is nothing magic, just an adjustment
+for the <tt>%cs</tt> selector, done by an <tt>ljmp</tt>.)
 
-It then loads the first 15 sectors at 0x10000 (segment BOOTSEG in the
-biosboot Makefile), and sets up the stack to work below 0x1fff0.
+It then loads the first 15 sectors at <tt>0x10000</tt> (segment BOOTSEG in the
+biosboot Makefile), and sets up the stack to work below <tt>0x1fff0</tt>.
 After this, it jumps to the entry of boot2 within that code.  I.e., it
 jumps over itself and the (dummy) partition table, and it's going to
 adjust the %cs selector---we are still in 16-bit mode there.
 
-boot2 asks for the boot file, and examines the a.out header.  It masks
-the file entry point (usually 0xf0100000) by 0x00ffffff, and loads the
-file there.  Hence the usual load point is 1 MB (0x00100000).  During
+boot2 asks for the boot file, and examines the <tt>a.out</tt> header.  It masks
+the file entry point (usually <tt>0xf0100000</tt>) by <tt>0x00ffffff</tt>, and loads the
+file there.  Hence the usual load point is 1 MB (<tt>0x00100000</tt>).  During
 load, the boot code toggles back and forth between real and protected
 mode, to use the BIOS in real mode.
 
-The boot code itself uses segment selectors 0x18 and 0x20 for %cs and
-%ds/%es in protected mode, and 0x28 to jump back into real mode.  The
-kernel is finally started with %cs 0x08 and %ds/%es/%ss 0x10, which
-refer to dummy descriptors covering the whole address space.
+The boot code itself uses segment selectors <tt>0x18</tt> and <tt>0x20</tt> for <tt>%cs</tt> and
+<tt>%ds/%es</tt> in protected mode, and <tt>0x28</tt> to jump back into real mode.  The
+kernel is finally started with <tt>%cs</tt> <tt>0x08</tt> and <tt>%ds/%es/%ss</tt> <tt>0x10</tt>, which
+refer to dummy descriptors covering the entire address space.
 
 The kernel will be started at its load point.  Since it's been linked
 for another (high) address, it will have to execute PIC until the page
@@ -38,9 +38,6 @@ table and page directory stuff is setup properly, at which point
 paging will be enabled and the kernel will finally run at the address
 for which it was linked.
 
-The kernel still skips over the first 0x500 bytes of code, in the
-assumption this were valuable BIOS data space (back from old days
-where it has been loaded low).
 
 <em>Contributed by &a.davidg;.<newline>
   16 Apr 1995.</em>
@@ -48,7 +45,7 @@ where it has been loaded low).
 The physical pages immediately following the kernel BSS contain
 proc0's page directory, page tables, and upages. Some time later
 when the VM system is initialized, the physical memory between
-0x1000-0x9ffff and the physical memory after the kernel
+<tt>0x1000-0x9ffff</tt> and the physical memory after the kernel
 (text+data+bss+proc0 stuff+other misc) is made available in the
 form of general VM pages and added to the global free page list.