🚀 go-pugleaf

brazil@pawl.rpi.edu (Timothy E. Onders) writes:
>In article <20465@watdragon.waterloo.edu> swklassen@tiger.waterloo.edu (Steven W. Klassen) writes:
>>mentioned the 16 meg limit, however, the utilities which came 
>>with it allowed me to make larger partitions.

>Those would be HDX 3.0. HDX 3.0 allows partitions up to 1 GBy (that's
>1024 MB in case you didn't know.), It also allows more partitions per
>physical drive.

Right. Actually it's 3.01; the driver that came with 3.0 had a bug,
though the formatter (HDX) is the same.

>>unreliable for long term use?

Certainly not.

>The only problem, however, is that many disk utility programs ...
>don't know how to handle the larger partitions.

Also right.  Here's the bottom line: when you have a partition larger
than 16MB, the driver creates the partition with 1KB sectors (or more!)
rather than 512-byte sectors, which is the old value.  Cluster size is
still two sectors, whatever size that is.  The disk itself is formatted
with 512-byte sectors, and Rwabs does blocking and deblocking, turning
requests for "one logical sector" into as many physical sectors as
necessary.

The reason for the large-sector implementation is that all GEMDOSes can
handle any (power-of-two) sector size, but not all can handle a cluster
size other than two.

The drawback is that some (most) utilities assume that one sector is
always 512 bytes.  They could have used the Getbpb() call and used the
sector size returned from that, but the original TOS documentation all
but guaranteed 512 bytes forever.  These programs will crash, or worse,
will fail quietly because they read "one sector" into a buffer which is
only 512 bytes long; the Rwabs transfers 1K, clobbering whatever came
after the buffer in memory.  Also, their notion of how big a sector is
(e.g. number of directory entry slots in a directory sector) will be
wrong.

As an additional complication, if you use the "raw mode" (also called
"physical device") bit in the first arg to Rwabs, you get physical
sectors, which are still 512 bytes.  That number is not obtainable as a
variable anywhere, so it'll probably stay at 512.

The hardest-hit class of programs is the "add cache sectors" or  other
disk-caching kind, because it  needs to know how big a buffer to
allocate.  The answer to that question is impossible to compute, so
it's available from the hard-disk driver.  (It's impossible to compute
because it involves a user-preference value which can be patched into
the driver: with removable media you could pop the cartridge and put in
one with larger logical sectors, so the user tells the driver a
minimum for the "maximum sector-size" value to use.)

CACHExxx.PRG from Atari, of course, interrogates the driver and uses
that number correctly.

I'm not publishing the way to interrogate the driver here because I
would not get it right.  The straight scoop is avaiable to developers
in the HDX 3.0 Release Notes document.

The moral is, utilities should always use Getbpb to find out how big
sectors are, how many sectors per cluster, etc., and base all your
other calculations and "constants" on the answers.  If you're adding
GEMDOS buffers or other permanent objects, get the release notes and do
it right.

============================================
Opinions expressed above do not necessarily	-- Allan Pratt, Atari Corp.
reflect those of Atari Corp. or anyone else.	  ...ames!atari!apratt