Tim,
have you had a look at Simon's DIY Toolkit, Volume D - FFormat. He describes
the interleaving and sector allocation in one (or more) of the doc files. It
looks like the algorithm is quite simple - find a free slot in the map, use
the interleave to select the sectors on disc and slap the data into the
appropriate place. (If required, allocate more space for the directory as
well !) Everything is done in 3 sector multiples so a one byte file 'costs'
1.5k instead.
I did some investigations years ago - here's what I found .....
1. The map is kept in 3 sectors. It never gets any bigger.
2. The map starts at absolute position 1 on the disc - which seems to number
form 1 rather than zero !
3. There is system info in bytes 1 to 96 of the map. (counting from 1)
4. Bytes 42 and 43 define where the next two sectors of the map live, they
hold the absolute position of the beginning of the map sector being read.
5. Bytes 97 onwards hold (on a DSDD floppy) details of 479 allocation units
on the disc, each is 3 bytes long and holds the file number that the
allocation unit belongs to.
6. If the file number high byte is a special file, it will be :
00 = Directory sector
F8 = Sector Map
FC = Pending deletion
FD = Unused allocation unit
FE = bad block
FF = block doesn't exist
anything else is a file number. The file number is split into two groups of
12 bits. The highest 12 bits being the file number and the low 12 bits being
the block number of this allocation unit inside the file. (Numbering from
zero)
So how to find a block on disc to put some data into ?
First extract some constant values from the map :
SectorsPerTrack = The word at map bytes 27 and 28
BlocksPerTrack = (The word at map bytes 29 and 30) / 3
TrackOffset = The word at map bytes 39 and 40
LogicalToPhysicalMap = the bytes from map byte 41 to map byte 58 inclusive.
(18 bytes.)
1. Scan the map to find a free allocation unit. Call it 'unit'.
2. Track = Unit DIV BlocksPerTrack
3. BlockOnTrack = Unit MOD BlocksPerTrack
4. LogicalOffset = (BlockOnTrack * 3) +1 (this is the offset into the
logical to physical map on the map of this disc.)
5. LogicalToPhysical = 3 bytes in map from LogicalOffset. This maps our 3
sectors per allocation unit and is why we need the three bytes.
6. Side = (LogicalToPhysical(1) > 128)
7. If Side = 1 then subtract 128 from all 3 bytes in LogicalToPhysical.
8. SectorOnTrack = LogicalToPhysical (Array of 3 bytes again !)
9. For x = 1 to 3
SectorOnTrack(x) = (SectorOnTrack(x) + (Track * TrackOffset)) MOD
SectorsPerTrack
PhysicalDiscAddress(x) = SectorOnTrack(x) + (Side * 256) + (Track *
65536) +1
end for x.
So at this point we have converted the free allovation unit number into a
set of 3 physical disc addresses in the array PhysicalDiscAddress. Simply
write each 512 byte sector to these addresses.
Hope this helps.
Norman.
PS. This info will be appearing sometime on my QDOSMSQ information web site
at http://www.dunbar.cwc.net/qdos/qdos.html
----------------------------------------------------------------------------
----
Norman Dunbar EMail: [EMAIL PROTECTED]
Database/Unix administrator Phone: 0113 289 6265
Lynx Financial Systems Ltd. Fax: 0113 201 7265
URL: http://www.LynxFinancialSystems.com
----------------------------------------------------------------------------
----
-----Original Message-----
From: Timothy Swenson [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, December 27, 2000 10:02 PM
To: [EMAIL PROTECTED]
Subject: [ql-users] File System Question
I've been reading some QDOS documetation on the filing system. Most of it
talks about how information is stored on floppy, in a static sense. Nothing
talks about the algorithm used for determining where a file will reside on
disk
(to limit fragementation).
Does anybody know about the algorithms used by QDOS/SMSQ/E in determining
file
system allocation?
Tim Swenson
