Subject: Re: FileCore in 3.6 and new version of OS.
To: None <port-arm32@NetBSD.ORG>
From: Olly Betts <olly@MANTIS.CO.UK>
List: port-arm32
Date: 08/13/1996 09:38:00
In article <9608122125.AA02404@netsu002.oslo.Geco-Prakla.slb.com>, you wrote:
>In other words, there are three different FileCore's out there:

I'm pretty sure that's wrong.

>1) The one in RISC OS 3 up to and including v. 3.5 which only
>supports up to 512MB.

Correct.  It uses a 32 bit word to store the disc address, with the top 3
bits containing the drive number.  That leaves 29 bits for the offset into a
given disc.  This is in bytes, so that's 2^9 MB = 512MB.

>2) The one in RISC OS 3 v. 3.6 which supports up to 4GB.
>3) The new one that is soon to be released and that was
>beta-tested by Clan members.

I think you'll find these are the same creature, but in two different modes
of operation.

Hopefully I've remembered this correctly:

What has been done is to remove the drive number from the disc address,
which provides an extra 3 bits, and increases the possible disc size to 4GB.
However, because of potential problems with disc addresses with the top bit
set (the original FileCore code didn't need to worry about signed disc
addresses), Acorn suggested caution with discs above 2GB.  Not sure if that
was just for the Clan beta, or in general.

There's also support for "big discs", where the disc address is in multiples
of (I think) the LFAU, not bytes (LFAU is Large File Allocation Unit).  This
allows for enormous (by today's standards anyway) discs, though the bigger
the LFAU, the more space is wasted by "rounding up" of file sizes.  FileCore
can put small files into spare space at the end of LFAUs, but this can only
help up to a point.

>I am sorry about the confusion I have caused, and I hope
>that this settles the issue.

Nope, I think you just muddied the waters further.

Olly
-- 
cool wet grass  cool wet grass  cool wet grass  cool wet grass  cool wet grass