Partitions

The RISC OS filecore format (as I understand it) makes the assumption that it is the only show in town. It therefore starts at a fixed address on disc (which I think is either &E00 or CHS[0,0,8], where address &000 or CHS[0,0,1] is thus not looked at by RISC OS. A sensible decision since this leaves the MBR partition table, which is 512 bytes, untouched and ignored. It puts its map half way into the disc space it uses which, I think, meant that on double-sided drives it was on the same track as the beginning but on the other side.

On a multi partition disc it is easy to create a MBR that simply protects the filecore partition from being trampled on by other operating systems. The MBR partition table is placed at address &00 = CHS[0,0,1] = LBA 000. The LBA size may be 512b or (since 2010) 4k.

Now (since the late 1990s) we also have a GPT partition table which resides at either LBA 001 to LBA 033 (on a 512b sector disc) or LBA 001 to LBA 005 (on a 4k sector disc). There is often a ‘protective’ MBR at LBA 000 that says the whole disc is partition type &EE. Does this mean that the current filecore format will, at some point, trample on the GPT? Can filecore trample on the MBR on a 4k sector disc (it does not appear to)?

Is the first stage of partition support simply to create a MBR partition table showing a type ‘AD’ partition covering the extent of the filecore partition when using HForm to format a disc in the first place? Or to add this as an option? The second step might be to open a FAT partition if one exists using an ADJUST click on the icon bar filer icon.

Not sure, maybe I’m wrong… That’s the first things that came to my mind ;-)

Here is a “screenshot” how EADFS works. 4 Filecore partitions I was using on my A4.

Second “remark” is PartFC by Anton Reiser.Creates a second FAT partition behind the Filecore one for bigger devices. The Partition you can mount with FAT32FS.

On my NVMe drive I use just three partitions:

RISC OS sees the filecore partition and Linux sees the next two partitions as ‘/boot’ and ‘/’

which I think is either &E00 or CHS[0,0,8]

The FileCore info always starts at &C00 regardless of sector size, and the disc record starts at offset &1C0 within that.

we also have a GPT partition table which resides at either LBA 001 to LBA 033 (on a 512b sector disc) or LBA 001 to LBA 005 (on a 4k sector disc). There is often a ‘protective’ MBR at LBA 000 that says the whole disc is partition type &EE

There’s always an MBR at LBA 0, which must include a protective MBR entry for the GPT partitioning. LBA 1 contains the GPT header, followed by the partition entries – the number of which is specified in GPT header, so it can be of any length.

Does this mean that the current filecore format will, at some point, trample on the GPT?

No, HForm and Partition Manager both map out the MBR/GPT area of the disk so FileCore can’t overwrite them.

Can filecore trample on the MBR on a 4k sector disc

The FileCore disc record is in the middle of LBA 0 on 4Kn, so FileCore must perform a read/write when writing the disc record to avoid corrupting the MBR. I think that was covered when 4Kn support was added.

Is the first stage of partition support simply to create a MBR partition table showing a type ‘AD’ partition covering the extent of the filecore partition when using HForm to format a disc in the first place?

That depends if MBR or GPT is used. With GPT it would create a regular GPT partition using the FileCore GUID. For MBR it would be a type AD entry…

However, that’s complicated by current “full-disc” FileCore which starts at LBA 0 – it’s not possible to add a valid partition entry to either MBR or GPT which covers current FileCore, so although an entry is added to cover everything past the MBR/GPT tables, it’s technically not valid as the partition entry starts part-way into the “full-disc” FileCore area.

When MBT/GPT partition support is officially added, that will complicate things for existing drive support.

The solution I use in Partition Manager is to first check for a full-disc FileCore, then check for MBR/GPT and essentially overlay the MBR/GPT partitions over FileCore – which you can see visually on your NVMeFS/SDFS drives in the screenshot above, where the MBR partitions are shown embedded within the FileCore drive.

For the sake of simplicity, PM just assumes the whole drive is FileCore so will incorrectly show partitions that come after the FileCore area as being within the FileCore drive – at some point, I’ll fix that.