Roger,
  remember you got me thinking about how to do big discs in FileCore the
other day? Well, here's the result:

Answer: Yes, probably feasible in a not unreasonable amount of time.

How:
  Two parts to change here:
  * The map format needs adjusting to cope better with monster discs. The
        limiting factor in the map is the header field which gives the
        link to the first free fragment in a zone. This is currently 2
        bytes big which limits the disc to being divided into 32766
        pieces. On a 4G disc this will give 128K byte directories! This is
        silly. There's three approaches to sorting this out: stretch the
        field to 4 bytes; deal with the 2-byte first free link specially;
        free links are 15 bits or LinkBits (a field in the disc record)
        long, whichever is the shorter. All of these are practical and
        reasonable - it just needs a day or so of analysis to choose which
        is best. Instant analysis gives: new disc format - awkward; special
        case at start of free lists - awkward; doesn't seem to have obvious
        problems. Once the limit has been removed discs can be divided into
        more parts and so are somewhat more sensible. Unfortunately, this
        means monster maps too:
        LinkBits        Max Map Size    Disc Size
        15              ~64K            ~512M (dirs 16K)
        16              ~136K           ~1G (dirs 17K)
        17              ~288K           ~2G (dirs 18K)
        18              ~608K           ~4G (dirs 19K)
        19              ~1280K          ~8G (dirs 20K)
        Note the map size approximate values are low by about 1%.
        Each halving of the directory size takes you into the next higher
        map size.
  * The conversion from indirect disc addresses (Object ID,offest) to
        direct disc addresses (disc offset) needs to convert to sector
        offsets instead. Indeed, FileCore will always deal with sector
        offsets internally and will convert to these when a DiscOp is given
        and from these if the low level filing system can't cope with sector
        offsets. An analysis is given below of the impact of such a change.

I'd definitely do and finish the first change before the second because it
gives some benefits early (smaller directories) and has less of a global
impact throughout FileCore.


Convert FileCore to big discs:

Externally the world sees big files (up to 4GBytes) and a new low level API
where a filing system (eg SCSIFS) can request to be given sector numbers,
not byte numbers as disc addresses. On these filing systems FileCore_DiscOp
will reject non-sector aligned requests with non-sector transfer amounts.

Internally IndDisc addresses are still passed around with offsets, but get
converted to sector addresses before DiscOp is called.

IndDiscAdd:
bit     use
0-7     sector offset within shared object (usually 0)
8-28    Object ID (21 bits)
29-31   disc number

Routines to be changed (Files with routines listed have been analysed, those
without haven't):

Commands
FileCore15
  GenIndDiscOp - convert to sector shifted
  RetryDriveOp - convert to sector shifted scheme
  DoCachedReadSecs - convert (yuck!)
  DoCachedReadSector - convert (yuck!)
FileCore20
  ReadFsMap - convert
  Mount - convert defect address for sect size
FileCore30
  MoveData - convert to shifted quantities
FileCore31
  NewRandomClaim - convert to shifted form
FileCore32
  DoCompMoves - convert to shifted form
FileCore33
  FindFileFragment - Add offset shifted by sector size
  MapDiscApp - work in sector shifted quantities
  MapPtrToDiscAdd - work in sector shifted quantities
  DiscAddToMapPtr - work in sector shifted quantities
FileCore45
  CriticalWriteFsMap - switch to shifted
FileCore80
  Shifting for DiscOp calling
GenSWIs
Identify
InitDieSvc
ModHand
MsgsStuff
MyMacros

Files which won't change:
DebugOpts
Defns
DevVersion
Errors
FileCore00
FileCore05
FileCore25
FileCore35
FileCore40
FileCore60
FileCore70
Fixes
FormSrvcs
FormSWIs
HelpText
TokenHelp
