h6. [[FileCore]] h6(. » [[FileCore Technical Details|Technical Details]] h6((. » Overview h2(#overview). Overview h3(#intro). Introduction FileCore is a module that provides all the necessary entry points for [[FileSwitch]] that any other filing systems does, but unlike them, does not control hardware. FileCore issues calls to secondary filing system modules that in turn communicates and controls the hardware. h3(#basics). Basics of FileCore * FileCore can be thought of as the parent module, and the secondary module that provides access to the hardware as the child module * Secondary modules register themselves as part of the filing system with FileCore using a SWI Call, [[FileCore_Create]] * Secondary modules provides a pointer to FileCore to a table that has information about the hardware, and entry points to low-level routines in the module * FileCore communicates with the module using these entry points When a secondary module registers with FileCore, it creates a new instantiation of itself, and returns a pointer to its workspace. Your module then uses this to identify itself on future calls to FileCore. h3(#reg). Registering a Secondary Module When a new module is registered with FileCore, it reduces the complexity and coding effort required by a developer, as most of the functionality is provided by FileCore itself. A secondary module must, however, provide: * Low-level routines to access the hardware * *Command that can be used to select the filing system. e.g. [[*ADFS]] * SWI interface In addition, a secondary module may provide additional * Commands that provides extra functionality to the system h3(#swi). SWI Interface provided by a Secondary Module The SWI Interface that a secondary module must provide is usually quite simple. It is very common for FileCore-based filing systems to provide SWI Calls that functionally are a subset of those provided by FileCore itself. They call FileCore SWIs, ensuring they identify which Filing System they are. So unless a lot of additional SWI Calls are required, secondary modules do little more than provide low-level routines that control the hardware. [[RamFS]] implements all its SWI Calls like this, while [[ADFS]] implements most of them like this. h2(#discformats). Disc Formats h3(#laylogic). Logical Layout table(bordered). |_<^{width:8em}. Format |_<^{width:8em}. Disc Type |_<^{width:6em}. Map |_<^{width:6em}. Zones |_<^{width:6em}. Directories |_<^{width:6em}. Boot Block |_<^{width:12em}. FileCore Supported | |<^. ADFS L |<^. Floppy Disc |<^. Old |<^. - |<^. Old |<^. No |<^. ✔ | |<^. ADFS D |<^. Floppy Disc |<^. Old |<^. - |<^. New |<^. No |<^. ✔ | |<^. ADFS E |<^. Floppy Disc |<^. New |<^. 1 |<^. New |<^. No |<^. ✔ | |<^. ADFS F |<^. Floppy Disc |<^. New |<^. 4 |<^. New |<^. Yes[1] |<^. ✔ | |<^. ADFS D |<^. HDD/SSD |<^. Old |<^. - |<^. New |<^. Yes |<^. No[2] | |<^. ADFS E |<^. HDD/SSD |<^. New |<^. ≥1 |<^. New |<^. Yes |<^. ✔ | fn1. The Boot Block is required for ADFS F formatted floppy discs to specify which zones holds the map fn2. Not supported on RISC OS 3.5 onwards h3(#layphysical). Physical Layout table(bordered). |_<^{width:8em}. Format |_<^{width:8em}. Disc Type |_<^{width:6em}. Density |_<^{width:6em}. Sectors/Track |_<^{width:6em}. Bytes/Sector |_<^{width:6em}. Heads |_<^{width:6em}. Storage | |<^. ADFS L |<^. Floppy Disc |<^. Double |<^. 16 |<^. 256 |<^. 1 |<^. 640K | |<^. ADFS D |<^. Floppy Disc |<^. Double |<^. 5 |<^. 1024 |<^. 2 |<^. 800K | |<^. ADFS E |<^. Floppy Disc |<^. Double |<^. 5 |<^. 1024 |<^. 2 |<^. 800K | |<^. ADFS F |<^. Floppy Disc |<^. Quad |<^. 10 |<^. 1024 |<^. 2 |<^. 1.6M | |<^. ADFS D |<^. HDD/SSD |<^. - |<^. - |<^. - |<^. - |<^. 512MB | |<^. ADFS E |<^. HDD/SSD |<^. - |<^. - |<^. - |<^. - |<^. 4GB | h4(#layheader). Header Information As detailed in the Physical Layout table above, there are two possible values for the Header. The Header value is used to determine the order of tracks stored on the disc medium. The table below details the two different Header Types: table(bordered). |_<^{width:8em}. Header Value |_<^{width"8em}. Header Type |_<^. Meaning | |<^. 1 |<^. Sequential |<^. The logical order of tracks are sequenced sequentially on one side of the disc, followed by those on the other side | |<^. 2 |<^. Interleaved |<^. The logical order of tracks alternate between sides of the disc, one track at a time | h4(#laytrack). Track Layout The Track layout consists of several discrete pieces of information. These are detailed in the table below: table(bordered). |_<^{width:8em}. Track Element |_<^. Meaning | |<^. _gap4b_ |<^. This is the gap between the mechanical index pulse and the magnetic index mark | |<^. _ID_ |<^. This is the magnetic index mark | |<^. _gap1_ |<^. This is the gap between the index mark and the first sector | |<^. _sector_ |<^. This is the sector, which in turns contains more information (as detailed in the following table) | |<^. _gap3_ |<^. This is the gap between sectors | |<^. _gap4a_ |<^. This is the gap between the last sector and the index pulse | The magnetic index mark and the preceding gap4b are optional. If absent, _gap1_ is therefore the gap between the mechanical pulse and the first sector. *Note:* The presence or absence of the magnetic mark must never be relied upon. The size of _gap1_ and _gap3_ change between formats, whilst the other sizes remain constant. The gap sizes vary in bytes and the sector skew in sectors. The following table details the gap sizes by Format of Disc: table(bordered). |_<^{width:6em}. Format |_<^{width:6em}. Disc Type |_<^{width:6em}. Gap 1 (side 0) |_<^{width:6em}. Gap 1 (side 1) |_<^{width:6em}. Gap 3 |_<^{width:6em}. Sector Skew | |<^. ADFS L |<^. Floppy Disc |<^. 42 |<^. 42 |<^. 57 |<^. 0 | |<^. ADFS D |<^. Floppy Disc |<^. 32 + 271 |<^. 32 + 0 |<^. 90 |<^. 0 | |<^. ADFS E |<^. Floppy Disc |<^. 32 + 271 |<^. 32 + 0 |<^. 90 |<^. 0 | |<^. ADFS F |<^. Floppy Disc |<^. 50 |<^. 50 |<^. 90 |<^. 2 | h4(#laysector). Sector Layout table(bordered). |_<^{width:8em}. Sector Element |_<^. Meaning | |<^. _sector ID_ |<^. This is the ID that specifies the sector number | |<^. _gap2_ |<^. This is the gap that is used to accommodate the variations in mechanical speeds of the underlying hardware | |<^. _sector data_ |<^. This is the actual data that is to be read/written to the disc | The ID is separated from the sector data because of the time taken to switch a Drive from 'Read' mode to 'Write' after the ID has been located on the disc. By ensuring they are separated allows the mechanical drive to handle the time required for this to happen. h2(#maps). Disc Maps h3(#mapoverview). Types of Maps supported by FileCore A disc has a section of information defined as a Map. It controls the allocation of the disc to the files and directories. [[FileCore]] currently understands two different types of Disc Maps: table(bordered). |_<^{width:8em}. Map |_<^{width"8em}. Information Stored |_<^. Compaction Required |_<^. Recovery Story | |<^. _[[FileCore Disc Map Old|Old]]_ |<^. Free space |<^. Yes |<^. From directories | |<^. _[[FileCore Disc Map New|New]]_ |<^. Space allocation |<^. No |<^. Two copies stored | The type of map used is dependent on the format of the disc. These are detailed "here":#laylogic. h3(#discrecord). Types of Disc Records supported by FileCore The disc record is used to specify numerous attributes about the disc, including many of the terms we have already discussed. The format of the disc record is highly detailed and [[FileCore]] currently supports two different types: table(bordered). |_<^{width:8em}. Disc Record |_<^{width:12em}. Max Number of Discs |_<^{width:12em}. Max Size of Disc |_<^{width:12em}. Max Size of FS |_<^. Max Number of Disc Objects | |<^. _[[FileCore Disc Record Small|Small]]_ |<^. 4 |<^. 512MB |<^. 2GB |<^. 2[^15^] - 2 (32,766) | |<^. _[[FileCore Disc Record Large|Large]]_ |<^. 4 |<^. 4GB|<^. 8GB |<^. 2[^15^] - 2 (32,766) | Each Disc record type is detailed in it's own page that can be accessed by clicking on links in the table above.