Commits (1)
  • Robert Sprowson's avatar
    Docs update · 04030b45
    Robert Sprowson authored
    Having disassembled various old copies of FileCore, make a note of the most likely reason it declares with fsinfo_dontuseload to maximise the use of background transfer buffers.
    Not tagged.
......@@ -60,7 +60,7 @@ When idle FileCore will look to see if any more background work could be
started. If writes are possible the first buffer (attached to the Fcb) will
be picked and using its BufFileOff this is mapped to a fragment. More buffers
will be considered (using SkipWriteBehind and BackwardsSkipWriteBehind) to
see how many buffers cover the corresponding fragment. These are then inserted
see how many buffer s cover the corresponding fragment. These are then inserted
in one go onto a scatter list and consumed.
Later, the above steps will repeat. Due to the way the buffers are attached
to the Fcb this results in writing backwards through the file as it happens.
......@@ -96,3 +96,16 @@ in sync, the buffer address can be recreated by just adding RamAdjust.
DiscAdjust works the same, only it's a disc address rather than RAM.
I'm thinking that DiscAdjust must be always sector aligned. If
this assumption breaks I'll have fun.
OS_File Load
At least as far back as FileCore 2.41, and throughout all CVS history, FileCore
has registered with FileSwitch with bit 20 (fsinfo_dontuseload) of the FS
info word set.
This is rationalised as being so that the GetBytes entry gets used in the
hope that some of the request can be met from the read ahead cache.
The code to handle OS_File 255 (DoOsFileLoad in FileCore45.s) bypasses the
read ahead cache, using IndDiscOp directly, but the function is never called.