MR> Is there some reason that 0 is an invalid number for heads (AKA
 MR> tracks/cylinder) and sectors/track?  If there isn't, then that should
 MR> be 1024*256*64, which comes out to exactly 8GiB (trying them on for
 MR> size), provided the drive uses 512-byte sectors (as almost all do
 MR> these days).

It isn't an invalid number.  It simply means 0 rather than 256.  I agree with
you that this is unfortunate, since one would never *want* 0.  But there it
is.

 MR> Of course, that doesn't address the issue of drives larger than 8GB.

I take it that you mean 8GiB.  8GB is 7.45GiB, of course.

 MR> The BIOS's which are capable of supporting such drives actually
 MR> support the entire drive, through a translation scheme I have yet to
 MR> find any information about.

They don't use translation at all.  In fact they don't use cylinders, heads,
and sectors.

There is a new API, the so-called "INT 13h extensions", promulgated by
Phoenix, IBM, and Microsoft.  It takes 64-bit logical block numbers as
parameters.  I can file attach the PDF file containing the API description to
your Fidonet node if you want.

This is obviously the correct solution to the 1024 cylinder problem, and the
one that I champion whenever this subject comes up.  All of this fuss about
translation merely postponed the problem.  Now that hard discs have reached
and exceeded the upper limit of translation, 7.84GiB, we are seeing the same
problem as was seen all those years ago when discs started to commonly exceed
504MeB.  Only this time there is no convenient ugly bodge that can save the
day by postponing the problem for a few years and passing it on to the next
generation of hardware product managers.

The problem with the INT 13h Extensions is threefold:  Not all BIOSes
implement these extensions, not all BIOSes implement these extensions
correctly, and not all operating system vendors have caught up.  

The fact that not all BIOSes implement these extensions is something that one
just has to accept.  But it *is* the reason for not all operating system
vendors (or indeed, hardly any of them) having caught up.  Their boot sector
and kernel loader code still uses the old INT 13h API, the one that uses
cylinders, heads, and sectors, because it is the *only* API that is
*guaranteed* to work on *any* arbitrary machine.  If the operating system
vendors were to change their boot sector and kernel loader code to use the
Phoenix/IBM/Microsoft extensions, they would eliminate a large range of older
machines from their market, and give themselves a reputation for
"incompatibility" as well.  ("I bought this operating system, and installed it 
on my old spare 486 to try it out before tackling my main machine, but it
doesn't even get as far as booting!")

It is worth noting that even operating systems as "forward thinking" as linux
2.3 is supposed to be (although I would contest that designation, given its
design principles) still use the old INT 13h API.  But linux is probably under 
more pressure than most to stick with the old broken way of doing things,
since much hyperbole is made from the fact that one can "re-use old 486es by
putting linux on them".  Fixing the linux boot code to work properly would
eliminate this possibility, and the hyperbole, and would have a severe impact
upon linux hobbyists, to boot.

As far as I have been able to find out, there are only three operating systems 
whose boot code uses the new INT 13h extensions.  Two of those are Microsoft
DOS-Windows 98 (and 95 OSR2) and IBM OS/2 Warp Server 5.  (IBM OS/2 Warp
Server 5 contains a new Boot Manager that uses the INT 13h Extensions and that 
can thus boot from any partition anywhere on any disk, for example.)  These
both avoid the problem of gaining a reputation for incompatibility in
different ways.  IBM OS/2 Warp Server is obviously targetted at server-class
hardware, and so is unlikely to be installed on machines with older BIOSes. 
And people to a large degree *expect* server operating systems to be fussier
than workstation ones.  Microsoft DOS-Windows 95 OSR2 and DOS-Windows 98 are
mainly aimed at the pre-load, rather than the retail, market (hence the
designation "OEM Service Release" -- which means that this was something given 
to OEMs to pre-load, rather than a retail product in its own right), and so
can be guaranteed, simply by the way that it is sold, that it will be used on
newer machines.

Of course, in a perfect world, all operating systems would change to use the
new INT 13h Extensions, and this whole problem of 1024 cylinders would go away 
completely.

Indeed, since the INT 13h Extensions don't work in terms of cylinders, heads,
and sectors, making them *the* standard would also simplify the boot-time hard 
disc support that has to be supplied in the BIOS extension ROMs on SCSI Host
Adapter cards, since SCSI natively doesn't use cylinders, heads, and sectors
either.  The mapping from native SCSI to what the BIOS uses would be much
simpler.

 ¯ JdeBP ®

--- FleetStreet 1.22 NR
143/1