From owner-freebsd-current  Sun Nov 24 16:15:44 1996
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id QAA21986
          for current-outgoing; Sun, 24 Nov 1996 16:15:44 -0800 (PST)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id QAA21977
          for <freebsd-current@freebsd.org>; Sun, 24 Nov 1996 16:15:35 -0800 (PST)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id LAB08714; Mon, 25 Nov 1996 11:05:33 +1100
Date: Mon, 25 Nov 1996 11:05:33 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199611250005.LAB08714@godzilla.zeta.org.au>
To: freebsd-current@freebsd.org, j@uriah.heep.sax.de
Subject: Re: 2.2-ALPHA install failure
Sender: owner-current@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

>DD mode works with anything of at least 15 spt.

I think it works with anything of at least 1 spt (and sufficently many
sectors below cylinder 1024 of course).  Floppy i/o requests don't
cross track boundaries, but the paritition table isn't used by the
BIOS for floppies.  Hard disk i/o requests do cross track boundaries.
A geometry of 15/1/1 should be sufficient for loading the bootstrap :-).

>Don't worry.  Anything with at least 15 spt will work.  IDE drives get
>their BIOS geometry from the BIOS setup anyway, not by implying some
>semantics to block 0 of the first disk.  (This implication as it is
>apparently done by some SCSI controllers seems to be a big crock to
>me, but oh well, we're in a PeeCee world here.)

The loader in the MBR uses the starting C/H/S value to load the
secondary bootstrap because it has to use the old BIOS C/H/S interface
for portability and converting from the absolute sector number to
C/H/S wouldn't fit in the MBR.  It takes a lot of code to determine
the geometry :-).  (Not really, it only takes a single interrupt ask
the BIOS for the geometry.)

Bruce