ADFSBuffer 2.99 KB
Newer Older
Neil Turton's avatar
Neil Turton committed
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113
ADFSBuffers
-----------

These are my general notes on ADFSBuffers support (FileCore80) as I attempt to
understand the code within (here be demons!).  I intend to list every ADFSBuffers 
function that I examine here along with what changes are required.  I'll also list 
those functions which I consider to not need updating at all.  I'll also generate 
some notes of general ADFSBuffers working.  Hopefully this documentation should be
useful to others in the future.

Buffers
-------

Each buffer is a 1K buffer.  It can however be considered
as two sub-buffers of 512 bytes or four sub-buffers of
256 bytes.

Processes
---------

Each 'process' contains a process block which tells us what this
process is actually doing.  Tacked onto the end of the process is
a scatter list - everyone likes scatter lists don't they?  Luckily
for us, pair extension is disabled.  That is, the scatter list never
gets extended just when the driver least expects it, as it causes
all sorts of headaches - allegedly, of course.

Process Scatter Lists
------- ------- -----

As mentioned above, the process scatter lists cannot be extended
by adding more pairs.  Indeed, enough pairs must be available
in each process to satisfy the maximum number of buffers that
can be in use.  Thus each process has a scatter list upto
MaxFileBuffers in length.  Each scatter list entry must correspond
to either a buffer or a direct transfer.  A scatter list entry
cannot cover multiple buffers as data for adjacent buffers in
a transfer will not conjoin.  Does this apply for sub-buffers?

DiscAdjust
----------

This seems to be an adjustment offset which would generally appear
to be added to any offset within a file to give the actual disc
address for that offset - thus DiscAdjust only remains valid
when working within a single fragment.  It is added to the offset 
into a file to give the disc address corresponding to that offset.
I'm thinking that DiscAdjust must be always sector aligned.  If
this assumption breaks I'll have fun.

The next three sections list what needs modified.

Functions which will need modified:
--------- ----- ---- ---- --------

FileFrag						... SBP: done
BackGroundFileCacheOp					... SBP: done
GetBytesEntry						... SBP: done
PutBytesEntry						... SBP: done
BackGroundOps						... SBP: done


Functions which will not need modified:
--------- ----- ---- --- ---- --------

FindSubBuf
UpdateProcess
GetPutCommon
FcbCommon
ReadAheadCommon
R3LoadNewMap
BufsToRam
BackGroundTidyUp
ReduceWriteBehind
AddBuffer
SkipEmpty
SkipWriteBehind
BackwardsSkipWriteBehind
DefFileFrag
FindSubBuf
UpdateBufState
ClaimFileCache
ReleaseFileCache
IncReadAhead
ExtendUp
ExtendDown
Flush
TestFileCacheGrowable
RestartCheck
FloppyOpDone
WinnieOpDone
TickerEntry
UpdateProcesses
ScanBuffers
FindFreeBuf
EmptyBuffers
UnlinkAllocChain
LinkAllocChain
UnlinkFileChain
LinkFileChain
LessValid
MoreValid
WaitForControllerFree
DiscWriteBehindWait
DriveWriteBehindWait
LockDisc
FindDisc
FreeFcb
ClaimController
ReleaseController
AddPair
FragLeft
DefFileFrag (veneer to FileFrag)