FileCore Overview (changes)
Showing changes from revision #7 to #8:
Added | Removed | Changed
FileCore
» Technical Details
» Overview
Overview
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.
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.
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
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.
Disc Formats
Logical Layout
| Format | Disc Type | Map | Zones | Directories | Boot Block | 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 | Yes1 | ✔ |
| ADFS D | HDD/SSD | Old | - | New | Yes | No2 |
| ADFS E | HDD/SSD | New | ≥1 | New | Yes | ✔ |
1 The Boot Block is required for ADFS F formatted floppy discs to specify which zones holds the map
2 Not supported on RISC OS 3.5 onwards
Physical Layout
| Format | Disc Type | Density | Sectors/Track | Bytes/Sector | Heads | 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 |
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:
| Header Value | 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 |
Track Layout
The Track layout consists of several discrete pieces of information. These are detailed in the table below:
| 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:
| Format | Disc Type | Gap 1 (side 0) | Gap 1 (side 1) | Gap 3 | 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 |
Sector Layout
| 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.
Disc Maps
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:
| Map | Information Stored | Compaction Required | Recovery Story |
|---|---|---|---|
| Old | Free space | Yes | From directories |
| New | Space allocation | No | Two copies stored |
The type of map used is dependent on the format of the disc. These are detailed here.
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:
| Disc Record | Max Number of Discs | Max Size of Disc | Max Size of FS | Max Number of Disc Objects |
|---|---|---|---|---|
| Small | 4 | 512MB | 2GB | 215 – 2 (32,766) |
| Large | 4 | 4GB | 8GB | 215 – 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.
Social
and
ROOL Store
Buy RISC OS Open merchandise here, including SD cards for Raspberry Pi and more.