Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!wuarchive!decwrl!sun-barr!newstop!sun!imagen!atari!apratt
From: apratt@atari.UUCP (Allan Pratt)
Newsgroups: comp.sys.atari.st
Subject: Re: 16 meg partition limit
Message-ID: <2039@atari.UUCP>
Date: 13 Feb 90 23:39:46 GMT
References: <2947@water.waterloo.edu> <1325@crash.cts.com> <20465@watdragon.waterloo.edu> <1990Feb6.223637.15845@sj.ate.slb.com> <8%90M%@rpi.edu>
Organization: Atari Corp., Sunnyvale CA
Lines: 36

brazil@pawl.rpi.edu (Timothy E. Onders) writes:

>In article <1990Feb6.223637.15845@sj.ate.slb.com> greg@sj.ate.slb.com (Greg Wageman) writes:
>>
>>What Atari has changed, I believe, is to treat the "recno" parameter
>>as an UNSIGNED int, with a range of 0 to 65535, and consequently a
>>32Mb limit.

Wrong.

>Actually, the logical sector size was also increased [...]

Right.  The logical sector size is now "large enough so the partition
can be represented by 32767 sectors," which is to say 512 bytes
for <16MB, 1024 bytes for <32MB, etc. all the way up to 8K/sector
or more.

This means BIG TROUBLE for any program which does Rwabs() calls and
expects to get 512 bytes per sector: you should use Getbpb() to FIND
OUT how big sectors are, rather than assuming any one value.  It's also
BIG TROUBLE for programs which add buffers to GEMDOS via the "bufl"
system variables: it's hard (not impossible) to tell how large each
buffer must be.  Get the AHDI 3.00 Release Notes from Atari (available
to developers) for the grubby details.

>>the old Dfree()/FAT search bug rears up

There is no such bug; I think you mean "really horribly slow implementation."

>>and file creation takes nearly forever.

That part is true.  So take your own advice and get TOS 1.4!

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