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):

SBP: Those files marked with * haven't been *fully* analysed and thus
more work will be needed on determining what requires changing.  Also
note that I've found routines which aren't mentioned below which I've
found need changed.

Commands*
  DoDefect - convert					... SBP: done
  DoDefectMapOut - convert				... SBP: done
  DismountDisc - convert				... SBP: done
  DoVerify - convert					... SBP: done
  DoBackup - convert					... SBP: done
  DoMap - covnert					... SBP: done - but need to widen field?
  DoCheckMap - convert					... SBP: done
  
FileCore15
  GenIndDiscOp - convert to sector shifted		... SBP: done
  RetryDriveOp - convert to sector shifted scheme	... SBP: done
  DoCachedReadSecs - convert (yuck!)			... SBP: done
  DoCachedReadSector - convert (yuck!)			... SBP: done
  
FileCore20
  ReadFsMap - convert					... SBP: done
  
FileCore30
  MoveData - convert to shifted quantities		... SBP: done
  FindErrBlock - generate error properly		... SBP: done
  
FileCore31
  NewRandomClaim - convert to shifted form		... SBP: done
  
FileCore32
  DoCompMoves - convert to shifted form			... SBP: simple vsn
  								 done
FileCore33
  FindFileFragment - Add offset shifted by sector size	... SBP: done
  MapDiscApp - work in sector shifted quantities	... SBP: done
  MapPtrToDiscAdd - work in sector shifted quantities	... SBP: done
  DiscAddToMapPtr - work in sector shifted quantities	... SBP: done
  
FileCore45
  CriticalWriteFsMap - switch to shifted		... SBP: done
  
FileCore80*
  FileFrag						... SBP: done
  BackGroundFileCacheOp					... SBP: done
  GetBytesEntry						... SBP: done (but buggy)
  PutBytesEntry						... SBP: done
  BackGroundOps						... SBP: done
  
GenSWIs*
  DoSwiDiscOp						... SBP: done
  add DoSwiSectorDiscOp					... SBP: done
  DoSwiFloppyStructure					... SBP: done
  
Identify*
  SanityCheckBadBlockList - sector shifted quantities	... SBP: done
  SanityCheckEDiscRecord - alignment of transfers to
                           sector boundary		... SBP: done
FormSWIs*
  LayoutFreeSpaceMap - sector vs byte addrs		... SBP: done
  MapOutADefect - sector vs byte addrs			... SBP: done
  LayoutRootDir - sector vs byte addrs			... SBP: done
  
FileCore35

FileCore60*
  DoOsFunObjectAtOffset					... SBP: done
  MarkObjMappedIn					... SBP: done

Files which won't change:
InitDieSvc
ModHand
MsgsStuff
MyMacros
DebugOpts
Defns
DevVersion
Errors
FileCore00
FileCore05
FileCore25
FileCore40
FileCore70
Fixes
FormSrvcs
HelpText
TokenHelp

SBP: Additional Comments
------------------------

DoReadCachedSecs and DoCacheReadSectors are sometimes called by
FileCore (using XFileCore_DiscOp) with non-aligned disc addresses.
This behaviour will have to change with the advent of sector-based
disc addresses; all start addresses will now have to be properly
aligned.
